MCP Tool Poisoning: How AI Gateways Defend Against It

Summary

The corpus is guidance-oriented analysis of the security exposure created by the Model Context Protocol (MCP), the open standard introduced by Anthropic in late 2024 that lets AI agents discover and call external tools, databases, and cloud services at runtime. Because an MCP server sits between the agent and the systems it acts on, frequently holds OAuth tokens for multiple connected services at once, and the base protocol mandates no authentication, authorization, or transport security, each server becomes a new trust boundary and a concentrated credential hub whose compromise can propagate to everything linked to it.^[0][44]

Rather than a report of a single tracked in-the-wild campaign, the material catalogs why ungoverned MCP deployment is dangerous and prescribes a governance program of server registries, agent RBAC, centralized gateways, real-time observability, and supply-chain hygiene. It cites illustrative real incidents—the September 2025 Postmark MCP maintainer backdoor, a platform path-traversal exposing secrets across thousands of MCP applications, and a late-2025 credential-stealing malicious-package campaign—alongside Wiz telemetry showing MCP servers in at least 80% of observed cloud environments in early 2026.^[0][44]

Empirical research now quantifies the tool-poisoning threat specifically: the MCPTox benchmark, built on 45 live MCP servers and 353 authentic tools, found widespread vulnerability across 20 LLM agents, with an attack success rate of 72.8% for o1-mini and a refusal rate under 3% even for the best-performing model, indicating that current safety alignment is ineffective against malicious use of legitimate tools.^[41]

How it works

MCP reverses the familiar client-server interaction pattern: instead of clients requesting data in a predictable, auditable sequence, servers query and execute actions on behalf of clients, and the agent discovers tools at runtime from any server it can reach. Each discovered server is a new trust boundary, yet the specification standardizes only how models discover and call tools while mandating no authentication, authorization, or transport security, so an MCP server is only as secure as the team that deployed it and can be reachable from agent runtimes with no credential check.^[0][44]

Tool poisoning is a metadata-level vulnerability: malicious instructions are embedded within a tool's metadata without execution, so an agent that reads a poisoned capability description at session start is induced to perform actions its operator never intended. Unlike attacks injected through tool outputs, this exploits the discovery step itself, and MCPTox demonstrates it systematically across live servers, finding that more capable models are more susceptible because the attack leverages their superior instruction-following.^[41][0]

Credential aggregation compounds the exposure: MCP servers frequently hold OAuth tokens for multiple connected services simultaneously, so compromising one server can grant access to everything linked to it, and those tokens can persist even after a password change. Wiz frames the resulting risk as five vectors—confused deputy, token passthrough, tool poisoning, SSRF via tool connectors, and rogue server registration—all arising because the protocol grants the LLM runtime ambient authority across multi-hop trust chains that perimeter and identity controls do not cover alone.^[44]

Key takeaways

• MCP introduces a new trust boundary and attack surface: each server an agent discovers at runtime holds credentials to the systems it touches, yet the protocol itself mandates no authentication, authorization, or transport security.^[0][44]
• Tool poisoning is now empirically validated as a widespread, high-yield attack: MCPTox found attack success rates as high as 72.8% and refusal rates under 3% across 20 LLM agents, and more capable models were more susceptible—showing existing safety alignment does not defend against legitimate tools being used for unauthorized operations.^[41]
• MCP adoption is already widespread—present in at least 80% of observed cloud environments in early 2026 with 5% exposing an internet-facing server—so attackers can assume the integration layer exists and defenders must inventory and govern it.^[44]
• The exposure is a governance absence rather than a single patchable protocol flaw; banning MCP backfires by driving usage underground, so the durable fix is a governed path built on registries, agent RBAC, gateways, real-time observability, and supply-chain hygiene—which also satisfies emerging regulatory inventory requirements.^[0]

Defensive actions

• Establish a server registry with an entry for every MCP server agents are allowed to connect to, capturing who deployed it, what it accesses, and under what authorization.: Ungoverned servers are invisible identities that become exploitable because no one is watching them; the registry is the foundational visibility control and is also required to produce the AI inventory that NIST AI RMF, ISO 42001, and the EU AI Act assume.^[0]
• Extend identity and access control to agents by applying role-based access control to each AI agent and MCP server.: Because RBAC is absent from the protocol, deliberate per-agent permissioning prevents discovering after an incident that an agent had access to everything it could reach.^[0]
• Route agent-to-server communication through a centralized gateway control point.: A gateway is the enforcement surface for access policies and the collection point for audit data; without it, policies exist only on paper and cannot interrupt an action in progress.^[0]
• Implement real-time observability capable of interrupting an action in progress rather than only retrospective audit logging.: An audit log reviewed after a breach is only a postmortem tool; governance that acts as a safety net must be able to stop autonomous actions that occur at machine speed.^[0]
• Apply supply-chain hygiene by vetting MCP server provenance and integrity before registration.: Documented maintainer-side backdoors such as the Postmark incident and malicious-package campaigns show the supply chain itself is an attack vector, so provenance vetting is established operational practice, not excess caution.^[0][44]
• Apply MCP-specific controls across authentication, transport security, and supply-chain governance, such as OAuth 2.1 token exchange and cryptographic server attestation.: The MCP specification enforces none of these controls, so they must be implemented per host, client, and server to close the identity, network, runtime, and supply-chain gaps MCP introduces.^[44]
• Provide a governed path for MCP adoption rather than banning AI tools outright.: Blanket prohibitions (as in the cited Samsung case) reduce visible use, not actual use, pushing adoption to personal accounts and unofficial servers with identical function and zero visibility; a governed path that is faster than the ungoverned alternative keeps the attack surface documented.^[0]

Changelog

• Added empirical benchmark evidence from the MCPTox study (arXiv, submitted 19 August 2025) quantifying tool poisoning against 45 live MCP servers and 353 tools: attack success rates up to 72.8% (o1-mini), refusal rates under 3%, and a finding that more capable models are more susceptible—strengthening the previously guidance-only characterization of tool poisoning with measured impact.^[41]