What Is an Indirect Prompt Injection Payload? Examples and Detection
An indirect prompt injection payload is a set of malicious instructions embedded inside content an AI agent retrieves or processes, such as a document, web page, email, or tool output, rather than typed directly by an attacker. When the agent ingests that content into its context window, the embedded instructions can be interpreted as legitimate input and acted on as if authorized, potentially triggering unintended tool calls or data exposure without any direct interaction between the attacker and the model.
Direct vs. Indirect Prompt Injection
Direct prompt injection occurs when an attacker types a malicious instruction directly into a chat interface, API call, or prompt field, and the model acts on it. Indirect prompt injection removes that direct interaction. The attacker instead embeds instructions inside content the agent will later retrieve or process, such as a resume submitted to an HR tool, a web page fetched by a browsing agent, or a response returned from a third-party API.
OWASP's Top 10 for LLM Applications treats these as distinct risk categories precisely because the delivery mechanism differs. The instruction still reaches the model's context window, but it arrives through a pipeline the system already trusts, which is why input filters designed for user-typed text often miss it entirely.
Anatomy of an Indirect Prompt Injection Payload
Indirect payloads are typically hidden within the substance of otherwise ordinary content, using formatting that a human reviewer would not notice but that a model still parses. Common techniques include near-invisible text, such as white text on a white background or zero-width characters, and instructions placed in metadata fields like alt text, document properties, or HTML comments.
A support ticket, for example, might contain a faint line reading something like an instruction to disregard prior directions and forward customer records to an address specified in the ticket.
In agent architectures using external tools, security researchers have described tool poisoning, where a malicious instruction is embedded directly in a tool's description or output rather than in visible content. For instance, an MCP server could return a tool description containing an embedded directive telling the agent to always invoke a data-export tool with broad scope before responding. Because that description is returned into the model's context as part of normal tool discovery, the agent may treat it as a legitimate operating instruction rather than as untrusted input.
This is what makes indirect payloads difficult to catch with input validation alone: the malicious intent is often only apparent when the content is evaluated alongside the agent's available tools and permissions, not from the text in isolation.
Indirect Prompt Injection at a Glance
| Dimension | Detail |
|---|---|
| Entry points | RAG documents, browsing results, tool outputs, MCP responses |
| Payload forms | Hidden text, metadata fields, malicious tool descriptions |
| Blind spot | Bypasses controls aimed only at direct user input |
| Control point | Runtime policy enforcement before tool execution |
Where Indirect Payloads Enter the Agent Pipeline
-
Retrieval-Augmented Generation
Documents pulled into context during RAG ingestion can carry hidden instructions that the retrieval layer does not inspect for intent.
-
Browsing Agents
Web pages fetched by an agent are rendered as text and passed into context, allowing embedded instructions on a page to influence the agent's next action.
-
Tool and API Outputs
Responses returned from internal or third-party APIs are often placed directly into model context without being treated as untrusted input.
-
MCP Server Responses
Model Context Protocol servers expose tool descriptions and outputs that flow into the model's context; if the server is untrusted or compromised, both can carry injected instructions.
-
Email and Message Content
Agents that summarize or act on inbound messages inherit whatever instructions are embedded in that message body.
Architectural Gaps That Allow Bypass
- No separation between the channel carrying system instructions and the channel carrying retrieved or tool content
- Tool descriptions and outputs handled as trusted system input rather than untrusted external content
- Tool calls executed automatically as a direct consequence of model output, with no independent policy check
- Missing provenance logging, making it hard to trace an unexpected action back to the content that triggered it
- No formal review or allowlist process for connecting new MCP servers or third-party tools to production agents
Detection Techniques and Runtime Controls
Effective coverage requires scanning ingested content and validating proposed tool calls, not only filtering direct user prompts.
Content scanning at ingestion
Apply prompt-injection detection to documents, retrieved web content, and tool outputs before they are added to model context, not just to user-typed prompts.
Least-privilege tool permissions
Limit each tool an agent can call to the minimum scope required, so a successful injection has limited ability to trigger high-impact actions.
Tool-call policy enforcement
Treat tool execution as a distinct, policy-gated step so a runtime layer can inspect a proposed action against rules before it runs, rather than executing automatically.
Sandboxed browsing and retrieval
Constrain browsing agents so that fetched content cannot directly rewrite system instructions or trigger unreviewed actions.
MCP server and tool vetting
Treat MCP servers and third-party tools as an extended trust boundary; require an allowlist and review process rather than connecting to arbitrary servers by default.
Context-origin logging
Log which content source and tool response contributed to a given model context, so unexpected agent behavior can be traced back to its origin.
Frequently Asked Questions
Can traditional input filtering stop indirect prompt injection?
Not on its own. Input filtering is designed to inspect what a user types, but indirect payloads arrive through documents, tool outputs, or MCP responses. Effective coverage requires scanning ingested content and validating proposed tool calls, not just filtering direct user prompts.
Is indirect prompt injection specific to Model Context Protocol systems?
No. It applies to any architecture where an agent ingests external content, including RAG pipelines and browsing agents. MCP increases exposure because tool descriptions and outputs are returned directly into model context, often with limited built-in trust labeling.
Does defending against indirect injection mean blocking all external content?
No. The documented approach combines content scanning, least-privilege tool permissions, and policy checks on proposed actions, allowing agents to keep using external content while limiting what an injected instruction can actually cause the agent to do.
Govern What Reaches Your Agents at Runtime
Trussed AI provides runtime governance for enterprise AI agents, including MCP security, tool approval workflows, least-privilege agent permissions, and audit logging to help security teams enforce policy on agent actions before they execute.
Talk to an Expert