Skip to content
Zumkai

Prompt injection: why there is no definitive fix, and what to do anyway

Twelve prompt injection defenses reporting near-zero rates were broken above 90%. Why the problem is structural and what reduces risk.

  • prompt injection
  • agent security
Card contrasting the twelve defenses that reported near-zero rates with the over 90% success under adaptive attack.
Contents
  1. Prompt injection is no class of bug
  2. The paper that broke twelve defenses
  3. Why the published numbers resist comparison
  4. The honesty of the one with the best number
  5. What reduces risk for real: architecture
  6. What layered defense actually buys
  7. What you can do this week
  8. Frequently asked questions
  9. What to take away

Twelve published defenses against prompt injection got bypassed with over 90% success. Most of them had reported, in their own original papers, an attack success rate close to zero.

Fourteen researchers did it, with people from OpenAI, Anthropic and Google DeepMind signing the same work. The result came out in October 2025 and changed what saying a defense works means.

The conclusion is not that those twelve defenses were bad. It is that the ruler was wrong: all of them faced only static attack in evaluation, and none faced someone studying the defense's design before attacking.

Prompt injection is no class of bug

The model receives instruction and data through the same channel, as text, and it has no reliable mechanism for separating the two. That property is what the attack exploits.

A SQL injection gets solved with a prepared statement, because the database starts receiving command and parameter through different paths. In a language model, that separate path does not exist. You can ask it to ignore instructions coming from external content, and it will obey most of the time, which differs from a guarantee.

One confusion that search results scramble is worth undoing. Jailbreak is the user working around the model's own policy. Prompt injection is a third party placing text in the agent's path so it acts on the user's behalf, against the user. The second is graver, because the victim takes no part.

The size of the problem shows up on the OWASP list: among the ten risks in the Top 10 for agents, injection maps to six. The case that opened that category was EchoLeak, CVE-2025-32711, where a single email with hidden instructions made Microsoft 365 Copilot fetch and exfiltrate internal data, with no click at all.

Where the text comes in

Before defending, mapping the surface pays off. Every place the agent reads content that another person can write is an entry point.

SurfaceWho can write there
Repository issues and commentsanyone, on an open project
A dependency's README and changelogwhoever maintains the package, and whoever compromises it
A web page the agent opensthe site owner, and whoever posts a comment on it
Email and incoming messagesany sender
A tool or MCP server responsewhoever controls the server
A file the user uploadswhoever produced the file earlier
Memory from earlier sessionswhoever landed any of the items above

The last row is the one that tends to go unnoticed, and it is the one that gives reach across time: an instruction planted once can get reread for weeks.

Note that connecting an MCP server adds a whole row to that table. The tool widens what the agent can do and, in the same motion, widens where it accepts text from.

The paper that broke twelve defenses

On 10 October 2025, fourteen authors published "The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections" (arXiv 2510.09023, accessed 27 August 2026). The group includes Milad Nasr, Nicholas Carlini and Chawin Sitawarin, with researchers from OpenAI, Anthropic and Google DeepMind in the same work.

The method was direct: take already published defenses and attack them with adaptive adversaries, which study the defense's design and tune their strategy against it. Four families of technique entered the count: gradient descent, reinforcement learning, random search and human-guided exploration.

What the defense reportedWhat happened under adaptive attack
Most of the 12 published an attack success rate close to zeroAbove 90% on most of them
Model-based filters: Protect AI Detector, PromptGuard, PIGuard, Model ArmorBypassed
Secret-knowledge defenses: Data Sentinel, MELONBypassed
Adversarial training and other techniquesBypassed
Human red teaming: 100%

The finding that matters sits in the distance between the two columns. Going from 2% to 8% would be noise. A defense published as all but impenetrable fell almost every time, as soon as someone put real effort into the problem.

The lesson holds beyond this subject: a security number measured against static attack produces false confidence. Whenever you read a low success rate, the useful question is which adversary it faced.

Why the published numbers resist comparison

<!-- [UNIQUE INSIGHT] -->

The same model, evaluated in the same month, shows up at 1% and at 63% attack success. Both measurements are legitimate, and comparing one with the other is not.

Two measurements of the same model, with different methods Claude Opus 4.5 shows up at 1% attack success in Anthropic's measurement, run in a browser with safeguards on and a Best-of-N attacker over 100 attempts, and at 63% in Gray Swan's measurement, with strong curated attacks over 100 attempts. Claude Opus 4.5 · attack success over 100 attempts Anthropic browser, safeguards on Best-of-N attacker 1% Gray Swan curated "very strong" attack escalation by attempt 63% Both are right. The difference is what each one calls an attack.
Sources: Anthropic, research on defenses in browser use; Gray Swan, benchmark of 25 November 2025.

Anthropic measured Claude Opus 4.5 with the Claude for Chrome extension, safeguards active, against an adaptive Best-of-N attacker with 100 attempts per environment, and published 1% (Anthropic, accessed 27 August 2026). Gray Swan measured the same model with curated attacks classified as very strong and published 4.7% on one attempt, 33.6% on ten and 63% on a hundred, on 25 November 2025 (The Decoder, accessed 27 August 2026). In the same round, Gemini 3 Pro and GPT-5.1 reached 92%.

