On September 1, Anthropic released Claude Fable 5.1 and Claude Mythos 5.1 — by the company's own description, the same model under two different levels of safeguards. Fable 5.1 is generally available. Mythos 5.1 is restricted to vetted organizations in Anthropic's trusted access programs. For anyone operating coding agents, the operational headline is a number: Anthropic says Claude Code users "can expect an average of around 60% fewer interventions per session" from its cyber safeguards, relative to the previous safeguards on Fable 5.

A safeguard intervention is the moment a model provider's safety system interrupts a session — refusing, redirecting, or stopping work it classifies as risky. Anthropic's newest cybersecurity safeguards block 60% fewer false positives than before, and Fable 5.1 is now permitted to identify software vulnerabilities, though not to develop exploits for them.

Some dual-use security work still gets redirected away from Fable 5.1 entirely: penetration testing, exploit generation, and binary-based vulnerability scanning route to Anthropic's Opus models. And the two-tier release puts a rare number on what safeguards cost in capability terms: on Terminal-Bench 4.0, run with production safeguards enabled, Fable 5.1 scores 55.8% while Mythos 5.1 — the identical model with trusted-access safeguards — scores 60.9%.

If your team runs Claude Code or Cowork, this lands in your sessions automatically. The interruptions you were tuning your workflows around last week fire less often this week — and whatever screening those interventions were performing now happens less often too, on a dial you do not control.

Why do vendor safeguards keep moving under deployers' feet?

Because the dial has a cost in both directions, and the vendors themselves say so. Anthropic's release frames the change as precision: fewer false positives on benign work, like "cyberdefenders using the model to make their systems safer." The pressure it responds to is stated on the page itself: the release opens by naming customer feedback on safeguards as one of three things this version addresses.

The same week, OpenAI moved the same dial the other way. Its September 1 post on Astra — the first model OpenAI has designated at the Critical cybersecurity threshold of its own Preparedness Framework — says the system "may occasionally flag legitimate activity as potential cyber misuse or unauthorized behavior, leading to it inadvertently being slowed, paused, or stopped," explicitly including "work that does not appear directly related to cybersecurity or tasks in which an agent is running for an extended period." On API surfaces, OpenAI notes, a paused task simply stops. OpenAI says it expects Astra's safeguards "to create more friction than we ultimately intend" at launch.

Two frontier labs, one week, opposite adjustments — that is an observation about a contrast, not a claim that either influenced the other. But it exposes the structural problem for deployers. Provider-side safeguards are calibrated for the provider's entire user base, retuned on the provider's schedule, and applied inside a system you cannot inspect. They can loosen 60% or tighten into mid-task stops between one model release and the next, with no change to your code, your prompts, or your risk appetite. A control that moves without your involvement is not a control you can build an assurance case on.

There is a second, quieter shift in this release. Fable 5.1 may now be used to identify software vulnerabilities. If your organization did not want general-purpose coding agents doing security analysis on your codebase, the boundary that used to be enforced in the model's refusals is now, on that class of work, a boundary only if you enforce it yourself.

What should teams running coding agents check now?

First, treat vendor safeguard behavior as an unversioned dependency. Record which model each agent session ran on, so that when behavior changes — fewer refusals, new permitted work — you can tell whether the change arrived in your prompts or in the provider's safeguards.

Second, write down which risks you were implicitly delegating to the provider's classifier. Interventions were mostly friction — that is why Anthropic reduced them — but if any workflow treated "the model will refuse that" as a control, that assumption needs to be re-verified per release, or replaced with a control you own.

Third, decide your own policy on vulnerability identification. The model now does it. Whether your agents should is a question for your security team, and the answer needs to live in your tooling, not in a hope that the model declines.

Fourth, plan for the opposite failure mode too. If you run agents on API surfaces with other providers, OpenAI has told you in plain language that on surfaces like the API, a task its misalignment monitor pauses will stop. Capture enough at runtime to answer what an agent had already done before it stopped — a need we've written about in the approval-scope gap and in what happens when an agent's refusal is bypassed.

How Waxell handles this

