Prompt Injection in Agentic Pipelines

How Agentic Pipelines Change What a Successful Injection Can Do

A chatbot that gets injected produces bad output. An agent that gets injected browses the web, executes code, sends email, queries databases, and calls APIs, all on behalf of the user whose session it's running in. Every capability the agent holds becomes a lever. This is a category shift in what "compromised" actually means, and most organizations haven't fully reckoned with it yet.

The scale compounds things in ways that aren't immediately intuitive. Agents move roughly 16 times more data than human users, which means a single hijacked agent isn't a single-user incident — this figure comes from Salesforce's 2025 Agentic AI research. It's a high-magnitude exposure event wearing the clothes of ordinary workflow behavior. Gartner projects that 40% of enterprise applications will integrate AI agents by 2026 (Gartner, "Predicts 2025: Software Engineering," November 2024). The attack surface is expanding faster than most security teams can honestly track.

What makes agentic injection genuinely different from anything the industry has dealt with before is persistence. In a multi-step pipeline, an injected instruction doesn't have to survive just one response. It carries forward across tool calls, silently shaping every downstream decision. Exfiltration, impersonation, lateral movement, data modification, all within a single workflow, with no human review required at each step. The old threat model assumed a human would eventually check something. Agents don't wait for that.

Where Injections Enter a Pipeline: Direct and Indirect Vectors

Two entry points. Direct injection comes through the user input field. Developers think about this one first, usually because it's visible. Indirect injection is the dominant threat in any pipeline that touches the real world, and it arrives through external content the agent retrieves and processes.

The indirect surface is genuinely vast: RAG pipelines summarizing documents, assistants processing email, agents fetching web pages during research tasks, scheduling tools parsing calendar invitations, developer assistants analyzing code repositories, orchestration layers consuming API responses from third-party services. In every one of these cases, the agent treats retrieved content as data. But if that content contains adversarial instructions, the model has no reliable mechanism to distinguish them from legitimate directives. None.

A 2025 research demonstration made this concrete in a way that was hard to dismiss. A Google Docs file, appearing entirely innocuous, triggered an AI coding agent to contact a malicious MCP server, execute a Python payload, and harvest developer secrets (Wietze Beukema, "Prompt Injection via Malicious Google Doc," 2025). No action required from the victim beyond opening the document. Zero clicks. The attacker didn't need access to the agent or the user's session, only to control content the agent would eventually read.

And then it stopped being hypothetical. In June 2025, Aim Security disclosed EchoLeak (CVE-2025-32711, CVSS 9.3), the first documented zero-click prompt injection against a production AI system, targeting Microsoft 365 Copilot. Enterprise-grade deployments. The attack surface for indirect injection is wherever the agent reads, which in a well-integrated enterprise environment is effectively everywhere.

How Injection Propagates Across Multi-Agent Systems

Multi-agent architectures introduce a propagation problem that single-agent threat models miss entirely. One agent's output becomes another agent's input. Corruption doesn't stay contained; it travels.

An attacker doesn't need to compromise the most privileged node in a network. They target the weak one, knowing downstream agents will process and act on whatever it produces. Research by Perez and Ribeiro (2022) found that GPT-4 ReAct agents comply with attacker goals in roughly 24% of injection cases. That number sounds modest until you run it across a ten-agent pipeline. Chain-wide compromise probability scales with hops, and 24% per node stops looking like a partial failure rate pretty quickly.

Analysis of a production multi-agent social network found a measurable percentage of agent-generated posts containing hidden prompt injection payloads, the first large-scale demonstration of bot-to-bot injection in a live environment (Greshake et al., "Not What You've Signed Up For," 2023). The implication gets glossed over: injection doesn't require a human victim. It propagates entirely within automated systems, invisibly, for as long as those systems keep running.

What collapses in multi-agent chains is attribution. Which agent acted? On whose instruction? At what point in the workflow? Standard logs, built around the assumption that actions trace cleanly to human-initiated requests, cannot answer these questions retroactively. Containment cannot rely on protecting only the user-facing entry point, because in a multi-agent system, that entry point is one of many, and usually not the most vulnerable.

MCP as a High-Value Injection Target and What Tool Poisoning Means in Practice

The Model Context Protocol has become the connective tissue between agents and external tools. It grew from roughly 1,200 entries in the public registry in early 2025 to over 9,400 servers by mid-April 2026 (MCPHub registry data, April 2026). That growth rate is an attack surface expansion whether anyone intended it or not, and researchers noticed. Between January and February 2026 alone, over 30 CVEs were filed targeting MCP servers, clients, and infrastructure.

Tool poisoning is the attack pattern specific to this layer. Rather than embedding malicious instructions in user inputs, an attacker embeds them in tool metadata: descriptions, parameter fields, JSON Schema definitions. The channel looks like configuration. The model reads it as instruction. There's no sanitization layer, no provenance check, and the agent operates with full ambient authority throughout.

