Indirect Prompt Injection

Prompt injection is divided into two categories—direct injection and indirect injection—where indirect injection refers to attackers concealing malicious instructions in external content that the AI may read, such as webpage body text, code comments, README files, and image OCR text.

Indirect prompt injection is an attack vector in which an attacker embeds malicious instructions in web pages, documents, or emails that an agent may read, inducing the agent to perform operations beyond the scope of the original task.

Indirect prompt injection refers to attack instructions hidden in external web pages, documents, or API responses accessed by an agent, where the malicious instructions are activated when the agent retrieves and injects them into the context.

Indirect injection refers to attackers hiding malicious instructions in external content that the model will read, such as webpage body text, email body text, or document content.

Indirect prompt injection refers to attackers pre-embedding malicious instructions into third-party content (such as web pages, PDF documents, or API responses), which the model then executes after RAG systems retrieve or tool calls pull this content into the context.

Prompt injection can be divided into two types: direct injection and indirect injection; indirect injection is where an attacker hides malicious instructions in external data sources such as web pages, PDFs, and emails, and when an AI agent processes this data the malicious instructions are executed as legitimate instructions.

Permissions that appear harmless when held individually by an agent (such as reading files and calling an HTTP library) can enable data exfiltration when combined, which is the tool-combination emergence problem.

The industry has yet to find a solution that fundamentally resolves prompt injection, and can only reduce the risk through multi-layered defenses.

The principle of indirect prompt injection is that an attacker disguises malicious instructions as normal data, delivers them to the model through a data source trusted by the agent, and induces the model to interpret the data as instructions and execute them.

Indirect prompt injection is especially dangerous because an attacker can carry out the attack without directly touching the user.

The AI Standards and Innovation Center under NIST defines agent hijacking as a form of indirect prompt injection.

Defending against indirect prompt injection cannot rely on prompt engineering alone (such as "please ignore conflicting instructions"), because the model treats all tokens as equally authoritative, and it must rely on architectural-level separation of commands and data.

The attack surface of indirect prompt injection includes any text that flows into the model context, such as emails, web pages, tickets, and contracts.

In indirect prompt injection, the attack payload can lie dormant for weeks undetected, triggering when a code repository, document, or web page is automatically fetched by an agent.

For business systems, indirect prompt injection is especially dangerous, because attackers often need no account or login, as long as they can influence some indexed data source.

The core principle for defending against indirect prompt injection is the separation of data and instructions, that is, wrapping external data source strings in boundary tags (such as <untrusted_data>) and stripping control tokens that could be disguised as conversation role markers (such as <|im_start|>, [INST], etc.).

The focus of defending against indirect prompt injection cannot be on 'identifying malicious text' but must be on capability constraints—even if the agent is persuaded to call a tool, the system should have the authority to refuse that call.

In an agent scenario with three tools—reading tickets, reading customer records, and sending email—instruction text embedded in the ticket body can cause the agent to call the customer records and email tools without any traditional exploit and without stolen credentials, because permissions are granted per session rather than per call.

A file-read tool with path traversal, a URL fetch tool without target filtering (an SSRF vector), and a Shell execution tool without an allowlist (arbitrary code execution) are all exploitable items for indirect prompt injection.

Indirect prompt injection is structurally consistent with stored XSS: the malicious content resides in the data source in advance rather than entering the system at the time of the user query, revealing that statically stored data also crosses trust boundaries.