MCP Tool Poisoning Attack Vectors
How MCP Lets Agents Trust Tool Descriptions (and Why That Trust Is the Vulnerability) MCP's core design lets agents dynamically …
How MCP Lets Agents Trust Tool Descriptions (and Why That Trust Is the Vulnerability)
MCP's core design lets agents dynamically discover and execute tools based on natural-language descriptions, JSON Schema definitions, and server-fetched metadata. The model reads those descriptions as ground-truth documentation: authoritative specification of what a tool does and how to use it. Not helpful hints. Not context clues. Instructions.
This is a meaningful departure from how software integration has worked for decades. In a traditional API integration, a developer writes every call. They control the parameters, the endpoints, the logic. In MCP, the model decides which tools to invoke, when, and with what parameters. The developer is no longer in the loop at invocation time, and that shift creates a trust channel with no real analog in prior software architecture.
Structured metadata gets processed as instruction. The model has no independent way to verify whether that instruction is legitimate, and nothing in the current protocol requires anyone to prove it is.
The NSA said as much in their May 2025 report: "MCP's rapid proliferation has outpaced the development of its security model. Much like early web protocols, MCP was released with a flexible and underspecified design, allowing implementers freedom of design but also introducing ambiguity for safe usage." The protocol specification lacks mandatory authentication. Identity association, role-based access control, session verification: largely unspecified. Every MCP server picks its own answer to who is allowed to do what. Most pick nothing.
That design gap is the structural precondition for everything that follows.
Tool Poisoning: What the Classic Attack Actually Does
Tool poisoning is straightforward to the point of being uncomfortable. An attacker embeds adversarial instructions inside a tool's natural-language description on a malicious or compromised MCP server. The model processes the full description as authoritative and cannot distinguish genuine documentation from embedded directives. The attacker's instruction becomes, from the model's perspective, a required step in the tool's legitimate operation.
The user experience and the model experience diverge completely. A user sees a simplified label, something like "Add Numbers." The model receives the full description, which includes hidden commands to exfiltrate data, harvest credentials, or access resources the user never intended to authorize. The user approves the tool. The model executes everything the description tells it to. Functionally, the user is signing a contract they have never read.
Invariant Labs first identified this in April 2025. Confirmed impacts included WhatsApp chat history exfiltration, GitHub private repository access, and SSH credential theft across major AI platforms. Controlled testing found an 84.2% success rate when AI agents have auto-approval enabled. That number stopped surprising me after I thought through what it actually measures: not a clever exploit, but a population of agents doing exactly what they were designed to do, trusting the description they were given.
The persistence characteristic is what makes tool poisoning categorically more dangerous than most prompt injection variants. A single-session prompt injection requires re-injection on every session. Tool poisoning requires one compromise. The effect propagates to every subsequent session that uses the tool, without any additional attacker action, until someone notices and revokes it. OWASP has listed this as MCP03:2025 in the MCP Top 10, currently in beta for 2026.
The Broader Attack Family: Rug Pulls, Shadowing, Schema Poisoning, and STDIO Injection
Rug Pull Attacks
A rug pull exploits something specific about MCP client behavior: schema integrity is not verified after the initial handshake. A tool definition gets silently modified after the agent has already approved it. No re-approval is triggered. No alert fires. The approval from earlier is now covering behavior the user never reviewed.
The mechanics are fairly precise. A server changes a tool definition to require a parameter such as AWSACCESSKEY_ID as mandatory. The agent treats this as a legitimate API constraint, extracts the credential from context, and passes it to the server. The server logs the stolen credential while continuing to execute the original query, preserving the appearance of normal operation. Invariant Labs named this attack alongside their classic tool poisoning research.
Shadowing Attacks
Shadowing is subtler. Malicious tool definitions influence trusted tool behavior without ever being directly invoked; an attacker hides directives inside definitions that appear benign to users but are parsed and acted upon by the agent reading the metadata. MCP clients do not alert users when tool descriptions change after approval, so a previously approved tool can be weaponized post-approval with no visible trigger. Those instructions persist across sessions.
Schema Poisoning
Schema poisoning operates one layer below description-level attacks, which is partly why it gets less attention. The schema is the typed contract defining request and response shape for every tool interaction. It is the language agents use to call tools. Corrupt that contract and you corrupt the agent's fundamental understanding of what a valid call looks like. Every downstream inference the model makes about the tool's behavior is built on a falsified foundation. Most security tooling is not looking at this layer, because nobody built that tooling when the layer was just documentation.
STDIO Command Injection
OX Security researchers identified STDIO command injection as a structural weakness in MCP's architecture, enabling arbitrary command execution on any system running a vulnerable MCP implementation. It was found across Anthropic's official MCP SDK in Python, TypeScript, Java, and Rust. OX Security reported: "This flaw enables Arbitrary Command Execution on any system running a vulnerable MCP implementation, granting attackers direct access to sensitive user data, internal databases, API keys, and chat histories."
A single compromised server can propagate corruption through the broader toolchain in ways that are difficult to trace after the fact.
Supply Chain and Parasitic Toolchain Attacks
A malicious MCP server introduced via a supply chain attack enables tool poisoning at scale. Session hijacking allows token reuse across tool invocations. What makes the MCP threat model genuinely distinctive is how these vectors compound: tool poisoning exfiltrates credentials; credential theft enables session hijacking; session hijacking enables broader tool poisoning. Each vector left unaddressed increases the leverage available to every other. The attack surface expands in ways that are difficult to model linearly, because the interactions between vectors matter as much as the individual vectors themselves.
Confirmed CVEs and Real-World Compromises
The vulnerability catalog for MCP is no longer hypothetical. CVE-2025-6514, discovered by the JFrog Security Research Team and disclosed in 2025, carries a CVSS base score of 9.6, placing it among the most severe ecosystem vulnerabilities identified to date. MCPoison (CVE-2025-54136) and CurXecute (CVE-2025-54135) exploited the schema integrity gap through different mechanisms but proved the same structural point. Additional confirmed CVEs include CVE-2025-49596 in MCP Inspector and CVE-2025-54994 affecting @akoskm/create-mcp-server-stdio.
The confirmed impacted platforms include GitHub MCP, Clawdbot, Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI. These are not obscure research targets. They are the development environments and AI interfaces in daily use across the industry.
The named incidents are instructive. The Clawdbot gateway exposure. The GitHub MCP repository exfiltration, where the root cause was broad-scope Personal Access Tokens with write-level permissions that were never revoked. A financial services intrusion that went undetected for 14 days. An audit of 17 popular MCP servers found an average security score of 34 out of 100, and every single one lacked permission declarations.
The common thread: MCP shipped without mandatory authentication, default configurations were the attack surface, and no observability layer surfaced misconfiguration before attackers found it. When security is optional in a protocol, most implementations treat it as optional.
Why These Attacks Are Designed to Evade Detection
Here is the thing that took me a while to internalize: the malicious channel looks like configuration, not execution. JSON Schema fields, tool descriptions, structured metadata fetched at boot. None of these register as instructions in a conventional security stack. That framing is not accidental. It is the evasion. The attack hides in the layer that security tooling was never built to read, because nobody built that tooling when the layer was just documentation.
Persistence compounds detection difficulty considerably. A tool is poisoned once; the effect propagates to every subsequent session without any recurring attacker action. No SIEM alerts. No EDR events. No network anomalies that look out of place. Malicious activity surfaces as normal tool usage because it is delivered through legitimate tool calls. That is exactly how the financial services intrusion ran undetected for two weeks.
MCP's trust model treats approval as a point-in-time event. Everything after the initial handshake is effectively unmonitored, and that absence of observability is what extends dwell time from hours into days or weeks.
Shadow MCP servers, catalogued as OWASP MCP09, compound detection further. Unapproved deployments run outside formal governance, use default credentials and permissive configurations, and generate no visibility in the central security stack. From a defender's perspective, they are invisible until they are exploited, at which point the question of when the compromise began is genuinely difficult to answer.
The Authentication and Authorization Gap at the Protocol Level
The NSA's May 2025 analysis is blunt: "Associating a session to an identity is not defined by the protocol. MCP currently lacks support for exchanging Role-Based Access Control (RBAC) permissions at instantiation."
Identity in MCP is asserted, not verified. Servers and tool definitions claim to represent a particular provider. Without cryptographic proof, those claims cannot be validated. OAuth 2.1 support exists in the specification, where MCP clients act as OAuth 2.1 clients and protected servers act as OAuth 2.1 resource servers, but implementation is optional. An optional security control in a protocol is, in practice, a suggestion. Suggestions get skipped when teams are moving fast and there is no enforcement mechanism.
The session management gaps follow directly from this foundational absence. Message replay vulnerabilities, unauthorized reuse of valid sessions, session hijacking that enables impersonation of legitimate clients: all of these flow from the same place. Token passthrough and lifecycle handling are left underspecified in the protocol itself.
The confused deputy problem is the clearest way to articulate the consequence. Without verified identity, an agent acting on behalf of a legitimate user cannot be distinguished from a rogue agent acting on behalf of an attacker. Traditional bearer tokens compound this: whoever holds them can use them. Proof of Possession tokens address the problem by cryptographically binding credentials to the requesting client. Certificate-based identity verification binds identity claims at the network access layer. Both represent the direction the protocol needs to travel. Neither is the default today.
OWASP MCP01 covers token and credential mismanagement directly: hard-coded credentials, long-lived tokens, secrets stored in model memory or protocol logs. OWASP MCP02 covers excessive permissions and scope creep, temporary or loosely defined permissions that expand over time without enforced review cycles or automatic expiry. Most of the specific failure modes they describe are not exotic. They are the same credential hygiene problems that have plagued software for twenty years, now propagating through a new and less-monitored channel.
Credential Management Inside Agentic Workflows
Broad-scope Personal Access Tokens were the confirmed root cause of the GitHub MCP toxic agent flow attack. Most MCP integrations grant write-level scopes at setup and never revisit them. The agent inherits those credentials, delegates them to sub-agents without strict scope enforcement, and the privilege surface expands with each handoff. Nobody revokes anything, because nobody is watching.
The failure modes that follow are predictable once you have seen them a few times: over-privileged agents, credential reuse via model memory, confused deputy escalation, and time-of-check/time-of-use gaps where a permission is validated at one moment and exercised at another after conditions have changed. The permission that looked reasonable in January is doing something entirely different by March, and the team that granted it has long since moved on to other priorities.
Credentials must be short-lived by default. Every integration that ships with a static, long-lived key is a future incident waiting for a trigger. Replace static keys with short-lived OAuth 2.1 tokens. Validate token audience per server. Enforce automatic scope expiry. Require MFA for human approvers of high-risk actions. Run continuous secrets detection across repositories, developer machines, and CI runners to catch hard-coded tokens before they ship.
OWASP MCP10, context over-sharing, is the quieter companion to the credential management problem. Shared context windows leak data across agents, sessions, or users. Tool responses that dump excessive fields into the model context extend the exfiltration surface in ways that are rarely audited and almost never visible to the end user who authorized the tool in the first place.
What Defense Actually Requires: Detection, Governance, and Continuous Verification
The attack surface spans tool descriptions, schemas, invocation chains, session tokens, and credential scopes. A defense that covers only one layer leaves every other layer accessible, and the attacker only needs one.
Start with the OWASP MCP Top 10, currently in beta for 2026. It covers ten categories from credential mismanagement through shadow server governance, and it is the most practical audit checklist available for any server before connecting. Treat it as a baseline, not a ceiling.
Server-side controls are the first requirement. Schema integrity verification after the initial handshake detects rug pull modifications before they execute. Cryptographic tool definition signing detects description tampering at the source. Mandatory re-approval workflows when tool definitions change close the post-approval weaponization window. Permission declarations on every server address what every currently audited server is missing. None of these are aspirational; they are the minimum viable response to a known and documented attack surface.
Detection requires instrumentation at the right depth. Logging of LLM and MCP activity is the baseline; without it, dwell time is unbounded, as the financial services case demonstrated. Monitoring at tool-call depth, not just at the network perimeter, is necessary to see what agents are actually doing. Real-time detection for tool poisoning, prompt injection, intent drift, and exfiltration patterns cannot be retrofitted after an incident. Tamper-proof audit logs and full OpenTelemetry tracing provide the forensic foundation for post-compromise investigation, but only if they were running before the compromise began.
Identity and session controls close the structural gap at the protocol level. Cryptographic binding of tokens to requesting clients, mandatory re-authentication when tool definitions change, and continuous session validation after the initial handshake replace the point-in-time approval model with something durable. Something that holds up when a tool definition changes silently at 2 a.m. and no human is watching.
Fourteen days of undetected dwell time is not an anomaly in the financial services case. It is the predictable outcome of deploying MCP without observability. Most organizations sitting on that gap right now have no idea, because the absence of alerts is not the same as the absence of compromise.
