Prompt injection is not a bug

The security community got here first and has been admirably loud about it, and that deserves saying plainly. Prompt injection — an agent reading content from the world and treating what it finds there as instruction — is the failure mode that actually reaches production. Not the exotic scenarios that fill risk workshops. An agent reads a document, a page, an inbound email, a support ticket, and somewhere in that content sits text shaped like a directive, and the agent obliges. The defensive work that has grown up around this is serious engineering by serious people: filtering what comes in, ranking instructions by trust, separating the reasoning layer from the tools it can reach, constraining what the output is allowed to be. It reduces real risk. Nothing here argues against any of it, and we would tell any client running agents in production to do all of it and to keep doing it.

Our disagreement is with the category, not the work. Almost everyone treats this as a vulnerability, and a vulnerability, by the grammar of the word, is a thing you patch. Every mature engineering organization has a reflex built around that word — find the flaw, close it, verify closed, move on. Applied here, the reflex quietly promises something that is not coming.

The exploit is the feature

The exploitable property and the useful property are the same property. You bought an agent precisely because it takes in unstructured content nobody prepared it for — a contract, a thread, a page, a ticket — and works out what to do about it. That is the capability. A system that reads its environment and derives intent from it is not a system with an injection weakness bolted onto the side; it is a system whose entire job is to be instructed by what it reads. Injection is not a flaw in that design. It is that design, seen by an adversary.

Which is why the strongest defenses tend to have a family resemblance to lobotomies. Narrow what the agent will accept direction from, and you narrow the range of situations it can handle without a human first translating them into something safe. Push that far enough and what you are left with is not a safer agent. It is a worse one — a parser with a language model attached, which is a thing you could always have built and mostly chose not to.

Why prompt injection is not SQL injection

The analogy everyone reaches for is the one that misleads them. SQL injection was a genuine bug with a genuine fix, and the fix worked because there was a real boundary to enforce. Code was code and data was data, the categories existed independently of the attacker, and parameterized queries simply made the machine respect a distinction that was already true. The patch was possible because the line was already there.

Here there is no such line. The model has one channel, and everything arrives on it. The system's own instructions, the user's request, the retrieved document, the tool's response, the text sitting in a page footer — all of it lands as the same kind of thing and is weighed by the same faculty. You can raise the cost of confusion, and you should. You can make a model far more suspicious of content that arrives from somewhere low-trust. What you cannot do is make the categories genuinely distinct, because that ambiguity is not an oversight in the engineering. It is the mechanism by which the system handles input nobody anticipated. Sharpen the boundary far enough and you have described a rules engine.

Scope by reversibility

This moves the problem out of security tooling and into territory we have argued before: agentic AI risk is a delegation problem, not a defense problem. The question stops being whether you can keep the agent from being misled. Assume you cannot. Assume that on an ordinary Tuesday it will read something crafted and believe it. The useful question is what the worst thing is that a misled agent can do before a human sees it — and that question gets sharpest wherever the agent is working inside a person's own credentials, which is the ordinary condition of a browser agent.

Framed that way, the only variable you fully control is the consequence set. And the discipline that follows is to scope by reversibility rather than by likelihood. A draft sent to the wrong reviewer is embarrassing and recoverable. A payment is neither, which is why the sharpest form of this problem shows up wherever an agent holds something that cannot be taken back. Most risk registers rank by probability, which sorts the list in almost exactly the wrong order — the frequent, cheap, visible failures rise to the top, and the rare, silent, unrecoverable one sits three pages down under a comfortable score. An unlikely irreversible action is worse than a likely reversible one. Almost nobody's register is built that way.

Defenses that mostly work

There is a second-order cost here that deserves its own accounting, and it is the one we watch good teams walk into. A defense that catches most attempts is, in one specific way, more dangerous than a defense that catches few. It moves the failure from frequent-and-visible to rare-and-unexamined.

It is the same trade we have described elsewhere: the filter that quietly absorbs a thousand attempts also absorbs the knowledge that a thousand attempts were made. The incident count goes to zero, the quarterly review notes that the concern was overstated, scope creeps outward because nothing has gone wrong, and the attention that was on the agent moves to whatever is currently on fire. Then the one that gets through arrives into an organization that has spent two quarters learning not to look.

So instrument for attempts, not only for breaches. The number worth putting in front of an executive is not how many injections succeeded — that number reads zero right up until it doesn't, and while it reads zero it tells you nothing. It is how many were attempted, from which surfaces, aimed at which permissions. That is the number that tells you whether the environment your agent reads from has turned adversarial, and it is the one that lets you tighten scope before rather than after.

What you bought, what you permit

None of this is an argument for less security engineering. It is an argument about where the remaining risk lives once that engineering has been done well. Treat compromise as the design premise rather than the incident. Bound the agent's authority to actions you can reverse or review, and hold that bound even when the defenses are performing beautifully — because their performing beautifully is not evidence about the day they don't.

You cannot patch this without removing the capability you bought. That is the trade, and it has no clever way out. So stop asking whether your agent can be fooled. Assume it will be. Start asking what it is permitted to do on the day it is.