When the Model Says No: Safety Refusals, Bans and Fallbacks for SRE Agents

A host starts to send traffic to an unknown address. The alert fires, and the AI SRE agent starts to work. It finds a binary in /tmp, decodes a base64 string from a cron entry, and reads the access log, which is full of exploit attempts against a known CVE. This is normal incident response. To a provider's safety classifier, it can look like malware analysis or exploit development.

Providers say openly that this happens: Anthropic's docs say benign technical work sometimes triggers its safeguards, and OpenAI's cyber-safety page says legitimate cybersecurity work "can still trigger a safeguard." For an agent that runs at 3 AM with nobody watching, a refusal is a failed dependency, and an account-level block is an outage of every investigation at once. This post treats refusals as an operational risk and shows how to build fallbacks without trying to trick the model.

How Providers Say No Today

Anthropic. Since the Claude 4 models, streaming classifier refusals end with stop_reason: "refusal". The response is HTTP 200, not an error. A stop_details object carries a category, such as cyber, bio or general_harms, though the category can be null. The docs say two more things that matter for agents. You must reset the conversation context after a refusal, because "attempting to continue without resetting will result in continued refusals". And re-sending a refused request to the same model usually gets another refusal.

The refusals and fallback page explains billing. A cyber refusal before any output is not billed, a refusal in the middle of a stream bills the input and the output already streamed, and refused requests still count against rate limits. For Claude Fable 5, Anthropic's fallback billing guide calls its safeguards "deliberately conservative" and recommends that API customers configure fallback to Opus 4.8. This fallback is opt-in on every request: a call without the fallbacks parameter gets the refusal, not a silent retry. Claude Haiku 5.5 has no server-side fallback.

OpenAI. The API cybersecurity safety checks guide covers its Cyber models. When activity is flagged, requests return an error with the code cyber_policy, and access may be limited while the activity is reviewed. The blast radius is the important part: without a per-user safety_identifier, access may be revoked for the entire organization. If you believe access was limited in error and need it back before the 7-day period ends, you contact support. For security teams, OpenAI runs a reviewed Trusted Access for Cyber program, and that page notes that approval is not guaranteed.

Account bans. Anthropic's safeguards warnings and appeals article lists repeated Usage Policy violations as one reason for a ban. You appeal by logging in with the banned account. A banned Free, Pro, Max or Ultra user can still export data, but the article says the data you can export "may be restricted" depending on the violation. The export itself arrives as an email link that expires after 24 hours, and the data cannot be imported into another personal Claude account.

The policies are not against security work. Anthropic's Usage Policy, in the version effective November 12, 2026, does not prohibit security research and testing on systems you own or operate, or done with the system owner's authorization, and it says that "encountering a block does not by itself indicate a violation." But a classifier decides in milliseconds, and an appeal takes days.

Five Ways a Refusal Shows Up

An agent has to tell these cases apart, because the right reaction differs for each.

The first and fourth rows look like success at the HTTP level. A naive agent loop posts "I can't assist with analyzing this binary" to the incident channel and marks the investigation done. The worst row is the org-level block: one investigation of a suspicious binary can cut off triage for every other alert that night, including a disk-full alert that has nothing to do with security.

Build the Fallback Chain

1. Treat a refusal as its own outcome. Check stop_reason and error codes, not only HTTP status. Count refusals per model and per alert type. If one alert rule produces refusals every week, you know where to put a different model before it matters.

2. Reset context, do not resend. Anthropic's docs say a refused conversation keeps refusing. Retry with the refused turn removed, or on the next model in the chain. Never loop the same transcript against the same model.

3. Order the chain by trust boundary. A good order is: the primary model, then the same vendor's documented fallback (for example Fable 5 to Opus 4.8 with server-side fallbacks), then a model from a different vendor, then a self-hosted model. A different vendor protects you from one company's classifier and account decisions. A self-hosted model protects you from all of them: nobody can revoke your access to weights on your own GPUs. An open-weight model can still refuse in text, so the fourth row of the table still applies.

4. Make the router do it. A LiteLLM proxy supports fallbacks for general errors and content_policy_fallbacks for errors it maps to ContentPolicyViolationError:

model_list:
  - model_name: sre-agent
    litellm_params:
      model: anthropic/<primary-model>
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: sre-agent-backup
    litellm_params:
      model: openai/<open-weight-model>
      api_base: http://vllm.internal:8000/v1
      api_key: os.environ/VLLM_API_KEY

router_settings:
  content_policy_fallbacks: [{"sre-agent": ["sre-agent-backup"]}]
  fallbacks: [{"sre-agent": ["sre-agent-backup"]}]

One trap: LiteLLM's docs describe these fallbacks as triggered by errors. Anthropic's classifier refusal is a successful HTTP 200 response. Send a known refused request through your proxy and check which model answered before you count on the chain.

5. Record which model answered. With Anthropic server-side fallback, the response's model field names the model that actually answered. Keep it with the incident. When a fallback model writes the root cause, the reviewer should know.

6. Limit the blast radius of identity. Send a safety_identifier per user or per service where the provider supports it, so a flag hits one identity, not the organization. Consider a separate organization or project for security-heavy workloads, so a review of that work does not stop general alert triage. If your team does security work every day, apply for the provider's trusted access program before the incident, not during it.

Where Akmatori Fits

Akmatori runs on your servers. The incidents, their execution logs and the agent's responses live in your own instance, and runbooks and memories live in its PostgreSQL. If a provider bans the account behind your API key, you lose that model, not your investigation history.

You can save several LLM configurations in Settings → AI models, for OpenAI, Anthropic, Google, OpenRouter, NVIDIA NIM, MiniMax, Ant Ling or a Custom OpenAI-compatible endpoint. One configuration is active at a time. Switching is one API call, PUT /api/settings/llm/:id/activate (see the API reference), so a runbook can move the whole instance to the backup model in seconds. For an automatic chain, connect a LiteLLM proxy as a Custom model, as the local models guide shows. That guide also warns that small self-hosted models often fail at tool calls, so test your last-resort model before you need it. Our self-hosted SRE agent post lists open-weight models that found the root cause in 11 of 12 SRE Bench incidents.

Checklist Before the Next Security Incident

• A second provider is configured and tested with a real alert, not only a ping.
• A self-hosted or private endpoint exists for the case where both public providers say no.
• Your agent loop checks stop_reason and policy error codes, and marks refused runs as failed.
• Refused turns are dropped, not resent to the same model.
• safety_identifier, or the provider's equivalent, is set per user or service.
• Security-heavy workloads use a separate organization or project.
• The trusted access application for your security team is approved, or at least submitted.
• Investigation history lives in your own database, not only in a vendor chat UI.
• A scheduled canary includes one benign security task, so you see a new refusal pattern before an incident does. Our LLM canary post shows how to build one.

Conclusion

Hosted models now ship with conservative safety classifiers, and they will not change for your incident. Do not try to trick them. Design for them: detect refusals as a distinct failure, reset context, fall back to a model behind a different trust boundary, and keep your incident data where no account decision can reach it.

If your team wants AI-assisted incident workflows on your own infrastructure, Akmatori helps SRE teams investigate alerts, coordinate response, and automate safe infrastructure actions. Powered by Gcore for global infrastructure reliability.