Indirect Prompt Injection

What Is Indirect Prompt Injection?

Indirect prompt injection occurs when attacker-controlled instruction-like content reaches an LLM application through a resource or content path rather than through the primary user's query. A website, email, document, search result, knowledge-base entry, source file, image, or tool result can carry the content. The application retrieves or processes that resource for a legitimate task, then makes some representation of it visible to the model.

The attacker may never use the victim application and may not know which individual will trigger processing. They can instead control or influence a resource that the application is likely to browse, retrieve, index, summarize, classify, or analyze. NIST describes this distinction as resource control rather than direct query access. The human who opens a message or requests a summary is therefore not necessarily the primary target. The embedded language can be aimed at the AI system that consumes the material.

Malicious content may be obvious to a reader, visually unobtrusive, represented in metadata, or present in a non-text modality that the system converts into model-visible information. Visibility is not the defining condition. What matters is whether attacker-influenced content enters the AI processing pipeline and is interpreted in a way that changes the intended task, output, plan, or proposed action.

How Indirect Prompt Injection Works

The application intends external material to be data. A browser assistant may fetch a page, an email assistant may read a message, a document service may extract PDF text, and a RAG system may retrieve passages from an index. In each case, an application component obtains content and places it, or a transformed representation of it, into the context supplied to the model.

The model is then asked to interpret application instructions, the user's task, and the external material together. Natural language inside the material may describe facts, quote another person, contain ordinary prose, or resemble a command. If instruction-like language changes how the model interprets its task, the content has crossed a semantic trust boundary even though the retrieval, parsing, and storage operations behaved exactly as designed.

This distinction matters: parser or storage trust is not semantic trust. A file can be valid, malware-free, correctly signed, and successfully parsed while still containing language intended to redirect the model. Likewise, a connector can be authentic and correctly implemented while returning attacker-controlled content from a public website, shared mailbox, collaborative document, issue tracker, or third-party service.

Source content may arrive dynamically during one request, or it may have been ingested into a corpus days earlier. In the stored case, the attacker-controlled text can persist until the affected document, chunk, cache entry, or index representation is removed. The later user who triggers retrieval may have no relationship with the attacker.

Attack Success Chain

A complete path has separately testable gates. The attacker must first control or influence a source and have it reach the relevant workflow. Its meaning must survive retrieval, parsing, extraction, summarization or other transformations before becoming model-visible. Only then can model or plan influence be observed. A material vulnerability still requires a reachable data or capability path and an application control that is absent, fails, or authorizes more than the initiating principal and task permit.

Success at one gate is not evidence that the next is exploitable: source placement is not processing reachability, reachability is not model visibility, visibility is not influence, influence is not policy bypass, and policy bypass is not an actual effect unless protected data, authority or a side effect is reached.

Defenders can break the chain at several points. They can prevent retrieval, exclude or isolate content during context construction, reduce capability exposure, deny an unauthorized resource or action, reject an unapproved destination, or stop execution before a side effect. Evaluation should therefore record where influence occurred and where containment succeeded rather than classifying every changed response as exploitation.

Offensive Review Questions

An authorized assessment should describe the complete path without assuming that control of a source guarantees impact. The following questions apply across vectors while leaving implementation details to the dedicated child articles.

What Actually Happens in the Model Context

Not every product supplies every source listed above, and providers represent messages and roles differently. Structured roles, data delimiters, content labels, and separate fields can help the model distinguish task instructions from supporting material. They improve clarity and may reduce successful injections, but they do not create deterministic isolation inside a probabilistic natural-language interpreter.

The surrounding application must retain the authoritative provenance of every external item. It should know which connector produced it, which resource and principal originated it, when it was ingested or retrieved, which trust policy applies, and which user is currently requesting access. Those facts should remain structured application data rather than depending on the model to infer them from prose.

The model's output is not authorization. Even if it confidently proposes a tool call or labels external text as safe, the application must independently evaluate identity, resource permissions, action, parameters, destination, and current policy. The model can assist interpretation, but it cannot promote untrusted content into authority.

Trust Boundaries and Data Provenance

