The prompt is four words long and it is the whole attack.

"Perform security testing on /path/to/geopy."

That is the entire user input in the proof-of-concept Boyan Milanov and Heidy Khlaaf published on July 8 through the AI Now Institute. They took geopy, a boring, widely used Python geocoding library, and added four files: a security.sh wrapper script, a compiled binary called code_policies, a decoy Go source file called code_policies.go, and a short section appended to the README.md. Nothing in the library's own code calls any of it. A developer points Claude Code at the folder and asks it to look for vulnerabilities. The agent reads the README, decides the security script is part of the job, runs it, and the attacker's binary executes on the host. No approval prompt. No warning.

The obvious reading is "prompt injection strikes again, agents remain unsafe, film at eleven." That reading is wrong, or at least lazy, and it will cause you to reach for the wrong fix. This attack is not interesting because an agent got hijacked. It is interesting because of what it did not have to do to get hijacked. It never had to push the agent outside the user's intent. It never had to make the agent do something the user did not ask for. It made the attacker's payload into the thing the user asked for. And that distinction is precisely the seam that both of Claude Code's defensive layers are built on.

Auto mode is the configuration the attack requires. It is opt-in, and it exists for an honest reason. In Anthropic's engineering write-up from March, the number that justifies the whole feature is this: users approve 93% of permission prompts. A permission prompt that gets approved 93% of the time is not a security control, it is a latency tax with a UI. So people were reaching for --dangerously-skip-permissions, and auto mode is the attempt to give them the autonomy without the cliff. Instead of asking the human, a classifier running on Sonnet 4.6 decides.

There are two layers. At the input layer, a server-side prompt-injection probe scans tool outputs before they enter the agent's context and, if the content looks hostile, appends a warning "telling the agent to treat this content as suspect and anchor on what the user actually asked for." At the output layer, a transcript classifier gates each tool call before it runs.

Here is the load-bearing detail. That transcript classifier does not see the agent's own prose, and it does not see tool outputs. Anthropic strips both. Their term for it is "reasoning-blind by design," and the reasoning behind it is good: if the classifier reads the agent's justifications, the agent can talk its way past the classifier with lines like "this is safe because the user implicitly approved it earlier." Stripping tool results is the structural anti-injection move, since tool output is where hostile text enters. You cannot poison a judge that never reads the poison.

They also state the cost, in plain language, in their own post:

That is the trade. And the argument for why the trade is safe comes one sentence earlier:

Read that carefully, because it is correct, and it is the entire bet. The claim is that provenance is a luxury, because a dangerous action indicts itself. You do not need to know why the agent decided to POST your environment variables to an unknown host. The shape of the action is damning on its own. Strip the context, judge the deed, stay unpersuadable.

Now run the same logic against ./security.sh.

The user said "perform security testing." The command is a shell script named security.sh, sitting at the root of the project, referenced in that project's README as the project's own convention:

What, exactly, is the transcript classifier supposed to catch here? It sees a user message asking for security testing. It sees a tool call running a script called security.sh. That is not scope escalation. It is not a credential grep, not a force-push, not an exfiltration POST to an unrecognized domain. It matches no block rule because it violates nothing. It is the single most intent-aligned command in the entire session. The classifier approves it for the same reason a competent human reviewer skimming the transcript would approve it.

The one fact that would change the verdict is that the instruction to run security.sh came from a file inside the untrusted repository under review, rather than from the user or from the project's actual maintainers. That fact is provenance. Provenance is the input Anthropic deliberately removed.

So the exploit is not evading the classifier. There is nothing to evade. The classifier is working exactly as specified, on exactly the inputs it was designed to receive, and returning the correct answer to the question it was asked. It was just asked the wrong question, because the right question requires an input that was thrown away two layers upstream.

The researchers did have to do real work to get there, and the work tells you where the remaining friction is. They expected Claude Code to distrust a bare binary, so they shipped code_policies.go, a legitimate Go program that really does perform static checks, named to look like the binary's source. Claude Code often disassembles binaries before running them, so they seeded string constants from the Go file into the binary to make the association hold up. None of that is classifier evasion either. It is decoration for the agent's judgment, upstream of the classifier entirely.

The natural objection is that the transcript classifier is not alone. There is a whole other layer whose entire job is catching hostile text in tool output, and the README is tool output. Anthropic is explicit that the layers are meant to compound: an injection has to beat the probe, then steer the agent into emitting a call that the classifier independently judges safe and intent-aligned, "with the second layer blind to the payload that compromised the first."

That compounding is real, and against the canonical injection it works. But look at what the probe actually does when it fires. It does not block. It appends a warning telling the agent to treat the content skeptically and re-anchor on what the user actually asked for.

The user actually asked for security testing. Re-anchoring on user intent lands the agent exactly where the attacker wants it. The probe's remedy is the attack's cover story. Both layers are intent-based defenses, and the payload is intent-compliant, so the defenses are correlated in the one direction that matters. They are not really two independent layers against this attack. They are the same layer twice.

