Safety Best Practices

Production AI systems need layered safety: input controls, moderation, user-level abuse tracing, output review, and a way for users to report problems. The OpenAI safety guidance maps cleanly to AvalAI because AvalAI supports OpenAI-compatible request shapes through https://api.avalai.ir/v1.

Layer Guardrails

• Redact secrets early: Enable AvalAI Guardrails to detect API keys, tokens, and credentials before content reaches the model.
• Know the scan scope: Guardrails scan supported payload fields such as messages, input, and prompt on compatible routes including /v1/chat/completions, /v1/responses, /v1/messages, and /v1/completions.
• Keep secrets out anyway: Guardrails reduce risk, but production apps should still avoid sending credentials, private keys, or sensitive customer data to any model.

{
  "messages": [
    {
      "role": "user",
      "content": "Here's my question about the API..."
    }
  ],
  "guardrails": [
    "hide-secrets"
  ]
}

Defend Against Prompt Injection and Tool Abuse

Prompt injection happens when untrusted text tries to override your instructions or steer downstream tool calls. Treat user input, retrieved documents, webpage text, tool outputs, and uploaded files as untrusted unless your application validated them.

• Keep untrusted text out of instructions: Put user-provided or retrieved content in input or message content, not in high-priority developer/system instructions.
• Separate data from commands: Label retrieved snippets as reference material and instruct the model not to follow instructions found inside that material.
• Use structured boundaries: Prefer Structured Outputs for handoffs between workflow steps so attackers cannot smuggle free-form commands through intermediate text.
• Validate tool calls twice: Check arguments before execution and check tool results before feeding them back to the model. For side effects such as writes, refunds, deletes, shell commands, or database changes, require human approval.
• Expose least-privilege tools: If a hosted tool or MCP surface is not enabled for your AvalAI route, keep the capability in your backend and expose only a narrow function tool with validated parameters.
• Evaluate adversarial paths: Add prompt-injection, jailbreak, malicious document, and unsafe tool-call cases to Evaluations, then run them before changing prompts, models, retrieval, or tool schemas.

Moderate Inputs and Outputs

• Use /v1/moderations: Classify user input before generation and model output before showing it to users. omni-moderation-latest supports text and images; text-only aliases include text-moderation-latest and text-moderation-stable.
• Treat scores as signals: Start with flagged, then inspect categories, category_scores, and category_applied_input_types for routing, audit logs, and human-review queues.
• Inline moderation when supported: OpenAI-compatible /v1/responses and /v1/chat/completions may support a top-level moderation object that returns input and output moderation scores with the generation. If AvalAI support is not enabled for the selected route, call /v1/moderations separately.
• Handle streaming carefully: Inline moderation scores for generated content arrive only after the full output is available, not with partial stream deltas.
• Know the tool boundary: Moderation can cover tool-call arguments and tool outputs when they are included as conversation content; it does not moderate tool names, tool descriptions, tool schemas, or response-format schemas.
• Expect model updates: Custom thresholds based on category_scores should be evaluated periodically because moderation models may improve over time.

Workflow	Use when	AvalAI pattern
Standalone moderation	You need to classify text or image input without generating a response	Call POST /v1/moderations before or after generation
Inline generated-content moderation	You need generation and moderation scores together	Add moderation: {"model": "omni-moderation-latest"} to /v1/responses or /v1/chat/completions when enabled
Human review	The output is high-risk, borderline, or business-critical	Queue the request with flagged, category scores, user ID hash, and transcript context

Design Age-Sensitive Experiences

If your product may be used by minors, add safeguards before launch rather than relying on model behavior alone. OpenAI's under-18 guidance is a useful baseline, but AvalAI deployments must also verify the selected route, provider, data-retention posture, and local legal requirements.

• Confirm the audience: decide whether the product is for adults only, mixed-age users, or minors, then document age-gating or age-assurance requirements.
• Use age-appropriate disclosures: explain that the user is interacting with AI, what the system can and cannot do, and how to report unsafe or uncomfortable interactions.
• Tighten content controls: use moderation, allow/deny topic lists, shorter generation limits, and human escalation for high-risk categories.
• Protect young users' data: avoid collecting unnecessary personal data, do not send raw child identifiers, and require a verified retention/compliance path before processing regulated minor data.
• Check child-privacy rules early: if your product may serve children, verify whether local law or customer policy prohibits processing personal data for users under a specific age, and keep those requirements outside prompt-only enforcement.
• Monitor and escalate: define who reviews high-risk conversations, how quickly they respond, and when access should be limited or suspended.

For strict retention or regulated-data scenarios, pair this section with Data Controls before accepting production traffic.

Use Safety Identifiers

Send a stable, privacy-preserving safety_identifier for products where individual end users interact with a model. Hash usernames, email addresses, or internal user IDs; use a session ID for anonymous previews. Safety identifiers do not automatically carry across APIs or sessions, so send the same stable value on each relevant request.

Python

import hashlib
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AVALAI_API_KEY"],
    base_url="https://api.avalai.ir/v1",
)


