Prompt Injection in Multi-Agent Pipelines: Attack Paths and Fixes

At some point during a red-team engagement, you stop being surprised by where the injections land and start being surprised by how far they travel. a single crafted string, sitting quietly inside a calendar invite or buried in a GitHub pull request comment, gets picked up by one agent, forwarded to another, and eventually reaches something with actual authority - a code execution tool, a credentials store, a deployment pipeline. The original user never sees it. The system never flags it. And by the time you notice the blast radius, the instruction has already been followed.

That is the architecture problem with prompt injection in multi-agent systems. It is not a prompt problem. It is a trust propagation problem, and most pipelines are not built to handle it.

What Is Prompt Injection in Multi-Agent Pipelines

Prompt injection is the technique of embedding adversarial instructions inside content that an LLM-based agent will process as if those instructions were legitimate. In a single-agent setup, the damage is bounded by what that one agent can reach. In a multi-agent pipeline - where orchestrators spawn sub-agents, where agents pass structured messages to other agents, where tool outputs feed back into context windows - the attack surface multiplies with every hop.

The term covers two distinct entry points. Direct injection happens when an attacker can write to a surface the agent reads directly: a user prompt, a chat interface, a form field. Indirect injection is the one that keeps architects up at night. The adversarial instruction arrives embedded in third-party content - a document the agent is summarizing, a web page it retrieved, a code comment it scanned, a calendar event it parsed. The agent never asked for those instructions and has no clean way to distinguish them from the surrounding content.

In late 2025 and early 2026, both variants showed up in production-grade environments. Researchers identified a technique where prompt injections were embedded inside document macros - content that sits outside the main text but gets processed by the underlying LLM anyway. Around the same time, a disclosed weakness in Google's Gemini showed how a calendar invitation could carry injected instructions that manipulated the model through what looked like a routine enterprise workflow. Neither attack required compromising the AI system directly. They worked by feeding bad instructions through trusted data channels.

How Injection Propagates Across Agent Boundaries

The clinical name for what happens next is inter-agent message poisoning, but the practical reality is simpler and messier. Agent A reads an external document. The document contains an injected instruction. Agent A processes it, produces output shaped by that instruction, and passes that output to Agent B as if it were clean data. Agent B has no visibility into what Agent A ingested. It sees a message from a trusted peer and acts on it.

This is exactly the attack pattern researchers called PromptPwnd, documented in CI/CD pipeline contexts in late 2025. AI agents embedded in development workflows were processing GitHub issues and pull request descriptions. Crafted malicious content inside those artifacts tricked the agents into executing high-privilege commands - not because the agents were poorly written, but because they were doing their job: reading inputs and taking action. The privileged execution was a downstream consequence of injected context that looked indistinguishable from legitimate task data.

The CurXecute vulnerability (CVE-2025-54135) extended this further - remote code execution through prompt injection inside software development environments. The injection path was a development tooling surface that most security models do not model as an adversarial channel at all.

What makes multi-agent pipelines specifically dangerous is the compounding of trust assumptions. Each agent in a well-designed pipeline trusts its upstream. That trust is operationally necessary - you cannot run an autonomous workflow where every agent demands independent verification of every message. But it means a successful injection at any upstream node gets a free ride through every downstream node that shares that trust relationship.

Why Existing Security Controls Miss It

The honest answer is that most security tooling was not designed for semantic attack surfaces. Network perimeters care about packets and ports. Application firewalls care about malformed requests and known signatures. Neither has a model for "this string, when processed by a language model, will override its behavioral constraints."

Input validation helps at the edges but breaks down fast in multi-agent contexts. By the time injected content has been summarized, re-formatted, and passed through two or three agent hops, it no longer looks like the original string. Signature-based detection cannot keep pace with the variety of encoding, obfuscation, and natural-language variation attackers use. Itay Ravia, Aim Labs' head of research, put it plainly: attackers will keep finding novel ways to embed injections in places that are out of sight for the user but processed by the LLM regardless.