"Internal" is not a trust classification. An internal wiki can accept contributions from many employees. A support database can contain customer-controlled fields. A shared repository can include pull requests from external contributors. A mailbox can contain messages from the public internet. Each source needs a trust assessment based on who can write it, how it is reviewed, and what consuming workflow can do.

Documents should default to untrusted for security decisions. A higher classification requires evidence about provenance, chain of custody, effective permissions, and who can write or replace the material. Internal hosting alone does not grant instruction authority or establish that the document is safe to control a workflow.

Preserve source identity, initiating principal, tenant, ingestion path, retrieval event, policy version, resource permissions, timestamps, and transformations outside the LLM. When content is split into chunks or copied between systems, keep enough lineage to identify the original document and revoke or quarantine all derived representations. Without that lineage, incident responders may see a suspicious model output but be unable to determine which stored source caused it or who else consumed it.

Four Security Questions

These dimensions are independent. A source can be authentic, correctly signed, or hosted inside the organization and still have no authority to issue workflow instructions. Conversely, a model may legitimately see confidential data for one purpose without gaining permission to disclose it, transfer it, or use it in an unrelated action.

Keeping the questions separate prevents trust laundering. Source authenticity answers where content came from, not whether its language may control the system. Model access answers what was supplied for processing, not what the model or an agent may reveal or execute.

Worked Examples

These examples describe complete paths without supplying optimized attack strings. Each separates model-behavior change from a meaningful security boundary crossing.

Website summarization or browser assistant. A user asks an assistant to summarize a public page. The page contains language directed at automated readers, asking them to change the requested task. The model produces a distorted summary or follows the page's preferred framing. That is an instruction-control failure. It becomes a material security issue if the assistant also exposes private context, visits unrelated resources, or sends information externally without authorization.

Email assistant. An attacker sends a message that is later summarized or triaged by an assistant. The message attempts to influence categorization, request access to unrelated records, or change the intended recipient of a follow-up. If the assistant only drafts a visibly reviewed summary, impact may be limited. If it can autonomously retrieve customer data or send messages, independent authorization and destination controls become essential.

RAG or document knowledge base. An attacker or low-trust contributor adds a document that later ranks as relevant to another user's question. A retrieved chunk tries to redefine the task or request disclosure of other context. The model may combine the chunk with legitimate sources. Cross-user impact becomes possible when one stored contribution influences answers or actions for many users, but only if ingestion, retrieval, model behavior, and missing downstream controls align.

Tool output or agent chain. An agent calls a trusted issue-tracker tool. A ticket description contains language aimed at the agent and causes it to propose reading an unrelated repository and sending a report elsewhere. The connector operated correctly, but its output carried untrusted content. Each subsequent access and communication must be authorized against the initiating principal and task.

Common Indirect Prompt Injection Vectors

These categories describe delivery surfaces and mechanisms. They can overlap: a PDF can enter a RAG corpus, a search result can point to a website, and one agent's output can become another agent's input. Obfuscation and encoding can also be carried through externally supplied content; that changes representation and evasion characteristics, not the direct-versus-indirect classification.

Persistent and Stored Prompt Injection

Indirect influence can outlive the request that introduced it. Relevant stores include RAG corpora and vector indexes, agent memory, conversation summaries, scratchpads and shared state, database fields and collaborative records, caches, and other derived artifacts. Persistence changes both exposure and investigation: one contribution can affect later users, sessions, agents, or tasks long after ingestion.

Second-order persistence occurs when a model-generated summary, memory entry, extracted fact, cached response, or derived chunk preserves attacker influence after the original source changes or disappears. Removing the source document may therefore leave the effective instruction in downstream state. A clean-looking derivative can also blur provenance and make the original writer or resource difficult to identify.

Containment must follow the lineage graph. Responders may need to quarantine or rebuild affected chunks, summaries, caches, memory entries, indexes, and embeddings while retaining original artifacts, identifiers, timestamps, and transformation history as evidence. Reprocessing from a known-good source is safer than assuming deletion from one store removes every derivative.

RAG Prompt Injection