def safety_identifier(raw_user_id: str) -> str:
    return hashlib.sha256(raw_user_id.encode("utf-8")).hexdigest()[:64]


response = client.chat.completions.create(
    model="gpt-5.5",
    messages=[{"role": "user", "content": "This is a safety test."}],
    max_completion_tokens=50,
    safety_identifier=safety_identifier("user_123"),
)

print(response.choices[0].message.content)

JavaScript

import crypto from "node:crypto";
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.AVALAI_API_KEY,
  baseURL: "https://api.avalai.ir/v1",
});

const safetyIdentifier = crypto
  .createHash("sha256")
  .update("user_123")
  .digest("hex")
  .slice(0, 64);

const response = await client.chat.completions.create({
  model: "gpt-5.5",
  messages: [{ role: "user", content: "This is a safety test." }],
  max_completion_tokens: 50,
  safety_identifier: safetyIdentifier,
});

console.log(response.choices[0].message.content);

Bash

curl https://api.avalai.ir/v1/chat/completions \
  -H "Authorization: Bearer $AVALAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "messages": [
      { "role": "user", "content": "This is a safety test." }
    ],
    "max_completion_tokens": 50,
    "safety_identifier": "9f86d081884c7d659a2feaa0c55ad015"
  }'

Responses API version using the same safety identifier pattern.

Use this version when the selected model supports /v1/responses. messages moves to input, max_completion_tokens becomes max_output_tokens, and the final text is read from response.output_text.

Python

import hashlib
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AVALAI_API_KEY"],
    base_url="https://api.avalai.ir/v1",
)

safety_identifier = hashlib.sha256(b"user_123").hexdigest()[:64]

response = client.responses.create(
    model="gpt-5.5",
    instructions="You are a helpful assistant.",
    input="This is a safety test.",
    max_output_tokens=50,
    safety_identifier=safety_identifier,
)

print(response.output_text)

JavaScript

import crypto from "node:crypto";
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.AVALAI_API_KEY,
  baseURL: "https://api.avalai.ir/v1",
});

const safetyIdentifier = crypto
  .createHash("sha256")
  .update("user_123")
  .digest("hex")
  .slice(0, 64);

const response = await client.responses.create({
  model: "gpt-5.5",
  instructions: "You are a helpful assistant.",
  input: "This is a safety test.",
  max_output_tokens: 50,
  safety_identifier: safetyIdentifier,
});

console.log(response.output_text);

Bash

curl https://api.avalai.ir/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AVALAI_API_KEY" \
  -d '{
    "model": "gpt-5.5",
    "input": "This is a safety test.",
    "instructions": "You are a helpful assistant.",
    "max_output_tokens": 50,
    "safety_identifier": "9f86d081884c7d659a2feaa0c55ad015"
  }'

• messages → input
• system message → instructions or a developer item
• choices[0].message.content → response.output_text
• user → safety_identifier for abuse monitoring; use prompt_cache_key separately for cache bucketing.

Protect Keys and Sessions

• Rotate exposed keys immediately: If an AvalAI API key is logged, committed, shared with a client app, or suspected of misuse, revoke it and issue a new key before continuing traffic.
• Keep safety IDs private: Send hashed or opaque identifiers, not emails, phone numbers, national IDs, or raw database primary keys.
• Link safety and observability: Store request_id, safety_identifier, moderation result, model, route, and user-facing action so abuse reviews can be traced without exposing raw personal data.
• Realtime sessions need explicit handling: Safety identifiers do not automatically carry between APIs or sessions. For Realtime-compatible routes, bind the same stable user hash through the route-supported parameter, header, or server-side session metadata when available.

Red Team and Evaluate

• Test representative and adversarial inputs: Include normal usage, prompt injection attempts, off-topic redirects, malformed payloads, and users trying to break policy boundaries.
• Use evals plus red teaming: Evals measure expected behavior; red teaming probes misuse, jailbreaks, and unexpected high-risk interactions.
• Consider Promptfoo: OpenAI points to Promptfoo as an open-source option for LLM red teaming workflows. Use it only against systems and assets you own or are authorized to test.
• Keep a release playbook: See Red Teaming AI Applications for a practical AvalAI smoke-test dataset, Chat/Responses harness, and triage checklist.

Add Human and Product Controls

• Human-in-the-loop: Require review before high-stakes outputs are used, especially for medical, legal, financial, security, or code-generation workflows.
• Constrain inputs and outputs: Prefer dropdowns, validated IDs, retrieval from trusted content, and tight max_output_tokens over open-ended free-form generation.
• Know your customer: Require login for risky products and consider stronger verification for abuse-prone use cases.
• Let users report issues: Provide a monitored report path for unsafe, incorrect, or abusive outputs.
• Communicate limits: Tell users where the system can fail, where human review is required, and how moderation decisions can be appealed.

Related Resources

• Moderation API Reference
• Safety Checks
• Red Teaming AI Applications
• Production Best Practices
• Data Controls
• Prompt Engineering Guide
• AvalAI Content Policy