MCP Tool Poisoning in the AI Supply Chain
In 2023, enterprise AI was almost entirely read-only. Employees pasted text in, pasted answers out. A bad output was an embarrassing email. The system had no authority to act, so the stakes were genuinely low, and most security teams didn't lose sleep over it.
That changed quickly. By late 2025, agents were calling APIs, pushing code, querying customer data, drafting approvals, and chaining tool calls with limited human review. According to Salesforce's "State of IT" report (2025), more than 80% of Fortune 500 companies were piloting or running AI agents. Independent security researchers and analysts, including those at Gartner and Forrester, have noted that monitoring and identity controls for these deployments remain inconsistent and often immature, though precise figures on the share of unmonitored agents vary across sources and should be treated as estimates.
When an agent acts rather than advises, a poisoned tool description stops being a nuisance. It becomes an execution vector. The agent carries out whatever the description instructs, using the credentials and access it was granted. The blast radius of a compromised tool is bounded only by what the agent has permission to touch. In agentic systems, that permission tends to be broad, established at configuration time, and rarely revisited.
The Three Mechanisms by Which MCP Tools Get Poisoned
MCP tool poisoning embeds adversarial instructions inside tool descriptions, parameter schemas, or response content. The agent assumes this content was authored by a trusted developer. That assumption is the entire attack surface. The agent has no native mechanism to question it.
This is meaningfully different from standard prompt injection, which rides in on user-supplied text. Most stacks apply scanning at that layer already. Tool poisoning exploits structural metadata that sits upstream of user input, in the operational context the agent consumes before a user ever types anything.
Tool Description Poisoning
Invariant Labs named this variant formally in April 2025. Hidden instructions embedded inside a calculator tool's description caused the Cursor editor to locate a user's private SSH key and exfiltrate it. The model read the description as an instruction, not as metadata, and complied without hesitation. Nothing anomalous appeared at the network layer. The agent did what it was told, because from its perspective, it had been told by something it trusted.
Rug-Pull Attacks
A server presents a clean tool description at the moment of approval, then silently replaces it after trust is established. Static scanning cannot catch this because the package was clean when scanned. The malicious payload arrives later, in an update, after the trust decision has already been made and forgotten.
Trail of Bits proposed a "trust-on-first-use" control specifically for this pattern: capture the description at first approval, then re-prompt the user if it ever changes. It is the only control that structurally stops rug pulls, because it operates on the delta between what was approved and what is currently running. Almost nobody has implemented it yet.
Cross-Server Tool Shadowing
This variant is the most architecturally insidious. In a documented case, a malicious GitHub issue hijacked an agent connected to the GitHub MCP server and walked data out of private repositories. The tools themselves were untouched and trusted. The adversarial instructions rode in on the data the agent read. OWASP cited this case as an agentic supply chain vulnerability example in its December 2025 Top 10 for Agentic Applications.
The attack surface is anywhere the agent reads, not just the tool manifest. You can lock down every tool description and still be exposed through the content those tools return.
All three variants share a root cause: MCP clients inherit trust from servers they connect to, without continuous verification of that trust.
How Effective These Attacks Are in Practice
The MCPTox benchmark, released in August 2025, ran poisoned tool descriptions against 45 real MCP servers and 20 leading AI models. Success rates reached as high as 72.8%, and the models almost never refused.
This is not a niche result requiring exotic conditions or carefully selected targets. This is the baseline outcome across a broad sample of production-grade models and servers, tested against real infrastructure. The models complied because they were designed to trust their tool context. That design choice, entirely reasonable when MCP was conceived, has become a liability.
A separate 2026 analysis of the public server population found that roughly 5.5% of public servers carry active tool-poisoning vulnerabilities, and around 43% carry command-injection flaws. The raw count of vulnerable servers is growing faster than those percentages suggest. The registry expanded from roughly 1,200 entries in early 2025 to over 9,400 servers by mid-April 2026, more than sevenfold in fourteen months. A percentage that stays flat while the denominator multiplies is not a reassuring trend.
The attacks also require no sophistication. Basic poisoned descriptions reliably cross the 70% success threshold across diverse models.
Where Poisoning Enters the Supply Chain: Packages, Registries, and Dependency Chains
Many agent frameworks fetch MCP servers and plugins via package managers like npm and PyPI without verifying the registry source. Security teams who lived through the npm dependency confusion incidents of 2021 and 2022 will recognize this pattern. The difference is that the downstream consequence is no longer a compromised developer workstation. It is a compromised agent with live credentials and authorized access to production systems.
The postmark-mcp incident in September 2025 illustrated rug-pull behavior at the package level. Researchers found an npm package that mirrored a legitimate email tool through fifteen clean releases. Version 1.0.16 added one line that secretly BCC'd every email an AI agent sent to an attacker-controlled address. The package passed static scanning at every prior version because the malicious behavior simply wasn't there yet.
The mcp-remote package, assigned CVE-2025-6514, shipped a critical command-injection bug to more than 437,000 downloads before it was patched.
Registry-level poisoning is a qualitative escalation from package-level incidents. In the ClawHub registry case, five of the top seven most-downloaded skills at peak infection were confirmed malware. The first confirmed malicious MCP package appeared in September 2025; ClawHub demonstrated what happens when the registry itself becomes the attack surface. ClawHub has since implemented automated scanning and partnered with VirusTotal, but the broader ecosystem remains largely unprotected.
OX Security researchers identified a weakness in the MCP SDK architecture present across Python, TypeScript, Java, and Rust implementations that enables arbitrary command execution, affecting an estimated 200,000 vulnerable MCP instances across IDEs, internal tools, and cloud services. Named CVEs include CVE-2025-49596 affecting MCP Inspector and CVE-2025-54136 affecting Cursor. When the same architectural flaw appears independently across four language implementations, it indicates a pattern problem, not a bug problem.
An enterprise that builds its own MCP servers from scratch is still exposed through every third-party server, plugin, or framework dependency it pulls in.
Why Cascading Failures in Multi-Agent Systems Make This Harder to Contain Than Traditional Supply Chain Attacks
Traditional supply chain attacks compromise a build pipeline or a developer workstation. The blast radius is bounded by what that system touches directly. You find the compromised component, isolate it, remediate.
Multi-agent systems do not work that way. A poisoned tool can ride an agent's outputs into the next agent's inputs. The attack propagates through trust relationships between agents, not through code execution alone. Galileo AI research published in December 2025 found that in simulated multi-agent systems, a single compromised agent poisoned the downstream decision-making of the broader system within four hours, faster than traditional incident response could contain.
Three distinct incident types converge on the same gap: indirect prompt injection through a support ticket, tool chaining through a public GitHub issue, and tool poisoning through a shared document. In each case, no control operates at the semantic layer between the agent's intent and the system action it takes. The action looks authorized. It is, in a narrow technical sense. The authorization was just obtained through deception.
Shadow MCP servers compound this further. OWASP identifies them as unapproved or unsupervised MCP deployments operating outside formal security governance, typically spun up by developer or research teams using default credentials and permissive configurations. Development teams stand up MCP servers to test things, the servers persist, nobody tracks them. Individual agent governance is necessary. It is not remotely sufficient. System-level circuit breakers and quarantine mechanisms are required to contain propagation once a compromise is detected.
The Authentication Gap That Lets Poisoned Servers Operate Undetected
The MCP specification mandates OAuth 2.1 with PKCE for any server accessible over the internet, with no exceptions as of the November 2025 spec revision. The compliance reality looks nothing like that mandate.
A 2026 security audit found that a quarter of public MCP servers have no authentication at all. More than half rely on long-lived static API keys or personal access tokens, credentials that, once leaked, provide indefinite access with no expiration and no revocation pressure. Only a small fraction of MCP servers implement OAuth 2.1 despite it being the protocol's own mandatory security standard. Because the spec does not enforce authentication for local deployments, those deployments are technically compliant and practically insecure.
The confused deputy problem compounds this. A compromised or malicious MCP server can use its own access token to make requests to other MCP servers or downstream APIs on behalf of the original user, escalating privileges beyond what the user ever intended to grant. The spec explicitly forbids token passthrough: MCP servers must not forward an inbound client token to upstream APIs but must instead obtain a separate narrow token for each upstream hop. Many implementations do not enforce this, collapsing the access boundary the spec was designed to create.
GitGuardian counted roughly 29 million new secrets pushed to public GitHub in 2025, with AI-service credential leaks up 81% year-over-year (GitGuardian, "State of Secrets Sprawl 2026"). MCP servers contribute to that surface because hardcoded credentials in server configurations are a common implementation shortcut taken under deadline pressure. OWASP designates hardcoded credentials and token mismanagement as its top MCP risk category.
The authentication gap is also what makes poisoned registries dangerous in a specific way: a server that requires no authentication and presents a convincing tool manifest is indistinguishable from a legitimate one without out-of-band verification. There is no technical signal at connection time that separates them.
Where Defenses Currently Break Down, and What Categories of Control Actually Work
Existing static analysis tools focus on package manifests. They cannot detect runtime behavior: network exfiltration, file system access, or description changes that arrive after install. Scanning at install time fails against rug pulls by design. Perimeter controls see the traffic, not the semantic context. They cannot evaluate whether an agent's tool call is consistent with its authorized intent. These are not implementation failures; they are categorical limitations of tools built for a different threat model.
The controls that structurally address MCP poisoning share one characteristic: they operate at the semantic layer, on identity, in real time, rather than at install time on static artifacts.
Trust-on-first-use verification captures the tool description at initial approval and re-prompts the user on any subsequent change. It is the only control that structurally stops rug pulls, and it requires no complex infrastructure.
Just-in-time credentials, short-lived scoped tokens issued per agent session, prevent a compromised agent from replaying credentials across sessions or service boundaries. This limits lateral movement even when a poisoning succeeds.
Semantic intent verification operates as a control layer between what the agent intends to do and the system action it actually takes, evaluating whether the action is consistent with the agent's authorization rather than just whether the network traffic looks benign. This is the hardest category to implement and the most important.
Tamper-proof audit logs with full tool-call tracing are required for incident response within the window that matters. Without them, reconstructing what happened after a cascade failure is guesswork.
System-level circuit breakers and quarantine mechanisms address the multi-agent propagation problem directly. When a compromised agent is detected, the ability to isolate it before it poisons downstream agents is the difference between a contained incident and something much worse.
What an Enterprise MCP Security Architecture Looks Like in Practice
The core problem most enterprises face is fragmentation. The agent builder, the gateway, and the security tooling are separate products from separate vendors, often with no shared context about what is authorized, what has changed, or what is propagating through the system. Coverage gaps appear at every handoff.
A coherent MCP security architecture addresses four layers simultaneously.
The first is the tool registry layer: every MCP server an agent can reach must be inventoried, authenticated against a known-good manifest, and monitored for description changes. Trust-on-first-use controls belong here, as does enforcement of OAuth 2.1 for any server that is not purely local.
The second is the credential layer: no long-lived static tokens in server configurations, JIT credential issuance per session, strict enforcement of the spec's token passthrough prohibition. This is where many organizations have the largest immediate gap, because it requires integration between the agent identity system and the credential issuance infrastructure, two systems that were never designed to talk to each other.
The third is the semantic control layer, a verification mechanism that evaluates agent actions against authorized intent before execution, not after. This is the least mature category in terms of available tooling and structurally the most important, because it is the only layer that addresses cross-server shadowing and indirect injection at their root.
The fourth is the observability and response layer: tamper-proof logs, real-time tool-call tracing, and circuit breaker mechanisms capable of isolating compromised agents in a multi-agent system fast enough to matter.
Several vendors are building toward integrated coverage across these layers. Wiz has extended its cloud security graph to include AI agent workloads and MCP server inventory. Palo Alto Networks has incorporated MCP-aware controls into its AI Runtime Security product. Orca Security covers agent context within its cloud-native posture management platform. For teams that want purpose-built MCP security rather than an extension of an existing cloud security product, Invariant Labs, the same team that named tool description poisoning in April 2025, offers Invariant Guardrails, which applies semantic-layer analysis to MCP traffic in real time.
No single product covers all four layers today. Start with inventory and trust-on-first-use verification, enforce JIT credentials as a second step, and treat semantic intent verification as the capability to build toward, either through vendor tooling as it matures or through custom control logic in the agent framework itself. The sequence matters because the first two layers are implementable now, with existing infrastructure, and they close the vulnerabilities that are being actively exploited while the harder work gets done.
The monitoring coverage data tells you how far most organizations still have to travel. The propagation research tells you how little time you have once something goes wrong. Both figures deserve more urgency than most security roadmaps currently reflect.
