Most teams meet prompt injection as a content problem. A user, or a document the system retrieved, contains text that reads like an instruction, the model follows it, and something happens that nobody intended. The instinctive response is to filter: detect the malicious phrasing, strip it out, tell the model in the system prompt to ignore instructions found in user content.
That approach helps at the margins and fails as a security control. There is no reliable classifier for “text that is an instruction”, the input space is unbounded, and every filter is a pattern an attacker can rephrase around. If your defence depends on correctly labelling adversarial natural language, you have signed up for an arms race you cannot win.
The more useful framing is that prompt injection is an authorisation problem.
The model is a confused deputy
The classic confused deputy has legitimate privileges and is tricked into using them on behalf of someone who should not have them. An LLM with tool access fits exactly. It holds credentials — a database connection, an internal API token, an email integration — and it decides how to use them based on text, some of which comes from people you do not trust.
Framed that way, the question stops being “was that input malicious?” and becomes the question we already know how to answer: what is this execution allowed to do, and on whose behalf?
Four controls that actually hold
Scope every tool call to the end user’s own permissions. If a support agent can only see their own tickets, the model acting for that user must inherit that restriction at the data layer — not through an instruction in the prompt. A retrieval pipeline that queries an index built with service-account privileges will happily return documents the requesting user could never open, and no amount of prompt engineering fixes that.
Separate the trusted plan from the untrusted content. Retrieved documents, tool output and third-party API responses are data, not instructions. Keep them in a clearly delimited channel, and make the set of permitted actions a property of the application’s control flow rather than something the model can expand by reading a web page.
Make dangerous actions require something the model cannot supply. Sending money, deleting data, emailing an external address, changing permissions — these should sit behind a human confirmation, a second authorisation factor, or an out-of-band approval. If the worst outcome of a successful injection requires a human click, injection becomes an annoyance rather than an incident.
Constrain the blast radius of every integration. Short-lived credentials, per-tenant scoping, egress allow-lists, and separate identities per tool. The same least-privilege work you would do for any service, applied to a component that happens to make decisions from text.
Where filtering still earns its place
Input and output handling is worth doing — as defence in depth, not as the control you rely on. Output encoding matters especially: model output rendered into a page, a shell, a SQL statement or another model’s prompt is untrusted input to that downstream system, and the injection that matters is often the second one, not the first.
Adversarial evaluation belongs in CI. A suite of known injection patterns run against every release will not prove safety, but it will catch the regression where someone widens a tool’s scope without noticing.
The practical test
When we threat model an AI system, one question tends to settle the design:
If an attacker had full control over every token the model reads, what is the worst thing they could cause the system to do?
If the answer involves data crossing a tenant boundary, an irreversible action, or a privileged API call, the architecture needs to change. If the answer is “produce embarrassing text”, you have a content-moderation problem — which is real, but it is not a breach.
Prompt injection is not going to be solved at the model layer any time soon. Systems built on the assumption that it will be are the ones that will need rebuilding.