What is indirect prompt injection?

Summary slides

Why indirect injection specifically exploits the trust a system extends to its tools and data sources

Direct prompt injection, already covered in depth elsewhere in this broader body of work, exploits a model’s inability to structurally distinguish an instruction from content it’s merely asked to read and process. Indirect injection exploits that exact same underlying gap, but it does so through a specifically different, and often considerably more dangerous, pathway: the trust a system extends to its tools, its retrieval pipeline, its integrations, treating whatever those trusted mechanisms return as safe by default simply because the system itself, not an external party, chose to fetch it. A model asked to summarize a webpage has no particular reason to distrust that webpage’s content any more than it trusts its operator’s instructions, since both arrive through that exact same underlying channel, and this is precisely the gap indirect injection is specifically built to exploit.

This means indirect injection isn’t really, in the narrow sense, an attack on the model at all, it’s an attack on the boundary between a system’s trusted infrastructure and the untrusted, real world that infrastructure reaches out into every day. A search tool, a document retrieval system, an email client, a calendar integration, each of these represents its own door the system has deliberately opened to the outside, real world specifically in order to be useful at all, and indirect injection is precisely what happens when someone entirely outside walks through that door carrying something other than what the door was originally meant to admit through it.

How the attacker and victim being different people changes the actual threat model

In direct injection, the actual person attempting the manipulation and the actual person experiencing its consequences are the exact same individual, someone trying to get a system to do something it shouldn’t do, entirely on their own behalf, within their interaction. Indirect injection breaks this alignment entirely, and this break has practical consequences for how the threat has to be modeled and defended against. An attacker plants content somewhere they merely expect a target system will eventually process, a comment on a page the system’s browsing agent might visit, a document uploaded to a shared drive the system indexes, a calendar invite sent to someone whose assistant reads upcoming events, and then simply, patiently waits, with no further action required on their part at all, for a legitimate user’s entirely ordinary, everyday activity to eventually trigger the payload on its own.

This particular separation means a victim organization can be quite well-defended against direct manipulation attempts training its users, actively monitoring its direct interactions, while still remaining completely exposed through indirect vectors that never involve any of its users doing anything unusual at all. It also means a single successful plant can affect many different victims over time, since the injected content doesn’t get consumed or exhausted by triggering once, it simply sits waiting for the next legitimate user whose activity happens to surface it, giving an attacker a persistent, low-effort foothold that a one-time direct attempt simply can’t match.

Common delivery vectors for indirect injection

Web content is by far the most commonly discussed vector overall, since any system with browsing or search capability is, quite by definition, built to pull in content from sources with no vetting process attached to them at all, but it’s far from being the only one worth naming here. Email represents a particularly concerning vector for any system with an email-handling assistant of its own, since an attacker can simply send a message containing injected content to literally anyone whose assistant reads and summarizes incoming mail, requiring no access to any system the target organization controls at all, merely the ordinary ability to send an email the exact same way literally anyone can. Documents shared through various collaborative platforms, calendar invites with instructions embedded in their description fields, code comments sitting quietly in a shared repository a coding assistant might read, customer support tickets that get fed into a knowledge base later on, each represents its own distinct vector worth naming, and the common thread running across all of them is simply that the content originated somewhere the target system doesn’t fully control and ended up somewhere the system’s model reads it in full.

This breadth of vectors means an organization simply can’t treat indirect injection defense as a problem specific to just one particular integration alone, hardening its retrieval pipeline while leaving its email assistant or its calendar integration essentially, entirely unexamined and unreviewed. Every distinct channel through which external content reaches a model’s context represents its instance of the same underlying risk, and a thorough defense has to inventory every one of these channels rather than assuming that securing the most obvious one, typically web search or document retrieval, has addressed the risk category as a whole.

How multimodal indirect injection works through images and other non-text content

As models have gained the actual ability to process images, audio, and other non-text content directly and natively, indirect injection has naturally followed right along with that same expanding capability, with instructions embedded in an image’s visible text, in metadata a model processes alongside the image itself, or in patterns specifically designed to be legible to a model’s vision capability while remaining unremarkable or invisible to a casual human glance. An image containing text instructing a model to take some action, deliberately sized and positioned so a human reviewer merely skimming the image would never notice it at all, works through essentially that exact same underlying mechanism as ordinary, text-based indirect injection, the model reads content it was asked to process and, entirely absent any structural distinction, can treat an instruction embedded within it as fully authoritative, exactly as it would treat any other instruction.

