Safety Checks

Safety checks help you detect risky usage before it becomes an account, user, or product incident. This guide adapts OpenAI’s official safety-check guidance for AvalAI’s OpenAI-compatible API at https://api.avalai.ir/v1.

Use this page with Safety Best Practices, Moderation, and Red Teaming.

What to Check

Layer	What to check	AvalAI pattern
User identity	Can you trace risky requests to a stable end user without storing raw PII?	Send a hashed safety_identifier on every supported request.
Input risk	Could the user input violate policy, reveal secrets, or trigger unsafe tool calls?	Run /v1/moderations, schema validation, and tool allowlists before expensive work.
Output risk	Could the answer be unsafe, high-stakes, or policy-sensitive?	Moderate or review output before display; buffer streams for risky surfaces.
Tool actions	Could a tool write data, spend money, or call a privileged system?	Validate arguments and require human approval for side effects.
Release changes	Did prompts, models, routing, retrieval, or moderation thresholds change?	Run evals and red-team smoke tests before rollout.

Send Safety Identifiers

For products where individual users interact with a model, send a stable, privacy-preserving safety_identifier. Hash internal user IDs, email addresses, or account IDs before sending them. Do not rotate identifiers to bypass provider safety enforcement; block or review the abusive account instead.

Chat Completions

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",
)

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

completion = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {"role": "system", "content": "Answer safely and follow product policy."},
        {"role": "user", "content": "Summarize the safety checklist for launch."},
    ],
    max_completion_tokens=120,
    safety_identifier=user_hash,
)

print(completion.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 userHash = crypto
  .createHash("sha256")
  .update("user_123")
  .digest("hex")
  .slice(0, 64);

const completion = await client.chat.completions.create({
  model: "gpt-5.5",
  messages: [
    { role: "system", content: "Answer safely and follow product policy." },
    { role: "user", content: "Summarize the safety checklist for launch." },
  ],
  max_completion_tokens: 120,
  safety_identifier: userHash,
});

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

Bash

curl https://api.avalai.ir/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AVALAI_API_KEY" \
  -d '{
    "model": "gpt-5.5",
    "messages": [
      {"role": "system", "content": "Answer safely and follow product policy."},
      {"role": "user", "content": "Summarize the safety checklist for launch."}
    ],
    "max_completion_tokens": 120,
    "safety_identifier": "9f86d081884c7d659a2feaa0c55ad015"
  }'

Responses API version and migration path

Use this version for new Responses-first workflows. messages becomes input, the system message becomes instructions, max_completion_tokens becomes max_output_tokens, and 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",
)

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

response = client.responses.create(
    model="gpt-5.5",
    instructions="Answer safely and follow product policy.",
    input="Summarize the safety checklist for launch.",
    max_output_tokens=120,
    safety_identifier=user_hash,
)

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 userHash = crypto
  .createHash("sha256")
  .update("user_123")
  .digest("hex")
  .slice(0, 64);

const response = await client.responses.create({
  model: "gpt-5.5",
  instructions: "Answer safely and follow product policy.",
  input: "Summarize the safety checklist for launch.",
  max_output_tokens: 120,
  safety_identifier: userHash,
});

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",
    "instructions": "Answer safely and follow product policy.",
    "input": "Summarize the safety checklist for launch.",
    "max_output_tokens": 120,
    "safety_identifier": "9f86d081884c7d659a2feaa0c55ad015"
  }'

Handle Safety Enforcement Gracefully

Provider safety systems may add latency, return errors, or restrict access when traffic repeatedly looks abusive. Design for that path instead of treating it as an ordinary transient failure.

• Understand GPT-5+ classifier behavior: OpenAI documents additional safety classifiers for GPT-5 and newer models that classify requests into risk thresholds. Repeated high-risk traffic can trigger warnings, errors, or model-access restrictions. Through AvalAI, exact enforcement depends on the selected provider route, model, and account state.
• Show a loading state for streams: If a streaming response is delayed while safety checks run, keep the UI responsive and avoid duplicate retries.
• Do not blind-retry policy blocks: Retry network failures, but route policy or safety errors to a safe fallback, account review, or support flow.
• Log safely: Store x-request-id, model, route, hashed safety_identifier, moderation result, and final action. Avoid raw prompts unless your retention policy allows them.
• Block the right subject: Safety identifiers help you limit or review an abusive user instead of disabling the whole integration.
• Avoid identifier churn: If a provider blocks a safety_identifier, do not issue a fresh identifier to bypass the block. Review the underlying account and add product-level controls that prevent repeated abuse.