This is why the classic mental model misleads. We describe prompt injection as text that redirects the agent "from the user's task toward the attacker's" - that is Anthropic's own threat-model wording, and it describes threat number three on their list of four. Friendly Fire does not redirect anything. The user's task and the attacker's task are the same task. Only the implementation is swapped. Injection did not have to move the goal; it only had to supply the method.

The reflex is to assume this is a "current models" problem. It is not, and the evidence is unusually clean.

The payload was written against Sonnet 4.6. It then worked unchanged on Sonnet 5, on Opus 4.8 at high effort, and on GPT-5.5 in Codex. One injection, two vendors, four models, zero modifications. And the failure survives noticing. Per the brief, Sonnet 5 sometimes identifies that code_policies and code_policies.go do not belong to the upstream geopy repo, and runs the binary anyway. Opus 4.8 sometimes spots that the binary does not match its supposed source, and runs it anyway. Asked point-blank whether geopy contained prompt injection attempts, Sonnet 4.6 and GPT-5.5 both said no.

Smarter models did not help, because intelligence is not the bottleneck. The judgment was made without a fact, and being smarter does not conjure a fact you were not given.

There is a number in Anthropic's own post that predicts all of this, and it is the most important number in the whole story. On a curated set of 52 real overeager actions from live sessions, the deployed two-stage pipeline has a 17% false-negative rate. Anthropic calls it "the honest number," and their diagnosis of the misses is the part to sit with:

Approval-shaped evidence. That is the vulnerability, named and measured by the vendor four months before the exploit was published. The 17% was measured against accidents: an agent stumbling into approval-shaped evidence on its own. Friendly Fire is what the same failure looks like when someone manufactures the evidence on purpose. "Perform security testing" is approval-shaped evidence for running a security script, planted by an attacker who got to write the script. An accident rate under adversarial pressure is not an accident rate. It is an attack surface with a measured floor.

The exposure here is narrower than the headlines suggest, and the honest version of this argument has to say so. Auto mode is opt-in and off by default. The attack needs a command-capable agent, in that mode, pointed at code you do not control. If you review untrusted repos in the default prompting mode, none of this touches you today. Anthropic's provenance trade also remains right for the case they designed it for: a POST of your .env to an unknown host really does indict itself, and stripping tool results really does buy structural robustness against the injection class that constitutes most of the real-world traffic. Both of those things are true, and a fair reading has to hold them alongside the finding rather than pretend the design was careless. It was not careless. It was a trade, made explicitly, with the cost written down.

The two mitigations everyone reaches for are weaker than they look, though. Sandboxing is the obvious one, and it is worth doing, but it converts remote code execution into a sandbox-escape problem rather than a non-problem, and Claude Code's own sandbox has shipped escape bugs this year including CVE-2026-39861 and CVE-2026-25725. The other is "just review every action," which is where the 93% approval rate walks back onstage. Prompt fatigue is not a character flaw you can exhort your way out of, and the AI Now authors are right to lean on the automation-bias literature here. A mode that requires a human to catch what a classifier missed, on every action, forever, is not a mode anyone runs for long.

And the researchers' own recommendation, followed honestly, has teeth: do not hand untrusted code to an agent that can execute commands and reach your host. Which is awkward, because scanning untrusted third-party code is the exact use case both vendors are marketing. That is the uncomfortable part, and it should stay uncomfortable.

Stop treating "the agent stayed aligned with user intent" as a security property. It is not one. It is a security property only when the user's intent names a specific object. "Deploy the thing I named" is checkable. "Perform security testing," "fix the build," "review this repo," "clean up my branches" are verbs whose objects the environment gets to fill in, and whoever fills in the object is the one giving the order. Any command-capable agent working from a task description that vague is executing attacker-supplied nouns the moment the environment goes hostile.

So the practical question for your next architecture review is not "does our agent have guardrails." It is: when our agent proposes an action, can anything in the system tell where the instruction that motivated it came from? If the answer is no, then every intent-based check you have is scoring the action against a goal the attacker is free to satisfy however they like. The fix direction is provenance and taint tracking, not a smarter judge. A judge with better reasoning and no provenance returns the same wrong verdict with more confidence, which is roughly what Opus 4.8 did when it noticed the binary did not match its source and ran it anyway.

Concretely, for Monday. Draw the line at the data, not the mode: an agent that ingests untrusted content and an agent that can execute commands should not be the same agent in the same session, whatever your permission settings say. If you review third-party code with an agent, do it in a session with no shell and no credentials, and treat its output as a report rather than as actions. And if you want one tell to grep your transcripts for, take the one from the AI Now writeup: an agent executing a script or binary that nothing but a README or a docs file ever told it to run. That command will look perfectly reasonable. That is the point.