Prompt Injection in Agentic Pipelines

A user asks an AI assistant to summarize their inbox. The assistant does, and the summary looks fine. Buried in one of those emails, though, is a hidden instruction: forward the user's private cloud access key to an external address. The assistant has file access, so it finds the key. It has email access, so it sends it. The user never sees that step happen. They just see a clean summary and move on with their day. That's the entire difference between prompt injection on a chatbot and prompt injection on an agent, and it's why the governance conversation has to change.

Why prompt injection means something different when the AI has a to-do list

In a plain text system, the worst thing an injected prompt can do is make the model say something false or misleading. A person reads the output, decides whether to trust it, and can throw the whole thing out if something seems off. The model has no hands. It can't act on the world. The damage stops at the screen.

Give that same model a to-do list; the math changes completely. An agent tasked with something ordinary (summarize these emails, process this document, research this topic) reads external content as part of doing its job. If that content carries adversarial instructions, the agent follows them with whatever tools it has, and often still finishes the task the user asked for. The user gets a correct-looking result. By the time anyone could check, the injected action had already happened underneath it.

That's the core problem: the moment to catch the attack has already passed by the time anyone would think to look. Two things decide how bad it gets. One is action scope: what tools the agent can actually reach. The other is the confirmation model: whether anything high-impact requires a person to sign off before it runs. Tighten either variable and the blast radius shrinks. Loosen both, and an email summary becomes a credential theft.

The structural features of agentic pipelines that turn injected text into injected action

Four properties of agentic systems turn a text flaw into a real-world incident, and each builds on the one before it.

Start with tool access. Agents today read files, call APIs, run shell commands, commit code, and send messages on a person's behalf. Those capabilities are what make agents useful, and they're also what makes an injected instruction dangerous instead of just wrong. Parallax, in its research on agent safety, frames this as the shift from generative AI, where the worst case is harmful or misleading content, to agentic AI, where the worst case is data walking out the door, a system getting compromised, or critical resources getting destroyed in ways that can't be undone.

Tool access alone would be manageable if a person checked every step before it executed. Autonomous execution removes that check. The agent acts, then reports back, rather than pausing for review along the way. The CI/CD world shows what this looks like once it's built into real products: browser agents click links on their own, coding assistants run shell commands without a human typing them, CLI agents commit code and post to GitHub unattended. Each capability that got added for convenience also turned what used to be a contained text-generation flaw into a live path to action.

Now stack persistent memory on top. Most agentic systems don't start from zero in every session. They keep notes, files, or memory records that carry forward. Research out of the University of Washington looked at Claude Code and OpenAI Codex and found that payloads planted in memory files like CLAUDE.md, AGENTS.md, and core/behaviors.md can successfully attack both the current session and future ones. A single successful injection doesn't just compromise one conversation. It can sit quietly in a file the agent trusts and reads every time it starts up, shaping behavior long after the original attack vector is forgotten.

The last property is multi-step orchestration, where one agent's output feeds directly into another agent's input. A single injected instruction, once it lands, doesn't have to stay contained to the agent that first read it. Parallax's analysis found that during a single injection incident, attacks propagate to 48% of co-running agents. Guardrails built into one agent provide no protection once that agent's output is treated as trustworthy by the next one in line.

Put together, these four properties don't just make injection possible. They compound. Tool access makes action possible. Autonomous execution removes the checkpoint. Persistent memory extends the damage across time. Multi-agent orchestration extends it across the whole pipeline.

MCP: The Dominant Attack Surface for Agentic Injection

It has become close to universal across production agent deployments, appearing in nearly every enterprise integration built on agentic AI right now. That ubiquity makes it the highest-value target for anyone trying to inject malicious instructions into an agent pipeline.

One pattern researchers have documented is tool poisoning, which some call a rug pull. A malicious MCP server advertises a perfectly benign instruction when it's first installed. After a second use, it switches to a malicious one. The server, not the user, controls what the agent believes a given tool actually does, and that control can change without any new install or visible warning.

A second pattern runs through MCP outputs themselves. When one agent's output gets passed downstream and trusted blindly, it can be read not as passive content but as an executable prompt. That opens the door to manipulating tool metadata, hiding instructions inside otherwise normal-looking outputs, and chaining injections across a series of connected MCP processes.

One researcher pushed this further and described how promptware-powered command-and-control infrastructure can run entirely through prompt injection. It amounts to a botnet where the bots are AI agents, recruited across different agent architectures with nothing but indirect prompt injection. One government agency's guidance called MCP a "promising but still maturing foundation" and flagged "significant and evolving security concerns," which is about as direct as an institutional assessment gets without naming names.

Three Incidents from the CI/CD and Coding-Agent Surface

None of this is theoretical anymore. A handful of documented incidents from early 2026 show that something as mundane as a pull request title or a GitHub issue is enough to trigger a supply-chain compromise.

The Clinejection incident, on February 17, 2026, started with a single malicious GitHub issue title [1][2][3][4][5][6]. That one piece of text triggered a chain of four separate vulnerabilities, and it ended in an unauthorized supply-chain compromise of the Cline AI coding tool's npm package [1][2][3][4][5][6]. The malicious package reached an undisclosed number of developer and CI/CD systems over roughly eight hours before it was pulled [1][2][3][4][5][6].

