Prompt Injection in Agentic Pipelines

Prompt injection used to mean a chatbot said something embarrassing. In an agentic pipeline, the same attack means a wrong action gets taken, and that action can complete, spread to other systems, and compound before anyone notices.

That difference is architectural. A large language model reads everything inside its context window as one undifferentiated stream of text: system instructions, the user's request, and whatever document, email, or web page got pulled in along the way. There's no wall inside that window separating "instructions you should obey" from "content you're just supposed to read." The output of an agentic injection is a wrong action that fires on its own schedule.

Scale matters here too. A chatbot injection stays contained to one conversation. An agentic injection reaches as far as the agent's tools and permissions allow, which in production systems can mean file systems, payment APIs, internal databases, or other agents downstream. But agents introduced attack patterns that simply didn't exist when a model could only talk, not act, and that's why OWASP built a separate framework for 2026: the Top 10 for Agentic Applications. The old list measured what a model might say wrong. The new one measures what a system might do wrong, and that's the problem this piece is built around.

How an agentic system's architecture turns a manipulated input into a multi-step attack chain

Three properties turn a manipulated input into a running attack: tool access, persistent memory, and the ability to chain actions together without a human checking each step. Strip any one of those away and prompt injection stays a nuisance; combine all three, and a single poisoned sentence can start a sequence that ends somewhere the attacker chose.

Start with where the poison enters. Agents pull input from sources that carry wildly different trust levels: a user's typed instruction, the system prompt the developer wrote, an external document, a web page, an API response. The model has no reliable way to rank these by trust. It can't always tell "a document I was asked to summarize" from "a document trying to give me new instructions," especially when there's no provenance tagging or structured boundary marking where trusted text ends and untrusted text begins. That gap is the entry point.

Researchers have given this sequence a name: the Promptware Kill Chain, which reframes prompt injection as a multi-stage process that behaves a lot like traditional malware. Initial access happens when the payload enters the context window. OWASP's Agentic Top 10 captures the first link in that chain as ASI01, Agent Goal Hijack: a manipulated input doesn't just change one output, it redirects the goals, the planning, and the multi-step behavior of the entire workflow.

Most of these attacks don't arrive as a direct command typed by a user. They arrive indirectly, planted inside a third-party source the agent reads during ordinary operation: an email, a document, a web page, a log line, a comment on a GitHub issue. Current models frequently fail to separate "content to process" from "instructions to obey," particularly where no structured boundary enforces that distinction. That failure mode is the mechanism behind nearly every incident described next.

What real-world exploitation looks like: from the Cline incident to production CVEs

The kill chain isn't a hypothetical. It has already run to completion in production systems, and the record from 2025 and 2026 shows it executing the same way each time.

One of the clearest cases involved Cline, an AI coding assistant whose issue-triage workflow had shell access and processed untrusted GitHub issue input. A single malicious issue title carried a prompt injection payload into that workflow. One malicious issue comment turned into one compromised agent, one poisoned package, and a window during which any developer pulling that package was exposed.

Enterprise-scale CVEs show the same shape. Cursor IDE carries a vulnerability rated 9.8. Three different products, three different vendors, one underlying pattern: untrusted content reaching a model with enough permission to act on it.

The tracking infrastructure hasn't caught up to the scale of the problem. An industry tracking effort documented eight major AI-related incidents between January and April 11 of that year. Google's Security team separately reported a meaningful rise in malicious indirect prompt injection content across the billions of pages it crawls monthly between November 2025 and February 2026, with attackers seeding static sites, blogs, forums, and comment sections as delivery vehicles.

What's striking is where the payloads are heading. Documented cases now include forced financial transfers, recursive file deletion aimed at IDE-integrated coding agents, API key exfiltration, and biased recruitment screening. The intent is moving past data theft and into active system compromise. Agents embedded in CI/CD pipelines and everyday productivity workflows sit at the center of this risk, because they combine elevated permissions with constant ingestion of content nobody has vetted.

Why the MCP tool layer has become the fastest-growing attack surface in agentic deployments

The Model Context Protocol gave agents a standard way to connect to tools and external services, solving the problem of every integration being a one-off. That standardization came with a side effect. By creating one common path for agents to reach tools, MCP also created one common path for injected instructions to reach those same tools.

Conventional software runs input through defined validation layers before anything executes. MCP systems work differently because a model sits in the middle of the decision: it decides which tool to call and what parameters to hand it. An injected instruction doesn't need to break through a firewall; it just needs to convince the model to make a different tool call than the one the developer intended, with different parameters than the ones the user asked for.

The scale of exposure here is substantial. In April 2026, OX Security disclosed a systemic flaw that affected an estimated large number of vulnerable instances, across a supply chain tied to more than 150 million package downloads. The flaw sits in the MCP STDIO transport, which executes operating system commands without sanitizing or validating them first. Where an attacker can influence the server configuration, that gap enables remote code execution on the host.

A second pattern documented in the field involves tools that behave one way at install time and another way later. Security researchers call these "rug pulls": a tool's description gets modified after installation, quietly rerouting credentials or redirecting the agent's behavior without the operator noticing anything changed. OWASP's Agentic Top 10 names this ASI02, Tool Misuse and Exploitation.

Standardizing how agents connect to tools did more than make integration easier for builders. It made the injection pathway identical across every deployment using that standard. A flaw found in one implementation has implications for every other system built the same way.

Memory poisoning: why persistent state turns a one-time injection into a permanent compromise

