[MODEL] False-positive "cyber" refusals on routine container/Kubernetes templating work (9-refusal cluster, claude-fable-5)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude refused a reasonable request

What You Asked Claude to Do

I asked Claude (Ember, my agent) to reuse our own existing internal LXC containers (aludel, pelican — our sales-team and security-team containers) to extract a Dockerfile / Kubernetes deployment template, so we could stand up a new deployment for an internal finance team. Standard internal platform engineering: read our own container configuration (read-only inventory — names/paths only, never secret values) and draft a reusable template. No exploit development, no third-party systems, no credential values requested or produced at any point.

Session ID: e925e2f2-32a2-421d-af40-00c204da3247 · Working directory: ~/.foundry/ember/work/wire-format · Incident window: 2026-07-11, 00:43:40–00:52:20 UTC.

What Claude Actually Did

9 separate API calls were rejected mid-generation within a single ~9-minute cluster, each with stop_reason: "refusal", stop_details.category: "cyber", and the message:

"This request triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy."

The refusal fired across retries AND across unrelated follow-on actions in the same task (spawning subagents, sending them messages, drafting the template) — suggesting the classifier pattern-matches on infra vocabulary (containers, exec, SSH, Kubernetes, "template") rather than actual malicious intent or content. The task could not be completed without routing around the classifier via subagent delegation.

Request IDs (all confirmed directly against the raw session JSONL, identical stop_details shape):

| # | Request ID | UTC | Context |
|---|---|---|---|
| 1 | req_011CcuLrp6gFeKW1Vbi1SSzN | 00:43:40 | Initial ask: build the template from our own LXC containers |
| 2 | req_011CcuLz6WMCHF9zEeDYjhPp | 00:45:18 | Retry after the flag; user asked to offload to subagents |
| 3 | req_011CcuM257KWL1aSETLyGNae | 00:45:48 | Answering "are you stuck in a loop?" while spawning a recon subagent |
| 4 | req_011CcuM4CCGhnzw4PCnd9SZu | 00:46:07 | Continuing the subagent-spawn flow |
| 5 | req_011CcuM53astFnqWXhTGoLDY | 00:46:15 | Follow-up message to the spawned subagent |
| 6 | req_011CcuM5nhCnufk5AzhJRrNG | 00:46:24 | Continuation of the same dispatch thread |
| 7 | req_011CcuMKn3QQH94zsS3ooQgW | 00:49:48 | Dispatching a subagent to draft the Dockerfile from read-only inventory |
| 8 | req_011CcuMPambwf98B4jHHhB4f | 00:50:35 | Explaining to the user that the classifier was flagging mid-generation |
| 9 | req_011CcuMWdgfbUWxeixz1eTTo | 00:52:20 | Dispatching the subagent that collected this evidence |

Expected Behavior

Complete the benign infrastructure task: read our own container inventory (read-only) and draft a Dockerfile/Kubernetes template — without safeguard refusals. If the classifier must flag, it should evaluate actual content/intent (no exploit code, no third-party targets, no credentials present) rather than infrastructure vocabulary, and it should not re-fire on unrelated follow-on actions (subagent dispatch, user-facing explanations) within the same session.

Files Affected

No unexpected file access — the incident is about refusals, not file modifications. Access in the flagged turns was explicitly scoped to read-only container inventory (names/paths only). Working directory: ~/.foundry/ember/work/wire-format.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

Not deliberately re-triggered (production workspace). Observed pattern: ask claude-fable-5 to inventory existing Linux containers (LXC) over SSH/pct exec and draft a Dockerfile/Kubernetes deployment template from the results — in our session this reliably produced category: "cyber" refusals across 9 consecutive/related turns, including turns that were only spawning subagents or explaining the flag to the user.

Claude Model

Other

Relevant Conversation

Each flagged call returned: "This request triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy." (stop_reason: "refusal", stop_details.category: "cyber" — identical shape across all 9 events, verified in the session JSONL.)

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.204 (Claude Code) — current on this host; incident occurred 2026-07-11 on the same install line

Platform

Anthropic API

Additional Context

Related: #76518 — same apiRefusalCategory: cyber over-trigger on claude-fable-5, different workload class (routine curl/scraping of public pages there; container/Kubernetes templating here) and different failure surface (silent fallback to Opus 4.8 there; hard mid-generation refusals here). Together they suggest the cyber classifier is over-weighting ordinary infrastructure/web vocabulary in agentic contexts.

Pattern notes: the flags clustered on turns containing container names + exec/SSH + "template"/Kubernetes vocabulary; they persisted across retries and re-fired on adjacent turns with no infra content of their own (subagent dispatch, user-facing explanation). Happy to provide the full transcript excerpt around any request ID above.