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

Contents
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.
| Surface | Who can write there |
|---|---|
| Repository issues and comments | anyone, on an open project |
| A dependency's README and changelog | whoever maintains the package, and whoever compromises it |
| A web page the agent opens | the site owner, and whoever posts a comment on it |
| Email and incoming messages | any sender |
| A tool or MCP server response | whoever controls the server |
| A file the user uploads | whoever produced the file earlier |
| Memory from earlier sessions | whoever 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 reported | What happened under adaptive attack |
|---|---|
| Most of the 12 published an attack success rate close to zero | Above 90% on most of them |
| Model-based filters: Protect AI Detector, PromptGuard, PIGuard, Model Armor | Bypassed |
| Secret-knowledge defenses: Data Sentinel, MELON | Bypassed |
| Adversarial training and other techniques | Bypassed |
| — | 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.
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%.
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:
- 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.
- 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.
- Which safeguards were on? Anthropic's number holds for their configuration, with the protections active. It describes no bare model behind an API.
- 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'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:
| Configuration | A | B | C | Verdict |
|---|---|---|---|---|
| Reads public issues, accesses private code and opens a pull request | yes | yes | yes | no unsupervised run |
| Reads public issues and hands a diff to someone to apply | yes | yes | no | acceptable |
| Summarizes your email, sending nothing | yes | yes | no | acceptable |
| Summarizes your email and can reply | yes | yes | yes | no unsupervised run |
| Runs tests on the private repository and comments on the pull request | no | yes | yes | acceptable |
| Searches the web and writes in a document of yours | yes | no | yes | acceptable |
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.
- 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.
- 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.
- 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.
- 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.
- 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.
Read next
Motion •
Motion Design for the Web: The Complete Guide
Scroll, text, images and video: the complete catalog of motion techniques for the web, with implementation in Next.js and the cases where each one pays off.
- motion
- scroll
The definitive guide — a Next.js site built around motion and scroll
The scroll foundation that, when missing, keeps the animations from working at all: Lenis, GSAP and Next.js wired in the right order and the mistakes to avoid.
- next.js
- lenis
Infra •
Documentation: deploying a Next.js application with GitHub + Hostinger
Every push becomes a live site with no hosting panel involved: connecting GitHub to Hostinger, the build settings that break and the checks after each deploy.
- deploy
- github


