Indirect prompt injection is the case where the attacker never types into your chat box. They plant instructions in content your application will later retrieve — a web page, a PDF in the knowledge base, an email body, a JSON field returned by a tool — and wait for the model to read it. The user asks a perfectly normal question, the retrieval layer does its job, and the model executes text that arrived through a channel it was told to treat as data.
The term comes from Greshake et al., whose 2023 paper “Not what you’ve signed up for” is still the reference framing: LLM-integrated applications blur the line between data and instructions, so any content the model ingests becomes a potential command channel. Three years on, OWASP still ranks prompt injection as LLM01, and the indirect variant is the half that scales, because it does not require the attacker to have access to the victim’s session.
This piece covers the mechanism, the delivery channels, what attackers do once the payload lands, and what the published benchmarks actually measure. If you want the full five-class picture — direct, indirect, multi-modal, agentic, multi-turn — start with the working taxonomy of prompt injection attacks and come back here for the indirect branch in depth.
Why the boundary does not exist
There is no protocol-level separator between instructions and data inside a transformer’s context window. System prompt, retrieved chunks, tool output and user turn are concatenated into one token stream. Delimiters, XML tags and “the following is untrusted content” preambles are themselves just tokens; nothing in the architecture forces the model to honor them.
The BIPIA benchmark work (arXiv:2312.14197) puts a finer point on it by naming two distinct failure modes rather than one. First, models cannot reliably distinguish informational context from actionable instructions. Second, even when they can, they lack any awareness that instructions found inside external content should not be executed. Those are separate problems, and they explain why the two common fixes behave so differently: prompting tricks that improve boundary awareness help with the first failure and barely touch the second, while fine-tuning that teaches refusal of embedded instructions attacks the second directly. The paper reports that its black-box defense provides substantial mitigation while the white-box (fine-tuned) defense pushes attack success toward zero without degrading output quality — a result worth knowing before you spend a quarter on prompt engineering alone.
NIST AI 100-2 E2025 is worth knowing for anyone who has to map findings onto an existing risk register, because it does not fold this into an existing category. Its generative-AI taxonomy gives indirect prompt injection its own class, NISTAML.015, separate from the direct case (NISTAML.018) — and separate from the evasion classes, which sit on the predictive-AI side of the document only. NISTAML.015 is then listed under all three attacker-goal headings: availability violations, integrity violations and privacy compromises. One attack class, three impact categories, which is usually one row more than a risk register expects.
The delivery channels
Indirect injection is defined by its channel, not its payload. Anything your pipeline pulls in and hands to the model is a channel:
- Retrieved documents. The classic RAG path. A poisoned PDF, wiki page or support ticket in the index gets chunked, ranked and injected into context. The Llama 3 RAG proof of concept walks four distinct attack classes through exactly this route.
- Live web content. Browsing and search-augmented assistants fetch attacker-controlled HTML on demand. The Bing Chat / Sydney case remains the best-documented public example of a commercial deployment reading instructions off a web page.
- Email and calendar bodies. Assistant integrations that summarize an inbox will happily summarize an instruction. The attacker only needs the victim’s address.
- Tool and API responses. An agent that calls a third-party API is trusting that vendor’s response body as much as its own system prompt. OWASP’s LLM01 guidance calls out untrusted tool output specifically.
- Code, config and repository files. Comments, commit messages, issue text and README content all land in the context of coding agents.
- Image, document and file metadata. Alt text, EXIF fields, PDF annotations and OCR’d text in screenshots are all text to the model.
Cutting across every one of those channels is the encoding problem. A payload does not have to be visible to a human reviewer to tokenize as an instruction — Unicode Tag characters smuggle invisible instructions past eyeballs and naive string filters while remaining fully legible to the model. Any channel review that relies on someone reading the document is weaker than it looks.
What the payload does once it lands
Four objectives account for most published indirect injection work, and they escalate in that order:
- Instruction override. The retrieved text tells the model to ignore its task and do something else — return a fixed answer, refuse, or misclassify. Cheap, noisy, easy to detect.
- Data exfiltration through an output channel. The model is instructed to embed conversation contents or retrieved secrets into a URL, a citation, a markdown image reference, or a footnote that the client renders and fetches. This is the objective that turns a nuisance into a breach.
- Tool-call hijacking. In an agentic deployment, the injected text does not need to convince the user of anything. It only needs the model to call
send_email,create_pull_requestortransfer_fundswith attacker-chosen arguments. - Persistence. Where the application writes conversation state to long-term memory, an injection that survives into memory keeps executing in later, unrelated sessions.
Simon Willison’s “lethal trifecta” is the cleanest way to explain to a product owner why objective 2 matters more than objective 1: an agent holding private data, exposure to untrusted content, and any outbound communication channel at the same time has an exfiltration path by construction. Remove one leg and most of the payload class collapses regardless of whether your detector fired.
Where the deployment is agentic rather than a chat surface, the same three legs and the controls that break them are worked through in prompt injection in AI agents.
What the benchmarks measure
The most useful development for defenders since 2024 is that indirect injection now has published benchmarks with numbers attached, so “are we vulnerable” has an answer shape. Three are worth knowing, and they measure different things:
| Benchmark | Scope | Scale | Headline result |
|---|---|---|---|
| BIPIA | Indirect injection against LLMs consuming external content | First dedicated indirect-injection benchmark | Evaluated models universally vulnerable; fine-tuned white-box defense drives attack success near zero |
| InjecAgent | Indirect injection against tool-integrated agents | 1,054 test cases, 17 user tools, 62 attacker tools, 30 agents | ReAct-prompted GPT-4 vulnerable in 24% of cases; adding a reinforcing hacking prompt nearly doubles that |
| AgentDojo | Dynamic agent environment for attacks and defenses | 97 realistic tasks (email, e-banking, travel), 629 security test cases | Used in follow-on work reporting roughly 20% average attack success on a banking agent, with a 15 to 50 point drop in task utility under attack |
Two things fall out of that table. First, attack success rates in the 15 to 25 percent range are typical for undefended general-purpose agents, which means a single clean run against your own application proves very little. Second, AgentDojo’s design choice to score utility alongside security is the one most internal test plans miss: a defense that blocks every injection by making the agent refuse half its legitimate work has not improved anything. A 2025 study of data exfiltration from a banking agent found that no built-in AgentDojo defense fully prevented leakage, and that tasks resembling data extraction or authorization workflows had the highest attack success rates — structure of the task predicts risk as much as the model does.
If you want to turn this into a repeatable exercise rather than a one-off, the method is laid out in prompt injection testing: a repeatable method, and the framework choice is covered in Garak vs. PyRIT vs. promptmap.
Why indirect is harder to defend than direct
Direct injection has an attacker in the session. That gives you rate limits, account signals, abuse reporting and a clear notion of a malicious user. The distinction from jailbreaking matters, and it matters most here: with indirect injection the person in the session is the victim, every request looks legitimate, and the malicious content sits in a system you may not own. Your abuse signals point at the wrong party.
The practical consequences:
- Provenance is the missing primitive. You cannot filter what you cannot label. Tagging retrieved content at ingestion, and carrying that tag through to the prompt assembler, is the prerequisite for every other control.
- Detection sits downstream of the compromise. By the time a classifier sees the retrieved chunk, the attacker has already chosen the phrasing to beat it. Detection techniques and their documented bypasses is the honest accounting of what each layer buys, and the Rebuff architecture review shows the limit concretely: its four layers are built around the user’s input, so an injection arriving through retrieved content passes them unexamined.
- Blast radius is an architecture decision, not a prompt decision. Scoped credentials, human approval on state-changing actions, and separating the agent that reads untrusted content from the agent that holds tools are the controls that hold when detection misses. The sequencing is in the layered mitigation guide.
Working out your own exposure
The fastest way to scope this for a specific application is to enumerate which channels above your architecture actually has. The injection threat modeler does that mechanically: select the building blocks your app contains — retrieval, browsing, tools, memory, file upload, multi-modal input — and it returns the taxonomy classes that become reachable, the trust boundary each one crosses, and the defenses that apply. An application with no retrieval and no tools has a much smaller indirect surface than its vendor’s threat model assumes, and one with a browsing agent plus write-capable tools has a much larger one.
For deployers, the regulatory reading of an unmitigated injection is worth a look too. Where an indirect injection causes downstream harm, the question of who documented which control tends to arrive before the question of who wrote the payload.
