Poisoned MCP Tool Descriptions: A Silent Exfiltration Path

Key Takeaways

Microsoft’s security research team disclosed on June 30, 2026, that the natural-language descriptions attached to Model Context Protocol (MCP) tools can be quietly modified to redirect an AI agent’s behavior, causing it to collect and exfiltrate sensitive data while every individual action still appears authorized [1][2]. The vulnerability is architectural rather than a bug in any single implementation: MCP mixes instructions and data in the same channel, so a tool’s metadata carries exactly as much influence over agent behavior as the system prompt does, and many deployments apply that metadata immediately without requiring a re-approval step — a configuration Microsoft’s own disclosure flags as a risk to check for, not a measured industry norm. The underlying technique predates this disclosure by over a year. Invariant Labs demonstrated the underlying “tool poisoning” technique against the Cursor editor in April 2025, researchers hijacked GitHub’s MCP server through a poisoned issue the following month, and a malicious npm package impersonating Postmark’s email service used the same mechanism to exfiltrate customer email traffic in September 2025 [3][4][5][7]. An August 2025 academic benchmark found that current AI agents follow poisoned tool instructions at meaningfully high rates even when the most capable models are used, because the same instruction-following ability that makes a model useful also makes it obedient to hidden commands [6]. For organizations that have adopted MCP or similar tool-calling protocols to connect AI agents to internal systems, the practical implication is that every connected tool is a live software dependency whose metadata requires the same change control, review, and monitoring as executable code — not a one-time integration decision made at onboarding and then left alone.

Background

The Model Context Protocol, introduced by Anthropic in late 2024, standardizes how AI agents discover and invoke external tools: a calendar, a customer database, an email sender, a code repository. When an agent connects to an MCP server, the server returns a list of available tools, each accompanied by a natural-language description that tells the agent what the tool does, what parameters it accepts, and when to use it. The agent reads that description as part of its working context and uses it to decide, autonomously, whether and how to invoke the tool during a given task. This design choice is what makes MCP useful — it lets a general-purpose agent adapt to an arbitrary set of tools without bespoke integration code for each one — and it is also the design choice that creates the vulnerability class Microsoft is now warning about.

The core weakness is that MCP does not distinguish between instructions the agent should follow and data the agent should merely process. A tool description is technically metadata, but functionally it is an instruction: the agent treats it with the same authority it gives its system prompt. Invariant Labs, a research group focused on AI agent security, was the first to formalize this in an April 2025 disclosure it named “Tool Poisoning Attacks.” Its proof of concept used an innocuous-looking calculator tool whose description contained hidden text instructing the connected agent to read the contents of the user’s SSH private key file and a local MCP configuration file, and to smuggle both out as a parameter of the tool call itself. When tested against the Cursor code editor, the attack succeeded: the editor’s AI assistant read and exfiltrated the private key while displaying a normal, truncated summary of the tool to the human user, who never saw the malicious instruction text [3].

The same underlying mechanism has recurred in the year since, with each subsequent case demonstrating a wider blast radius than the last. In May 2025, Invariant Labs showed that a single malicious GitHub issue, posted publicly, could hijack an AI agent connected to GitHub’s MCP server: when a user asked the agent to check open issues, the agent read the poisoned issue text as an instruction, used its existing access to pull sensitive data — including salary information and private repository contents — out of the user’s private repositories, and autonomously opened a public pull request exposing that data [4]. GitHub’s server code was not flawed in the traditional sense; the vulnerability lived in the architectural assumption that a broadly scoped access token combined with an agent that cannot distinguish trusted instructions from embedded ones is a safe combination. In September 2025, the pattern showed up in the software supply chain directly: a package on the npm registry called postmark-mcp, which let AI agents send transactional email through the Postmark service, built up fifteen clean releases and real usage before version 1.0.16 quietly added a line of code that blind-copied every outgoing email to an external address. Snyk, which caught and documented the malicious update, confirmed the mechanism and the September 17, 2025 release date; Koi Security, the researchers who first identified the compromised package, separately estimated that roughly 300 organizations were affected before it was removed, with several thousand emails a day flowing to the attacker-controlled domain during peak usage [5][7].

