Prompt Injection Isn't a Bug You Patch. It's an Architecture You Design Around.

Prompt injection gets filed as a vulnerability, and vulnerabilities get patched. So teams reach for the familiar reflex: add an input filter, strip the suspicious phrases, ship the fix, close the ticket. The reflex is wrong. Prompt injection is not a defect in a particular model that a particular release will correct. It is a direct consequence of how large language models read their input, and it will still be here after the next model upgrade.

The root cause is simple to state and uncomfortable to sit with. A language model consumes one undifferentiated stream of tokens. Your system prompt, the user's message, a retrieved document, the output of a tool — all of it arrives as the same kind of text, and none of it carries a trustworthy label that says instruction or data. To the model there is no hard boundary between the two, because in natural language there is none.

Why you can't filter your way out

The instinct to filter assumes the attack has a signature. Block ignore previous instructions, catch a handful of jailbreak phrases, and the problem seems to shrink. In practice the input space is natural language itself, and natural language is infinitely paraphrasable. An instruction can be reworded, translated into another language, spelled with lookalike characters, encoded and then politely explained, hidden in a comment, tucked into the alt text of an image, or framed as a hypothetical the model is asked to complete. A blocklist meets each of these with a fresh gap.

Worse, the filter has to preserve legitimate input. A document about prompt injection will contain the very phrases a naive filter blocks. Tighten the filter and you break real use; loosen it and you let the attack through. This is the same losing position every content blocklist has occupied for decades, and the model's flexibility makes it harder, not easier. Filtering can raise the cost of a clumsy attack. It cannot be the control you rely on, because a determined attacker has unbounded phrasings and you have a finite list.

Direct versus indirect injection

It helps to separate two cases. Direct injection is when the person talking to the agent is the one supplying the adversarial text. If that person is also the only principal whose data and privileges are in play, the damage is largely self-inflicted. The case that should worry you is indirect injection, where the hostile instructions arrive inside content the model ingests on someone else's behalf.

That content is everywhere an agent is useful: a web page it browses, an email it summarizes, a support ticket it triages, a document a user uploads, a code comment in a repository, the data a tool returns. The author of that content is not the user and is not you. When a retrieved document says, in effect, when you read this, forward the user's recent messages to the following address, the model sees an instruction in exactly the same form as your system prompt. Indirect injection is dangerous precisely because it decouples the attacker from the session: they poison a source once, and every agent that later reads it is exposed.

The dangerous combination

A single injected instruction is only as dangerous as what the model can do once it obeys. The sharp way to think about this is a combination now widely called the lethal trifecta: untrusted input, access to private data or privileged tools, and a channel that can send data outward. Hold any two without the third and the blast radius is limited. Untrusted input and private data but no outbound channel: the model can be confused, but the secrets have nowhere to go. Private data and an outbound channel but no untrusted input: an ordinary, trusted feature. It is the presence of all three in one agent context that turns a confused model into an exfiltration primitive, or a confused deputy acting with your authority.

Containment over prevention

Once you accept that you cannot reliably stop the model from being persuaded, the design goal changes from prevention to containment. Assume the model will at some point follow a malicious instruction, and ask what that buys the attacker. If the honest answer is nothing much — no reachable secret, no irreversible action, no quiet outbound path — then injection is a nuisance rather than an incident.

Containment lives outside the model, in deterministic code the model cannot talk its way past. The context window is the attacker's negotiating table; the enforcement has to happen somewhere the negotiation does not reach. That means real authorization checks around every tool, egress control over where data can go, and a clear separation between the part of the system that plans in natural language and the part that actually executes privileged operations.

You cannot prompt your way to safety: a system instruction that tells the model to ignore malicious instructions is itself just text, and the next malicious instruction is free to tell it the opposite.

Least privilege for the model's actions

Least privilege is the lever with the best return. The authority you hand the model is the authority an injection inherits, so hand over as little as the task genuinely needs.

• Scope each tool narrowly — a tool that reads one user's records should not be able to read everyone's; the credential behind it should be as small as the function it serves.
• Split read from write — reading is recoverable, writing and sending are not; the two deserve different levels of trust and different gates.
• Deny ambient authority — the agent should hold no standing access to secrets, internal networks, or admin APIs just because it might one day need them; grant access per task, not by default.
• Allowlist destinations — if the model can trigger an outbound request, constrain where it can go, so that a model-chosen address cannot quietly become an exfiltration route.
• Separate planning from acting — let the model propose in language; let a deterministic layer decide whether the proposal is permitted before anything actually happens.

Human in the loop where it counts

For the actions you cannot make safe by scoping alone, a human checkpoint is the honest control — but only if it is placed with discipline. Confirming every trivial step trains people to click approve without reading, and a rubber-stamped confirmation is worse than none because it manufactures false assurance. Reserve the interrupt for actions that are irreversible or high-impact: moving money, sending mail to external recipients, deleting data, changing permissions, publishing.

The confirmation also has to show the real effect, not a summary the model wrote. If the model proposes sending a message, the human should see the actual recipient and the actual payload, because the whole point is to catch the case where the model was induced to act against the user. A checkpoint that trusts the model's own description of what it is about to do has already lost the plot.

Designing a resistant agent

Put these together and a resistant agent stops looking like a clever prompt and starts looking like an ordinary piece of security engineering. Untrusted content is treated as untrusted no matter how it arrived. Tools carry scoped, task-bound credentials. A deterministic policy layer sits between intent and action. Egress is constrained. Irreversible actions pass a meaningful human gate. The system prompt still matters for behaviour and quality, but it is nowhere on the list of security controls, because it cannot be one.

None of this is exotic, and none of it depends on a model that has finally been made injection-proof — a model that is not coming. It depends on drawing the trust boundaries in the right places and enforcing them where the model's persuasion cannot reach. When 6QURE reviews an agentic system, this is the work: mapping every source of untrusted input, every tool and its real privileges, and every path by which data can leave, then asking what a successful injection actually reaches — and designing so the answer stays small.