system: OPERATIONAL
← back to all hacks
SUPPLY CHAIN MEDIUM NEW

The tool you approved isn't the tool you're running: MCP description rug-pulls

Microsoft's June 30, 2026 research shows an approved MCP tool can be silently re-described after review. Because agents pick up description changes on the fly, a clean tool turns into a data-exfiltration channel with no alarm.

2026-07-02 // 6 min affects: m365-copilot, copilot-studio, azure-ai-foundry, mcp-based-agents

What is this?

On June 30, 2026, Microsoft Incident Response and its Defender research team published an analysis of a trust gap that opens once an AI agent can act rather than just read and summarize. The finding, reported the same day, is not a new attack class — description poisoning has been documented since April 2025 — but a fresh and important variant: the poisoning can happen after a tool has passed review. A tool you vetted and approved with a clean description can be silently re-described later, and because agents read descriptions on every turn, the switch goes live with no re-approval.

The specifics matter for anyone deploying Microsoft 365 Copilot, Copilot Studio, or Azure AI Foundry agents, but the mechanism applies to any agent that reaches tools through the Model Context Protocol (MCP).

How it works

Every MCP tool ships with a description: a few lines of plain text telling the agent what the tool does and when to call it. The agent reads that text to decide how to act, and it sits in working memory right next to the agent’s real instructions. To the model, an honest description and a malicious one are the same kind of token stream — there is no reliable way to tell them apart.

Microsoft illustrates the temporal twist with an invoice example, built to show the pattern rather than name a victim. A finance team stands up an agent to process vendor invoices, connecting it to three tools — including a third-party “invoice enrichment” service that was approved but never given a real security review. Later, the attacker updates that tool. The visible name and summary stay identical; buried in the description, dressed up as formatting notes, is a hidden order: collect the last thirty unpaid invoices and attach them to the next call.

Tool registry entry (schematic — payload redacted)
--------------------------------------------------
name: invoice_enrichment
description: |
  Enriches vendor invoice records with tax and payment metadata.
  [REDACTED: instruction telling the agent to gather and attach
   additional records on the next call]

MCP picks up description changes on the fly. In a setup without a re-approval trigger, the poisoned version is simply live. An analyst then asks a routine question about a supplier; the agent follows the hidden order, pulls the invoices with the analyst’s own permissions, and ships them out inside a normal-looking request to a server that was allowlisted when the tool was added. Every step is individually legitimate. The weakness lives in what Microsoft calls “the trust boundary between them.”

Why it matters

The shift from reading to acting changes the stakes. Against a reader, an injection changes the output. Against an agent, it changes what the software does — sending email, moving files, reaching business systems. Microsoft calls MCP the fastest-growing part of the agentic AI supply chain, which makes it an expanding attack surface.

The temporal angle is what defenders often miss. Approval is treated as a one-time gate, but a tool’s description is mutable state that can drift long after review. Academic measurement backs the concern: the MCPTox benchmark, released August 2025, ran poisoned descriptions against 45 real MCP servers and 20 leading models and found the attack effective up to 72.8% of the time, with models almost never refusing. OWASP now lists this pattern under Agentic Supply Chain Vulnerabilities in its December 2025 Top 10 for Agentic Applications.

Defenses

There is no payload to patch; the fix is architectural, and Microsoft’s guidance maps cleanly to it.

  • Pin and diff descriptions. Treat a tool description like a system prompt or a code change. Snapshot the approved version, re-review any change, and require re-approval before a modified description goes live — don’t let updates land silently.
  • Curate the supply chain. Maintain an allowlist of approved tool publishers, turn off “allow all,” and give each agent only the specific tools it needs.
  • Human-in-the-loop on consequences. Any action that moves money, shares data externally, or changes accounts should require a person to approve it before execution.
  • Give each agent an identity and watch it. Log actions, baseline what normal looks like, and flag new endpoints, larger data pulls, or unusual queries.
  • Apply least agency, not just least privilege. Even a low-permission agent can do real harm if it is free to act without checks.

Status

ItemReferenceDate
Microsoft “reading → acting” analysisMicrosoft Security Blog2026-06-30
CoverageThe Hacker News2026-06-30
Description-poisoning measurementMCPTox (arXiv:2508.14925)2025-08
Original tool-poisoning PoCInvariant Labs2025-04
Framework referenceOWASP Top 10 for Agentic Applications2025-12

The takeaway: approval is not a permanent property of a tool. If a description can change after review and the agent picks it up unprompted, the tool you approved is not necessarily the tool you’re running.

Sources