Attack success scales with the number of attempts In Gray Swan's measurement, Claude Opus 4.5 goes from 4.7% attack success on one attempt to 33.6% on ten attempts and 63% on a hundred attempts. 1 attempt 4.7% 10 attempts 33.6% 100 attempts 63% a rate with no attempt count beside it tells you nothing
Source: Gray Swan benchmark on Claude Opus 4.5, November 2025.

The second chart shows where the real axis sits. An attempt is cheap for the attacker: an agent reading issue comments or dependencies receives hundreds of opportunities a week without anyone having to push. A rate measured over one attempt describes a scenario that does not exist in production.

Hence this post's explicit judgment: an attack success rate published without the attempt count and the attacker type beside it tells you nothing. And that holds for the numbers I cited here myself, which came in accompanied by the method.

The difficulty is structural in the market, not a lapse by whoever writes it up. Comparing the reports of four large labs in June 2026, VentureBeat observed that none of them used a common framework or a shared adversarial suite. Anthropic reported a browser agent hijack rate, while OpenAI, Google and Meta measured indirect injection in tool calls or in document summarization. Different questions under the same label.

The honesty of the one with the best number

Whoever publishes the market's best result is the one saying, in the same text, that the problem stays open.

Anthropic writes that 1% attack success, while a significant improvement, still represents relevant risk, that no browser agent is immune to prompt injection, and that it shares the results to demonstrate progress, without claiming to have solved the problem. It treats the question as "far from a solved problem", above all as models start taking more actions in the real world.

Keep that as a commercial ruler. Any vendor offering total protection against prompt injection is claiming more than the best public number supports.

Once a rate shows up on a product page, four questions separate measurement from marketing:

  1. How many attempts per environment? Without that number, the rate has no meaning. The difference between one and a hundred attempts was 4.7% to 63% in the same measurement.
  2. What type of attacker? A static attack from a ready-made list and an adaptive adversary that studied the defense's design are different adversaries. That distinction is what took down the twelve defenses.
  3. Which safeguards were on? Anthropic's number holds for their configuration, with the protections active. It describes no bare model behind an API.
  4. In what environment? Browser, tool call and document summarization produce different numbers, and that is why the four labs' reports resist comparison.

If the page answers none of the four, the number it publishes serves communication, not decisions. It is the same criterion I used when evaluating what changes when you take Claude Code to production: transparency about failure counts in your favor, and a promise of immunity counts against.

What reduces risk for real: architecture

The defenses that fell in the paper had something in common: they depended on the model resisting. The two approaches that survive better change the system's design, so that resisting stops being necessary.

Separating who reads from who acts

In March 2025, Google DeepMind published Defeating Prompt Injections by Design, describing CaMeL (arXiv 2503.18813, accessed 27 August 2026). The idea is old in software security and new in this context: capability tracking and control flow integrity.

The system uses two models with distinct roles. A privileged LLM sees only the trusted user query and generates Python code representing the intended task. A dedicated interpreter runs that code and tracks, for each piece of data, metadata about origin and permitted use. A quarantined LLM processes the untrusted content and has access to no tool at all.

The benchmark result was defending 67% of attacks, reaching zero successful attacks on some models. It is no immunity, and the difference in nature is what matters: the guarantee starts coming from where the data can travel, and not from the model's willingness to obey.

If you already split work between agents, that boundary is a design decision and not a prompt one, the same reasoning as when to delegate to a subagent, here with validation between them becoming a requirement.

The Rule of Two

