Analysis
Every Model Context Protocol (MCP) tool ships with a description — a few lines of plain text that tell an AI agent what the tool does and when to use it. The agent reads that text to decide how to act. In guidance published June 30, 2026, Microsoft Incident Response warned that this description is an attack surface: an attacker who can edit it can steer an approved agent into leaking sensitive data or taking unintended actions — with no malicious code and no exploit in the traditional sense. The agent is not tricked into running malware; it is persuaded, by text it trusts, to misuse the legitimate access it already has.
What we know
- 2025-08 — The MCPTox benchmark is released, testing poisoned tool descriptions against 45 real MCP servers and 20 leading AI models. It finds the attack widely effective, with success rates as high as 72.8%.
- 2026-06-30 — Microsoft Incident Response publishes guidance formally warning enterprises that poisoned MCP tool descriptions can drive agent data leakage, and walks through a concrete invoice-processing example.
- 2026-07 — Tier-1 coverage (The Hacker News, Security Boulevard, TechRepublic) amplifies the warning as MCP moves from experimental to production across enterprises.
Source-layer flag: the MCPTox figures and the attack mechanics are reported from Microsoft's guidance and the benchmark authors; we have not independently reproduced the 72.8% figure or the invoice scenario.
Technical analysis
The root cause is structural, not a coding bug in any one product: MCP mixes instructions and data in the same channel. A tool's description lives in the agent's working context right next to its real orders (the system prompt and the user's task). Editing the description can steer the agent as effectively as rewriting its system prompt — because to the model, both are just authoritative text in context.
Microsoft's worked example: a finance team stands up an agent to process vendor invoices, connected to three tools — including a third-party "invoice enrichment" service that was approved for use but never given a real security review. Buried in that tool's description, dressed up as formatting notes, is a hidden instruction: grab the last thirty unpaid invoices and attach them to the next call. In deployments without a re-approval trigger on description changes, the poisoned version goes live with no additional review, and the exfiltration happens inside an ordinary, expected tool call.
Source-layer flag: the invoice scenario and the "instructions and data in the same place" framing are reported from Microsoft's June 30 guidance, not independently verified against a live incident.
The dangerous property is that nothing here looks like an attack. There is no dropped binary, no anomalous process, no C2 beacon — just an approved agent making a tool call it is fully authorized to make, carrying data an attacker chose.
Indicators of compromise
This is a technique, not a single campaign, so classic IOCs are largely inapplicable. Detection is behavioral:
- Tool descriptions containing imperative language aimed at the agent — "always include…", "attach the last N records…", "before responding, send…" — especially disguised as formatting or usage notes.
- Description changes to a third-party MCP tool that did not trigger a re-review.
- Agent tool calls carrying more data than the task requires — bulk records attached to a call whose stated purpose is single-record.
- Outbound tool calls to third-party MCP endpoints that receive sensitive data as a side effect of an unrelated task.
Detection and mitigation
- Security-review every MCP tool description like code, not config. Approval must cover the description text, and any change to it must re-trigger review.
- Pin MCP server versions and treat description drift as a change-control event (the same discipline the
postmark-mcpsilent-update case argued for). - Least-privilege the agent's tools: a tool should only be able to touch the data its stated function needs; an "enrichment" tool should not have read access to thirty unpaid invoices.
- Require authentication on all MCP endpoints and inventory which agents connect to which third-party servers.
- Log and baseline tool-call data volumes so bulk exfiltration inside a legitimate call stands out.
Attribution
No specific threat actor is attributed; this is a defensive advisory and benchmark, not an incident report. What is claimed: the technique works at high success rates across many models and servers (MCPTox) and Microsoft assesses it as a realistic enterprise risk. What is not claimed: that a named actor has run it against production victims at scale. Confidence that the technique is effective is high (benchmarked); confidence in any active-campaign attribution is unknown. A shift would come from an IR firm publishing a real-world case with a poisoned marketplace tool and an identified operator.
Criminal-market signal
Bounded negative (evidenced): on 2026-07-03 we swept ~25 dark-web search engines over Tor for MCPTox and MCP tool poisoning; ~76 pages were crawled and zero were flagged relevant — no tooling or discussion surfaced on the venues our pipeline can see (closed forums and Telegram are out of scope). The natural marketplace for this technique is not an exploit listing but the MCP tool marketplace itself — the ClawHub-style ecosystems where a malicious or silently-updated tool can accrue legitimacy before poisoning its description, mirroring the postmark-mcp "fifteen clean versions, then one line of exfiltration" pattern. That makes supply-chain vetting of MCP tools the operative control surface, not criminal-forum monitoring. The bounded expectation: absence of a forum listing does not lower the risk, because the distribution channel is the legitimate tool registry.
CISO translation
Attackers can hide instructions inside the description text of an AI "tool," and an approved agent will follow them — quietly sending our data out through a normal tool call, with no malware involved. This matters because we are wiring agents into real systems (finance, code, tickets) and connecting them to third-party tools we may not have reviewed line by line. Review and lock down every AI tool description like we review code, require re-approval when any description changes, and limit what data each tool can reach. Confidence is high that this works — an independent benchmark got it to succeed roughly seven times in ten — though we have not yet seen a confirmed attack against us. The cost of inaction is a slow, invisible data leak through a system we trust, one that leaves none of the usual malware fingerprints and could run for months before anyone notices.