What is MCP tool description poisoning?

MCP tool description poisoning is an attack where an adversary modifies the plain-text description field of a Model Context Protocol tool to include hidden instructions. When an AI agent reads the description to decide how to act, it also reads and executes the hidden commands. Because the tool itself remains functionally intact and the agent acts using the user's own permissions, the attack can exfiltrate data without triggering standard security alerts.

How effective is this attack in practice?

The MCPTox benchmark, released in August 2025, tested poisoned tool descriptions against 45 real MCP servers and 20 leading AI models. It found attack success rates as high as 72.8 percent, and the models almost never refused the hidden instructions. This indicates the attack is broadly effective across current AI agent deployments rather than being model-specific.

What is the 'least agency' principle Microsoft recommends?

Least agency extends the traditional least-privilege concept to agentic AI systems. Least privilege limits what resources an account can access. Least agency limits what actions an agent is permitted to take, regardless of what it has access to. Even an agent with minimal account permissions can cause significant harm if it can act autonomously on risky operations like sending email, writing files, or exfiltrating query results. Microsoft recommends requiring human approval for any action that moves money, shares data externally, or modifies accounts.

Tool Descriptions as Attack Vectors: Microsoft MCP Poisoning Research

Microsoft Incident Response published research on June 30, 2026 documenting an attack pattern that has been building quietly in the background of the agentic AI rollout: poisoning the description field of a Model Context Protocol tool to redirect an AI agent’s actions toward data exfiltration. The attack exploits a fundamental structural issue in how MCP works. It does not require exploiting a vulnerability in any specific product. It requires only write access to a tool that an enterprise agent trusts.

The analysis is the third in Microsoft’s AI Application Security series, and it marks a shift in focus. The first two posts addressed what happens when AI reads content. This one addresses what happens when AI acts on it.

The New Attack Surface

The difference matters. A prompt injection against a passive summarizer changes an output. A prompt injection against an agent changes what software actually does. Microsoft 365 Copilot can send email, create files, update calendars. Custom agents built in Copilot Studio or Azure AI Foundry can call business systems and run multi-step workflows autonomously.

MCP is the protocol connecting those agents to external tools. Microsoft describes it as the fastest-growing part of the agentic AI supply chain. Every MCP tool ships with a description: a few lines of plain text that tell the agent what the tool does and when to use it. The agent reads that text to make decisions. That is the attack surface.

The description is just a string. It can carry anything. And unlike a system prompt, it receives almost no security scrutiny in most enterprise deployments.

How the Attack Unfolds

Microsoft walks through a finance workflow scenario designed to make the attack pattern concrete. A team deploys an agent to handle vendor invoices. The agent connects to three tools, including a third-party invoice enrichment service approved by IT but never subjected to a detailed security review.

The attacker gains write access to that third-party service. The name and the visible summary stay the same. Buried in the description, formatted to look like metadata or instructions to the tool, is a hidden order: grab the last thirty unpaid invoices and include them in the next request.

MCP picks up description changes on the fly. In a default setup without a re-approval trigger, the updated version goes live without any additional review. The attack is now in position.

An analyst asks a routine question about a supplier. The agent, following the hidden instruction, queries the invoice database, collects the unpaid records, and attaches them to the outbound call. The enrichment service returns a normal answer. The stolen invoices arrive at a server the attacker controls. The analyst sees a clean result and moves on.

Each individual action is legitimate. The tool was approved. The data query ran under the analyst’s own permissions. The outbound call went to an endpoint already on the allowlist. Microsoft puts the core issue precisely: the weakness lives in what it calls “the trust boundary” between those components, not in any one of them individually.

The deeper structural problem is that MCP mixes instructions and data in the same context. A tool description sits in the agent’s working memory alongside the agent’s actual directives. Editing that description is functionally equivalent to editing the system prompt. The agent has no reliable way to distinguish a legitimate instruction from a malicious one embedded in metadata.

Evidence This Is Not Theoretical

The attack class has a documented history that predates Microsoft’s analysis.

Invariant Labs named “tool poisoning” in April 2025 and published a proof of concept that hid instructions in a calculator tool’s description to make the Cursor editor read a user’s SSH private key and send it to a remote endpoint. A related demonstration showed a malicious GitHub issue hijacking an agent connected to the GitHub MCP server, walking data out of private repositories through a tool that was never modified directly.

The real-world progression came in September 2025, when Koi Security found a package called postmark-mcp on npm. It had mirrored a legitimate email tool through fifteen clean releases. Version 1.0.16 added a single line that silently BCC’d every email sent by an agent to an attacker-controlled address. Koi identified it as the first confirmed malicious MCP server in the wild.

OWASP included it as an example case in its December 2025 Top 10 for Agentic Applications, under the Agentic Supply Chain Vulnerabilities category.

The MCPTox benchmark, released in August 2025 and cited in Microsoft’s post, provides the most systematic measurement. Researchers ran poisoned tool descriptions against 45 real MCP servers and 20 leading AI models. The attack succeeded at rates as high as 72.8 percent. The models almost never refused the embedded instructions. The benchmark’s conclusion is that the attack is broadly effective across the current generation of deployed AI agents rather than being specific to any one model or platform.

What Defenders Can Do

Microsoft’s guidance translates into five operational controls, separated from the Microsoft product recommendations that accompany them.

Treat connected tools as supply chain components. Maintain an explicit allowlist of approved tool publishers. Disable permissive defaults that allow agents to use any available tool. Each agent should be restricted to the specific tools it needs for its defined task.

Review tool description changes the same way you review code. A change to a tool description is a change to an instruction the agent will receive. It should go through the same approval process as a system prompt modification or a configuration update. Automated scanning for command-like content in description fields can catch obvious cases.

Put humans in front of risky actions. Any agent action that moves money, shares data outside the organisation, or modifies accounts should require explicit human approval before it executes. This is the control that would have broken the finance workflow attack: the exfiltration step would have required a human to approve an outbound data transfer they never explicitly requested.

Give each agent its own identity and audit its actions. Agent behaviour should be logged at the action level, not just at the request level. Baseline what each agent normally does and flag deviations: new outbound endpoints, data volumes larger than typical, queries outside the agent’s normal operational scope.

Apply least agency, not just least privilege. Least privilege limits what a credential can access. Least agency limits what an agent is permitted to do. Even an agent running with minimal account permissions can exfiltrate significant data if it can act autonomously on the results of queries it is legitimately allowed to run. Constraining the action space, not only the access scope, is the distinct control that agentic deployments require.

Microsoft maps each of these to specific product controls including Prompt Shields, Purview DLP, Entra Agent ID, Defender for Cloud Apps, and Sentinel. The underlying principles hold regardless of platform.

The Trust Model Problem

What Microsoft’s research identifies is not a bug to patch. It is a trust model that most enterprise AI deployments have not yet built. When an organisation approves an MCP tool, it is implicitly authorising the description that tool provides as a source of instructions for its agents. That authorisation persists through every subsequent change to the description.

Organisations adding agentic AI to their workflows are, in most cases, operating without any mechanism to detect when an approved tool’s instruction content changes. The attack surface is growing faster than the monitoring infrastructure around it.

The MCPTox numbers make clear that waiting for a vendor-level fix is not a viable posture. Models will not reliably refuse these instructions. The control has to come from the human layer, before the agent acts.