TL;DR: Indirect prompt injection is prompt injection where the payload arrives through content the model reads while doing its job: a retrieved document, an email, a web page, a tool result. The attacker never touches the chat box, and the victim is a trusted user who never sees the malicious text. It is the mechanism behind the serious real-world AI exploitation incidents to date, including the zero-click EchoLeak exfiltration from Microsoft 365 Copilot. The attack has a four-stage kill chain (plant, retrieve, execute, escape), and the defenses that work attack the first and last stages, where the model's judgment is not part of the control.
Direct prompt injection has a built-in consolation prize for defenders: the attacker is the user, so the blast radius is mostly the attacker's own session. Someone who talks a chatbot into revealing its system prompt has attacked their own conversation.
Indirect prompt injection removes that consolation. The attacker plants instructions in content your AI will read later, on someone else's behalf. The person harmed is a legitimate user doing their job. The attacker may never interact with your system at all. If you run retrieval-augmented generation (RAG), an email assistant, a browsing agent, or any tool-using AI, this is the attack class your threat model should be built around. This article covers how it works stage by stage, where payloads hide, what the real incidents chained together, and which defenses actually hold. For the broader prompt injection picture, start with our attacks and defenses guide; for the plain-English introduction, see what is prompt injection.
The core idea, precisely
An LLM application feeds the model a mix of trusted text (the system prompt) and untrusted text (whatever the workflow pulled in). The model processes all of it in one channel with no enforced privilege boundary. Indirect prompt injection exploits that by placing instructions in the untrusted portion, knowing the model will read them with the same attention it gives everything else.
The attack was formally described by Greshake et al. in early 2023, under a title that summarizes the whole field: "Not what you've signed up for." Their observation has aged well: the moment an application augments a model with external data, every source of that data becomes a potential command channel.
The severity difference from direct injection comes down to three properties:
- The victim and attacker are different people. A trusted employee's session executes the attacker's intent, with the employee's permissions.
- The payload is invisible. It sits in a document nobody rereads, white text in a PDF, an HTML comment, a code comment, or metadata. The user sees a normal-looking answer.
- It scales. One poisoned document in a shared knowledge base can affect every user whose query retrieves it, for as long as it stays in the index.
The kill chain: four stages
Thinking about indirect injection as a chain rather than a single event is what makes the defenses obvious, because each stage is a place to break it.
Stage 1: Plant. The attacker gets malicious text into a source the target system will read. This is usually the easiest stage, because modern AI applications are deliberately connected to everything: a shared drive, a public web page a crawler ingests, a support ticket anyone can file, a product review, a calendar invite, an incoming email, a code comment in an open-source dependency.
Stage 2: Retrieve. The payload has to actually reach the model's context. In a RAG system that means winning semantic retrieval for a plausible user query, which attackers optimize for by stuffing the document with the natural language of the questions they expect. In an agent, it means being on a page the agent browses or in a tool result it reads. This stage is where a lot of naive attacks fail, and where a competent attacker spends their effort.
Stage 3: Execute. The model reads the instruction and complies. This is the only stage that depends on the model's judgment, which makes it the least reliable one for attackers and, importantly, the one defenders most often try to fortify. Alignment training does push back here, inconsistently.
Stage 4: Escape. The result has to leave the system: data exfiltrated to an attacker-controlled endpoint, an email sent, a record modified. This stage frequently does not involve the model at all. A markdown image the client auto-fetches, a link the renderer resolves, a tool call that hits the network.
The strategic insight for defenders: stages 1 and 4 are engineering problems you can solve deterministically. Stage 3 is a probabilistic problem you cannot. Most teams pour their effort into stage 3, which is the one stage that cannot be made reliable.
Where payloads hide
The attack surface is larger than most teams map. Any of these can carry an instruction into a model's context:
- Documents in a RAG store: PDFs, Word files, wiki pages, and Confluence exports, including white-on-white text and content in metadata fields.
- Web pages an agent browses: visible text, HTML comments,
altattributes, and hidden elements. - Email and calendar: message bodies, invite descriptions, and attachments, which is exactly what EchoLeak used.
- User-generated content: support tickets, product reviews, forum posts, and issue trackers.
- Code: comments, docstrings, README files, and dependency metadata, which matters enormously for coding agents.
- Tool and API results: anything an agent fetches, including responses from third-party services you do not control.
- Images: text rendered in an image that a multimodal model reads as an instruction.
What the real incidents chained together
Indirect injection is not theoretical, and the serious 2024-2025 incidents were nearly all indirect.
EchoLeak (CVE-2025-32711), Microsoft 365 Copilot. The canonical case, and worth studying as a complete chain: a crafted email planted the payload (stage 1), Copilot read it during normal processing (stage 2), the instructions got the model to embed internal data in its output (stage 3), and the data left through an auto-fetched image routed via a trusted proxy (stage 4). Along the way the exploit evaded Microsoft's cross-prompt-injection classifier and used reference-style markdown to dodge link redaction. Zero clicks from the victim. Our EchoLeak breakdown walks the whole chain.
GitHub Copilot Chat (2025). After image-based exfiltration reports, GitHub disabled image rendering in Copilot Chat outright. Read that as a stage-4 defense: they could not guarantee the model would never emit an attacker URL, so they removed the channel that made emitting one dangerous.
Slack AI (2024). Researchers demonstrated indirect injection pulling private channel data through the integrated AI, reaching content the attacker could not access directly.
The Month of AI Bugs (2025). Johann Rehberger disclosed one AI vulnerability per day for a month across major platforms, the majority driven by indirect injection against agents and assistants.
What our own lab testing showed
We built a set of hands-on AI red-team labs that run real exploits against a live aligned model, verified in-pod rather than against mocks. Driving indirect injection across RAG pipelines, tool-using agents, multi-agent graphs, and memory stores produced a consistent pattern that maps directly onto the kill chain.
The exploits that fire reliably are the ones whose final stage does not require a model decision. Exfiltration through a rendered image works consistently once the poisoned document wins retrieval, because the damaging step is a client auto-loading a URL. Attacks that need the model to take a risky action are far less consistent: an attempt to redirect a payment to an attacker account failed on every run, since alignment training pushes back hardest on unsanctioned writes. Cross-tenant reads and server-side request forgery fired sometimes, depending on framing. Multi-step propagation across a two-agent graph was weakest of all, because it needs two compounding compliance events in a row.
The defensive lesson is the kill chain restated: the attack that does not depend on the model complying is the one that will get you, and it is also the one you can shut down deterministically.
Defenses that survive contact
Ordered by leverage, not by how satisfying they feel to implement.
- Control the output sink (stage 4, highest leverage). Decide server-side what the model's output may reach. Allow-list the hosts your renderer or client can load images and links from, so a model-emitted attacker URL is never fetched. This kills the most reliable exfiltration class even when the injection fully succeeds.
- Least-privilege tools, enforced server-side (stage 4). Every tool call runs with the requesting user's permissions, with no ambient authority. Scope database queries, forbid stacked statements, and put an egress allow-list in front of any fetch tool. An agent that cannot reach cross-tenant data cannot be talked into leaking it.
- Gate high-impact actions with a human (stage 4). Writes, payments, and outbound messages need confirmation, so a successful injection still cannot finish the job alone.
- Harden retrieval (stage 2). Validate and sanitize content at ingestion, restrict who can add to the knowledge base, strip hidden text and comments, and flag documents whose text looks like instructions. You will not catch everything, and raising the cost of stage 2 is still worthwhile.
- Mark untrusted content as data (stage 3). Wrap retrieved content with clear provenance and instruct the model never to act on directives inside it. Genuine defense in depth, and never your primary control, because it competes with the attacker's text on equal terms.
Design assumption
Assume stage 3 will sometimes succeed. Design so that a successful injection still cannot cause harm, because the data could not leave and the tool could not reach anything sensitive. A defense that requires the model to always refuse is not a control.
Practice the full chain hands-on
Indirect injection is a topic where reading the kill chain and executing it produce completely different levels of understanding. Our free Indirect Prompt Injection lab runs in your browser against a live model and walks all four stages: you plant a poisoned document, get it to win semantic retrieval, exfiltrate a customer record through the markdown-image channel, measure how reliably the exploit fires, defeat a naive prompt-level defense, then ship the boundary fix and prove it holds.
It opens the AI Red Team course, whose later labs cover tool misuse, MCP tool poisoning, memory poisoning, cross-tenant leakage, and a self-propagating payload across a two-agent graph, all mapped to the OWASP LLM Top 10 and MITRE ATLAS.
Frequently asked questions
What is indirect prompt injection? It is prompt injection where the malicious instruction is hidden in content the AI reads while doing its job, such as a document, email, or web page, rather than typed by the attacker. The victim is a trusted user who never sees the payload, and the attacker never needs to contact the system directly.
How is it different from direct prompt injection? Direct injection is typed into the AI by the attacker and mostly affects their own session. Indirect injection is planted in data the AI consumes, so it executes inside another user's session with that user's permissions. Indirect is the higher-severity class and the one behind the real-world incidents.
Why are RAG systems especially vulnerable? A RAG system retrieves external documents and feeds them to the model as context by design. One poisoned document that wins retrieval puts attacker instructions into the model's context automatically, with no attacker interaction at query time.
Can indirect prompt injection be prevented completely? Not by a single control, because it stems from how LLMs mix instructions and data in one channel. You reduce it to acceptable risk by breaking the kill chain at the stages you can control deterministically: harden ingestion, restrict what the output can reach, scope tools to least privilege, and require human approval for high-impact actions.
Was EchoLeak an indirect prompt injection? Yes. EchoLeak (CVE-2025-32711) delivered its payload through an email that Microsoft 365 Copilot read automatically, making it a zero-click indirect attack and the clearest documented example of the full four-stage chain.
How do I test my own system for it? Follow the kill chain. Try to plant text in each source your AI reads, craft it to win retrieval for a realistic query, see whether the model acts on it, and check whether any channel would let data escape. Practicing on a deliberately vulnerable environment first, like our lab, teaches you what each stage actually looks like.
Sources and further reading
- Greshake et al., "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" (2023)
- OWASP Top 10 for LLM Applications, LLM01: Prompt Injection
- CVE-2025-32711, EchoLeak
- MITRE ATLAS
- Our guides: What Is Prompt Injection and Prompt Injection Attacks Explained