This particular vector deserves deliberate attention because organizations quite often build defenses primarily around text content alone, scanning documents, filtering retrieved passages, monitoring email bodies, while giving comparatively little thought to images, audio, or other media a system might process, on the reasoning that these particular formats feel considerably less like the kind of thing that could carry an instruction at all. That particular reasoning doesn’t hold up under scrutiny, since any content type a model can meaningfully process is, quite by definition, content that can carry an embedded instruction the model might treat as authoritative, and defenses built with only text specifically, narrowly in mind will simply miss this entire category of actual risk altogether.

Why autonomous agents are especially exposed to indirect injection

A system that only ever produces text a human reviews before acting on it has a backstop against indirect injection, since even a successfully injected instruction has to first survive human scrutiny before it ever translates into any lasting consequence at all. An autonomous agent, one that takes actions, calls tools, and moves through multi-step tasks with limited or no human review at each individual step, removes exactly this backstop, meaning a successful indirect injection can translate directly into an executed action with nobody positioned to catch it along the way.

This particular exposure compounds specifically because agentic systems are often designed to process considerably more third-party content than a simple question-answering system ever would, browsing multiple pages to complete a research task, reading through a full email thread to draft an appropriate reply, reviewing several documents to compile a summary, and each additional piece of external content processed during a longer, more autonomous task represents another independent opportunity for an indirect injection attempt to succeed. An agent performing a long, multi-step task while carrying real-world authority is, in a very real sense, walking through considerably more doors than a simpler system ever would, and each single door represents a place where indirect injection specifically gets its chance to succeed.

How the confused deputy pattern shows up specifically in indirect injection

A confused deputy problem occurs when a system with legitimate authority gets tricked into using that authority on behalf of a request it was never honestly meant to serve in the first place, and indirect injection produces a particularly clean version of this pattern, since the agent does hold legitimate authority, to browse the web, to read email, to query a database, and the injected content’s entire goal is to redirect that already-legitimate authority toward an end the actual, authorized user never asked for and likely never even knew was happening. The agent isn’t being tricked into acquiring some new authority it shouldn’t have at all, it’s being tricked into using authority it correctly, legitimately holds for a purpose that has nothing to do with the actual task its user assigned it in the first place.

This framing matters for defense because it clarifies that the fix isn’t reducing what a legitimately operating agent can do in general, an agent does need broad tool access to be useful, the fix is ensuring the agent’s actual use of that access stays tethered to what its current user asked for, rather than drifting toward whatever an embedded instruction in some piece of processed content happens to suggest instead. This is precisely why privilege scoping alone doesn’t fully, entirely solve indirect injection on its own, an agent can be given exactly the right, correct permissions for its legitimate task and still be redirected, well within those exact same permissions, toward serving an attacker’s goal rather than its actual user’s goal.

How isolating untrusted content processing helps contain indirect injection

One effective architectural pattern separates the process that reads and reasons about untrusted, external content from the entirely separate process that holds authority to take consequential action, sometimes described as a dual-model or quarantine pattern, where one model summarizes or extracts information from untrusted content with no tool access of its own, and a separate, privileged model only ever receives that already-summarized, structured output rather than the raw, untrusted content directly. This separation means an injected instruction embedded in the raw content can, at worst, manipulate the summarizing model’s limited output, but has no direct path to the privileged model that holds authority to act.

This pattern isn’t free, adding architectural complexity and, for some tasks, loss of nuance since a summarized, structured intermediate representation inevitably carries less information than the original raw content did. But for systems where the underlying task warrants it, particularly agents with meaningful tool access processing content from sources the organization doesn’t fully control, this separation closes off exactly the direct path indirect injection depends on, forcing an attacker to somehow manipulate the privileged model’s behavior through nothing more than an already-constrained, already-summarized intermediate output rather than through raw, unconstrained content it can shape however it likes.

How requiring confirmation for consequential actions limits indirect injection’s impact