Security Analysis

Microsoft’s June 2026 disclosure formalizes what these earlier incidents suggested individually: poisoned tool descriptions are a general-purpose exfiltration technique against any agent that consumes MCP-style tool metadata, not a quirk specific to one client or one server implementation. Microsoft’s own reference scenario involves a finance team’s Copilot Studio agent, which manages vendor invoices through three connected tools, one of which is a third-party invoice-enrichment server. A developer with write access to that server’s configuration modifies the tool’s description, framing the change as a fraud-detection requirement, so that the description now instructs the agent to retrieve the organization’s most recent unpaid invoices and attach them to the next tool call regardless of what the user actually asked for. In configurations where description updates to a previously approved tool do not trigger a re-approval workflow — a condition Microsoft’s disclosure singles out as a risk to check for rather than a measured majority behavior — the poisoned description can go live in production the moment it is published. The next time an analyst makes a routine request — checking on a specific vendor, for instance — the agent silently follows the embedded instruction in addition to the visible one, collects the invoice data, and forwards it to an endpoint the attacker controls. The analyst sees a clean, correct-looking answer to their original question; nothing in the default configuration raises an alert [1][2].

Four properties of this attack pattern make it difficult to catch with security controls designed for earlier generations of software. Every individual action the agent takes is one it is technically authorized to perform, since the tool was already approved and the credentials it uses are the agent’s legitimate ones; there is no unauthorized access event in the traditional sense, only unauthorized use of authorized access. The malicious payload also lives in metadata that most engineering and security review processes do not treat as code, so it is unlikely to pass through the same static analysis, code review, or change-management gates that would catch a comparable change to an application’s source. Compounding both problems, MCP servers can update their tool descriptions dynamically, and clients that re-fetch and trust that metadata on every session without a re-approval workflow let an attacker skip compromising the agent or the model entirely — only the description text on a server the agent already trusts needs to change, whether that server is internally operated or a third-party dependency. The August 2025 MCPTox benchmark, which tested 20 prominent language models against 353 real tools drawn from 45 live MCP servers, put a number on the resulting exposure: an average attack success rate across all tested configurations of 36.5%, with the most instruction-compliant models — including o1-mini at 72.8% — following poisoned instructions the majority of the time and refusing the attack in fewer than 3% of cases even for the most cautious models tested [6]. This note’s assessment is that no plausible model-capability upgrade path resolves this problem on its own, since the same instruction-following ability driving the vulnerability is also the capability organizations are paying for when they adopt more capable models.

The consequence for enterprise risk assessment is that MCP tool integrations need to be evaluated the same way an organization evaluates a third-party API dependency or an open-source library: as a live component of the software supply chain that can change behavior after initial vetting, not as a static configuration decision made once during onboarding. A tool that was reviewed and approved as safe on the day it was connected offers no assurance about its behavior six months later if its publisher, or an attacker who has compromised that publisher’s account or infrastructure, can update the description text without triggering any review. This is functionally the same trust assumption that made the postmark-mcp incident possible, applied to the natural-language layer instead of the code layer, and it means that npm-style “clean release history, then a poisoned update” patterns are exactly as viable against tool descriptions as they are against package code [5][7].

Recommendations

Immediate Actions

Security teams operating any AI agent with MCP or comparable tool-calling access should inventory every connected tool and confirm whether the platform re-approves a tool automatically when its description changes; if it does, that behavior should be disabled or replaced with a workflow that requires explicit human review of the diff before the new description takes effect, exactly as a pull request to production code would be reviewed. Organizations should also disable any “allow all tools” or blanket-trust configuration in favor of an explicit allowlist of approved publishers and tool identifiers, since an unbounded trust posture gives every connected server, including ones added for a single low-risk use case, the same effective reach as the agent’s broadest credential.