Realtime and Session-Based Routes

Safety identifiers do not automatically carry between APIs or sessions. If AvalAI enables a Realtime-compatible route for your account, bind the same stable user hash when creating or connecting the session, using the route-supported header or metadata. Keep request-based audio and chat flows on safety_identifier.

OpenAI's Realtime shape uses an OpenAI-Safety-Identifier header on the trusted server request that creates or connects the session. Treat this as an architecture reference until AvalAI announces the matching Realtime route:

curl https://api.avalai.ir/v1/realtime/client_secrets \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AVALAI_API_KEY" \
  -H "OpenAI-Safety-Identifier: 9f86d081884c7d659a2feaa0c55ad015" \
  -d '{
    "session": {
      "type": "realtime",
      "model": "gpt-realtime-2"
    }
  }'

Do not send long-lived API keys from the browser. If the route uses browser or mobile WebRTC, mint the short-lived client secret on your backend and bind the safety identifier there.

Products Serving Minors

OpenAI's under-18 API guidance treats products for minors as requiring additional safeguards beyond ordinary abuse monitoring. If an AvalAI integration can be used by minors, treat that route as a high-safety release and confirm the legal, privacy, and provider-retention requirements before launch.

• Confirm age scope: decide whether the product is intended for minors, mixed audiences, classrooms, families, or adults only. Add age gates or age assurance when required for the use case.
• Protect younger children: do not process personal data from children under 13, or under the applicable age of digital consent, unless the route has the required data-retention controls and your legal basis is documented.
• Use age-appropriate disclosure: tell young users when they are interacting with AI, what it can and cannot do, and when they should ask a trusted adult or professional.
• Filter sensitive content: add age-appropriate input and output moderation for sexual, violent, self-harm, exploitation, illegal, bullying, or other sensitive content categories.
• Create escalation paths: define who reviews high-risk interactions, how reports are handled, and when to involve parents, school administrators, moderators, legal, or emergency contacts.
• Minimize and separate data: avoid raw PII, use hashed safety_identifier values, and keep support logs, moderation results, and customer content under the retention plan documented in Data Controls.

Do not copy OpenAI-specific Zero Data Retention claims into AvalAI customer-facing material unless the selected AvalAI route, provider, and customer contract explicitly support the same control. When in doubt, keep the workflow stateless, avoid storing full prompts, and require human review before exposing the feature to minors.

Cybersecurity and Research Traffic

OpenAI documents additional automated safeguards for high-cyber-capability model families. Through AvalAI, the exact behavior depends on the selected provider route, model, account policy, and whether upstream safety controls are active for your traffic.

• Plan for policy errors: Cybersecurity-related safeguards may return policy-style errors such as cyber_policy from upstream routes. Treat them as safety enforcement signals, not retryable 5xx failures.
• Isolate end users: A stable safety_identifier helps providers and your own review systems limit or investigate one risky user instead of disrupting every user behind the same API key.
• Do not bypass blocks: If an identifier, account, or organization is limited after high-risk traffic, review the activity, tighten product controls, and contact support when appropriate instead of issuing fresh identifiers to continue the same behavior.
• Handle legitimate research carefully: Defensive security, life-science, chemistry, or dual-use research workflows should have authorization checks, narrower prompts/tools, human review, and a documented escalation path before production traffic.

Release Checklist

• Add safety_identifier to every supported user-facing call.
• Run /v1/moderations or inline moderation where the selected AvalAI route supports it.
• Validate tool arguments before execution and output before returning tool data to the model.
• Include safety failures in eval datasets and red-team smoke tests.
• Add a product path for cyber_policy, blocked identifiers, and other safety-enforcement errors.
• For products used by minors, add age-appropriate disclosures, content filters, reporting/escalation paths, and route-level retention review.
• Define who reviews blocked users, borderline moderation results, and high-risk generated content.
• Document user-facing appeals, support paths, and escalation timelines.