Even entirely without a full architectural separation between untrusted content processing and privileged action requiring explicit confirmation, from an actual human or from some independent, non-model verification step, before an agent takes any consequential action provides meaningful protection against indirect injection specifically and directly, since this confirmation step sits exactly at the point where an injected instruction would otherwise translate directly into real-world harm. An agent that reads a maliciously crafted email and, as a result, drafts an unauthorized wire transfer request is stopped cold if that transfer requires an independent confirmation step before it executes, regardless of how successfully the injection manipulated the agent’s internal reasoning up to that point.

The challenge here is defining what counts as consequential enough to warrant this friction, since requiring confirmation for absolutely everything defeats much of the value an autonomous agent was built to provide in the first place, while requiring it for too little leaves gaps exactly where indirect injection does its damage. A reasonable approach ties confirmation requirements to actual reversibility and actual consequence, an action that’s hard or impossible to undo, or one that involves money, data exposure, or communication sent on someone’s behalf, warrants this friction considerably more than a purely internal, easily reversible step does.

How content provenance tracking helps a system reason about what it’s reading

Content provenance tracking tagging content with exactly where it came from as it flows through the system distinguishing internally authored, carefully reviewed material from content pulled from some arbitrary, unvetted external source, gives both the system itself and whoever’s reviewing its behavior information to weigh that a system with no such tracking simply discards. A system that knows a piece of content in its context originated from an unvetted external webpage, rather than from its operator’s carefully written configuration, has a basis for treating instruction-like phrasing in that content with appropriate suspicion, even though the model still can’t structurally guarantee it will honor that distinction in every single case.

This particular provenance information also matters considerably after the actual fact, during incident investigation, since a system with content provenance tracking can trace a manipulated action back to the external source that likely caused it in the first place, while a system with no such tracking leaves an investigator with no way of determining whether an incident traces back to indirect injection at all, let alone which content carried the injected instruction.

How to test specifically for indirect injection vulnerability

Testing for indirect injection means deliberately placing crafted content into every single channel a system might process, a test webpage the system’s browsing tool would visit, a test document in whatever repository the system indexes, a test email sent to whatever address the system’s assistant monitors, and observing whether the system’s actual behavior gets redirected by instructions embedded in that content, rather than only testing how the system responds to direct, typed user input. This testing needs to specifically cover the full range of delivery vectors relevant to a system, since a test that only covers web content misses exactly the risk that email, documents, calendar invites, or images specifically introduce.

This particular testing also benefits from specifically, deliberately probing the multi-step, agentic case wherever relevant, crafting content designed to redirect behavior not on the very first step where scrutiny tends to be highest, but several steps into a considerably longer task instead, exactly where the techniques discussed in the broader prompt injection article around gradually shifting context tend to succeed. A system that’s only ever tested with a single piece of injected content encountered early in a short interaction hasn’t been tested against the more sophisticated, more dangerous version of this risk that a thorough security review needs to cover.

How supply chain relationships create an often overlooked indirect injection vector

Organizations increasingly build AI systems on top of third-party tools, plugins, and data feeds they don’t directly, fully control themselves, and this supply chain relationship introduces an indirect injection vector distinct from an attacker simply planting content in a channel a system happens to process: the third-party component itself, or its upstream data source, can be compromised or manipulated in ways that inject content directly into what an organization’s system receives, without the organization ever having interacted with the original attacker at all. A plugin that pulls data from an external API the organization has no visibility into whatsoever, a shared component library that fetches configuration from some remote source, each represents a point where injected content can enter a system through a relationship the organization trusted specifically because it was a vetted, sanctioned dependency rather than an obviously external, unvetted input entirely.

This particular vector deserves attention precisely because it doesn’t look anything like indirect injection from the organization’s vantage point at first glance, the compromised content arrives through infrastructure the organization actively chose and configured, not through some obviously external channel like a random webpage or an unsolicited email. Applying that exact same skepticism to what a trusted, sanctioned third-party dependency returns, rather than simply assuming vetted infrastructure automatically means vetted content closes a gap that a defense focused only on obviously, superficially external content sources would otherwise miss entirely.

How indirect injection interacts with an agent’s memory or persistent state