Retrieval-augmented generation typically ingests documents, extracts and chunks their content, creates representations such as embeddings, stores them in an index or vector database, and retrieves relevant chunks for a later query. These operations improve access to domain material. They do not neutralize instruction-like language. An embedding represents content for retrieval; it does not certify that the content is trusted or safe to treat as control input.

Retrieval relevance and trust answer different questions. A chunk can be highly relevant to a query while being authored by an attacker, obsolete, outside the user's permission scope, or unsuitable for directing the application. The retriever may correctly select it, and the model may still incorrectly treat its language as part of the task rather than as evidence to analyze.

Ingestion-time poisoning occurs when attacker-controlled material enters or alters the corpus before a victim query. Query-time exposure occurs when the retrieval process selects that material and supplies it to the model. A complete assessment examines both phases: who can add or modify sources, how transformations preserve lineage, how retrieval applies user and tenant permissions, and what controls govern the resulting output or action.

Authorization belongs before context construction. Security trimming and ACL-aware retrieval should enforce tenant-, document-, and where needed chunk-level permissions before any material becomes model-visible. Chunking and indexing must preserve authorization metadata and source lineage so a derived chunk cannot lose the access restrictions of its parent. Reranking and relevance scores can order permitted candidates, but they are not authorization or trust decisions.

Stored content may persist across sessions and affect multiple users when the corpus is shared. Scope depends on document permissions, retrieval filters, indexing boundaries, cache behavior, and downstream authority. This does not mean every RAG system is inherently unsafe. Systems with curated sources, strong access control, provenance-aware retrieval, constrained outputs, and no consequential tools have a different risk profile from open ingestion pipelines connected to powerful agents.

During containment, remove or quarantine not only the source but also its derived chunks, cached retrieval results, summaries, index entries, and embeddings where those artifacts can preserve reachability or influence. Keep enough evidence and provenance to establish which queries, users, and model requests consumed them before rebuilding from trusted inputs.

Why AI Agents Increase the Impact

An assistant that only returns text mainly influences what a user sees. An agent can interpret objectives, select tools, choose parameters and destinations, retrieve additional data, communicate externally, or write persistent state. Indirect injection can therefore influence not only the answer but also how the system decides what to do next.

External content may alter objective interpretation, cause unnecessary follow-on retrieval, select a higher-impact tool, broaden data selection, change a recipient, modify an action parameter, or create memory that affects later work. A model-generated plan can look coherent while drifting from the initiating user's purpose. The more delegated authority and autonomy the agent has, the more important independent enforcement becomes.

The model may propose an action. It must not decide that the action is authorized. The application should bind every consequential operation to the initiating identity, permitted resource, allowed action, validated parameters, approved destination, and current policy. This converts unpredictable model behavior into bounded proposals rather than self-granted authority.

Multi-Agent Prompt Injection and Delegation

Every inter-agent message is a trust boundary. A coordinator may pass retrieved content, a summary, a plan, or a tool result to a specialist agent with a different privilege scope. Across these hops, prose can lose its source label and appear to be a trusted instruction from another system component. Multi-agent coordination therefore increases the number of places where untrusted observations can be mistaken for delegated authority.

This can launder trust in a way similar to a confused deputy: a less-privileged component asks a more-privileged component to act, and the receiver mistakes the sender's wording for proof that the initiating user authorized the operation. The fact that another agent produced or relayed a message does not make its underlying website, document, tool output, or model-generated claim trustworthy.

Each hop should preserve the initiating identity, source provenance, task intent, and authorization context as structured data. The receiving agent or tool must revalidate permissions for its own resource and action rather than inherit authority from another agent's prose. Least privilege, narrow delegation, and validation at each hop bound the complexity identified in current Microsoft guidance.

Capability, Authorization, and Approval Design

Tool availability is an interface decision, not permission to perform a particular operation. Prefer capabilities scoped to the current task, principal, resources, action class, destination, and time window over ambient credentials that remain usable across unrelated plans. A stable agent identity supports audit and policy, while short-lived or just-in-time privileges reduce what compromised interpretation can reach.

