Prompt injection: why filters fail and what actually works
Not with filters. A model cannot tell where an instruction came from, so any defence that tries to spot a malicious one will eventually be talked past. What holds is constraining what the agent is able to do after it reads untrusted content, which is an architecture decision rather than a prompt.
Almost everyone selling agent security leads with the same product: a filter that inspects incoming content and blocks the malicious instructions before the model sees them. It is an appealing pitch. It sounds like antivirus, which buyers already understand, and it can be bolted onto a system that already exists without redesigning anything.
It does not hold, and the reason is worth understanding before you pay for one. Simon Willison, who named this problem in 2022, puts the arithmetic plainly: products in this space "almost always carry confident claims that they capture 95% of attacks or similar", and "in web application security 95% is very much a failing grade". A spam filter at 95% is genuinely useful, because spam is a volume business and the sender is not adapting to you specifically. An attacker with a target does adapt. They send the hundredth variation, and the hundredth variation is the only one that counts.
Why the model cannot help you here
The deeper problem is not that filters are badly built. It is that the thing they are protecting has no concept of where its instructions came from. Willison again: "LLMs are unable to reliably distinguish the importance of instructions based on where they came from."
Everything the model receives becomes one flat sequence of tokens. Your system prompt, the user's question, the body of the email it just opened, the contents of the web page it fetched, the ticket description a customer typed. There is no channel in that sequence that marks the first two as authoritative and the rest as inert data. The model infers authority from phrasing and position, which is exactly the thing an attacker controls.
That is why the most common mitigation, adding a line to the system prompt telling the model to ignore any instructions it finds in retrieved content, is not a control. It is a request, addressed to the same component the attacker is talking to, competing on equal terms with whatever the attacker wrote. It raises the effort required. It does not change the outcome of a determined attempt.
We have made a narrower version of this point twice already: in MCP integration, where tool results are untrusted input, and in agent to agent interoperability, where another agent's output is untrusted input. Prompt injection is the general case of both.
What holds when the model is fooled
Once you accept that the model will sometimes be talked into something, the useful question changes. It stops being "how do we stop the bad instruction arriving" and becomes "what is this agent able to do at the moment it is fooled". That second question has an answer you can engineer, because it does not depend on the model behaving.
A June 2025 paper by fourteen researchers drawn from Google, Microsoft, IBM, ETH Zurich and four other institutions states the principle better than we would: "once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions."
Read that as an engineering instruction rather than a slogan, and it has teeth. It means the decision about what an agent may do has to be made before it reads anything untrusted, not inferred afterwards from what it read. It means an agent that has just processed a customer email should not, in that same step, still be holding the ability to issue a refund, send mail to an arbitrary address, or query a table it did not need. In practice the shape that works is separating the part that reads from the part that acts: the reading step produces a constrained, checkable result, and the acting step operates only on that result with permissions fixed in advance.
This is where the field has settled. Anthropic's write up on containing Claude across products says it directly, that "protection in the model layer will never be 100% effective, which is why it cannot stand alone", and prompt injection sits at LLM01:2025, first position in the OWASP Top 10 for LLM Applications.
The cost nobody quotes you
Constraining an agent makes it less capable. Any vendor who tells you their defence is free is either not measuring or not telling you, and pretending the trade does not exist is how teams end up with a secure design nobody is willing to ship.
The most honest published number comes from CaMeL, Google DeepMind's March 2025 work on defeating prompt injection by design. Their result: "solving 77% of tasks with provable security (compared to 84% with an undefended system) in AgentDojo". Seven points of task completion, given up in exchange for a guarantee that holds whether or not the model is fooled.
Seven points is the real price of the strong version, from the team that measured it. Budget for a capability cost in that region rather than assuming zero, and decide deliberately which actions are worth paying it for. Most systems do not need every action constrained, only the ones that spend money, move data, or cannot be undone.
The test that tells you whether this applies to you
Not every AI feature needs this treatment, and treating them all the same is how security work stalls. Willison's framing is the most practical diagnostic we have found. Risk concentrates when a single agent holds all three of the following at once:
- Access to private data. Customer records, internal documents, anything you would not publish.
- Exposure to untrusted content. Email, uploaded files, web pages, support tickets, anything written by someone outside your organisation.
- A way to communicate externally. Sending mail, calling a webhook, writing to a system someone else reads, even rendering a link the user might click.
Any two of these is usually a design problem you can solve by removing the third, and that is the cheapest fix available. An agent that reads untrusted email and holds private data, but genuinely cannot transmit anything outward, has no route to exfiltrate. An agent that reads untrusted content and can send mail, but was never given access to anything sensitive, has nothing worth sending.
All three in one agent, with nothing separating the reading from the acting, is the configuration that gets exploited. If that describes something you are about to launch, the work to do is not choosing a filter vendor. It is deciding which actions are consequential, fixing those permissions before any untrusted content is read, and putting a human in front of the ones that cannot be reversed.
If you want a second pair of eyes on where your agent sits against that test, our free AI audit includes a review of agent permissions and blast radius, and we can take it further into a security architecture engagement if the answer is uncomfortable.
Related reading
Get this applied to your business.
The free AI audit measures your live setup and shows where AI would actually pay off.