Prompt Injection Detection in Production Agentic Pipelines

Prompt injection in production agentic pipelines is not a harder version of the same problem enterprises already know. It's a categorically different problem, and the gap between how most organizations are defending against it and how they need to be defending against it is measurable, consequential, and closing slowly. The central argument is that because agents act, chain tools, persist data, and reach live systems autonomously, detection must be built into the pipeline layer itself. Treating injection as a model-level or output-validation concern is a structural error, and the CVE record is beginning to reflect the cost of that error at scale.

The Full Injection Surface in a Production Agentic Pipeline

The distinction that matters most is direct versus indirect injection, and in production agentic systems, indirect now dominates. Direct injection, where a user crafts malicious input and submits it through a chat interface or API call, is the easier case. The input is visible, attributable, and passes through whatever validation the team has placed at the user-facing boundary. Indirect injection is harder in every dimension: malicious instructions are embedded in external content the agent retrieves autonomously, content the pipeline trusts by default because the agent requested it.

A calendar invite. A PDF the agent was asked to summarize. A third-party API response. A web page retrieved during research. A code repository the coding assistant is refactoring. None of these originate from a user, and none of them pass through a user-facing safety layer. The agent ingests them as data and, in many cases, executes them as instruction.

Six concrete entry points define the injection surface in a mature agentic deployment. First, user prompts remain a direct injection surface and shouldn't be dismissed, even if they're the easier case. Second, RAG corpora and vector stores are the modal attack surface in most enterprise deployments; 53% of organizations rely on RAG rather than fine-tuning, which means the majority of production pipelines are retrieving and injecting external documents into model context at scale. Third, tool responses and third-party API payloads arrive with an implicit trust that attackers can exploit by poisoning the data at the source. Fourth, email and document contents processed before summarization represent perhaps the broadest unvalidated ingestion surface in enterprise AI; an agent with inbox access and write permissions to internal systems is a high-value target by design. Fifth, MCP tool descriptions and server metadata are agent-readable instructions, not passive configuration. A poisoned tool description is a direct injection vector. Sixth, inter-agent messages in multi-agent or multi-hop architectures carry no special validation by default; one compromised agent's output becomes another agent's instruction.

The RAG-specific problem deserves its own treatment because it operates at a layer most defenses can't see. Adversarial embeddings are documents crafted so their vector representations cluster near target queries while containing malicious content semantically unrelated to the query. The attack exploits the high dimensionality of embedding spaces — 768 or 1536 dimensions in common models — which provide sufficient degrees of freedom for adversarial optimization. The attack is mathematical, not textual. Traditional keyword matching and pattern-based filters miss it entirely, because there's no malicious string to match; the malice lives in the geometry of the vector space.

Multi-hop injection compounds this. An attacker who corrupts one model's output, knowing that downstream models will process it, propagates the corruption through the full chain without needing to re-inject at each step. In a multi-agent pipeline, a single poisoned response can infect every subsequent agent that processes the same context window. By the time the payload executes a real-world action, its origin may be several hops removed from any visible entry point.

The MCP-specific surface is worth isolating because it's rapidly expanding. Tool descriptions and metadata are not passive labels; they're read and acted upon by agents making tool-selection decisions. A poisoned MCP tool description can redirect agent behavior before a single tool call fires. Rug-pull attacks, where tool behavior changes after deployment, are a live threat pattern in production MCP environments. Locally-running MCP servers without governance expose local secrets, credentials, and filesystem access to remote LLMs, often without the security team's awareness that the server exists.

The supply chain dimension connects all of this. Coding assistants that have transitioned from suggestion tools to autonomous codebase agents expand the blast radius of a successful injection from a single user session to a compromised repository. The agent is no longer a productivity tool; it's a commit-level actor in the software supply chain.

Where the Enterprise Currently Stands on Injection Defense

The gap is quantifiable. According to Cisco's State of AI Security 2026 findings, 83% of organizations plan to deploy agentic AI, but only 29% feel ready to do so securely. That asymmetry — between deployment intent and security readiness — is where the exposure accumulates. On prompt injection specifically, only 34.7% of organizations have deployed dedicated defenses. The majority of enterprise agentic deployments are operating without controls specifically designed for the threat they face.

OWASP's LLM Top 10 for 2025 lists prompt injection as LLM01 for the second consecutive year. The security community's consensus is unambiguous: this is the leading unsolved problem in LLM security, and it has held that position across multiple annual reviews.

The CVE record confirms that exploitation is active, not theoretical. Microsoft Copilot carried a CVSS score of 9.3 from a real production exploit. GitHub Copilot reached 9.6. Cursor IDE reached 9.8. These aren't research demonstrations; they're critical-severity findings in tools enterprises have already deployed at scale. EchoLeak, documented as CVE-2025-32711 with a CVSS score of 9.3 and disclosed in June 2025 by Aim Security, represents a particularly significant data point: it was the first documented zero-click prompt injection against a production AI system, targeting Microsoft 365 Copilot. Zero-click means no user interaction was required. The injection executed through content the agent retrieved autonomously.