CVE-2025-54136 (MCPoison) and CVE-2025-54135 (CurXecute) both demonstrated this concretely. An attacker who controls or compromises an MCP server can write directives into descriptors that the agent passes directly to its model. The attack arrives as structured metadata, not as a suspicious string in a text field. Security reviews miss this because they're not looking at tool descriptions as adversarial content. That's the gap, and it's not a small one.

The rug pull pattern makes the whole picture worse. An MCP tool can mutate its own definitions after installation. A server approved as safe on day one can quietly reroute API keys to an attacker by day seven. This wasn't just a researcher's thought experiment: documented prompt injection attacks against the GitHub MCP server in 2025, supply chain compromises through malicious npm packages, and an unauthenticated remote code execution vulnerability in Anthropic's own MCP Inspector developer tool (CVE-2025-49596). These happened in production environments. The research and the reality arrived almost simultaneously, which is not a comfortable place to be building enterprise infrastructure.

Why Credential Exposure Is the Most Consequential Outcome of a Successful Injection

Agents need credentials to act. API keys, OAuth tokens, service account secrets, whatever gives them access to the tools they call. An injected instruction that reaches a credentialed agent can direct that agent to exfiltrate, misuse, or relay those credentials. That's the outcome that moves prompt injection from nuisance to critical enterprise threat.

The underlying environment is already saturated with exposed secrets. GitGuardian's 2025 State of Secrets Sprawl report found nearly 23.8 million new secrets exposed on public GitHub in a single year, up 25% year-over-year. AI-service credentials specifically surged 81.5%. In the first year of widespread MCP adoption, researchers found over 24,000 unique secrets embedded in MCP configuration files. Most of these aren't adversarial exposures. They're engineers moving fast, cutting corners on secret hygiene, shipping things that work. An injection-triggered exfiltration doesn't care about intent.

The structural failure underneath all of this is that enterprises are granting agents credentials without applying the identity hygiene they demand of human employees. Shared service accounts. No rotation. No scoping. A single admin API key shared across multiple agents collapses attribution instantly. If any one of those agents gets hijacked, the blast radius is the full scope of that key, and the logs will not tell you how it happened, only that it did.

IBM's 2025 Cost of a Data Breach report found that organizations breached through AI systems were significantly more likely to lack proper AI access controls. Only 19% of organizations classify AI agents as equivalent to human insiders for access control purposes, despite 44% of those same organizations expecting malicious AI agent use to increase data theft risk (Gartner, AI Risk Survey, 2025). The gap between concern and practice isn't a knowledge problem. It's a prioritization problem, and the consequences are visible in the median time to remediate a leaked secret on GitHub: 94 days in 2025 (GitGuardian, 2025 State of Secrets Sprawl). Under current detection practices, injection-triggered exfiltration would spend most of that window undetected.

What Authentication and Authorization at the MCP Layer Actually Require

The MCP specification mandates OAuth 2.1 for all remote deployments. MCP servers are formally classified as OAuth 2.1 Resource Servers. Not a recommendation, a specification requirement. Only 8.5% of MCP servers currently implement it. Only 18% implement any form of access scoping. The compliance picture is poor, and it's worth sitting with that for a moment, because this is a case where the spec got it right and implementation simply hasn't followed.

The specification goes further than basic OAuth. PKCE using the S256 method is mandatory for any internet-accessible MCP server, specifically because agents, containers, and serverless functions often cannot store secrets securely the way a traditional application can. Resource Indicators, defined in RFC 8707 and made mandatory in the March 2026 spec update, scope tokens to specific MCP servers, preventing a malicious server from redeeming a token intended for another service entirely. Clutch Security research found that 86% of enterprise MCP servers have implemented Resource Indicators, which is one of the few places where implementation has outpaced the general compliance picture.

The July 2026 spec update removed session management from the protocol layer entirely. Each request is now self-contained, with token validation happening once per request. That makes per-agent scoped credentials simpler to implement, which matters because complexity has been a genuine barrier. Security engineers aren't ignoring this out of laziness; the tooling has been immature, and the spec is tightening in response.

Thirty-eight percent of organizations report that security concerns are actively blocking MCP adoption. Half of MCP builders cite access control as their top challenge (Clutch Security, MCP Adoption Survey, 2025). The protocol is well-specified. The gap between what the spec requires and what's actually running in production is where the attacks live, and that gap is entirely an implementation problem.

Credential Controls That Reduce What an Injected Instruction Can Reach

OpenAI acknowledged in December 2025 that prompt injection "is unlikely to ever be fully solved," and the reason is architectural. LLMs blend trusted instructions and untrusted data in the same context window, with no hard separation. The model cannot reliably distinguish a legitimate operator directive from a malicious one embedded in retrieved content. Given that reality, the security posture has to shift toward limiting what a successful injection can reach, because perfect prevention isn't on the table.