Tool access explains how an injected instruction turns into an action. Memory explains how that instruction outlives the session where it arrived.

A standard prompt injection needs to be delivered again for each interaction it wants to influence. Memory poisoning doesn't. It needs one successful write. After that single write succeeds, the agent's retrieval system can surface the adversary's instruction automatically, any time it judges that instruction relevant, across every future session and every future user interacting with that agent instance. The attacker doesn't need continued access. The system does the work of re-delivering the payload on its own.

OWASP treats this as a distinct category for a reason. Prompt injection is LLM01 in the LLM Top 10. Memory and Context Poisoning is ASI06 in the 2026 Agentic AI Top 10. That's a difference in how long the attack lives and how it gets triggered again, not a severity distinction.

A genuine design tension runs through this. Existing prompt injection defenses mostly operate at the input boundary, checking what comes in during a session. They don't cover the write boundary, where a poisoned entry gets committed to memory in the first place. An agent that can remember is an agent that can be permanently misdirected, and no amount of session-level filtering fixes that if the write itself was never checked.

Cross-agent privilege escalation in multi-agent architectures

Single-agent compromise is bad. Multi-agent compromise is worse, because the damage doesn't stay where it started.

Agents in a pipeline typically run with different permission levels by design. That separation looks like a safeguard, and it is, until a compromised orchestrator delegates a task downstream. When it does, it can pass along instructions that a subordinate agent executes under its own permissions, which may be broader than anything the orchestrator itself could touch directly.

OWASP's Agentic Top 10 documents this as ASI09, Human-Agent Trust Exploitation: an attacker uses one compromised agent to impersonate a trusted orchestrator and issue instructions to other agents in the system. This problem has a name in operating system security: the confused deputy, now appearing at a new layer. A subordinate agent has no way to verify that the orchestrator issuing its instructions hasn't itself been compromised. It extends trust because the instruction arrived through a channel it already trusts, not because it checked whether that particular instruction was legitimate.

The numbers show this pattern taking hold as deployments mature. By 2025 and 2026, it appeared in eight of twenty-one. As agents move from single-task tools to long-horizon systems operating across multiple other systems, the opportunities for one compromised node to reach another grow right along with them. Any serious defense has to treat the delegation boundary between agents as its own point of control, not an extension of whatever trust already existed upstream.

What a layered architecture requires

Injected instructions can enter through the tool layer, the memory layer, or agent-to-agent delegation, so no single control placed at one boundary catches everything. Defense here has to match the architecture it's defending: layered, because the attack surface is layered.

Government guidance reflects this directly. The Five Eyes agencies, CISA and the NSA together with counterparts in the UK, Canada, Australia, and New Zealand, issued joint guidance in May 2026 naming prompt injection as a core way attackers manipulate agents. The same guidance recommends incremental adoption paired with human oversight at consequential decision points, because the moments where an action is irreversible and high-stakes are exactly where an undetected injection does the most damage.

Three layers do different jobs here. An architectural prevention layer validates input from every data source before it enters the model's context, enforces minimal permissions per agent instead of letting agents inherit ambient authority, and sandboxes tool execution so one compromised call can't reach adjacent systems. A runtime detection layer monitors agent behavior against its declared goals, flags divergence through goal-lock mechanisms, validates outputs before tool calls fire, and enforces structured prompt boundaries so the model has some signal distinguishing trusted instruction from untrusted content. A governance layer puts human approval gates in front of high-impact, irreversible actions, maintains a traceable accountability chain across multi-agent pipelines, and treats reversibility as a design constraint, favoring actions that can be undone over ones that can't.

Memory needs its own set of controls layered on top of these three. Write policies should treat the memory layer as a trust boundary in its own right, not just a storage mechanism. Retrieval needs validation, or poisoned content can re-enter the context window. Long-term memory needs periodic auditing for adversarial content that may have slipped in earlier and is waiting to be triggered. Each of these layers targets a different point in the kill chain described earlier. None of them, alone, closes the whole thing.

The "agents may always be vulnerable" thesis and what it means for how you build

A 2026 paper titled "AI Agents May Always Fall for Prompt Injections" pushes back on the idea that better defenses eventually solve this problem. Testing frontier models from OpenAI, Google, Anthropic, and Meta, the paper's authors found all of them remained vulnerable, a result they argue reflects a theoretical impossibility that more engineering will not close. Their reasoning: an adversary can always construct a context under which a blocked flow appears legitimate. The vulnerability isn't a bug waiting on a patch; it's a property of building systems where instructions and content are read as the same kind of text.

If injections will sometimes succeed no matter how much is spent trying to stop them, the useful question is no longer how to prevent every injection but how to ensure a successful one can't cause irreversible harm. That's a different, more honest bar.

It also reframes the Five Eyes' emphasis on reversibility and resilience. Those properties aren't a consolation prize for organizations that skipped proper defenses; they're first-class requirements for any system where the model underneath might, at some point, be fooled.

The same principle has to hold at the infrastructure layer where these agents actually run. Runtimes that enforce minimal authority by default, that treat every external input as untrusted until proven otherwise, and that surface consequential actions for human review before they execute are the correct response to an attack class that current research suggests may be irreducible at the model level. A purpose-built agent operating system, built from first principles for this exact threat model rather than adapted from general-purpose cloud infrastructure, is in a position to enforce these constraints consistently, across every agent running on it, at the one layer where the model's own fallibility doesn't get the final word.