The pattern across these CVEs is consistent. Attacks are targeting the exact enterprise AI tools organizations have already deployed, at the exact trust levels those tools have already been granted. The proof-of-concept phase has ended.

Regulatory pressure adds a timeline constraint. Prompt injection maps to requirements across at least seven major frameworks: OWASP, MITRE ATLAS, NIST, the EU AI Act, ISO 42001, GDPR, and NIS2. The EU AI Act's August 2026 deadline converts what might otherwise be a technical debt question into an immediate compliance risk. Organizations without documented injection controls face exposure on both the security and the regulatory axis simultaneously.

Why Detecting Injection at the Model or Application Layer Keeps Failing

The model-level defense assumption is intuitive and wrong in agentic contexts. The assumption holds that the LLM's system prompt, instruction hierarchy, or fine-tuned safety behaviors will cause the model to reject malicious content. For direct injection from a human user, this assumption is partially defensible. For agentic retrieval, it breaks structurally.

Retrieved content arrives inside the model's context window, not as a distinct user turn that the model's safety layers are trained to scrutinize. The model can't reliably distinguish "data I am summarizing" from "instruction I should follow" when both arrive in the same context position. OpenAI acknowledged in December 2025 that prompt injection is unlikely to ever be fully solved at the model level; it's an architectural problem, not a tuning problem. The instruction-following capability that makes LLMs useful is precisely the capability that makes them susceptible to instruction-following attacks. You can't train away one without degrading the other.

Multi-hop chains deepen the problem. By the time injected content reaches a model several steps into a pipeline, it may have been transformed, re-encoded, summarized, or merged with legitimate context from earlier steps. Its origin is invisible. The model sees a coherent context; the injected instruction has been laundered by the pipeline itself.

Adversarial embeddings sidestep the model entirely. The attack is committed at the retrieval layer, before the model receives any input. No safety training acts on a cosine similarity calculation.

The application-layer defense assumption — that output validation after the model responds will catch harmful content before it reaches users — fails for a different reason: it's too late. Tool calls fire during inference, not after. File writes, API calls, data exfiltration, and outbound messages may complete before the output validation layer has evaluated anything. In multi-step agentic chains, the "output" of one step is the "input" of the next; there's no clean checkpoint at which validation can act before consequences have propagated.

Both common approaches treat injection as a model problem or a content problem. Neither treats it as a pipeline execution problem. In agentic systems, that's exactly what it is.

A Layered Detection Architecture That Operates at the Pipeline Level

Detection is not a single check at one point. It's a set of controls applied at multiple stages of pipeline execution, each covering blind spots the others can't see. The framing matters: no single layer is sufficient, and the layers are designed to be complementary, not redundant.

Layer 1: Input Validation Before Content Enters the Context Window

This layer applies at every ingestion point, not just user prompts. Every RAG retrieval, API response, email parse, and MCP tool output passes through it before entering the model's context.

Syntactic checks address length limits, format validation, and encoding normalization. These are coarse filters, but they eliminate a class of trivial attacks and reduce the surface that semantic analysis must cover. Semantic analysis asks a harder question: does this content contain instruction-like patterns inconsistent with its declared type? A calendar invite that issues commands. An API response that contains imperative directives addressed to an AI system. A PDF summary that instructs the reader to ignore previous instructions. The mismatch between declared content type and semantic content is a detectable signal.

Provenance tracking records where data originated and whether the pipeline's trust level for that source is consistent with the privilege the agent holds. An agent with write access to a production database shouldn't be ingesting content from an unverified external source without explicit provenance validation.

Layer 2: Embedding-Space Anomaly Detection for RAG Pipelines

Standard text-pattern matching can't detect adversarial embeddings. Detection at this layer requires analyzing vector representations directly.

Nearest-neighbor distance checks identify documents that cluster near high-value queries despite semantic mismatch between their content and the query intent. Outlier detection in retrieved document distributions flags retrievals that are statistically anomalous relative to the pipeline's established retrieval patterns. Cosine similarity thresholds between query intent and retrieved content surface documents whose geometric proximity to the query is not explained by their readable content.

This layer specifically addresses the 768 and 1536-dimensional attack surface. Text-based scanners have no purchase on it.

Layer 3: Tool-Call Monitoring and Behavioral Anomaly Detection

Establish a baseline of normal tool-call sequences for each agent role. Deviations from that baseline are detection signals. The specifics of what warrants a flag: unexpected tool invocations, calls to tools outside the agent's defined scope, unusually long or branching tool chains, and the pattern of a data read followed immediately by an external write.

The MCP-specific concern at this layer is tool description drift. If a tool's metadata changes after deployment, that's a rug-pull vector. The control is straightforward: treat description changes as security events requiring re-review before the tool is used again. A tool that was approved is not the same tool if its description has changed.

Layer 4: Execution Sandboxing and Least-Privilege Tool Access

Limit what tools an agent can call based on its current task context. Detection will fail in some cases; the purpose of this layer is to ensure that when it does, the blast radius is constrained by authorization rather than limited only by the agent's ambition.