There is also a structural gap in how most threat models are written. Orchestration logic - the layer that routes tasks between agents, manages tool access, and handles inter-agent messaging - is frequently treated as infrastructure rather than attack surface. Threat models document the agents. They document the tools. The message-passing layer between them gets a line item at best.

How Prompt Injection Differs From Classic Command Injection

The comparison to SQL injection or shell command injection is tempting and partially useful. Both involve untrusted input reaching an interpreter that executes it. But prompt injection operates at a different layer, and that difference has real implications for defense.

With SQL injection, the interpreter is deterministic. A properly parameterized query structurally prevents untrusted input from being parsed as SQL syntax. The fix is architectural and reliable - separate the code path from the data path, and the vulnerability class disappears.

LLMs do not separate code and data paths. They process everything as a unified sequence of tokens. A system prompt and a malicious instruction embedded in a user document occupy the same representational space. There is no structural delimiter that a language model will always respect, because the model's job is to integrate all of its context into a coherent response. Attempts to use phrasing like "ignore all previous instructions" are crude, but more sophisticated injections can achieve the same goal through framing, role assignment, or conditional logic buried in otherwise legitimate content.

This means prompt injection cannot be patched the way SQL injection was patched. There is no parameterized query equivalent for natural language. Defense requires layered architectural controls, behavioral monitoring, and privilege design - not a single sanitization fix.

Architectural Controls That Actually Help

The starting point is privilege minimization at the agent level, applied before an injection ever occurs. If a sub-agent handling document summarization has no access to deployment tools or credential stores, an injection in that sub-agent's context cannot reach those surfaces regardless of what the injected instruction says. This sounds obvious and is consistently underimplemented. Production pipelines tend to grant agents broad access because it is easier to build that way, and the blast radius only becomes visible after something goes wrong.

Input provenance tracking is the next layer. Each message in an agent pipeline should carry metadata about where it originated and what external sources contributed to its content. An orchestrator that knows a particular message was assembled partly from an untrusted external document can apply a different trust weight before routing that message to a privileged downstream agent. This requires investment in pipeline instrumentation that most teams skip because it adds latency and complexity to the happy path.

Output filtering at agent boundaries - specifically, monitoring for instruction-like patterns in agent outputs before they are passed forward - can catch a subset of injection propagation. It will not catch everything, particularly when injections are subtle or well-encoded, but it creates an additional detection surface that does not exist in most pipelines today.

Human-in-the-loop checkpoints before high-consequence tool calls are the control that generates the most organizational friction and also the most actual protection. An agent that must present its reasoning before triggering a deployment or accessing a credential gives a human observer a window to notice that something in the instruction chain looks wrong. The window is narrow and operationally inconvenient. It is also one of the few controls that holds when every other layer fails.

Real-time behavioral monitoring - watching for anomalous tool call sequences, unexpected privilege escalation attempts, or unusual data access patterns - provides a detection path even when prevention fails. The U.K. National Cyber Security Centre has flagged prompt injection as a persistent threat specifically because prevention-only models are insufficient; detection and response need to be part of the architecture from the start.

When to Treat This as an Incident Response Problem

If you are running multi-agent pipelines that touch privileged tools, external data sources, or user-generated content of any kind, the question is not whether prompt injection is a theoretical risk to model in your threat documentation. The question is whether your current pipeline would surface an active injection in time to contain it.

The PromptPwnd CI/CD research and the Gemini calendar-injection disclosure both involved environments that organizations treat as trusted - internal development workflows, standard enterprise productivity tools. The injection surface was not an exotic edge case. It was the normal operational surface of those systems.

If your agents ingest content from sources outside your direct control - web retrieval, document processing, code review, calendar data, API responses from third parties - you have indirect injection exposure. If your agents pass outputs to downstream agents with higher privilege, you have propagation exposure on top of that. Both conditions are common. Both require active architectural response, not just updated threat model documentation.

The teams that are handling this well are not the ones with the cleverest prompt hardening. They are the ones who designed their pipelines assuming injection would succeed somewhere and built containment logic around that assumption. The injection happens. What matters is whether it reaches something that can do real damage before someone in your stack notices.