Skip to content
AI Primer
release

Claude Code adds layered prompt-injection defenses by default next week

Anthropic engineers said Claude Code is slated to add model training, probes, and auto-mode layers by default next week. They said Claude models now largely resist practical prompt injection.

7 min read
Claude Code adds layered prompt-injection defenses by default next week
Claude Code adds layered prompt-injection defenses by default next week

TL;DR

  • Claude Code will switch new Pro, Max, and Team sessions to auto mode on August 14; existing user defaults get a prompt, pinned defaults stay pinned, and classifier overhead stops counting for those plans, according to ClaudeDevs' blog link.
  • The safety case is permission fatigue: humans in Anthropic's 1,053-person study caught 13.6% of dangerous swapped prompts, while auto mode caught 89%, according to ClaudeDevs' study thread.
  • Anthropic's prompt-injection claim is layered: bcherny's stack reply says 0% requires model + probe + auto mode, and bcherny's classifier reply says multiple classifiers sit on top of model behavior.
  • The caveat is in the same numbers: auto mode still missed 11% of dangerous swapped prompts in the human study, and simonw's post says he wants more independent confirmation.

The official launch post buries a migration gotcha: broad Bash allow-rules get set aside in auto mode, because python:* would otherwise skip the classifier. Simon Willison's writeup points at the nastiest open edge case: a malicious package that turns a normal test command into exfiltration. The production note says Claude works 9x longer between interruptions under auto mode, and Gusto saw roughly 10% of transcripts include an auto-mode denial.

August 14 default

The switch applies to new Claude Code sessions on Pro, Max, and Team plans. Anthropic's launch post says Claude Enterprise, the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry remain opt-in while admins review the change, with a broader default rollout planned over the following month.

Users who already set a different default may see a one-time prompt, while pinned defaults stay pinned. ClaudeDevs' admin note says Shift+Tab still switches modes, and admins can pin defaultMode or disable auto mode through managed settings.

One follow-up about further expansion got a tentative answer from bcherny's expansion reply: "I think it is likely."

Permission fatigue

In Anthropic's launch post, the controlled study used 1,053 paid professional testers in a test environment. A single permission prompt was replaced with clearly dangerous text, and approving it did not run anything dangerous.

The useful numbers:

  • Human reviewers caught 143 of 1,053 dangerous prompts, or 13.6%.
  • Auto mode blocked 937 of the same 1,053 commands, or 89%.
  • Head to head, auto mode blocked 800 commands that humans approved.
  • Humans blocked 6 commands that auto mode allowed.
  • Human blocking fell from about 17% early in a session to about 5% after 50 or more prior prompts.
  • Auto mode's block rate stayed flat across session length.

The same post says Claude Code users approve 97% of permission prompts, reject only 3% of individual permission requests, and reject 39% of plan approvals. That gap is the permission-fatigue argument in one line.

Prompt-injection stack

The model-side problem is source attribution. paul_cal's threat-model reply framed the target as reliably distinguishing user instructions from untrusted external text, such as a GitHub comment telling the agent to install something.

Anthropic's described stack has four layers:

  • Model training to resist external instructions that conflict with the user.
  • Input probes that scan tool results for potentially malicious instructions, according to Anthropic's launch post.
  • An auto-mode classifier that checks whether each action aligns with user intent.
  • Extra classifiers for the last mile, which bcherny's classifier reply described as necessary "to get to 0%."

bcherny summarized the implementation as "model, probes, and harness" in bcherny's harness reply. In bcherny's stack reply, he said the model + probe + auto-mode combination becomes the Claude Code default next week.

720-attack eval

Anthropic commissioned Trajectory Labs to test public Claude Code and Codex builds as of July 17, 2026, according to the launch post. The setup used 72 indirect prompt-injection scenarios, 10 attempts each, held out from Anthropic and optimized against Claude Opus 4.7, which was not in the reported set.

Results from the post and bcherny's chart reply:

  • Claude Fable 5, Opus 5, and Sonnet 5 in auto mode: 0 successful attacks across 720 attempts per model.
  • GPT-5.6 Sol in Codex Auto-review: 5.83% attack success.
  • GPT-5.6 Sol in Codex Full Access: 19.03% attack success.
  • Claude Fable 5 in bypassPermissions: 0.28% attack success; Sonnet 5 and Opus 5 showed 0.00% in that chart.

bcherny's footnote reply says the comparison used Claude Code v2.1.205 and Codex v0.144.5, and notes that OpenAI had released a newer Auto-review version that could change the results.

Separate from Claude Code, Anthropic's Opus 5 system card says Opus 5's largest agentic-safety gains were in prompt-injection robustness across coding, computer use, and browser use. The Gray Swan IPI chart in bcherny's reply puts Opus 5 at 0.2% after one attempt, 1.6% after 10 attempts, and 2.0% after 15 attempts.

Remaining attack surface

Simon Willison accepted the permission-fatigue result but questioned whether the prompt-injection claim covers package-mediated attacks. His example is a malicious third-party package that tells the agent to fetch model files before running tests, where the fetch command exfiltrates available data.

kunchenguid made the sharper version of the critique: 11% misses are not a small residual when the command is dangerous, and command-by-command review is the wrong unit of security in kunchenguid's 11% reply. In the same thread, kunchenguid's follow-up argued that the risk is users treating auto mode as sufficient by itself.

The counter-position was also in the thread. paul_cal's scale-up reply argued that agents only need to be better than diligent humans once permissions, rollbacks, exfiltration prevention, backups, and spend limits are part of the system around them.

bcherny's shortest answer to the shared-responsibility point was bcherny's security reply: "Security is every engineers' job."

Production runs

Anthropic's production note gives three concrete deployment patterns:

  • Nuro uses auto mode for parallel coding sessions and overnight research agents; one engineer described a 10 p.m. to 5 a.m. run that produced three PRs.
  • Gusto reported 2,425 Claude Code sessions from one AI Dev Tools engineer since December, with roughly 10% of transcripts since mid-May containing an auto-mode denial.
  • Garner Health rolled Claude Code out to 550 employees and connected it to systems including Salesforce, Zendesk, and Snowflake.

The same post says Nuro blocks dangerous commands such as recursive deletes in settings, Gusto routes MCP traffic through a governed proxy layer, and Garner configured auto mode not to approve actions that communicate with other people, such as Slack messages or emails.

Settings that still matter

The old permission machinery remains visible under auto mode. Claude's user FAQ says Shift+Tab cycles between auto, manual, acceptEdits, and plan modes, while /permissions manages persistent approvals.

The launch post adds one important precedence rule: permission rules still run before the classifier, except broad allow-rules that grant arbitrary code execution, such as Bash(python:*). Those rules are ignored while auto mode is active, settings files are not modified, and the rules apply again after switching modes.

The blocker path has its own thresholds. If the classifier blocks three times in a row, or twenty times across a session, Claude Code falls back to manual approvals, according to Anthropic's launch post.

Two support replies fill in the tuning loop: bcherny's settings.json reply says users can add allow-list entries directly in settings.json, and bcherny's allow-forever reply says /permissions can allow a command forever next time. For odd behavior, bcherny's bug-report reply asked a user to run /bug in the affected session and share the feedback ID.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 6 threads
TL;DR2 posts
August 14 default2 posts
Prompt-injection stack4 posts
720-attack eval2 posts
Remaining attack surface4 posts
Settings that still matter3 posts
Share on X