MCP Security Vulnerabilities in Agentic Pipelines
Of those 13,875 servers identified in the Lin et al. dataset, the overwhelming majority were built by individual developers, open-source contributors, or small teams working entirely outside any formal security review process. That is not a criticism; it describes how most open ecosystems begin. In an agentic context, however, the implications compound faster than they do elsewhere.
Inconsistent credential handling, limited dependency management, no defined responsible-disclosure process, no ongoing audit: these are not unusual conditions for community software. They are the baseline. The Vulnerable MCP Project, maintained by researchers from SentinelOne, Snyk, Trail of Bits, and CyberArk, tracks over 50 known MCP vulnerabilities across servers, clients, and infrastructure as of mid-2026, with 13 rated critical and new CVE disclosures continuing through the first half of the year. By January 2026, more than 2,000 exposed MCP instances were discoverable via Shodan, leaking API keys and conversation histories to anyone who looked.
Here is the thing that took me a while to fully sit with: the problem is not just that individual servers are insecure. It is that an agent connecting to a community MCP server extends implicit trust to an artifact that was probably never audited, and that trust propagates forward through every subsequent tool call the agent makes. The contamination travels with the context. This is the foundational condition under which all of the specific attacks described below succeed: agents treat tool descriptions and server responses as trusted inputs because the protocol, by design, gives them no systematic basis to do otherwise.
How Tool Poisoning Works and Why the Description Field Is the Attack Surface
MCP servers advertise their capabilities to host agents through free-form text descriptions. These descriptions explain what a tool does, when to invoke it, what arguments to pass. That description lands inside the model's context window. It is part of the prompt.
That is the entire attack surface, and it is simpler than most people expect when they first encounter it. A description field is attacker-controlled text that the model reads and follows as instruction, with roughly the same weight it gives a system prompt or user message. A malicious description can instruct the model to exfiltrate sensitive files while suppressing its own outputs so the user sees nothing, then chain further tool calls that were not requested. The attack does not require compromising the host, the model, or any network layer. It requires only controlling what the description says.
Tool poisoning ranks first in OWASP's LLM Top 10. A 2025 DREAD analysis scored it 46.5 out of 50, the highest severity rating across a model covering 57 documented threats. Lin et al. identified prompt injection as the most prevalent and impactful client-side vulnerability in their survey of MCP clients, noting that most tested clients failed due to insufficient static validation and low parameter visibility. A named variant called tool shadowing extends the basic attack: a malicious server registers a tool whose name overlaps with a legitimate one and hijacks calls intended for the legitimate tool. The agent does not know the substitution occurred.
Why does this attack class remain so durable? The reason is structural, not incidental. Descriptions must be expressive enough to guide model behavior, which means they must be rich, natural-language text. There is no format that is simultaneously useful to a model and immune to injection. Any description field expressive enough to do its job is expressive enough to be weaponized. I have yet to see a proposed mitigation that resolves this tension rather than managing it.
The Rug Pull: How Tool Definitions Can Change After Approval Without Any Alert
Most MCP clients verify tool definitions at install or approval time. Continuous verification is absent. That gap is the rug pull.
The attack works as follows: a developer reviews a server's tool metadata, finds it acceptable, and allowlists it. The agent begins calling the server's tools. At some later point, the server's tool definitions change. The agent continues calling what it believes is the approved tool while executing a version that has been quietly altered. Nothing within any individual request looks anomalous, because each call, considered in isolation, remains within normal parameters. Microsoft's security team documented exactly this dynamic in a June 2026 analysis and noted that the attack succeeds precisely because no single transaction is obviously wrong.
A real incident gave this theoretical framing concrete weight. In September 2025, the Postmark MCP server's maintainer pushed an update that added BCC logic to the email-sending tool, silently copying every sent email to an attacker-controlled address. Koi Security's incident response found that the backdoor had been live across multiple versions. Package signature proved nothing about behavior; the signed package was, technically, authentic. The developer who approved the original version had no mechanism to know it had changed.
This is what I find most troubling about the rug pull as an attack class: it corrodes the very concept of approval-based trust. The protocol blends instructions and data so thoroughly that a changed tool description redirects agent behavior exactly as a changed system prompt would. For any team building agentic pipelines today, the implication is direct. Approval at a point in time is not ongoing trust. Any pipeline that skips re-validation of tool definitions on each session is implicitly trusting all future versions of a server it reviewed exactly once.
Session Hijacking, OAuth Token Theft, and What Long-Lived MCP Sessions Make Possible
MCP sessions are frequently long-lived, persisting across multiple tool invocations within a single pipeline run. That persistence is architecturally necessary; stateless sessions cannot support the context an agent needs to complete multi-step tasks. But it creates an exposure profile materially different from a short-lived web session. A compromised MCP session does not yield access to one request's worth of data. It yields access to everything the agent was authorized to touch, for as long as the session persists.
Those authorizations are often substantial. Sessions carry access tokens for downstream systems, GitHub, Slack, Salesforce, AWS, scoped to whatever the agent was expected to do. CVE-2025-6514, the mcp-remote vulnerability carrying a CVSS score of 9.6, allowed a malicious authorization endpoint to intercept OAuth tokens during the authentication flow, before the session was even established. The confused-deputy pattern compounds this further: a token issued for one agent passes to another without scope revalidation, and the receiving agent gains privileges the issuer never intended to grant.
The broader credential hygiene problem in the MCP ecosystem runs parallel to these specific CVEs. Agents and servers commonly rely on static API keys or long-lived tokens stored in configuration files or CI/CD pipelines. Once exposed, they grant access until someone manually rotates them. The Smithery platform compromise in October 2025 illustrated the scale of this risk: a path-traversal vulnerability allowed an attacker to read arbitrary files from container filesystems, exposing API keys, database credentials, and OAuth secrets for over 3,000 deployed MCP applications from a single exploited instance. One vulnerability, three thousand blast radii.
Cross-Server Trust Escalation and What Happens When Agents Orchestrate Multiple MCP Servers
Production agentic pipelines rarely call a single MCP server. The typical architecture chains them: a Slack server passes context to a Jira server, which triggers an AWS server, which writes to a database. Each hop extends the pipeline's reach. Each hop also extends the attack surface, in ways that compound non-linearly.
Trust granted to one server in a chain does not stay contained. A compromised server can embed instructions that propagate to the servers the agent connects to next. This cross-server attack pattern was documented in a 2025 attack taxonomy alongside tool poisoning and rug pulls. Invariant Labs described the underlying mechanism in research published between April and May 2025 under the term "toxic agent flows": prompt injection at one node in a pipeline carries forward through context into subsequent nodes because the agent transports the adversarial instruction as part of its own accumulated context. The injection travels as cargo.
Simon Willison articulated the compounding risk in April 2025 with what he called the "lethal trifecta": an agent with access to sensitive data, the ability to make external calls, and insufficient output filtering between tool responses and subsequent tool invocations. Any one compromised server in a chain can weaponize all three properties simultaneously, even if every other server in the chain is clean. This is the point that tends to get underweighted in security reviews focused on individual server hardening. The attack surface of a pipeline is not the sum of its individual server surfaces. It is larger, because trust relationships compound across hops in ways that no individual server's security posture can fully mitigate.
Confirmed CVEs and Real Incidents That Show These Are Not Theoretical Risks
There is a recurring tendency in security discussions to treat novel attack classes as hypothetical until a sufficiently public breach forces a reassessment. The MCP incident record has already moved past that threshold, though I am not sure the broader industry has fully registered it.
Three CVEs in Anthropic's own Git MCP server, CVE-2025-68145, CVE-2025-68143, and CVE-2025-68144, documented remote code execution via prompt injection through a path validation bypass, unrestricted git initialization, and argument injection. Claude Code received CVE-2025-59536, carrying a CVSS score of 8.7: Check Point Research demonstrated in February 2026 that a malicious.claude/settings.json file could trigger shell command execution via configuration injection through the Hooks mechanism before the trust dialog appeared. The user sees nothing unusual. That detail deserves more attention than it typically receives.
OX Security's April 2026 disclosure identified a systemic design flaw in Anthropic's core MCP STDIO transport: direct configuration-to-command execution without input sanitization, affecting Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI simultaneously. More than 10 critical or high-severity CVEs traced to a single root cause. Anthropic confirmed that sanitization is the developer's responsibility. Langflow's CVE-2025-3248 carried a CVSS score of 9.8: a pre-authentication endpoint executed user input directly through Python's exec() without any authentication gate. CISA added it to the Known Exploited Vulnerabilities catalogue in May 2025 after confirmed active exploitation.
The pattern across these incidents is consistent. The exploited surface is the boundary where agent-controlled text becomes execution: tool descriptions, configuration files, transport layers, code evaluation endpoints. These are not obscure forks or edge-case deployments. They involve Anthropic's own tooling, widely deployed development environments, and a platform hosting thousands of production applications. The boundary between instruction and execution is the seam that keeps failing.
Why Standard Containers Fall Short for AI-Generated Code Execution in MCP Pipelines
Containerization was designed to isolate known code paths. A developer defines an application, packages it, and the container ensures it runs consistently without interfering with neighboring workloads. The threat model is: protect against bugs, not against the code itself.
But what if the code itself is the threat? AI agent sandboxing faces a categorically different problem. The code being executed is generated at runtime by an LLM, based on inputs that may have been manipulated through any of the attack vectors described above. It cannot be reviewed before execution. The threat model shifts from "protect against bugs" to "protect against arbitrary adversarial code generated in response to a successful prompt injection." A container built for a developer's known workload was not designed for that. The distinction is not pedantic; it changes what isolation properties you actually need.
Standard containers share the host kernel. A kernel exploit or container escape puts the entire host at risk. November 2025 brought three critical runC CVEs (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881) affecting Docker, Kubernetes, and related platforms and allowing host file access from within ostensibly isolated containers. The three isolation tiers in current use span the necessary spectrum: microVMs (through implementations like Firecracker and Kata Containers) provide a dedicated kernel per workload and the strongest isolation boundary; gVisor interposes a user-space kernel that intercepts syscalls before they reach the host; hardened containers offer adequate protection only for trusted, known code. According to 2026 infrastructure research, sandboxed agents running in properly isolated environments substantially reduce security incidents compared to agents with unrestricted host access.
If tool poisoning, a rug pull, or cross-server injection succeeds at the protocol layer, the execution environment is the last line of defense. It needs to be built for that specific role, not adapted from infrastructure designed for a different threat model entirely.
What Purpose-Built Agent Runtimes Provide That Retrofitted Infrastructure Does Not
The requirements that emerge from the MCP threat model are specific enough to enumerate. Near-instant provisioning matters because agents need isolated environments created per invocation or per session, not pre-warmed pools shared across workloads where one session's compromise can reach a neighbor's context. Strong kernel-level isolation, not shared-kernel containers, is the minimum viable boundary given the runC vulnerability class. Statefulness is necessary because MCP pipelines are not ephemeral; an agent mid-task that loses its execution context may resume in an inconsistent state that creates new attack surface independently of any external actor. Per-session credential scoping limits blast radius when a session is compromised, because tokens that do not persist across sessions cannot be stolen for later reuse. Full auditability at the agent level, covering every tool call, every context switch, and every code execution event, provides both a detection mechanism and an evidentiary record; retrofitted infrastructure rarely provides this granularity.
Microsoft's Agent Governance Toolkit, released as open-source under MIT license in April 2026, demonstrates what purpose-built governance tooling looks like at the action layer: sub-millisecond policy enforcement at the p99 level covering all 10 OWASP agentic AI risks. It is a useful reference point for what teams can build when they start from the MCP threat model rather than adapting general-purpose infrastructure. Daytona, built specifically for executing AI-generated code, addresses the execution isolation layer directly; its sandboxes provision in under 90 milliseconds, are stateful by design, and run in customer-managed compute so that credentials and data remain within the customer's own infrastructure boundary rather than transiting shared platforms.
The protocol and the runtime are separate layers. Hardening one without the other leaves the pipeline exposed at the layer that was not addressed. I have seen teams invest heavily in MCP server vetting while running agent code in shared containers, and the security posture that results is roughly analogous to locking the front door while leaving the back window open.
The Operational Controls Teams Can Implement Now, Before the MCP Security Model Matures
The MCP specification, as of mid-2026, does not mandate re-verification of tool definitions after initial approval, does not standardize credential scoping across servers, and does not define a disclosure or patching process for server vulnerabilities. Teams operating production agentic pipelines today are, in a meaningful sense, ahead of the protocol's own security model. The controls available are real; they are also partial, and it is worth being precise about which problems each one actually addresses.
Treating tool descriptions as untrusted input and diffing them against a known-good baseline before each session's first invocation addresses the rug pull and catches definition changes before they execute. This requires tooling that most current MCP clients do not provide natively. Building or integrating it is proportionate to the risk.
Least-privilege scoping at the MCP server level means issuing short-lived credentials scoped to the minimum set of actions the agent actually requires, avoiding passing a token issued for one agent to another without explicit re-scoping, and eliminating static API keys stored in configuration files wherever alternatives exist. This is standard security practice applied to a context where it is frequently ignored, often because the convenience of long-lived tokens makes them the path of least resistance during rapid development.
Isolating every agent session in its own execution environment, not a shared container, not a shared process, ensures that a compromised session cannot reach neighboring sessions or the host. This is where the isolation tier decision matters concretely: microVM-level isolation for untrusted or AI-generated code, hardened containers only where the code source is reliably known.
Community-contributed MCP servers warrant the same treatment security teams apply to third-party software dependencies: source review, version pinning, monitoring for definition changes, and a revocation path that does not depend on the server's maintainer doing anything. That last condition is the one that most dependency-management frameworks assume away. For MCP servers, the assumption is not safe.
Structured output filtering between MCP tool responses and subsequent tool calls breaks the propagation chain that makes toxic agent flows possible. It is the operational implementation of Willison's lethal trifecta insight: the third element, insufficient output filtering, is the one teams can most directly control right now, with existing tooling.
Every tool invocation should produce a durable log entry capturing server identity, tool name, arguments, and a hash of the tool description at call time. The hash is the critical element. It is what allows retrospective verification that the description at execution time matched the description at approval time, which is the only evidence chain that makes a rug pull detectable after the fact.
None of this is complete. These controls reduce exposure materially and measurably, but they are compensating measures applied over a protocol that has not yet formalized the security properties enterprise deployment requires. MCP's adoption trajectory is steep enough that the security model will need to catch up. The teams building on it now are accumulating the incident data that will shape what that catch-up looks like. That position carries real responsibility, and the teams I have seen handle it best are the ones who hold both truths simultaneously: the technology is useful, and the security model is immature. Neither fact cancels the other.
