Prompt Injection › Indirect Prompt Injection

Indirect prompt injection is the more dangerous variant, because the attacker is not in the conversation at all. Instead, the malicious instructions are embedded in external content that the model retrieves or processes during a task.

Consider a model-powered email assistant. The user says: "Check my email and summarize anything important." The model calls an email API, retrieves messages, and passes their content to itself for summarization. An attacker who can send the user an email can include instructions in the email body:

The model, which has been given access to email-sending tools, may execute this instruction. The legitimate user asked for a summary; the malicious email asked for data exfiltration. From the model's perspective, both appear as text it should process.

This attack class was formally described by Greshake et al. (2023) in "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection," which demonstrated successful attacks against Bing Chat, code assistants, and productivity applications. The paper is notable for establishing that injection attacks could succeed without any prior access to the system's prompts or configurations: an attacker only needs to know that the target uses an LLM to process web content or documents.

What makes indirect injection particularly insidious is the mismatch between the perceived trust level of the content and the actual trust level of its source. An AI assistant's user trusts the assistant to read their email. That trust does not extend to every sender of email, but when the assistant processes all emails uniformly, an attacker who can send an email inherits the processing trust of legitimate emails. The model cannot distinguish between an email from a trusted colleague and an email from a stranger who has designed its content to issue instructions. Both are just text in the context window.

Indirect injection becomes dramatically more dangerous when the model has access to tools. A pure text-generation model that gets injected is inconvenient but mostly harmless; it produces malicious output that a human must still act on. An agent with tool access can take actions directly.

The capabilities that make agents powerful, web browsing, code execution, file system access, API calls, email and calendar management, become attack surfaces. Each tool expands what a successful injection can accomplish. An injection that reaches a model with no tools can, at worst, generate harmful text. An injection that reaches a model with tool access to email, cloud storage, and payment systems can exfiltrate data, delete files, or initiate transactions.

This creates a risk profile that scales with agent capability. Security practitioners speak of the "confused deputy problem": the model acts as a deputy on behalf of the user, but the attacker has confused the model into acting as a deputy for the attacker instead. The term comes from operating system security, where a program with elevated privileges is tricked into performing an action that would not be authorized for the requesting user. The LLM-as-agent is exactly this: a high-privilege process (the model with tools) is being directed by an untrusted principal (the injected instruction).

The severity is not hypothetical. Real-world agentic systems have been demonstrated to be vulnerable to indirect injection that achieves credential theft, unauthorized file access, unintended API calls, and data exfiltration. As agent capabilities grow to include executing code, browsing the web, managing files, and communicating on behalf of users, the attack surface expands correspondingly.

What makes the agent amplification problem particularly difficult to reason about is that the severity of an attack is determined by the intersection of the injection and the tools the agent has access to. The same injected text that is harmless against a read-only Q&A system becomes critical against an agent with write access to an email system. This means that assessing the security posture of an LLM deployment requires understanding the injection surface, the full capability surface, and how they interact.

In multi-agent architectures, where specialized models coordinate to complete complex tasks, a single injection in the outermost data layer can propagate through the entire pipeline. A web-scraping agent feeds content to a summarization agent, which feeds to a decision-making agent. If the web page contains an injection, it may execute at any stage of this chain.

The 2023 demonstrations against Bing Chat showed exactly this: a user asking the model to summarize a web page could trigger injections placed in hidden HTML comments, white-on-white text, or metadata fields. The model fetched the page, processed all its text, and followed embedded instructions that the user never saw.

Multi-agent contamination is harder to defend against than single-agent injection because each handoff between agents represents a new opportunity for injected text to be treated as trusted. An orchestrator agent may pass a sanitized prompt to a subagent, but if that prompt includes summaries or excerpts from processed documents, injections may survive in paraphrased form. The subagent receives the text from a trusted orchestrator and has no reason to be suspicious.

This problem motivates the principle of treating all data as potentially hostile regardless of where it arrives from. An agent receiving instructions from another agent should apply the same scrutiny it applies to instructions from external sources, rather than trusting that the orchestrator has done adequate sanitization. This is a hard constraint to enforce in practice, since many agent architectures are designed around the assumption that orchestrator outputs are trusted.

The multi-agent contamination problem also interacts with context compression. When a long document is summarized by one agent and the summary passed to another, the summary may retain the semantic content of an injection while shedding the specific phrasing that a keyword-based filter would detect. The attacker's instruction survives in a paraphrased form that looks like ordinary content to both the receiving agent and any detection layer that evaluates incoming text.