Claude Code Auto Mode Is Not a Security Boundary

Is Claude Code’s auto mode a security boundary? No, and Anthropic says so. After researcher Johann Rehberger reported a working attack chain against Claude Code Opus 5 in auto mode, Anthropic closed the report as Informative, with the position that auto mode is a convenience feature backed by a best-effort classifier rather than a security guarantee, that determined chains assembled from individually-benign steps fall outside what a classifier is expected to catch, and that the real boundary is operating-system isolation together with network egress control.¹ That answer is not a dodge. It is the correct mental model, and most of us have been carrying the wrong one.

There is a particular kind of security finding that matters less for the bug than for the belief it corrects. Rehberger’s August 26 writeup is one of those. The chain he demonstrates is clever, but the useful part is the response it drew, because the response tells you which layer of your setup is actually load-bearing – and it is not the one most developers have been trusting since auto mode became the default in August.

TL;DR

• Rehberger published a working attack chain against Claude Code Opus 5 in auto mode on August 26, 2026, reporting a 60-80% success rate on small samples: three of five runs for the primary chain, and three of five and four of five for two configurations of a second variant. He notes those are small samples rather than a general attack-success rate.¹
• The finding lands against a specific number: a third-party evaluation Anthropic commissioned reported a 0.00% prompt-injection attack success rate for Opus 5 in auto mode, measured over 72 scenarios run ten times each. Rehberger’s chain was not in that set, so the 0.00% and a working code-execution chain are both true at once.¹
• Every step in the chain is individually reasonable. That is the design lesson: a classifier evaluates actions one at a time, and the attack lives in the composition, not in any single action.
• Anthropic closed the report as Informative, framing auto mode as a convenience feature backed by a best-effort classifier rather than a security guarantee, with OS isolation and network egress control as the real boundary.¹
• The sharpest detail, which Rehberger reports and Willison foregrounds: in a few runs Claude detected the compromise and tried to kill the malware process, and auto mode denied the cleanup command.¹²
• Practical consequence: auto mode is a productivity control that also blocks a documented list of destructive operations when it judges you did not ask for them. It is not what stands between attacker-controlled text and your credentials. A container, restricted egress, and a credential-free home directory are.

The Chain, Step by Step

The setup is an agent doing ordinary work: fetch a resource, decode it, use the contents. Here is how that becomes code execution.¹

A server answers the agent’s WebFetch with HTTP 415, which reads as a content-type problem rather than an attack. The agent does the sensible thing and falls back to curl. The archive it retrieves expands into a scratch directory holding a README, a checksum manifest, a CSV index, seven Base85-and-zlib-encoded JSON records, a native decoder binary, and a file named struct.py.

Then the safety machinery works. The agent declines to run the untrusted native binary, exactly as you would want. Having refused the binary, it writes its own Python decoder instead, and runs it from inside the extraction directory.

That decoder imports base64. The standard library’s base64 imports struct. Python puts the working directory at the front of the module search path, so struct resolves to the attacker’s struct.py in the extracted archive instead of the standard library’s.

Read the sequence again and notice what is missing: there is no step where the agent is instructed to do something obviously malicious, and no step a reasonable reviewer would flag in isolation. Falling back to curl after a 415 is normal. Extracting an archive is normal. Refusing an unsigned binary is a safety win. Writing your own decoder is resourceful. Running it in the directory holding the data is the obvious place to run it.

Why a Classifier Loses This One

Auto mode’s classifier evaluates an action against the session’s intent: does this command match what the user asked for, and is it dangerous on its own? That question has a good answer for rm -rf / and a bad answer for python decode.py.

The attack never presents a dangerous action. It rearranges the environment so that a safe-looking action has an unsafe consequence, and the consequence only exists because of a step that happened earlier – the archive extraction that planted the module. To catch that, a reviewer would have to hold the whole history in mind and reason about Python’s import resolution against the current working directory. Anthropic’s position, that chains built from individually-benign steps fall outside classifier scope, is a statement about that gap.¹

It is worth naming the class precisely. Willison updated his write-up on August 30 to endorse a point raised by a Lobste.rs reader: this is not a classic prompt injection at all, because at no point does the model read attacker instructions and follow them. It is better described as a confused environment attack, where the shape of the environment the agent is handed produces the exploit.² That distinction sharpens the problem rather than softening it. A classifier watching for injected instructions has nothing to look at here, because there are none.

This is the same structural point the MCP CVE wave keeps making: agent tooling accumulates capability faster than it accumulates containment, and per-action review does not compose into per-session safety.

