Prompt injection is a category mistake

Half the security industry is trying to figure out how to sanitize LLM input. Better filters, better classifiers, more fences. Every quarter there is a new benchmark for how well your model resists adversarial prompts.

It is all defense in a category that should not exist.

The bug is upstream. If your architecture lets external content (an email, a web page, a document, a ticket title) become instructions to the model, you have already collapsed two things that should never have shared a channel. The model cannot tell the difference between “the user wants you to do X” and “the email says you should do X” because both arrive as text in the same context window at the same priority.

That is a type system problem. People keep treating it like a filtering problem.

The fix is structural. The user’s intent goes in as instructions. External content goes in as a thing to analyze, never a thing to obey. The system prompt is sealed. Actions, meaning anything that touches the world outside the model, require a named tool call. The destructive ones require a human approval that the model cannot self-issue, retry around, or chain past.

Once the boundary is real, prompt injection stops being a content problem. The worst a poisoned email can do is make the model try to call a destructive tool. It cannot change what the tool does, because the tool’s code was written by you, not by the model.

Stop trying to harden the model. Harden the boundary, and whether the model can be tricked stops being load-bearing. That is the work the security industry has been postponing for a decade.