§1What happened
Someone asked a coding agent to summarise a web page, and the web page made it run malware. The researcher Johann Rehberger, who has spent the year quietly breaking agent guardrails, pointed Claude Code at an attacker-controlled site and asked for a summary. The site did not hold an article. It held an archive: some encoded records, a small decoder program, and a malicious Python file. To produce the summary the agent did the natural thing, unpacked the archive and ran the decoder to read the records, and in running it handed the attacker code execution on the machine. Claude Code's Auto Mode, the feature that auto-approves commands it judges safe so you are not clicking yes all day, let the malicious process start. In Rehberger's testing it worked as often as eight times in ten.
Nobody was social-engineered. No password leaked. The instruction that started it was "summarise this website", which is about as ordinary as agent work gets. The danger was not in the request, it was in the quiet assumption underneath it: that content fetched from the internet is data to be read, when to an agent with a shell it is also code that can be run.
§2A filter is not a boundary
Auto Mode is good at its job. Anthropic reports it blocks around 89 per cent of dangerous commands, and that is a genuinely useful number for defence in depth. It is also the wrong kind of number to lean a security boundary on, and the gap between those two statements is the whole story. Eighty-nine per cent blocked means eleven per cent runs, and that eleven per cent is not a random unlucky slice. An attacker sits on the other side tuning the payload until it lands in the part the classifier waves through. A control that is right most of the time is precisely the control an adversary optimises against, because their entire job is to find the case where it is wrong.
To their credit, Anthropic does not claim otherwise. They closed Rehberger's report as informative and, in his paraphrase, described Auto Mode as a convenience feature backed by a best-effort classifier, not a security guarantee. That is an honest and correct description. The failure here is not really Auto Mode being 89 rather than 100. It is what happens when a convenience feature gets quietly promoted, in a user's head, from "saves me clicks" to "keeps me safe". A filter and a boundary look identical right up until the moment an adversary is actively steering for the gap, and then they behave nothing alike.
§3The tell: it approved the danger and blocked the fix
Here is the detail that should stay with you. In some runs the agent noticed, after the fact, that something was wrong, and tried to kill the malicious process it had started. Auto Mode blocked that command. It had approved starting the malware and it refused the cleanup.
Do not treat an Auto Mode approval as evidence that code is safe.
Read the asymmetry slowly, because it is the signature of a classifier doing its best rather than a rule enforcing a line. A boundary is consistent: it knows what is allowed and applies it the same way going in and coming out. A best-effort guess is not consistent, it scores each command on the surface features it happens to see, so "run this program" can read as fine while "terminate this process" reads as alarming, and you get the exact backwards outcome on display here. Danger in, fix out. When your safety layer can approve the harm and then stand in the way of the remedy, it was never a wall. It was a probability wearing the costume of one.
§4What actually holds
The durable fix is not a smarter classifier, it is a boundary that does not live inside the model at all. Three lines hold where a probability does not. Content fetched from the web is inert by default, never executable, so summarising a page cannot turn into running a program no matter how the page is dressed up. Shell commands that touch downloaded files stop at a human, because "execute a thing that arrived from outside" is exactly the category you cannot take back. And the tools an agent may reach are an explicit allowlist written in code, not a set the model talks its way into. In each case the model is free to read, reason and propose. What it cannot do is be the thing that decides whether the dangerous action runs.
This is the same lesson the whole field keeps relearning from different directions: a rule written inside a prompt, or scored by a model, is advice the model can be argued out of. A rule that runs in code, outside the model, is a control. OWASP moved excessive agency up its list this year for this reason. The point is not that models are untrustworthy, it is that trust is the wrong mechanism for an action you cannot undo.
§5How we run it
We run an autonomous fleet, so this lands close to home, and the honest version is that we built these boundaries because we did not trust ourselves not to need them. When our agents pull anything off the web, a guard that runs in code, not a prompt, refuses private and internal addresses, scans the fetched text for injection before it reaches the part of the agent that acts, and hands the content on as untrusted rather than as instructions. Nothing an agent scrapes gets to be a command. That guard is deterministic and it sits outside the model, which is the only place it is worth anything.
The rest is the same boring shape as always. Actions that cannot be taken back cheaply stop at a person. Our agents draft, queue and propose all day, and a human presses the button on anything that touches the outside world. We would rather the agent be brilliant at the thinking and hold no authority over the trigger, because this week is a clean demonstration of what happens when those two are the same thing. An agent that will run a stranger's code because it was asked to read a web page is not a broken agent. It is an agent doing exactly what it was told, with nothing in code standing between the request and the shell. Put something there. Not a better guess. A wall.