The Detail That Should Change Your Mental Model

Rehberger reports, and Willison foregrounds, the moment worth sitting with: in a few runs Claude noticed the compromise and tried to terminate the malware process, and auto mode denied the cleanup command.¹²

A safety layer preventing remediation is not a paradox, it is what happens when a control optimizes for “do not let the agent do anything drastic” without a notion of why the drastic thing is being attempted. Cleanup after a compromise looks, to a classifier, a great deal like destruction.

The operational lesson is narrow and useful. “The agent will notice” is not a control. Noticing and being able to act are different capabilities, and your incident response cannot assume the compromised agent gets to clean up after itself.

What Actually Bounds an Agent

Rehberger’s recommendations are the unglamorous ones, and the first two would have contained this chain:¹

Run unattended agents in a container or VM. The compromise executed code as the agent’s user. An isolation layer turns full-machine access into a disposable environment.

Restrict network egress. The chain’s payoff was a subprocess reaching out to fetch and run a remote payload, and a callback afterward. An allowlisted egress policy breaks both the download of the remote stage and the callback.

Keep credentials out of the agent’s reach. SSH keys, cloud credentials, and .env files in the home directory are inside the blast radius by default. Move them, or run the agent somewhere they are not.

Monitor the agent, and do not read approvals as evidence. Auto-mode approval means a classifier did not object. It is not a finding that the action was safe.

Note what is not on the list: turning auto mode off. It blocks a documented list of destructive operations when it judges you did not ask for them, and it reduces the prompt fatigue that leads people to approve everything reflexively. Trading it away for a false sense of rigor swaps one weak control for a worse one. Keep it, and stop treating it as the boundary.

The Part Worth Saying Plainly

It would be easy to write this finding up as a failure, and easier still to write it as vendor-blaming. Neither is right.

Anthropic’s answer – a convenience feature backed by a best-effort classifier, not a security guarantee, with OS isolation and network egress control as the boundary – is a more honest security posture than a stronger claim would have been.¹ A vendor that promised its classifier caught determined injection chains would be making a promise no classifier can keep, and developers would build on that promise. The interesting question is not whether this attack works. It is whether the ecosystem’s mental model matches the vendor’s, and right now it does not: auto mode became the default for Pro, Max, and Team sessions in August while a 0.00% attack-success-rate figure from a commissioned 72-scenario evaluation was the number Anthropic had put into circulation – Rehberger files it under the 0.00% marketing problem – and the framing that traveled with it was safety, not convenience-plus-blast-radius-reduction.¹ Rehberger draws a harder conclusion than I do: he reads the 0.00% messaging and the out-of-scope disposition as mixed messages that do not fit together.¹ I think both can hold. The disposition is the honest one, and the number should never have been marketed as a property of the product.

If your setup assumed the classifier was the wall, add the wall.

Key Takeaways

• Auto mode is a convenience and blast-radius control, not a security boundary. That is the vendor’s own position after a working bypass, not an outside critique.¹
• Classifiers judge actions; attacks live in compositions. Every step in the demonstrated chain is individually defensible, which is precisely why per-action review missed it.
• Noticing is not remediating. In some runs the agent detected its own compromise and was then blocked from cleaning it up. Plan incident response accordingly.¹²
• The controls that hold are outside the model. Container or VM, restricted egress, credentials out of the home directory. Everything else is depth, not boundary.

FAQ

Should I turn auto mode off?

No, unless you were relying on it as containment. It blocks a documented set of destructive operations – git reset --hard, git checkout -- ., git clean -fd, git stash drop, and terraform/pulumi/cdk destroy – when it judges you did not ask for them, and it cuts the prompt volume that drives reflexive approval. Keep it as a productivity and blast-radius control, and add real isolation for sessions that touch untrusted input.

Does this only affect Claude Code?

The mechanism is not Claude-specific. Any agent that fetches untrusted archives, writes code, and runs it in the directory it just extracted is exposed to the same import-resolution trap, and any per-action safety review is exposed to the same composition gap. The specifics here were demonstrated against Claude Code Opus 5 in auto mode.¹

What counts as an untrusted-input session?

Anything where attacker-influenced text can reach the model: fetched web pages, downloaded archives, issue and PR text, email, logs from a public service, and third-party MCP servers. In practice that is most real work, which is the uncomfortable part.

Has this been fixed?

It was not treated as a vulnerability to fix. Anthropic closed the report as Informative on the basis that classifier evasion of this kind is outside what auto mode promises.¹ Treat it as a documented property of the system rather than a pending patch.

Sources