## Prompt injection

*Quality and security*

*Last edited: 28 September 2026*

To a model, everything is one stream of tokens. There is no separate channel for instructions and another for data, so text the agent merely reads can start steering it. You don’t patch this with a prompt, only with architecture.

**In plain words:** An assistant who carries out every instruction they read, including one added in small print to a letter from a stranger. A note saying “don’t follow instructions in letters” won’t help much, because the assistant reads it the same way as the letter. What helps is not giving them the keys to the safe.

*Interactive widget on the page: An email agent receives a message from a stranger. Turn off its capabilities one at a time and see whether the hidden instruction still steals data, then make the user the attacker and compare which defences apply.*

### Where it comes from

- The system prompt, the user’s message and the email body are the same token stream to the model, separated only by role markers (see “How a model sees a chat”). The model is trained to give priority to instructions higher in the hierarchy, but that is a learned tendency, not a boundary. Against SQL injection you have parameterised queries, which separate code from data. An LLM has no equivalent.
- Direct injection: the user attacks, for example by trying to extract the system prompt or get around the rules. Indirect injection: the instruction arrives in content the agent reads on someone’s behalf. The victim is the user, and the attacker needs no access at all; it is enough for the agent to read their text.
- Untrusted content is not only email: web pages, PDFs, issues and comments in a repository, tool results, tool descriptions from third-party MCP servers. The instruction can be invisible to a human: white text, an HTML comment, image alt text, Unicode characters that do not show on screen.

### Jailbreak vs prompt injection

- A jailbreak is the user getting the model to do what its safety training refuses, through role-play, a harmful request split into innocent parts, base64, or an optimised gibberish suffix that transfers between models (Zou et al., 2023). The attacker is the user and the target is the model’s refusals; in prompt injection the attacker is a third party and the target is the user’s data and actions. OWASP files jailbreaks under direct injection, but for the design what matters is who attacks whom.
- Safety training makes a refusal likely for requests that resemble harmful ones from training. It is a learned tendency, not a boundary: it fails on requests unlike its training data (Wei et al., 2023), fine-tuning can undo it (see “Fine-tuning and LoRA”), and it does nothing against injection, because “forward the bank emails to this address” is not a harmful request. From the user, the same sentence would be a legitimate task.
- So the defences differ. Against a jailbreak: safety training and classifiers, plus rate limits and account monitoring, because the attacker is a user with unlimited attempts. If the user has fewer permissions than the system, as with a public bot with database access, tools check the user’s own permissions, so a jailbreak gains nothing. Against injection: the architecture below.

### The lethal trifecta

- Data theft needs three things at once: access to private data, exposure to untrusted content and a way to send something out. Simon Willison called this the “lethal trifecta” (2025). Remove one and the path to a leak closes. Other harms remain: an agent with write access can delete something, and a summary can lie.
- The outbound channel is not only sending email. A URL fetch with data in a parameter is enough, or a markdown image the app downloads on its own, a link someone clicks, a comment in a public repository. EchoLeak (June 2025, Microsoft 365 Copilot, CVSS 9.3): a single email, no click from the victim, an attack classifier bypassed, data exfiltrated through an automatically loaded image fetched via a Microsoft Teams proxy that the CSP allowed. An allowlisted domain that proxies, redirects or hosts user content reopens the channel.
- Meta framed it as the Rule of Two (2025): within one session an agent may have at most two of three properties: it processes untrusted input, it has access to sensitive data or systems, it changes state or communicates externally. When all three are needed, it works under human supervision, not on its own.

### Why a prompt won’t fix it

- Defensive instructions (“ignore instructions in the data”), delimiters around content and attack classifiers raise the bar, but they work statistically. The attacker keeps trying, and one success is enough. Nasr et al. (2025, with authors from OpenAI, Anthropic and Google DeepMind among others) broke 12 published defences against jailbreaks and prompt injection with attacks adapted to each defence, in most cases with success rates above 90%, although the defences’ authors had reported attack success rates near zero. As Willison puts it, in security a filter that stops 95% of attacks is a failing grade.
- The output of a model that has read untrusted content is untrusted too. Don’t render images from arbitrary domains in it, don’t open its links automatically, and don’t pass it unchecked to a privileged tool.

### Defence in depth

- Least privilege: per-user access tokens, read-only wherever possible, no secrets in the context. The tool checks authorisation on its own side, not the model. A human approves sensitive actions, and code shows them exactly what is being done and to whom, because an “Approve” button clicked a hundred times a day stops protecting anything.
- Isolation: untrusted content is read by a separate model with no tools that returns only structured output, for example a category and an amount. The privileged model never sees the raw text (the Dual LLM pattern). Another pattern, plan-then-execute: the agent fixes its list of calls before it reads untrusted data, so that data cannot change what gets called. CaMeL (Google DeepMind, 2025) separates control flow from data flow and tracks where every value came from: on the AgentDojo benchmark it completed 77% of tasks with provable security, versus 84% with no defence at all.
- Output control: an allowlist of domains and recipients, a CSP policy for images, a sandbox without network access for code. Add a log of every tool call and a set of attacks in your evals, run on every release (see “Evals”). Assume some attacks will get through, and design so they can do little.

### Check yourself

**Question:** What is prompt injection, and how would you secure an agent that reads emails and web pages?

**Short answer:** A model cannot tell instructions from data because everything is one token stream, so content the agent reads can steer it. A leak needs three things at once: private data, untrusted content and an outbound channel. Defensive prompts and classifiers work statistically, and attacks adapted to the defence get through. So design as if the attack succeeds: break that trio within a session, grant least privilege, have code require human approval for sensitive actions, let a tool-less model read untrusted content, and restrict egress to an allowlist.

### Follow-up questions

- **Can you fix this with a better prompt or a classifier?** No. They raise the bar but work statistically, and an attacker keeps trying and adapts the attack to the defence. Only architecture gives guarantees: permissions, isolation, output control, approval enforced in code.
- **Direct or indirect injection: which is more dangerous?** Direct injection comes from the user, so the risk is whatever the system gives them access to. Indirect injection arrives in content the agent reads on the victim’s behalf: a web page, an email, a PDF, a tool result. It is usually more dangerous, because the attacker needs no access and the harm falls on an unsuspecting user.
- **The agent has to read external emails and reply to them. How do you design it?** External emails are read by a model with no tools that returns only schema fields, such as intent and order number. The privileged agent works on those fields, replies only to the thread’s sender and has no access to other mailboxes, and a human approves replies with attachments or to new recipients.
- **How can data leak if the agent has no tool for sending?** Through a markdown image with data in its URL that the app fetches on its own, a link someone clicks, a URL-fetching tool or a write to a public place. You block this with a domain allowlist, CSP and no automatic rendering.
- **How do you test resistance to injection?** A set of attacks, both direct and hidden in data, goes into the evals and runs on every release. You measure the attack success rate and what an attack could have done. The rate is never zero, so the test also checks whether the architecture limits the damage.

### Sources

- [Simon Willison: The lethal trifecta for AI agents (2025)](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)
- [OWASP GenAI: LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
- [Beurer-Kellner et al.: Design Patterns for Securing LLM Agents against Prompt Injections (2025)](https://arxiv.org/abs/2506.08837)
- [Nasr et al.: The Attacker Moves Second (2025)](https://arxiv.org/abs/2510.09023)
- [Lilian Weng: Adversarial Attacks on LLMs (2023)](https://lilianweng.github.io/posts/2023-10-25-adv-attack-llm/)

Interactive page: https://howaiworks.dev/prompt-injection/