When agents move from reading to acting: MCP tool-description poisoning

What is this?

On June 30, 2026, Microsoft Incident Response published Securing AI agents: When AI tools move from reading to acting, the third post in its AI Application Security series. Its argument is a threat-model shift rather than a single bug: as enterprise agents graduate from summarizing content to taking action — sending mail, updating records, calling business systems through the Model Context Protocol (MCP) — the impact of prompt injection changes shape. A poisoned input against a passive summarizer biases an output; the same class of manipulation against an action-taking agent triggers an action.

The concrete mechanism Microsoft walks through is MCP tool-description poisoning, a technique first flagged by Invariant Labs in April 2025 and, per Microsoft, increasingly observed against production agents in 2026. It maps to two categories of the OWASP Top 10 for Agentic Applications released in December 2025: ASI02 (Tool Misuse) and ASI04 (Agentic Supply Chain Vulnerabilities).

How it works

An MCP tool ships with a natural-language description — the metadata an agent reads to decide how and when to call that tool. Crucially, MCP blends this metadata with data in the same context window: the description sits in the agent’s working memory next to its real instructions, and the model has no reliable way to tell an honest instruction from a malicious one an upstream maintainer slipped in.

Microsoft’s walkthrough follows a finance workflow. A team builds an agent that connects to three tools: an approved vendor database, a mail connector, and a third-party “invoice enrichment” server that was reviewed by a service owner but never given a separate security review. The chain then unfolds in four stages, and no exploit payload is reproduced here:

1. Description poisoning. The enrichment server’s maintainer pushes an update. The tool name and user-facing summary stay identical, but the description is silently rewritten to embed hidden instructions — framed as a “fraud-heuristic requirement” — telling the agent to collect recent unpaid invoices and attach them to the enrichment call.
2. Silent re-trust. MCP reflects metadata updates dynamically. Where a description change does not trigger re-approval, the poisoned text goes live in production with no review.
3. Invocation. An analyst asks a routine supplier question. The agent, reading the poisoned description, gathers sensitive records beyond the request’s scope and forwards them as a normal-looking parameter.
4. Exfiltration. The server returns a plausible “validated” response and quietly logs the attached data to an attacker endpoint. The analyst sees a clean answer; in default configurations, no alert fires.

Every individual step is within the agent’s normal parameters. The MCPTox benchmark — 45 live MCP servers and 353 authentic tools — measured attack success rates above 60% on many popular agents, peaking around 72%.

Why it matters

What makes this effective is that there is no vulnerability in any single component. The tool was approved, the database query inherited the analyst’s own permissions, and the outbound call went to a server that was allowlisted when it was added. The weakness lives in the trust boundary between systems, not inside them — which is why default logging often stays quiet and why the pattern sidesteps a user, a prompt, and a credential all at once. As Microsoft notes, IDC projects active enterprise agents growing from 28.6 million in 2025 toward billions by 2030; every one of them inherits its tool supply chain as attack surface.

Defenses

Microsoft’s guidance distills to three principles that generalize beyond its own stack:

Treat every MCP server as part of the supply chain. Keep a tenant-level allowlist of approved publishers and servers, disable “allow all” tool access, enable only the specific tools an agent needs, and require a documented owner for any third-party server before production use.

Treat tool descriptions as system prompts. Because the model reads tool metadata as working context, a change to that metadata is equivalent to a change in the agent’s instructions. Put tool-description updates through the same change review as a code or system-prompt change, and scan the text for imperative language that has no business in a documentation field.

Apply least agency, not just least privilege. Even a minimally permissioned agent can do damage if it has too much autonomy. Require human-in-the-loop approval for high-impact actions (financial access, external sharing, account changes), give each agent its own non-human identity with conditional access, inspect tool-call parameters with data-loss-prevention policies, and baseline normal agent behavior so new endpoints, expanded parameters, or unusual queries raise alerts. Red-team the agent against poisoned metadata before deployment, not after.

Status

Item	Reference	Notes
Microsoft IR guidance	Microsoft Incident Response, 2026-06-30	”Reading to acting” threat-model shift; finance-workflow attack pattern
Technique origin	Invariant Labs tool-poisoning notification, 2025-04	First public disclosure of MCP tool-description poisoning
Framework mapping	OWASP Top 10 for Agentic Applications, 2025-12	ASI02 Tool Misuse, ASI04 Agentic Supply Chain
Empirical evidence	MCPTox benchmark	45 servers, 353 tools; success rates >60%, peak ~72%
Exploitation in the wild	Per Microsoft, observed 2026	No specific victim organization disclosed

The durable lesson is that autonomy, not permission, is the variable that turns an injected instruction into an incident. Prompt injection into an agent’s context — including via the tools it trusts — should be assumed possible; the defense is to constrain what a hijacked agent is allowed to do next.