Indirect Prompt Injection: Why the Attack Arrives in the Data, Not the Prompt
Indirect prompt injection hides instructions in content an agent retrieves (a web page, email or RAG chunk), so the attacker never talks to the model. Filters on the user's prompt miss it, because the payload is in the data. Six controls hold: mark untrusted content, keep it out of the control flow, cut privileges after reading it, confirm consequential actions, block exfiltration, and check actions before they run.
On this page
In February 2023, Kai Greshake and five co-authors asked the question that moved prompt injection out of the chat box: what if it is not the user prompting?
Their paper, Not what you've signed up for, argued that applications built on large language models "blur the line between data and instructions". An attacker does not need access to the model. They need to put text somewhere the model will read it.
Direct vs indirect prompt injection: what's the difference
OWASP's LLM01:2025 Prompt Injection defines both. Direct injection occurs "when a user's prompt input directly alters the behavior of the model". Indirect injection occurs when the model "accepts input from external sources, such as websites or files", and instructions inside that content change what it does.
The definitions are short. The consequences are not.
| Direct injection | Indirect injection | |
|---|---|---|
| Who writes it | The user | A third party |
| Where it enters | The prompt | Retrieved content: pages, emails, documents, RAG chunks, tool outputs |
| Whose privileges it uses | The user's own | The victim's: whoever's agent retrieved it |
| Who sees it | The person typing | Often nobody; it can be invisible |
| What a prompt filter sees | The attack | Nothing |
The third row matters most. A user who jailbreaks their own session mostly harms themselves. An indirect injection borrows the authority of whoever retrieves it, which makes it a confused deputy problem: the agent uses its rights on behalf of someone who has none. A poisoned MCP tool description is one special case of it.
How indirect prompt injection reaches an agent
Greshake et al. sorted delivery into four methods, and all four map onto agents in production today.
- Passive: instructions placed where retrieval will find them, such as public web pages, social media posts, code in a repository, or files a retrieval plugin indexes. Testing the Bing Chat sidebar in Edge, the authors found that instructions written on a page, even ones invisible to the user, could be injected and affect the model.
- Active: instructions sent to the system, such as an email processed by an assistant that reads the inbox.
- User-driven: the user is tricked into pasting text that carries the payload.
- Hidden: a small first-stage injection that fetches a larger payload from elsewhere, or prompts encoded to get past filtering.
For an agent, the list of channels is longer: RAG chunks, browsed pages, inbound email, tickets, calendar invites, PDFs, tool outputs and messages from other agents. OWASP's Top 10 for Agentic Applications opens its first risk, ASI01 Agent Goal Hijack, with two of them as examples: instruction payloads hidden in web pages or documents in a RAG scenario, and instructions arriving through email, calendar or team chat from outside the company.
The paper's impact taxonomy reads like an incident list: data theft, worming, information ecosystem contamination. Its worm demonstration was an LLM-augmented email client that received a malicious email, read the user's address book and forwarded the message on.
Why input filters miss indirect prompt injection
They watch the wrong channel. The paper's first key message is that retrieval opens new doors for injection "where current (likely brittle) input filtering techniques are not applied". Its attacks succeeded on Bing Chat, which seemed to filter its input and output channels without considering the model's external input.
The payload need not look like an attack. OWASP notes that injected content does not need to be human-visible or readable, as long as the model parses it. It can be a comment hidden in a page's HTML, an encoded string, or a perfectly polite paragraph.
Filtering retrieved content has its own trap. The authors describe the dilemma directly. A filter model general enough to catch cleverly encoded instructions can fall into the same trap as the model it protects; a less general one may not recognise them.
The content changes after you scan it. A document checked at ingestion can be edited later. A web page is whatever it is at fetch time.
Filters still earn their place. Cheap checks for known payloads belong on the fast path, as one tier of a two-tier prompt injection defence. They are not the control that decides what an agent may do. OWASP itself says it is "unclear if there are fool-proof methods of prevention".
How to defend against indirect prompt injection: six controls
The most useful single principle comes from Design Patterns for Securing LLM Agents against Prompt Injections (Beurer-Kellner et al., 2025). Once an agent has ingested untrusted input, "it must be constrained so that it is impossible for that input to trigger any consequential actions".
- Mark untrusted content. OWASP asks you to "separate and clearly denote untrusted content". Spotlighting (Hines et al., 2024) transforms retrieved text so the model has a continuous signal of where it came from. In the authors' experiments with GPT-family models, attack success fell from above 50% to below 2%. That is a mitigation, not a guarantee.
- Keep untrusted data out of the control flow. Decide the steps from the user's request before reading anything external. The design-patterns paper describes several ways to do this, including a dual-LLM split: a privileged model plans and uses tools, while a quarantined model processes untrusted text and has no tools at all. CaMeL (Debenedetti et al., 2025) takes the idea furthest, so that retrieved data "can never impact the program flow". It solved 77% of AgentDojo tasks with provable security, against 84% for an undefended system. The gap is the price of the guarantee.
- Cut privileges once the agent has read untrusted content. An agent that has just read an external email should not be able to email a new recipient without confirmation. Least privilege is old advice, and it still works here.
- Confirm consequential actions, with their full arguments. After his Gemini memory attack, Johann Rehberger recommended requiring user confirmation for every sensitive tool call once untrusted data is in the context.
- Close the exfiltration channels. Rendered images and links are how data leaves quietly. The paper's data-stealing injection, tested on Bing Chat, used a markdown link to hide a suspicious URL behind an innocent-looking string.
- Check the action, not the text. An injected instruction is only dangerous when it becomes an action. A check on every consequential tool call, outside the model, applies complete mediation to each tool call whatever the model was persuaded to want.
No single control here is sufficient, and Greshake et al. were clear that a foolproof fix was hard to imagine. Layered, they shrink what a successful injection can do.
Where Syntrox fits
Any check that reads an agent's work reads the same retrieved content the agent did, so it has to resist the same trick. Our judge, Nucleus, treats any text inside the material it evaluates as evidence, never as instructions, and an instruction addressed to the evaluator counts against the output. Its injection-resistance probes run as a release gate with explicit thresholds.