Three weeks earlier, on January 20, 2026, Cyata researcher Yarden Porat published an exploit chain targeting Anthropic's own official Git MCP server, the kind of reference implementation other developers look to as a model for how to build things correctly. Three separate CVEs, unrestricted git_init (CVE-2025-68143), argument injection (CVE-2025-68144), and path validation bypass (CVE-2025-68145), combined with flaws in the Filesystem MCP server to produce remote code execution through prompt injection. If the flaws showed up in Anthropic's own reference build, every third-party MCP server built with fewer resources and less scrutiny deserves the same level of suspicion.

Then, in April 2026, researcher Aonan Guan and a team at Johns Hopkins hijacked three separate coding tools at once: Claude Code, Gemini CLI, and GitHub Copilot. They did it by injecting malicious instructions into GitHub PR titles, issue bodies, and HTML comments. The agents read that PR data as part of their normal task context, so they followed the injected instructions, exfiltrated GitHub Actions secrets, and posted the stolen results back as PR comments. No outside infrastructure was needed. Any GitHub user with a free account could open a pull request and run the attack.

What connects all three incidents is the ability to place a few lines of text somewhere an agent will read them as part of a routine task, not privileged access to a trusted system. The attack surface, in every case, was the agent's own ordinary workflow. You can find this architectural pattern, where AI agents ingest untrusted repository data while holding elevated pipeline credentials, across the industry, not just in these three tools.

The Multi-Agent Trust Problem

Chaining agents together multiplies trust in ways most enterprise security frameworks haven't caught up to yet. When one agent passes a structured output to another, the receiving agent generally has no way to tell content apart from instructions once that content arrives over a channel it already trusts.

A compromised orchestrator agent can direct its sub-agents toward actions the user never approved. Just as easily, a compromised sub-agent can poison its own output to steer the orchestrator's next move. Parallax documents this as cross-agent trust exploitation, one compromised agent manipulating another by exploiting the implicit trust built into inter-agent communication, and notes that it's already been demonstrated in production coding environments, not just in a lab.

Multi-turn conversational injection makes the picture worse. A payload planted early in a conversation can sit dormant until a trigger phrase appears several turns later, possibly after the conversation has moved to a different agent entirely or resumed in a fresh session. Persistent memory compounds this further: because payloads planted in memory files influence future sessions, an injection doesn't expire when the original task ends. It waits.

The consequence for any organization running a multi-agent workflow, where one agent's output feeds the next agent's input, is that it's operating a trust network. That network is only as strong as the single least-protected input any agent in the chain reads. One weak surface anywhere in the pipeline sets the ceiling for the whole system's security, regardless of how well the other agents are locked down.

Why prompt-level defenses fail against agentic injection

The instinctive fix, better prompt engineering, stricter system instructions, a content filter bolted onto the model, doesn't hold up against this threat, and the reason is structural rather than a matter of execution. Parallax calls this the "prompt guardrail fallacy." The guardrail and the attack get processed by the exact same attention mechanism, inside the exact same model. There's no architectural wall separating trusted instructions from untrusted data, and that absence is the condition that makes injection possible. If a prompt has to defend itself against another prompt, the same system ends up refereeing its own compromise.

Guardrails also degrade as context grows. Agents carrying long conversation histories are more exposed, because cumulative context can shift the model's effective boundaries through small, repeated nudges instead of one obvious attack. Memory poisoning adds to this by planting false instructions that persist across sessions. And guardrails can't survive multi-agent propagation at all: once one agent is compromised, its guardrails offer zero protection to any downstream agent that trusts its output.

One defense framework referenced in earlier research on this problem is notable as the first architecture to offer provable security guarantees against this class of attack, though it comes with a real trade-off in task completion. It represents a direction rather than a finished answer.

So what does the architecture actually need? Cognitive-executive separation keeps the system that reasons about untrusted content separate from the system that executes actions, which is Parallax's foundational principle: an independent validator sits between reasoning and execution, so a compromised reasoning step can't directly trigger a real-world action. Confirmation gates require explicit human approval before any high-impact action runs, which is the exact mechanism that would have stopped the injected credential-send in the scenario at the start of this piece. External content an agent processes, whether it's GitHub metadata, a document, an API response, or another agent's output, needs to be treated as untrusted input rather than as an authoritative instruction. And information flow control needs to track where data came from over time, so content that started out from an untrusted source can't get silently promoted to instruction-level trust several steps downstream.

Each of these controls maps directly back to one of the mechanisms covered earlier. Scoping tool access limits what tools an agent can reach. Confirmation gates address autonomous execution. Memory integrity protections prevent payloads planted in memory files from attacking future sessions, as documented in the University of Washington research. Trust boundaries between agents limit propagation: Parallax measured it at 48% of co-running agents in a single incident.

The MCP specification itself provides a formal authentication foundation, but most of the actual risk is in the gap between what that spec requires and what enterprise deployments have actually built. Runlayer is one platform working in that gap: its MCP gateway scans tool definitions and outputs in real time, looking for tool poisoning, injection payloads embedded in MCP responses, and semantic manipulation, with the goal of catching an injected instruction before it propagates to the next agent in the chain. The protocol gave agents a common way to reach tools and data.