The layer that does not move when a vendor retunes its safeguards is the one that runs in your own deployment. Waxell Observe puts that layer directly on the surface this release affects: its Claude Code and Cowork integration is one command — wax observe claude-code setup --governance — and it registers hooks on the agent's own lifecycle.

At PreToolUse, before each Bash, Edit, or Write call executes, a local guard runs zero-latency checks across 8 protection layers — destructive commands, sensitive credential files, git safety, path boundaries, network access to internal and cloud-metadata endpoints, infrastructure files, session scope, and multi-session conflicts — and can deny the call outright or hold it for the user's confirmation. Session scope control warns at 20 modified files and prompts at 50, which bounds exactly the long-running, many-file sessions both vendors describe. A server-side policy check runs after the local guard on the same hook, so budget, scheduling, and kill-switch policies can block a call too. The rest of the lifecycle is recorded: tool calls as spans at PostToolUse, subagents with token usage, and LLM calls batch-recorded from the transcript when the session stops.

Those server-side policies are configured on the Waxell control plane and evaluated before execution, with optional mid-execution checks on each step for long-running agents. When a policy blocks, the block can route to a human approval handler — a terminal prompt out of the box, or custom handlers for Slack and webhooks — instead of failing silently. And policy changes take effect without redeploying agents, which is the property this news cycle argues for: when a provider retunes its safeguards on Monday, you can retune yours the same afternoon, in one place, without touching a prompt.

The honest limits: the local guard is deterministic pattern matching on concrete actions — commands, file writes, network calls — not a model-level intent classifier, and it governs a different layer than Anthropic's safeguards do. It is a complement to provider-side safety, not a replacement for it. What it gives you is the layer you control: a record of what your agent did on the surfaces the hooks cover, and a gate on the actions that matter, that stays put between model releases.

FAQ

What exactly changed in Claude Fable 5.1's cybersecurity safeguards?

Anthropic made its cyber safeguards more precise and newly permits Fable 5.1 to identify software vulnerabilities for defensive purposes. The company says the newest safeguards block 60% fewer false positives, and that Claude Code users can expect around 60% fewer interventions per session relative to Fable 5's safeguards. Penetration testing, exploit generation, and binary-based vulnerability scanning still redirect to Opus models.

What is the difference between Claude Fable 5.1 and Claude Mythos 5.1?

Per Anthropic, they are the same model with different levels of safeguards. Fable 5.1 is generally available; Mythos 5.1 is available only through trusted access programs for vetted cyberdefenders and life-science professionals, currently limited to a set of US organizations.

Does 60% fewer interventions mean Fable 5.1 is less safe?

Anthropic frames the change as reduced false positives rather than reduced protection, and says that after stress-testing — including commissioned external testing from two organizations — it has not found evidence of a critical-severity jailbreak for these safeguards. What is measurably true from the release itself: the same model scores 55.8% under general-availability safeguards and 60.9% under trusted-access safeguards on Terminal-Bench 4.0, so the two regimes demonstrably behave differently. Whether the new calibration is right for your environment is a judgment Anthropic cannot make for you.

How is OpenAI's approach with Astra different?

In the same week, OpenAI designated Astra as its first model at the Critical cybersecurity capability threshold under its own Preparedness Framework and is shipping it with misalignment monitoring that can pause or stop a running task. OpenAI states that legitimate work may occasionally be slowed, paused, or stopped, and that on API surfaces a paused task stops rather than waiting for review.

What should I do differently in my Claude Code or Cowork deployment this week?

Record the model version per session, re-verify any workflow that relied on the model refusing security-adjacent work, set an explicit organizational policy on vulnerability identification by agents, and put pre-execution checks you control — local guards and server-side policies — on the tool calls themselves rather than depending on provider-side classifier behavior that changes between releases.

Sources

• Anthropic, "Introducing Claude Fable 5.1 and Claude Mythos 5.1," September 1, 2026.

• OpenAI, "Path to Astra: critical capabilities and frontier safeguards," September 1, 2026.

Start free with Waxell Observe

Vendor safeguards moved this week and will move again. The guardrails that don't are the ones in your own runtime. Start free with Waxell Observe and one governed MCP upstream: one command to govern Claude Code and Cowork sessions, pre-execution policy checks, and a session-level record of what your agents did.