Every agent needs a unique identity. Shared service accounts collapse attribution and break least-privilege enforcement before any attack even arrives. The corollary is narrow tool allowlists: an agent should only be able to call the tools its specific task requires, not every tool the organization has connected to the platform. Time-bounded credentials that expire with the task, rather than standing permissions that persist indefinitely, compress the exposure window considerably.

When an agent calls a third-party service, OAuth Token Exchange (RFC 8693, using the act claim) preserves the delegation chain without exposing raw credentials to the agent itself. That's the architecture that keeps credential material out of the model context entirely, which matters because an AI system will summarize, repeat, and relay anything in its context window. Keeping secrets out of context is the only durable protection.

Long-lived static secrets need to go. Automated rotation and secrets vaulting define the damage window when an injection-triggered exfiltration occurs. And every agent with access to regulated data needs a kill switch. Kiteworks' 2026 Sensitive Content Communications Privacy and Compliance Report found that 60% of organizations cannot terminate a misbehaving agent in real time. An agent that cannot be stopped mid-execution gives an injected instruction unlimited run time, and at that point every other control becomes forensic rather than protective.

Audit Trails, Permissions, and Why Traditional RBAC Breaks Under Agentic Behavior

Traditional role-based access control was designed for humans performing predictable, bounded tasks. An agent granted "read email" permissions will use that permission however an injected instruction directs. RBAC defines the boundary; it cannot enforce intent. Standard access control frameworks don't survive contact with agentic systems because they were never designed to.

Adequate audit trails here require more than logging inputs and outputs. Every tool call needs identity attached: not just which agent acted, but under whose delegation and at what point in the workflow. Logs need to be tamper-proof and capture the full sequence of tool calls, in order, with timestamps that hold up to scrutiny. Tracing needs to span agent boundaries so that the propagation of an injected instruction through a multi-agent chain is actually reconstructable after the fact, not just theoretically traceable.

The CI/CD context illustrates this in a way that lands for engineering teams. Research by Daelman (2025) demonstrated AI-powered GitHub workflows being hijacked through pull request and issue body injection; Rizwan (2026) chained this into cache poisoning and credential theft. These are agentic workflows with real pipeline permissions and no human in the loop. The logs on these pipelines were built for a different threat model, one that assumed actions traced cleanly to human-initiated requests.

The correct frame for permissions in agentic systems is not "can this agent use this tool." It's "can this agent use this tool, in this context, on behalf of this identity, for this task." Four separate authorization questions. Without per-call attribution and tool-call-level enforcement, a prompt injection that hijacks an agent's mid-workflow decisions is indistinguishable in the logs from legitimate agent behavior. For any organization handling regulated data, that's not an acceptable audit condition. It's a compliance exposure sitting quietly inside what looks like normal operations.

Detection Controls That Operate at Runtime Rather Than at Model Training

Runtime detection is necessary and insufficient, and understanding that tension is the only way to build controls that actually hold. The threat model is too distributed for any single intervention point to cover. The goal is layered controls, not a silver bullet.

What runtime detection needs to surface: tool poisoning, specifically instructions embedded in tool metadata that deviate from registered definitions; intent drift, where an agent's sequence of tool calls diverges meaningfully from the task it was originally given; exfiltration patterns, where data moves to destinations outside the expected workflow; and prompt injection signatures in retrieved content before it enters the model context. That last one is the only intervention point that catches indirect injection before the model processes it. Everything else is response after the fact.

STRIDE and DREAD threat modeling applied across the five MCP components — the host and client, the LLM, the MCP server, external data stores, and the authorization server — provides a structured framework for placing detection instrumentation. The methodology transfers cleanly from traditional application security. What doesn't transfer are the assumptions about where trust boundaries sit, because in agentic systems those boundaries are porous in ways that traditional architectures never had to contend with.

Detection at the tool-call layer is necessary because injections that arrive via indirect vectors are completely invisible at the user-facing boundary. A document summarized by a RAG pipeline, a calendar invitation parsed for scheduling, these don't look like attacks at the input layer. They reveal themselves only in what the agent does next. OpenTelemetry tracing across the full pipeline enables detection of anomalous call sequences that no single-point monitor would surface on its own.

Detection without the ability to interrupt is just forensics. An agent that cannot be stopped in real time when detection fires negates the value of the detection layer entirely. The 60% of organizations that cannot terminate a misbehaving agent are logging attacks they cannot stop (Kiteworks, 2026 Sensitive Content Communications Privacy and Compliance Report). The architecture question isn't just "can we detect this." It's "can we detect it fast enough to matter, and can we actually stop it." Both questions need affirmative answers before the detection investment pays off.