Short-Term Mitigations

Tool descriptions should be brought into the same change-management discipline applied to system prompts and application code: version-controlled, diffed on every update, and scanned for embedded imperative language, unusual formatting artifacts, or instructions unrelated to the tool’s stated function. Agents that can take consequential actions — moving money, sending external communications, modifying access permissions, or exporting bulk data — should require a human-in-the-loop approval step before execution rather than operating on full autonomy, consistent with a least-agency design principle. Telemetry on agent-tool interactions should be centralized and monitored for the kind of anomaly that indicated compromise in the incidents above: a data volume much larger than the task appears to justify, a destination endpoint the organization has not seen before, or a tool invocation pattern that does not match the user’s stated request.

Strategic Considerations

Organizations building or procuring agentic AI systems should treat every MCP server, whether operated internally or by a third party, as a supply-chain dependency subject to the same vendor risk management applied to any other software component with production access: known provenance, a documented update process, and a revocation path if the publisher is compromised. Assigning agents distinct, scoped, non-human identities rather than reusing broad human credentials limits the blast radius of a successful poisoning event to what that specific agent’s identity can reach, and it gives the anomaly-detection work above a coherent baseline to measure against. Finally, procurement and security review processes for AI agent platforms should ask vendors directly how tool-description updates are validated and re-approved, since the answer to that question is now a material factor in the platform’s overall security posture rather than an implementation detail.

CSA Resource Alignment

This finding connects directly to CSA’s own recent MCP research. The CSA AI Safety Initiative’s MCP by Design: RCE Across the AI Agent Ecosystem (April 2026) documented a related but architecturally distinct class of MCP risk — a systemic remote-code-execution flaw stemming from how MCP’s STDIO transport handles server commands — and identified tool poisoning and malicious marketplace distribution as adjacent exposures in the same ecosystem, including the finding that nine of eleven tested MCP tool registries accepted a proof-of-concept malicious submission with no meaningful review. The Microsoft disclosure covered in this note extends that picture from the transport and marketplace layers to the metadata layer itself, reinforcing the earlier note’s core conclusion that MCP-connected tooling should be treated as an unvetted, dynamically mutable supply chain rather than a fixed integration.

CSA’s Agentic AI Red Teaming Guide (May 2025) provides the testing methodology organizations need to operationalize the mitigations above, with explicit coverage of supply chain risk and permission escalation as red-team dimensions for agentic systems; teams standing up a review process for tool descriptions should use that guide’s supply-chain test cases as a starting checklist rather than building one from scratch. At the governance layer, the AI Controls Matrix (AICM v1.1) supplies the control language for formalizing the change-management and vendor-risk practices this note recommends — its domains covering third-party and supply chain risk, and its Application Provider responsibilities under the Shared Security Responsibility Model, map directly onto the obligation to treat MCP tool metadata as a governed artifact rather than an unreviewed configuration value.

References

[1] Microsoft Security Blog. “Securing AI agents: When AI tools move from reading to acting.” Microsoft, June 30, 2026.

[2] The Hacker News. “Microsoft Warns Poisoned MCP Tool Descriptions Can Make AI Agents Leak Data.” The Hacker News, June 2026.

[3] Invariant Labs. “MCP Security Notification: Tool Poisoning Attacks.” Invariant Labs, April 1, 2025.

[4] Invariant Labs. “GitHub MCP Exploited: Accessing Private Repositories via MCP.” Invariant Labs, May 26, 2025.

[5] Snyk. “Malicious MCP Server on npm postmark-mcp Harvests Emails.” Snyk, September 2025.

[6] “MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers.” arXiv:2508.14925, August 2025.

[7] Koi Security. “First Malicious MCP in the Wild: The Postmark Backdoor That’s Stealing Your Emails.” Koi Security, September 2025.