Human approval pattern. A meaningful approval view shows at least the initiating principal, source, affected resource or data, exact action, relevant parameters, destination, and expected side effects. Approval is an additional control for selected high-impact or exceptional operations, not a universal remedy for ambiguous prompts or over-privileged architecture.

Potential Impact

The following outcomes depend on system architecture, permissions, exposed data, and downstream controls. They are possible consequences, not guaranteed results of every injected resource.

Plan Drift

Plan drift is a divergence between the initiating task and the steps the model proposes or executes. In this example, reading the requested document is expected. Accessing an unrelated private resource and attempting an external action are not necessary to summarize it. The added steps provide a useful signal that external content may have redirected the workflow.

Drift is not deterministic proof of attack. Complex tasks can legitimately evolve, and a malicious plan can remain superficially aligned with the user's goal. Detection should compare objectives, data dependencies, selected tools, destinations, and side effects, then combine that evidence with provenance and authorization outcomes.

Tool-Chain Analysis

Tool-chain analysis evaluates the relationship among actions rather than judging each call in isolation. A file reader, extractor, and mail sender may all be approved tools. Their sequence can nevertheless move confidential data from an internal trust domain to an external destination. Correlate the chain with the initiating task, principal, resource permissions, approved destinations, and previous authorization decisions.

A trusted tool does not make its output trusted, and an allowlisted tool does not make every sequence safe. Validate parameters and data flow at each boundary, including what one tool returns to the model and what a later tool receives.

Information Flow Control

Information-flow controls constrain how data may move between trust domains. Untrusted website or document content may legitimately influence a summary of that content. It must not authorize movement of confidential records into the summary, cause internal data to be sent externally, or expand the set of resources available to the current principal.

Implement this principle with structured provenance and policy outside the model. Label source, tenant, classification, owner, permitted purpose, and destination constraints. Track those properties through retrieval and tool calls. Before a side effect, evaluate whether the proposed flow from source data to destination is permitted. The model's explanation or confidence is not evidence of authorization.

Useful controls include tenant-aware retrieval, field-level access checks, destination allowlists, data-loss prevention, egress policy, scoped credentials, and separation between read and write capabilities. These measures do not prevent every interpretation error. They limit which errors can become disclosures or unauthorized actions.

Detection

Detection and enforcement serve different purposes. Content inspection, classifiers, model-based critics, and behavior analysis are probabilistic. They can prioritize review, block obvious cases, and provide context, but false positives and missed attacks remain possible. Authorization, resource access, parameter validation, and egress restrictions should be deterministic wherever the policy can be expressed deterministically.

Logging and Telemetry

Investigation requires a trace from the initiating task through external content, retrieval, model decisions, policy checks, tools, and side effects.

Prompts, retrieved content, emails, documents, and tool results may themselves contain personal, confidential, or regulated information. Apply minimization, access control, redaction where appropriate, retention limits, and secure deletion. Preserve forensic lineage without creating an unnecessarily broad secondary repository of sensitive content.

Incident Response

Adding the observed sentence to a blocklist is not sufficient. Determine why the resource entered a sensitive context, why its provenance was not preserved or acted upon, and which downstream control allowed model interpretation to reach protected data or authority.

Prevention and Mitigation

Design under the assumption that some indirect injections will evade content detection. Defense in depth reduces the probability of influence and limits the consequence when influence occurs.

1. 01
   Inspect and classify external content

   Use parsing, source analysis, data marking, and probabilistic detectors as screening signals rather than complete protection.

2. 02
   Preserve provenance

   Carry source identity, trust, tenant, permissions, ingestion history, and retrieval lineage outside the model.

3. 03
   Separate untrusted content

   Use clear context boundaries, focused tasks, constrained transformations, and quarantine paths where appropriate.

4. 04
   Minimize model-visible secrets

   Do not expose confidential data, credentials, or broad context unless the current task and principal require it.

5. 05
   Apply least privilege

   Give agents scoped tools, data access, short-lived credentials, and limited write authority.

6. 06
   Authorize every action

   Enforce principal, resource, action, tenant, destination, and current policy outside the LLM.

7. 07
   Validate tools and parameters

   Use allowlisted operations, typed interfaces, parameter constraints, destination checks, and business invariants.

