Prompt Injection in Multi-Step Agentic Pipelines
Injected instructions spread through multi-stage pipelines, not just chatbots.
Prompt injection in a multi-step agentic pipeline is not a bigger version of the chatbot jailbreak problem. It behaves differently, spreads differently, and breaks differently. Plant one malicious instruction in a document or an API response, and it can travel through every downstream agent and tool call in the system. The damage scales with how deep the pipeline runs, not with how many doors an attacker gets to knock on.
The old framing of prompt injection assumed an adversarial string sitting in user input, overriding developer intent, inside one context window belonging to one model making one decision. Fine for a chatbot. It falls apart the moment you build a pipeline, because a pipeline violates all three assumptions simultaneously. Multiple agents, each with its own system prompt and its own tool access. The output of one stage becomes the input of the next, so trust gets re-extended at every hop whether or not anyone checked it. Agents call tools, tools bring back content from the open web or a shared inbox or a database, and none of it arrives labeled. Memory makes it worse: whatever an agent writes to shared or long-term state can resurface days later, in a run touched by an agent that had nothing to do with the original compromise.
Safety findings from single-model chat testing do not carry over. Behavior in a pipeline emerges from message passing, routing, and tool use across agents that may not share a developer, a permission scope, or even a vendor. Underneath it all sits a structural fact no amount of prompt engineering resolves: to the model, a system prompt, a user message, a retrieved web page, tool metadata, and a memory entry are the same thing. Tokens in a stream. The model has no built-in way to tell "instruction from my operator" apart from "data I fetched from a site I don't control," no matter how the labels are written around them. Not a bug you patch. It's how context windows work.
The "lethal trifecta" and why most production agents already satisfy it
Simon Willison named this pattern in 2025, and the framing has held up under scrutiny: an agent becomes exploitable when it has access to private data, gets exposed to untrusted external content, and can communicate outward or take action in the world. Sit with each leg on its own and it looks manageable. Private data access alone just means good permission hygiene. Untrusted content alone just means sanitize your inputs. Outbound action alone just means log what the agent does. The trouble starts when you ask how often systems actually isolate these from each other in practice, and the honest answer, after looking at how teams actually build, is: rarely. All three together shows up in nearly every serious documented injection incident, and that's not coincidence, it's the precondition.
Here's the uncomfortable part. Most production agents check all three boxes on purpose. Teams give agents credentials and memory because an agent without either isn't useful for much. RAG pipelines and browsing tools exist specifically to pull in content nobody on the team wrote or reviewed. And the whole reason to deploy an agent instead of a static script is that it acts, it sends the email, writes the file, calls the API.
Strip out one leg of the trifecta and the agent gets safer and less capable at the same time. That trade-off rarely gets said out loud in planning meetings. It should be the starting line for threat modeling: if what you're building satisfies all three properties, assume it's exploitable and design around that, rather than hoping your case is the exception.
How a single injected instruction propagates from one pipeline stage to the next
The entry point can be almost anything the pipeline trusts by default: a user message, a document pulled by a retrieval step, a tool response, an email body, a config file sitting in a repo.
From there the mechanics are simple once you see them. Agent A reads the tainted content and folds the injected instruction into whatever it produces. That output moves to Agent B, which has no way of knowing the instruction didn't come from a developer, because by the time it arrives it looks exactly like any other upstream message. Agent B might act on it directly, might pass an altered version to Agent C, might hand it to a tool call. At each hop the payload can gain strength: translated into a new format, embedded inside a structured object, wrapped in language that grants it more authority than it started with.
Tool calls deserve a closer look, because people assume a tool boundary works like a checkpoint. It doesn't. Whatever the agent writes into a tool call's arguments gets executed, full stop. Tools that pull in outside content, a web fetch, a file read, an email client, are exactly where indirect injection climbs into the middle of a pipeline that started out clean.
Memory is what turns a single bad input into a recurring one. Write the injected instruction to shared or long-term memory and the attacker doesn't need to come back; it re-enters on its own, in a future run, touched by agents nowhere near the original compromise. Put a number on it: a five-stage pipeline with one tainted input has five places for that input to do damage, not one. Attack surface tracks depth, not entry count.
Direct injection at the user boundary versus indirect injection arriving mid-pipeline
Direct injection is the version everyone pictures first: the attacker types the malicious instruction straight into the prompt. Visible, loggable, filterable before it goes anywhere, using input validation, allow-listing, or an instruction hierarchy enforced right at the front door. The catch is the attacker has to show up and interact with the system to do it.
Indirect injection skips that requirement. The attacker plants the payload somewhere the agent will fetch later: a web page, a shared document, an email, a database record, a file in a public repo. The agent picks it up mid-task, no attacker present at the moment of compromise. The clearest documented case is EchoLeak, disclosed in June 2025 against Microsoft 365 Copilot: a single crafted email caused Copilot to reach into internal files and send their contents to a server the attacker controlled, zero user interaction required. First documented zero-click exploit of its kind in a production system.
Indirect injection is harder to stop for a simple reason: the malicious content arrives over the exact same channel as legitimate retrieved data, and once it's inside the context window there's no reliable flag marking it untrusted. Indirect attacks now make up the majority of documented injection incidents. That tells you where defenders have been looking, and where they need to look instead. A defense built only around the user boundary handles the easier half of the problem; indirect injection demands controls at every stage where outside content enters the context, not just the first one.
How tool-chaining and cross-agent delegation turn isolated actions into system-wide attacks
Tool-chaining research, notably the STAC work from Li and colleagues in 2025, shows that tools which are individually harmless can be strung together under an attacker's direction into a sequence no single tool's permission model would have allowed on its own. Read a file, summarize it, send the summary to an external endpoint. Each step is fine alone. Together, that's data exfiltration, and the danger lives in the ordering, not in any one call.
Cross-agent delegation extends the same logic. Compromise an orchestrator agent and it can pass instructions straight down to every subagent under it. Subagents trust the orchestrator by design, with no mechanism to check whether an instruction came from a developer or from injected content the orchestrator itself absorbed. One compromised orchestrator, potentially, directs the entire pipeline.
Lee and Tiwari described a further variant in 2024: self-replicating injection, where the malicious prompt is built to copy itself into whatever output gets passed downstream. It spreads the way a virus moves through a network; every agent it infects becomes a new source of spread. The resulting disruption is system-wide, not confined to wherever the attack started.
A GitHub incident involving the Model Context Protocol server makes this concrete. An attacker hid injection instructions inside a file in a public repository. A Claude agent working through the GitHub MCP server read that file as part of an ordinary, legitimate task. The hidden instructions redirected the agent to pull access tokens from a second, private repository and send them out through a follow-up tool call. Two tool calls, two repositories, one poisoned file, and the attack crossed a trust boundary the agent's permission model was never built to police. That's the governance gap stated plainly: permissions get defined per tool, not per sequence. Most current systems have no way to say "never chain these two tools in this order if the instruction to do so came from outside."
CI/CD pipelines as a high-stakes injection surface where agents hold elevated trust
CI/CD is where this stops being abstract. Agents reviewing pull requests operate with real repository permissions, read untrusted content (PR descriptions, changed files, issue comments) as their core job, and take autonomous action: approving, merging, running test suites, posting comments back to contributors. All three legs of the trifecta, present by design.
Config-file injection is the sharpest version of this. An attacker opens a pull request that includes a provider configuration file, something like CLAUDE.md, AGENTS.md, or GEMINI.md. The CI runner checks that file out before it looks at anything else in the PR. The agent loads it as operator-level instruction, at the same trust tier as configuration a developer would have written by hand. The payload runs at that elevated trust level before the agent has read a single line of the actual code change.
What makes this worse than a typical supply-chain risk is the lowered bar for entry. Supply-chain attacks used to require write access to a trusted repository. Getting an agent to act on a poisoned config file only requires opening a pull request, something any free GitHub account can do. The GhostAction campaign, documented in September 2025, showed what that looks like at scale: compromised workflows led to the theft of thousands of secrets across hundreds of repositories. Not hypothetical. Recorded.
The GitInject benchmark, published in the 2025/2026 cycle, formalizes the surface. It's an open-source framework that provisions actual GitHub workflows and triggers real runs rather than simulating tool calls, and it documents named attack classes, config-file injection at operator trust among them. Its central finding is worth sitting with: config-file injection works precisely because it exploits the same trusted channel that makes provider configuration files useful in the first place. You can't patch out the vulnerability without removing the feature that created it.
Why more capable models do not solve the cascading injection problem and may worsen it
The instinct is to assume a smarter model will notice the injected instruction and refuse to go along. Sit with that instinct for a moment, though, and it starts to look backwards. What actually makes a model "more capable" is that it follows instructions more faithfully and builds more coherent multi-step plans toward a goal. Neither of those properties has anything to do with sorting instructions by source. The evidence bears this out: research using the BIPIA benchmark for indirect injection found more capable models are, if anything, more susceptible, not less. A more capable model is better at following instructions, period, and it doesn't reliably sort "instructions I should follow" from "instructions embedded in data I retrieved." It's also better at building coherent multi-step plans, which means it's better at carrying out whatever goal the injected instruction sets once it's decided to comply.
Anthropic's system card for Claude Opus 4.5 adds a sharper edge. Indirect prompt injection success in agentic coding environments climbs substantially as the number of attack attempts goes up. What fails once can succeed at ten attempts, or a hundred. An attacker running automated tooling with enough patience eventually gets through, even against a model built with safety as a stated priority.
The ToolHijacker result closes the door on the hope that this is solvable by scaling. It's a no-box attack against tool-using agents that got past both prevention and detection defenses across every model tested, and its success had nothing to do with which model was weaker. Zhan and colleagues, in 2025, went further: all eight agent defenses they evaluated could be bypassed by adaptive attacks built from established jailbreaking techniques. Model capability isn't a defense layer. It's a variable that degrades under sustained pressure, and any strategy leaning on "the model will catch it" is building on sand.
Where in a pipeline controls can actually intercept propagating injection
If the model can't be the backstop, the backstop has to be architectural, sitting at every point where untrusted content enters the context, not just the front door. Every tool response, every retrieved document, every memory read, every message passed between agents is a potential entry point and needs treating as one.
Delegation boundaries are a natural place to put this. Each handoff between agents is a moment where trust can be re-evaluated instead of automatically inherited. A subagent shouldn't extend an orchestrator's authority to an instruction just because it arrived wrapped in orchestrator language claiming elevated permission.
Minimal-authority design at each stage matters too. Give an agent only the permissions its specific task needs and you limit what an injected instruction can accomplish even after it succeeds in hijacking that agent. This doesn't stop injection from happening. It shrinks what happens next, which is the more realistic goal.
Prompt segmentation and context isolation, structurally separating retrieved content from instruction rather than hoping the model sorts it out at inference time, is another lever. Tool-call enforcement deserves particular weight here, because the tool call argument is the exact point where an injected instruction stops being text and becomes a real action. Inspecting what an agent is about to write into a tool call, before that call fires, catches the exploit at its conversion point, with less disruption to legitimate work than blocking earlier in the pipeline, where you risk killing tasks that were never malicious to begin with.
Topology matters more than people give it credit for. Which agents see which data, and in what order, sets the blast radius for any given injection before a single line of defensive code gets written. Pipeline design is security design, whether or not a team treats it that way.
Some of this is starting to get formal structure, though it's worth asking, for each of these, what problem it actually closes off versus what it mostly just names. MAESTRO, released by the Cloud Security Alliance in 2025, lays out a seven-layer threat model built specifically for agentic systems, running from foundation models up through full agent ecosystems. It's a taxonomy more than a fix, useful for making sure a team isn't missing a layer, not for stopping an attack in progress. The OWASP Agentic Security Initiative, also from 2025, offers a threat taxonomy covering agent design, memory, planning, tool use, and deployment, similarly diagnostic rather than preventive. The AgentDojo benchmark is the one that engages the trade-off directly: it evaluates attacks and defenses inside simulated pipeline environments while explicitly measuring the cost to utility, a useful reminder that every control discussed here costs something. The teams that get this right will be the ones willing to say that cost out loud, before an attacker says it for them.
