Prompt injection: why detection is not a control

Why filtering does not close this

A model receives one stream of tokens. Your system prompt, the user message and the contents of a document the agent retrieved all arrive in the same channel, and nothing in the architecture marks which of them carries authority. Injection is not a bug in a particular model; it is a consequence of instructions and data being the same medium.

That is why detection degrades. Blocking phrases like "ignore previous instructions" catches the naive case and nothing else, because the same intent survives paraphrase, translation, encoding and indirection. A classifier raises the cost of the attack. It does not bound the outcome, and controls that reduce likelihood without bounding impact are the ones that fail quietly.

Indirect injection is the case that matters

Direct injection, where a user types a hostile instruction, is the demo. It is also the least interesting version, because the attacker already has whatever access their own account carries.

The real exposure is indirect: the payload is planted in content the agent will later read. A support ticket, a web page, a PDF, a calendar invite, a code comment. The agent retrieves it in the course of doing legitimate work and executes the instruction on behalf of a user who never saw it. There is no hostile user in the transcript, which is precisely why it is hard to spot afterwards.

Bound the blast radius instead

If you accept that the agent will sometimes act on an instruction it should not have followed, the question becomes what that agent is able to do at its worst. That is a governance question, not a detection one, and it has tractable answers:

• Scope the agent to the data it actually needs, so a compromise reaches less.
• Intersect agent permissions with the requesting user's, so injection cannot escalate.
• Require human approval for irreversible actions: payments, deletions, external sends.
• Treat retrieved content as untrusted input, never as instruction, in your own orchestration.
• Record every tool call with its trigger, so the path is reconstructible afterwards.
• Alert on behavioural deviation, since a compromised agent stops resembling its baseline.

The approval gate is doing the real work

Of those, the human gate on irreversible actions is the one that converts a breach into an incident report. An agent that has been successfully injected but can only propose a payment, not execute one, has produced an alert instead of a loss.

The design constraint is that the gate must be narrow enough to stay meaningful. Route everything to a human and reviewers approve reflexively within days, which is worse than no gate because it manufactures evidence of oversight that did not occur. Gate the small set of actions that are genuinely irreversible, and give the reviewer the context to judge.

What to tell an auditor

Nobody can claim immunity to prompt injection, and a vendor who does is telling you they have not thought about it. The defensible position is different: here are the actions an agent cannot take without a human, here is the scope each agent holds, here is the record of what was proposed and approved, and here is how we would detect and reconstruct a compromise.

That is a claim about containment and evidence, and unlike a claim about prevention it survives contact with a determined attacker.