You Can't Filter Out Prompt Injection — Here's What Actually Works
Anthropic put professional red teamers against a browser agent across 129 web environments held back from training. Before the extra defences switched on, at least one attack landed in nearly two-thirds of them. Prompt injection has topped the OWASP list for LLM applications in every edition since 2023 — three years, no fix. This episode explains why it can't be filtered out the way SQL injection eventually was.
The Promise
- The models are improving and the measurements are getting honest. The same model that failed 3.7% of browser attacks with product defences off is a real step forward, and the lab published both numbers.
- The control that limits the damage works today. OWASP moved excessive agency from sixth to third in its August 2026 list, because deciding what an agent may do is something you can actually enforce.
- The tool-permission audit takes about 20 minutes: list every action the agent can take without approval, mark the ones an attacker would want, and put those behind a human.
The Risk
- Prompt injection has been number one on the OWASP Top 10 for LLM applications in every edition since 2023. Instruction and data arrive on one stream of tokens, and there is no second channel to separate them.
- The surface decides the outcome. An adaptive attacker in a coding environment succeeded on about 7% of single attempts; in a browser, roughly a third of attempts got through and nearly two-thirds of environments were reachable.
- The widely quoted 0% across 1,290 browser attempts came with vendor-side classifiers switched on. The zero was produced by a layer outside the model, one the vendor builds, runs and updates.
- The surface that fails worst is the surface everyone is shipping fastest.
Three years at number one
On 4 August 2026, OWASP published the third edition of its Top 10 for large language model applications. Eight of the ten entries moved. Prompt injection did not. It has been number one in every edition since the list first appeared in 2023.
Three years at the top of a security list means one of two things. Either nobody is working on it, or it cannot be fixed the way the other nine can.
The entry that actually moved is the one almost nobody wrote about. Excessive agency climbed from sixth place to third. Prevention stayed where it was, unsolved. The control that limits the damage jumped three places.
Why a filter can’t fix it
SQL injection was the same category of problem: an attacker wrote input the database read as instruction. For years the industry tried to filter its way out with block lists, escaping and pattern matching. It half worked, which is the worst outcome, because half-working defences produce confidence.
The fix was not a better filter. It was parameterised queries. Query and data travel in separate channels, and the database is told structurally which is which. The problem did not get filtered. It got designed out.
A language model has no second channel. The system prompt, the user’s question, a retrieved document, a tool’s output and last Tuesday’s conversation all arrive as tokens on one stream. When a web page contains a sentence shaped like an order, the model is not being tricked in any exotic sense. It is doing what it was built to do. Every mitigation published so far reduces the probability; none of them is a fix.
Same model, different surface
Everything here comes from Anthropic’s own system cards: vendor-reported, on vendor infrastructure. Read it as a floor.
Against an adaptive attacker in a coding environment, single-attempt success came in around 7%, falling to about 2% with the outer defences on. Move the same class of attack to a browser, across 129 environments with ten tries each, and roughly a third of attempts got through. Count environments instead, and at least one attack landed in nearly two-thirds of them. Same data, two cuts: how often an attack works, and how many of your surfaces are reachable at all.
Then the Opus 5 card reported 0% across 1,290 browser attempts. The next line down is the episode. That zero came with product-side defences enabled, one system inspecting what the agent reads and another inspecting what it is about to do. With those layers off, the same model failed at 3.7%.
I watched this play out for 25 years in security. We spent the early 2000s trying to stop every piece of malware at the perimeter, got good at it, and never got to zero. Eventually the question changed: stop asking how to keep the bad thing out, and start asking what it can reach once it is in. That was segmentation. That was least privilege. AI security is making the same turn on a shorter clock.
The 20-minute audit
One. Open the configuration for the agent you already run and write down every action it can take without a human approving it. Not what it is supposed to do. What it can do.
Two. For each line, ask what an attacker would do with it. Read-only is a nuisance. Sending mail, opening pull requests, moving money or calling an external endpoint is your actual exposure.
Three. Put that second list behind an approval step. You are not trying to stop the model being fooled. You are deciding what it may do while it is fooled.
You cannot filter your way out of this one. You can decide in advance, and in writing, what your agent is allowed to do on a bad day.