Indirect Prompt Injection

TL;DR: Indirect prompt injection carries an attempted task redirection inside material the application processes, such as a retrieved document, message, image or tool result. Map who can influence that material, what reaches the model after transformation, and which data or effects the resulting proposal can reach.

What you should be able to do

Draw the path from a source writer to a specific assistant decision. Separate source access, ingestion, model influence and observed consequences. Then design an authorized test that checks both the blocked path and the legitimate task. The prompt-injection introduction explains why an input's role does not automatically give its author authority.

The writer can be several steps away from the assistant

Noor uses a fictional procurement assistant to compare two suppliers against internal requirements. The assistant may read approved supplier documents and a restricted requirements file, then prepare a draft for Noor. It has no grant to send the requirements to either supplier or change the procurement decision.

One supplier controls a public document that the assistant fetches. That document attempts to redirect the comparison and get internal requirements included in supplier-visible material. The supplier's ability to publish a document is a capability in the threat model. It is not permission to command the assistant or receive Noor's internal file.

The supplier need not operate the assistant's chat interface. But it may need an account on the document platform, permission to edit a particular page or access to an upstream integration. State the actual prerequisite. “No account required” is a property of some delivery paths, not the definition of indirect injection.

Greshake and colleagues' 2023 indirect-injection paper studied attacker-controlled data reaching LLM applications through retrieval. The enduring lesson is to inventory source influence beyond the person typing a request. A trusted transport or authenticated tool can faithfully deliver content whose author has no authority over the task.

Inventory authors, transformations and audiences

Start at the model input and trace backward. A tool result may contain a database field copied from a customer message, and a summary may contain a conclusion inherited from several pages. Record uncertainty when source lineage is missing.

An internal location can carry externally authored text. A cryptographic transport check can identify the service without making every returned claim true. Source provenance is useful evidence for enforcement and investigation; merely showing a label to the model does not prevent disclosure.

Relevance and authority also differ. A supplier's document can be highly relevant to the comparison while remaining unable to redefine its scoring criteria. Conversely, source instructions may be exactly what Noor asked the assistant to explain. The application must preserve the distinction between reporting those instructions and accepting them as permission for a new action.

Inspect the representation the model actually receives

A text extractor, rendered-page reader and screenshot-based model can receive different representations of the same document. Hidden markup may survive one parser and disappear in another. Text inside an image may become visible to a vision model or an OCR stage. Do not claim that every model reads raw page text or that changing visibility always changes exposure.

Record the source revision and the transformation that produced the supplied representation. Showing a human the processed view can help explain a finding, but human visibility is not an authorization mechanism. Visible ordinary prose can also attempt to redirect the task. Removing hidden elements or limiting parsers can reduce a specific input surface without resolving source authority.

A derived summary needs the same discipline. A structured record or second model does not automatically turn source content into trusted evidence. If a downstream policy accepts the summary's self-reported audience, the writer may have moved its influence to a different field. Keep trusted policy inputs separate from values extracted or inferred from source material.

Five conditions to test, with different failure meanings

For Noor's case, ask whether the source can be modified, whether it reaches the relevant task, whether it changes the assistant's proposal, whether a service accepts the proposal, and whether the forbidden consequence occurs. An application may stop the chain at several places.

These are observable conditions, not a prescribed attack recipe. Use only systems you own or are explicitly authorized to test, synthetic sensitive values and an isolated destination that cannot send real data. Exercise allowed supplier comparisons alongside the negative cases.

Work through an incomplete result

In a constructed evaluation, 20 source variants are tested once each. Twelve are retrieved into the selected task. Five of those runs produce a forbidden delivery proposal. Four proposals are denied by the delivery service. One is accepted, but the test observer loses the final result.

What can the report say? It observed ingestion in 12 of 20 cases, forbidden proposals in five of the 12 ingested cases, and four service denials among the five proposals. It has no confirmed forbidden delivery and one unresolved delivery outcome. Reporting “zero successful attacks” would hide that uncertainty. Reporting five leaks would confuse proposals with effects.

The set was constructed for these conditions; it is not a random sample of daily procurement work. Repeated attempts, changing queries and adaptive source revisions also need their own evaluation design. AgentDojo v3 (2024) is an example of research that evaluates agent security together with legitimate task performance. A benchmark result does not establish this product's incident probability.

Break the path with a policy the source cannot rewrite

For this task, the assistant does not need an external delivery capability. Remove that capability from the processing path and verify that alternate tools, direct credentials, queues and preview services cannot perform the same effect. Keep the draft in Noor's authorized workspace. This is a concrete scope reduction justified by the task, rather than a universal prohibition on useful automation.

If a later task genuinely requires delivery, the delivery service should check a current grant for the specific material and recipient. It must not infer permission from the supplier's document or from the fact that Noor can read the requirements. Approval is one way to obtain new authority when needed; an existing bounded grant may already cover the operation.

Review all rendered and persisted destinations. An application that disables its email tool might still fetch model-generated images, create link previews, export drafts or publish shared memory. A host allowlist is only one restriction: an allowed proxy, user-controlled path or recipient can still expose material outside its permitted audience. HTML sanitization helps prevent active-content execution; a syntactically safe URL can still carry confidential data.

Keep source labels, model training and detectors as additional measures. Test the particular reduction they provide. Down-ranking a document makes retrieval less likely under selected queries; an enforced exclusion policy can prevent it entering a specified path. Those are different control claims.

Prioritize the actual consequence

One source revision may be processed by several workers or users, but every reader does not automatically become compromised. Retrieval, model behavior, application permissions and output handling all affect the result. Shared caches and persistent summaries can extend reach and duration, so include them in containment and retesting.

Likewise, direct injection can reach a broadly privileged backend from an unauthenticated interface, while an indirect path may only affect a restricted draft. Compare observed effects, possible audiences, current capabilities and observation gaps. The 2025 OWASP taxonomy, checked November 2026, distinguishes input routes without making every indirect case a greater incident.

Use the map in a review

Bring a short source inventory and one end-to-end trace. State which authority the source writer lacked, which representation reached the model, and which policy decided the effect. Preserve the finding's limits: a tested denial on one recipient does not cover every rendering path, and a missing outcome needs reconciliation.

For further design work, use retrieval security, tool-result trust and agent memory. Each adds a different lifecycle or enforcement boundary to this source map.