Agents that maintain memory or persistent state across many separate interactions remembering a user’s stated preferences retaining a summary of prior conversations building up a working knowledge base over real time, introduce a meaningfully distinct variant of indirect injection risk worth naming specifically: an injected instruction that successfully influences what gets written into that persistent memory can continue affecting the agent’s behavior in every future interaction, long after the original piece of injected content that caused the write has left the agent’s active context entirely. This differs meaningfully from the more familiar case where an injection attempt only affects the single interaction during which the malicious content was present.

This means systems with persistent memory need a deliberate review process for exactly what gets written into that memory in the first place, not merely for what gets said or done during a single interaction, since a successful injection that corrupts stored, persistent state has a considerably longer lifespan and a considerably broader blast radius than one confined to a single, transient conversation. Treating memory writes with at least the same scrutiny applied to consequential actions, rather than as a purely internal, low-stakes bookkeeping step, closes a gap that’s easy to overlook precisely because writing to memory doesn’t feel, on its surface, like it carries the same weight as sending a message or executing a transaction.

How response length and framing can themselves be signals worth monitoring for indirect injection

An indirect injection attempt that partially or fully succeeds often leaves a behavioral trace behind even when it doesn’t ever produce an obviously wrong or harmful output, a response that’s oddly longer or shorter than the task would normally call for, a shift in tone or framing that doesn’t match the rest of the interaction, an unexpected reference to instructions or context the legitimate user never provided. These signals are subtler than a model obviously producing forbidden content, and they’re exactly the kind of thing a purely output-content-focused filter, built to catch dangerous phrases or categories, will typically miss, since the response itself might contain nothing individually alarming while still representing a deviation from what the task at hand should have produced.

Building monitoring around these subtler behavioral signals, rather than relying entirely, solely on filters that only look for obviously dangerous content gives an organization a chance to catch indirect injection attempts that succeeded just barely enough to shift behavior without ever producing an output dramatic enough to trip a content-based filter at all. This kind of monitoring benefits from having some baseline understanding of what a system’s ordinary, unmanipulated behavior looks like for a category of task, since a deviation is only meaningfully detectable relative to some sense of what normal, expected behavior would have looked like in the first place.

How organizational incident response should specifically account for indirect injection’s unique characteristics

Incident response for a successful indirect injection needs to account for characteristics that simply don’t apply the exact same way to a more conventional security incident: the actual attacker may never interact with the victim organization’s systems at all, meaning conventional approaches focused on tracing an intruder’s direct access simply don’t apply, and the injected content, if it was planted somewhere persistent, a public page, a shared document, an ongoing data feed, may still be actively present and capable of triggering again against the next legitimate user even after the incident under investigation has been fully resolved.

This means an indirect injection incident response needs its explicit step to locate and neutralize the original source of the injected content, not merely address the instance where it happened to trigger that one time, since patching the interaction that revealed the problem while leaving the actual planted content untouched leaves the exact same vulnerability live and waiting for the next unsuspecting user to trigger it all over again. Closing out an indirect injection incident means tracing the actual content back to wherever it was planted and removing or neutralizing it there, not simply treating the triggering interaction as the entire scope of the problem.

How indirect injection risk should shape which content sources a system is allowed to reach

Not every single organization needs a system capable of browsing the entire open web, reading arbitrary incoming email, or ingesting content from any document a user happens to casually share, and the decision about which content sources a system is allowed to reach deserves to be made deliberately, weighed against the indirect injection exposure each additional source introduces, rather than defaulting to the broadest possible access on the theory that more capability is always strictly better. A system scoped to only ever read from a small, internally curated set of carefully reviewed sources carries meaningfully less indirect injection exposure than one built to browse anywhere on the open internet, and this difference in exposure is a cost that broader access carries alongside whatever additional capability it provides.

This means the actual decision to grant a system access to a new content source, a new integration, a new type of document it can ingest, a new external API it can query deserves that exact same kind of deliberate, risk-aware review as any other capability expansion, explicitly, deliberately asking what indirect injection exposure this new source introduces and whether the value it adds is honestly worth that additional exposure, rather than simply treating content-source access as a purely functional decision entirely disconnected from the security implications each new source carries with it.

Common mistakes teams make around indirect prompt injection