On 31 October 2025, Meta AI published the easiest formulation to apply that I found in this research (Simon Willison's summary, 2 November 2025). An agent session should combine no more than two of these three properties:

The Rule of Two for agent sessions An agent session should combine no more than two of: processing untrusted input, accessing sensitive data, and changing state or communicating outward. Two-property combinations are acceptable; all three together require a fresh context or human supervision. A untrusted input B sensitive or private data C change state or speak outward Two per session at most A + B ok A + C ok B + C ok A+B+C no With all three together, the session needs a fresh context or a human in the loop. Short of that, the agent should not operate alone.
Source: Agents Rule of Two, Meta AI, 31 October 2025.

The rule's value lies in failing a design before it costs money. An agent that reads repository issues (A), has access to the private source code (B) and can open a pull request (C) gathers all three, and it is the most common coding agent configuration there is. By the rule, it should not run unsupervised.

Two honest ways out of that case. Either the agent loses C and starts producing a diff someone applies. Or it loses A, and the issues come in through a path a person already validated.

Classifying takes minutes. It is worth doing with the agents already running on your machine:

ConfigurationABCVerdict
Reads public issues, accesses private code and opens a pull requestyesyesyesno unsupervised run
Reads public issues and hands a diff to someone to applyyesyesnoacceptable
Summarizes your email, sending nothingyesyesnoacceptable
Summarizes your email and can replyyesyesyesno unsupervised run
Runs tests on the private repository and comments on the pull requestnoyesyesacceptable
Searches the web and writes in a document of yoursyesnoyesacceptable

The fourth row deserves attention. An assistant that reads and answers email on its own is among the first agents anyone builds, and it gathers all three properties. It was EchoLeak's shape.

The fifth row shows the other side. That agent touches sensitive data and changes state, and it is still defensible, because nothing from outside enters its context. Notice that the verdict depends on nothing about how much power the agent has. It depends on whether that power touches text a stranger wrote.

One uncomfortable observation is worth recording: CaMeL came out in March 2025 and, over a year later, the two-model architecture with a capability interpreter remains rare in products. Someone has already described the path. Adopting it costs a rewrite of the orchestration, and almost everyone preferred to stay with the filter.

What layered defense actually buys

A filter guarantees nothing, and it is still worth having. Both statements coexist, and conflating them leads to two opposite errors: trusting the classifier as though it were a barrier, or abandoning it because it is not one.

A filtering layer delivers this much, in verifiable terms:

It reduces volume. Most of what arrives is no adaptive attack designed against your system. It is a generic, copied attempt that a classifier stops. That frees human attention for the rest.

It imposes cost. The techniques that broke the twelve defenses in the October paper consumed gradient descent, reinforcement learning and hours of human exploration. None of that is free. Against most targets, the attacker gives up first, because a cheaper target exists.

It produces signal. A blocked attempt is a record with a time, an origin and content. Without the layer, the same event passes unseen. And escalation by attempt, the indicator that shows up first, exists only if someone is counting.

It fails to deliver a guarantee against whoever studies the design before attacking. That is the boundary, and it is sharp: a filtering layer works on top of probability, an architecture layer works on top of possibility. Taking the tool out of the agent's reach changes what is possible; training a filter changes what is probable.

The practical conclusion belongs to Anthropic, who run both things together and still publish that 1% attack success represents relevant risk. Layers subtract risk; none of them zeroes it.

What you can do this week

None of these steps requires switching models or waiting for a fix that never comes.

  1. Classify each agent by the Rule of Two. It takes an hour, costs nothing and fails designs before they reach production. Start with the agents already running.
  2. Take the dangerous tool out of reach instead of asking for care. An instruction in the prompt covers the case where the model obeys; removing the tool covers the rest. That is the subject of permissions and auto mode, and Cursor's CVE showed the cost of trusting the allowlist.
  3. Separate the task channel from the material channel. What arrives from outside comes in marked as data, and what the agent executes comes from a path that passed through a person.
  4. Decide what memory has the right to keep. An instruction planted today gets read weeks from now, when nobody connects the strange behavior to its origin any more. The criterion for what the agent keeps between steps is a security criterion too.
  5. Record attempts, and not only successes. Escalation by attempt is the signal that appears first, and counting the attempts is the only way to see it. A spike of strange external content reaching the agent precedes the incident.

Those five measures fall across the harness's five layers, and none of them depends on the model resisting better.

Frequently asked questions

What is prompt injection?

It is the attack where a third party inserts instructions into content the agent will read (an email, a README, an issue comment, a web page) so the agent executes the attacker's intent while believing it is doing the user's task. It works because instruction and data reach the model through the same channel, as text, with no reliable separation mechanism.

Does prompt injection have a definitive solution?

No. In October 2025, a paper with authors from OpenAI, Anthropic and Google DeepMind bypassed 12 published defenses with over 90% success, and most of them had reported near-zero rates; human red teaming reached 100%. Anthropic itself, publisher of the market's best number, states the problem is far from solved. Risk reduction through architecture is what exists.

What is the difference between prompt injection and jailbreak?

Jailbreak is the system's user trying to get around the model's policy to obtain an answer it should not give. Prompt injection is a third party placing text in the agent's path so it acts on the user's behalf and against their interest. In injection, the victim takes no part in the attack and often never notices.

Does a prompt filter or classifier solve it?

Not on its own. Among the defenses bypassed in the October 2025 paper were model-based filters such as Protect AI Detector, PromptGuard, PIGuard and Model Armor. A classifier reduces the volume of trivial attack, which has value, and it supports no promise of blocking an adversary tuning strategy against the filter's design.

Can an agent go to production with that risk open?

It can, by the same logic that puts software in production knowing undiscovered vulnerabilities exist: by limiting the possible damage. Classify the session by the Rule of Two, reduce what the triggered tool can do, isolate execution and record enough to investigate. The risk left over should be a risk you accepted on purpose.

What to take away

  • Twelve published defenses fell above 90% under adaptive attack, and most had reported near-zero rates. Human red teaming: 100%.
  • Injection is a structural property of a system that interprets natural language. No equivalent of the prepared statement exists.
  • A rate with no method beside it tells you nothing. The same model shows up at 1% and 63% depending on who measures, and the labs use no common adversarial suite.
  • What works comes from the design: separate whoever reads untrusted data from whoever calls tools, and never join the three properties of the Rule of Two.
  • CaMeL came out in March 2025 and remains little adopted. The path exists; the cost is rewriting the orchestration.

The next post in the cluster covers the layer that closes most of these risks: where to lock the agent before it acts. The foundation for all of it continues in the pillar on harness engineering, which describes the five layers these defenses fit into.