Role-based access control at the tool level should be tied to agent identity, not user identity. An agent acting on behalf of a user shouldn't inherit that user's full permissions. The agent's scope is defined by its task, not by the credentials of the human who initiated it.

Anomalous permission requests are themselves detection signals. An agent attempting to call a tool it wasn't provisioned for is exhibiting behavior consistent with injection. The attempt should log, alert, and block.

Layer 5: Audit Logging with Full Context Capture

Log the full prompt context, not just the final output. Injection evidence lives in what the agent was fed, not what it returned. Immutable, timestamped logs for each tool call, retrieval event, and inter-agent message are the prerequisite for forensic reconstruction and for demonstrating control to an auditor.

Without this layer, the other four are unverifiable. You may detect an attack and block it, but you can't reconstruct its path, can't demonstrate the control worked, and can't satisfy a compliance auditor who asks for evidence. Audit logging is not the most technically interesting layer. It's the one that makes all the others defensible.

Where Detection Must Sit in a Production MCP Deployment

The structural argument for a gateway layer is simple: without centralized routing, each MCP server is its own security perimeter. Input validation, tool-call monitoring, and audit logging must be rebuilt from scratch for every server. That doesn't scale, and the resulting controls are inconsistent by construction, because each server implements them differently.

A central gateway layer provides what per-server controls can't. Unified injection scanning across all tool inputs and outputs from a single enforcement point. Cross-server behavioral baselines, because detecting anomalous tool-call sequences that span multiple MCP servers requires seeing all traffic, not just one server's logs. PII and secret scrubbing applied consistently before any content reaches an LLM context window, regardless of which server sourced it. Tool description integrity checks, where the gateway verifies that tool metadata hasn't changed since last review before routing a request.

Authentication is a detection prerequisite, not a separate concern. Injection detection is most effective when tied to a verified agent identity. Anonymous or shared-credential agents make behavioral baselining impossible; without a stable identity to anchor baselines to, anomaly detection has nothing to measure against. OAuth 2.1 and OIDC, added to the MCP specification in June 2025, provide the identity substrate that makes per-agent anomaly detection tractable. Integration with enterprise identity providers means agent identity inherits the same lifecycle management as human identity: when a user is deprovisioned, their agents are too.

The shadow MCP problem is a detection blind spot that gateway controls alone can't address. Locally-running MCP servers bypass any gateway-level control entirely. Detection requires network-level visibility through DNS and firewall logs, combined with endpoint agent inventory. If servers can be spun up outside the governed perimeter, the gateway sees only the traffic that flows through it.

Several platforms have built gateway implementations that address these requirements. SpeakeasyAPI provides a governed distribution and enforcement layer for MCP servers, applying injection detection, RBAC, PII blocking, and full audit logging at the gateway level across an agent fleet, built for enterprise teams that need to govern many MCP servers without rebuilding controls for each one. Kong AI Gateway, in its v3.12 release from October 2025, added MCP proxy capabilities with OAuth 2.1 support and MCP-specific metrics. Microsoft's open-source MCP Gateway provides session-aware routing and lifecycle management on Azure Kubernetes Service with enterprise telemetry integration.

How to Prioritize Detection Investment When You Can't Instrument Everything at Once

Not all pipeline components carry equal injection risk. Prioritize by the combination of two factors: the trust level of the data source and the scope of tools the agent can reach from that context. High untrustworthiness plus high blast radius is where to spend first.

The highest-priority starting point is any agent that reads external content, email, web pages, documents, and also has write access to internal systems. This is the indirect injection plus high blast-radius combination. It's where a successful attack causes the most damage with the least detection opportunity. RAG pipelines ingesting third-party or user-supplied content, especially those feeding agents with broad tool access, belong in the same tier. MCP servers whose tool descriptions are editable or sourced from outside the organization's control represent a distinct high-priority surface. Multi-agent pipelines where one agent's output becomes another's input without re-validation also belong here; each hop is an injection opportunity, and the risk compounds with the length of the chain.

Detection debt compounds in a specific way that makes one control non-deferrable: audit logging. Without logging from day one, later forensic reconstruction is impossible. You can't retroactively recover the context windows that agents were processing six months ago. Behavioral baselining can be deferred; the baseline builds as data accumulates. Logging can't be deferred, because the data it captures is generated once and gone.

The provisioning-speed argument deserves direct engagement. Manual security reviews slow agent deployment enough that teams route around them. Shadow MCP servers emerge precisely because the sanctioned path carries too much friction. Controls that live in the gateway layer resolve this directly: teams provision agents quickly while maintaining coverage across the fleet. The alternative — making security teams a deployment bottleneck — produces a predictable outcome. Every engineer I've watched work around a slow security review finds a path around the bottleneck. The result is ungoverned infrastructure that the security team doesn't know exists, which is a worse outcome than a somewhat slower governed process. The gateway model is not a compromise between speed and security; it's the architecture that makes both achievable simultaneously.