Several distinct, and recurring patterns show up often enough across organizations building systems that process third-party content that naming them directly, right here, is worth doing before they’re discovered through a costly incident.

1. Hardening defenses around the most obvious content vector, typically web search or document retrieval, while leaving email, calendar, code repository, or other integrations essentially unexamined.

2. Assuming defenses built for text content automatically cover images, audio, or other media a system can process, missing that any content type a model can meaningfully read can carry an embedded instruction.

3. Treating indirect injection defense as equivalent to direct injection defense, applying user-facing input filtering that has no bearing on content arriving through a tool or integration rather than direct user input.

4. Giving an autonomous agent broad tool access without any confirmation step for consequential actions, removing the exact backstop that would otherwise catch a successful indirect injection before it causes harm.

5. Requiring confirmation for so many routine actions that legitimate users learn to approve requests reflexively, without reading them, defeating the purpose of the confirmation step entirely.

6. Building no content provenance tracking at all, leaving both the system itself and any incident investigator with no way of reasoning about where a piece of context came from.

7. Testing only how a system responds to direct, typed user input, never placing crafted content into the channels through which indirect injection arrives.

8. Testing indirect injection only at the very first step of an interaction, missing the more sophisticated pattern where an injection attempt is specifically timed to occur several steps into a longer, more autonomous task.

9. Assuming a well-scoped permission model alone prevents indirect injection, missing that the confused deputy pattern lets an agent misuse authority it legitimately holds rather than acquiring authority it shouldn’t have.

10. Building no architectural separation between untrusted content processing and privileged action-taking, giving injected content a direct path to whatever authority the agent holds.

11. Treating a single successful defense at launch as sufficient, without recognizing that a persistent, planted piece of injected content can continue triggering against new, legitimate users indefinitely until it’s found and removed.

12. Failing to consider that the attacker and the victim in indirect injection are often entirely different people, missing that user-level security training alone can’t defend against a vector that never involves any user doing anything unusual.

13. Underestimating how low the barrier to entry is for indirect injection, since planting content somewhere a target system might eventually process, a public comment, an email, a shared document, requires no access to any system the target organization controls.

14. Reviewing an agent’s individual actions for reasonableness without checking whether that action’s underlying justification traces back to the task its authorized user assigned versus content encountered along the way.

15. Assuming defenses effective against direct injection, like careful system prompt wording, automatically transfer to indirect injection, missing that the attack surface and the defensive levers available are different between the two.

16. Trusting a third-party plugin, dependency, or data feed’s output simply because the underlying integration itself was vetted, without applying the same skepticism to the actual content that integration returns.

17. Treating writes to an agent’s persistent memory as a low-stakes internal bookkeeping step, missing that a successful injection affecting stored state can continue shaping behavior across every future interaction.

18. Relying solely on content-based output filters that catch obviously dangerous phrases while missing subtler behavioral signals, unusual length, shifted tone, references to instructions the user never gave.

19. Resolving an indirect injection incident by addressing only the triggering interaction, without tracing the injected content back to its original source and removing it from wherever it was planted.

20. Defaulting to the broadest possible content-source access on the theory that more capability is always better, without weighing the indirect injection exposure each additional source introduces.

What connects all twenty of these mistakes is a single underlying pattern: treating an AI system’s trusted infrastructure, its tools, its integrations, its retrieval pipeline, as inherently, automatically safe simply because the system itself, not some external party, chose to reach out and fetch the content flowing back through it. Indirect injection specifically, deliberately exploits exactly this unearned trust in the system, and a defense that doesn’t explicitly account for the gap between what a system’s infrastructure is technically capable of reaching and what that infrastructure safely should be trusted to bring back entirely untreated leaves precisely the door indirect injection depends on standing wide open the whole time.

The deeper principle underneath all of this is that a system’s tools and integrations aren’t a neutral, safe extension of its trusted operator, they’re a bridge to an untrusted external world, and every single piece of content that crosses that bridge deserves the exact same fundamental skepticism applied to any other input a system doesn’t fully control, regardless of how legitimate, routine, or thoroughly sanctioned the mechanism that carried it across is. An organization that trusts its tools simply because it built them itself is missing the entire point of what those tools connect to out in the world.