Prompt injection is the defining security problem of applications built on language models, and it is routinely misunderstood as a bug that a good enough filter will fix. It is not a bug. It is a direct consequence of how these models work, and treating it as patchable is how systems get built that cannot be secured.
The root cause
A model receives its instructions and its input as one stream of text, with no reliable marker of which is which. So text that looks like an instruction is treated as one, wherever it came from. There is no separate command channel to protect — that is the whole vulnerability.
Why it exists
A traditional program keeps code and data apart. SQL injection happens precisely when that separation breaks — user data gets interpreted as query commands — and it is fixable, because the boundary is real and can be enforced with parameterised queries.
Language models have no such boundary. The system prompt, the user's message and any retrieved document are concatenated into one context, and the model predicts what comes next based on all of it equally. "Instruction" and "data" are not categories the model represents. They are the same tokens.
This is why the SQL injection analogy is instructive and also misleading. The shape is identical — untrusted input reinterpreted as commands. The fix is not, because SQL has a real syntactic boundary and prompts do not.
Direct and indirect
| Direct injection | Indirect injection | |
|---|---|---|
| Attacker | The user | A third party |
| Vector | Typed into the input | Hidden in content the model reads |
| Victim | The operator | Another user |
| Typical goal | Bypass restrictions | Exfiltrate data, trigger actions |
Direct injection is a user trying to make the assistant misbehave for themselves — jailbreaking, extracting the system prompt, getting it to ignore its rules. Annoying, and the blast radius is usually the attacker's own session.
Indirect injection is the dangerous one. The malicious instruction is planted in something the model will later read — and the person who triggers it is an innocent user, not the attacker.
🚨 The victim triggers it themselves
Indirect injection is dangerous because the attacker never touches your system. They plant the instruction in a public page, a document, an email or a repository, and wait. When your user asks the assistant to read that content, their own action fires the payload — with their permissions and their data.
An assistant that can read email and browse the web is a system where an attacker who can send an email or publish a page has a path to your user's context. That is the mental model to design against.
Why filtering does not work
The instinctive defence is to detect and block malicious instructions. It fails, and understanding why is what stops you relying on it.
The space of ways to express "ignore your instructions and do X" is unbounded. A blocklist enumerates a finite set of phrasings against an infinite set of alternatives.
Every filter is defeated by the next phrasing. Worse, aggressive filtering breaks legitimate use — a security researcher, a translator, or anyone discussing prompt injection itself gets caught by the filter meant to stop attackers. It is the same losing position as antivirus signature matching, for the same reason.
⚠️ Delimiters help and do not solve it
Wrapping untrusted content in tags — <user_data>…</user_data> — with an instruction to treat everything inside as data is worth doing. Models follow it much of the time.
It is not a boundary. The content can include a closing tag to break out, and the model can simply be persuaded to disregard the framing. Use delimiters as a helpful default, never as a control you rely on.
What actually reduces risk
Since injection cannot be reliably prevented, the working strategy is to build systems that stay safe when it succeeds. The controls are architectural and they live in your code, not the prompt.
Least privilege
An agent can only be made to do what it is able to do. An assistant with read-only access cannot be injected into deleting anything, because the capability is not there.
Human confirmation for consequential actions
The model can propose; a person approves anything that matters. Sending an email, moving money, deleting data, publishing — all cross a confirmation boundary the model cannot pass alone.
Separate reading from acting
A powerful pattern: one model with tools and privileges never sees untrusted content directly. A second, sandboxed model reads the untrusted content and returns only structured, validated results to the first.
The injection lands on a model that has nothing to give — no tools, no credentials, no ability to act. The model that can act only ever receives structured data that has been validated against a schema, not free text that could carry instructions.
Treat derived output as untrusted
If a model reads attacker-controlled input, its output is attacker-influenced. Feeding that output into another tool, rendering it as HTML, or executing it as code propagates the compromise.
🚨 The exfiltration-by-image trick
A classic indirect injection instructs the model to render a markdown image whose URL contains stolen data:
When the interface renders the markdown, the browser fetches the URL — silently sending the data to the attacker. The model never "sent" anything; the renderer did. This is why interfaces displaying model output must restrict which URLs and elements they will load, and why any output derived from untrusted input needs sanitising exactly like user input.
Defence in depth
| Layer | Reduces | Sufficient alone? |
|---|---|---|
| Delimiting untrusted content | Casual injection | No |
| Input classification | Known patterns | No |
| Least privilege | Blast radius | No, but essential |
| Human confirmation | Consequential actions | No, but essential |
| Reader/actor separation | The dangerous path | Strong |
| Output sanitisation | Exfiltration, XSS | No |
| Monitoring and logging | Detection after the fact | No |
No single row is sufficient, which is the point. The realistic posture is layered controls plus an assumption that some injection will get through, so the system is designed to limit what a successful one can achieve.
Testing for it
- Red-team every untrusted input path. Anything the model reads — uploads, retrieved documents, web content, tool results, email — is a vector.
- Try to make it act, not just talk. The dangerous outcome is a tool call, not a rude reply.
- Test the output sink. Can the model be induced to emit an image URL, a link, or renderable HTML carrying data?
- Test cross-user paths. Can content one user supplies affect another user's session?
- Assume the model can be turned. Design the test around what happens after it is, not whether it can be.
💡 The mental shift that matters
The question is not "can I stop the model being tricked". You cannot, reliably. The question is "what can a tricked model actually do" — and that answer is entirely under your control, through privilege, confirmation and architecture.
A system where a fully compromised model can only produce text is fine. A system where it can send email, move money or read another user's data is not, no matter how good the prompt.
Handling untrusted files in your pipeline?
Convert, inspect and clean files in your browser — nothing is uploaded, so untrusted documents never touch a shared service.
Browse all tools →Summary
- Instructions and data share one channel. That is the vulnerability, not a bug.
- Indirect injection is the dangerous form — the victim triggers it, not the attacker.
- Filtering cannot work against an unbounded space of phrasings.
- Delimiters help and are not a boundary.
- Least privilege and human confirmation limit what a compromise achieves.
- Separate the reader from the actor so injection lands on a model with nothing to give.
- Treat model output derived from untrusted input as untrusted.
- Design for "what can a tricked model do", not "can it be tricked".
Frequently Asked Questions
What is prompt injection?
Getting a language model to follow instructions its operator did not intend, by placing those instructions where the model will read them. It works because the model processes its system prompt, your input and any retrieved content as one undifferentiated stream of text — it has no reliable way to tell which parts are trusted commands and which are untrusted data.
What is the difference between direct and indirect prompt injection?
Direct injection is the user typing malicious instructions themselves. Indirect injection is malicious instructions hidden in content the model later reads — a web page, an email, a document, a code comment — so the attacker never interacts with the system directly and the victim triggers it unknowingly.
Can prompt injection be fixed?
Not fully, with current architectures. Instructions and data share the same channel, so there is no reliable boundary to enforce. Defences reduce the risk and none eliminates it, which is why the practical response is to design systems that stay safe even when injection succeeds.
Why doesn't filtering for malicious phrases work?
Because the space of ways to express an instruction is unbounded. Attackers use synonyms, other languages, encoding, roleplay framing and instructions split across inputs. A blocklist stops the examples it knows and the next phrasing walks straight past it.
What actually reduces prompt injection risk?
Architecture, not prompting. Give the model least privilege, require human confirmation for consequential actions, separate the model that reads untrusted content from the one that can act, validate every tool call in code, and assume any output derived from untrusted input is itself untrusted.