8. 08
   Restrict network and egress

   Constrain reachable services, external destinations, protocols, and data movement.

9. 09
   Require meaningful approval

   Use informed human confirmation for high-impact or unusual actions, showing source, data, destination, and effect.

10. 10
    Isolate execution

    Apply sandboxing, quarantine, read-only modes, transaction boundaries, and rollback where suitable.

11. 11
    Monitor plans and tool chains

    Detect task drift, risky action sequences, denied requests, and unexpected cross-domain flows.

12. 12
    Test adversarially

    Exercise source types, persistence, retrieval, tools, authorization, egress, isolation, and telemetry after relevant changes.

Secure Architecture

The stronger path does not assume that inspection or the model will always recognize malicious content. Inspection adds signals and provenance. The LLM proposes an interpretation or plan. Plan validation checks relevance to the user's task. Policy and authorization evaluate identity, resource, action, tenant, parameters, and destination. Human approval can add context for exceptional high-impact operations, and the tool remains restricted to the minimum capability required.

Each layer should fail safely. A classifier miss should not grant authority. A persuasive plan should not bypass access control. An approval screen should not hide the destination or affected data. A tool error should not trigger a broader fallback permission. The objective is bounded consequence, not perfect prediction of model behavior.

Severity Factors

Evaluate severity from demonstrated reachability and consequence rather than assigning a generic score to the attack name.

Threat Modeling Checklist

Testing Indirect Prompt Injection

Test in a controlled environment with synthetic content, non-production identities, bounded tools, and reversible side effects. Define expected policy outcomes before running cases so the assessment measures security boundaries rather than only response quality.

Keep these dimensions separate rather than combining them into one score. A system can show substantial model influence while containing every unauthorized side effect. It can also detect many injected sources while still failing authorization on the cases it misses. Use synthetic data, non-production systems, and predetermined expected outcomes so the measurements remain defensive, reproducible, and safe.

A passed test set is evidence about one configuration, not proof that indirect prompt injection has been eliminated. Record influenced, blocked, detected, contained, and successful paths separately. Validate both model behavior and real downstream effects.

Common Misconceptions

Direct vs. Indirect Prompt Injection

The distinction concerns delivery, not an automatic severity ranking. Both variants can produce harmless misbehavior or material system impact. See Direct Prompt Injection for the primary-user path.

Related Attack Classes

These classes can coexist in one incident but should not be conflated. The labels describe different placement mechanisms, compromised boundaries, or objectives. OWASP mappings are used only where the reviewed source explicitly supports them.

Research and Design Directions

Recent research explores controls that assume the underlying model may remain susceptible. Debenedetti et al.'s Defeating Prompt Injections by Design presents CaMeL as a protective system layer that separates control and data flow derived from the trusted query and applies capability-based controls to prevent unauthorized data flows. The design relevance is architectural: enforcement sits outside the model's ability to follow competing language.

He et al.'s AttriGuard examines action-level causal attribution for tool-using agents. Its central question is whether a proposed tool invocation is supported by user intent or causally driven by an untrusted observation. This direction complements authorization by adding evidence about why an action entered the plan; it does not turn model judgment into permission.

Chang et al.'s Overcoming the Retrieval Barrier emphasizes end-to-end evaluation in realistic systems: poisoned content must actually be retrieved before it can influence the model. Retrieval reachability is therefore part of both the attack success chain and defensive measurement, not a setup detail to assume away. This extends the real-world application perspective established by Greshake et al. without implying that any single technique eliminates indirect injection.

Standards and Classifications

OWASP LLM01:2026 distinguishes direct and indirect injection, identifies external sources such as websites and files as delivery paths, and treats retrieved documents and memory as a single untrusted token stream with no enforced trust boundary. MITRE ATLAS catalogs indirect LLM prompt injection as AML.T0051.001.

NIST AI 100-2e2025 provides adversarial machine-learning terminology. Its glossary describes indirect prompt injection as prompt injection executed through control of a resource rather than user-provided input. No additional CWE, CAPEC, or unreviewed framework mappings are asserted here.

Frequently Asked Questions