MCP Tool Poisoning

What is MCP tool poisoning?

The Model Context Protocol (MCP) lets AI agents call external tools. Every tool ships with a description that tells the model what it does and when to use it. Tool poisoning abuses that description as an instruction channel.

An attacker writes a tool whose visible name and summary look ordinary, such as a calculator or a text formatter. The description itself carries directives aimed at the model, instructing it to read a specific file, append the contents to a parameter, and stay quiet about doing so. The model treats the whole description as trusted context and complies.

This gap is what makes the attack work. As Invariant Labs put it, "AI models see the complete tool descriptions, including hidden instructions, while users typically only see simplified versions in their UI." You approve a math tool, and the model reads a paragraph of attacker prose that your interface never rendered.

How does the attack actually work?

Invariant's proof-of-concept, published April 1, 2025, was an add(a, b) tool. The arithmetic genuinely worked. Buried in its description was an instruction to read ~/.cursor/mcp.json and ~/.ssh/id_rsa before running, place their contents into a parameter called sidenote, and wrap the result in a plausible math explanation so nothing looked wrong. Pointed at Cursor, a mainstream MCP client, the tool exfiltrated those files.

No memory was corrupted and no CVE was involved. The tool used the model's instruction-following exactly as designed, which is what makes it hard to catch. The payload is ordinary English, so scanners built to find malicious binaries pass right over it. The practical consequence is that you have to treat the description field as untrusted input rather than documentation you can skim.

What are tool shadowing and rug pulls?

Invariant's reproduction repo ships three variants.

• Direct tool poisoning: the SSH-key leak described above.
• Tool shadowing: a malicious server's tool description changes how the model uses a different, trusted server's tool. Their example silently redirects every outgoing email to an attacker address while the trusted email tool appears untouched.
• Sleeper rug pull: the server behaves normally on first load, earns approval, then swaps in malicious tool definitions on a later load. Their WhatsApp demo combines shadowing with a rug pull to pull chat history and leak it, hiding the stolen data behind a wall of spaces so it scrolls off screen.

A rug pull adds a time dimension: the definition you approved is not the definition you later run. That is why both the MCP spec and OWASP recommend pinning and version-controlling tool definitions and re-checking integrity on every update.

Is it just the description field?

It is not. CyberArk research titled "Poison everywhere: No output from your MCP server is safe" (2025) widened the boundary.

CyberArk names this Full-Schema Poisoning (FSP): any part of the tool schema, not just the description, is a viable injection point. Tool names, parameter names, default values, and type fields all qualify. They also flag a distinct output (runtime response) poisoning vector, where the data a tool returns carries the payload rather than its definition. The practical takeaway is that sanitizing one field is not enough. Every string an MCP server can put in front of the model is attack surface, including the ones you might file under plumbing.

Has MCP tool poisoning happened in the wild?

Yes. The clearest case is postmark-mcp. In September 2025 someone published an npm package that copied the name of Postmark's official MCP server. Version 1.0.16, published September 17, 2025, added a single line (which Koi Security places around line 231) that BCC'd every outbound email to phan@giftshop[.]club. Koi caught it and disclosed in late September. Koi estimates the package saw roughly 1,500 weekly downloads and reached around 300 organizations, and those figures are Koi's estimates rather than a measured victim count. When Koi contacted the publisher, the package was deleted instead of explained. Koi describes it as the first publicly documented malicious MCP server caught in the wild.

Separately, Invariant Labs disclosed in May 2025 that the official GitHub MCP server could be coerced, through a prompt injection planted in a public GitHub Issue, into leaking data from a user's private repositories. Invariant's own writeup, published May 26, 2025, is the primary source, and GitHub issue #844 tracks the disclosure. Invariant framed it carefully: this is not a code bug in the server but an architectural weakness of agent-plus-MCP designs, and even strong models fell for it. Their recommended mitigations were direct: one repository per session, and least-privilege tokens.

The categories are worth keeping straight. postmark was a real backdoor shipped to real users. The add(a, b), WhatsApp, and CyberArk demonstrations are proofs-of-concept. The GitHub case sits between the two: a real, responsibly disclosed flaw on the actual official server.

How widespread is the exposure beyond named incidents? Academic work has started to measure it. The MCPTox benchmark fires tool-poisoning payloads at real-world MCP servers and finds the problem is broad rather than a handful of one-offs. So this is a measured, active threat, not a researcher's parlor trick.

What do the MCP spec and OWASP say?

The official MCP specification (revision 2025-11-25) is direct about the risk. Under tool safety it states that "Tools represent arbitrary code execution and must be treated with appropriate caution," and that "descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server." It also says hosts "must obtain explicit user consent before invoking any tool," and note that this line lives in the narrative principles as a lowercase must, not an all-caps RFC-2119 mandate. MCP cannot enforce any of this at the protocol level, so the burden falls on host and client implementors. The spec also requires OAuth 2.1 for authorizing remote MCP servers, an authorization framework that MCP first adopted in its earlier 2025-03-26 revision rather than this one.

OWASP addresses tool poisoning in two separate documents that are easy to conflate. The MCP Top 10, still a beta project rather than a finalized standard, lists MCP03:2025 Tool Poisoning, framing the attack as tampering with the schema definitions that govern agent-to-tool interactions. Its mitigations form a checklist: sign schemas and verify signatures before use, keep immutable version-controlled schema repositories with required approvals, enforce least-privilege with separated proposal and approval roles, encode semantic constraints as policy-as-code (OPA/Rego), attach provenance metadata, and require human approval for high-risk actions at runtime.

The second document is the OWASP Top 10 for Agentic Applications (2026), a released standard published by the OWASP GenAI Security Project in December 2025, with categories ASI01 through ASI10. Tool poisoning maps to ASI01 Agent Goal Hijack, where hidden instructions redirect the agent's goal. It is typically delivered through an ASI04 Agentic Supply Chain vector, meaning an untrusted or mutated server, and it often cascades into ASI02 Tool Misuse when the hijacked agent turns your trusted tools against you.

MCP tool poisoning best practices: how to prevent it

These recommendations are distilled from the primary sources.

• Treat all tool metadata and all tool outputs as untrusted. That covers names, descriptions, annotations, parameters, defaults, errors, and returned data, following CyberArk's point.
• Review tool definitions like code. Read the full description, not the friendly UI summary. Invariant released the open-source mcp-scan to scan servers for embedded instructions; use it, and still read the definitions yourself.
• Pin and integrity-check. Version-lock schemas, sign them cryptographically where you can, and verify signatures before use so a rug pull triggers an alarm instead of quiet trust.
• Surface the real description in your UI. The attack depends on you not seeing what the model sees, so closing that gap removes much of the leverage.
• Require explicit human consent before invocation and for any high-risk action, as the spec recommends.
• Use least-privilege scoped tokens and data-flow isolation between servers, so a shadowing tool on server A cannot quietly drive server B.

This is an engineering threat model rather than a full security program, so treat the list as a starting checklist and not a complete audit.

Govern the data plane, not just the agent

Every defense above aims to stop the agent from doing the wrong thing. Pair that with a second question: what can the agent reach in the first place? If a poisoned description talks your agent into reading a customer table, the blast radius depends entirely on what sits in that table.

This is where DataShield fits. Tokenize sensitive fields at ingest, so a hijacked agent that exfiltrates a column leaves with tokens rather than raw PII. Authorize per tool call against real policy with mid-session revocation, so a rug pull that flips a tool malicious mid-session is cut off instead of trusted. Seal every call into a tamper-evident audit chain you can verify after the fact at /verify. Govern the data plane and an ASI01 hijack degrades into a logged, low-value event rather than a breach. For the broader server-hardening picture, see the sibling guide on MCP server security.

Watch: MCP tool poisoning and agent security

A short walkthrough of the attack, plus two overviews of where it fits in MCP security.

▶

How tool poisoning works, a walkthrough (sublimetechie)

▶

MCP security risks explained (Tenable)

▶

Why MCP security is still hard (Prompt Engineering)

The short version

Tool poisoning is prompt injection delivered through a tool definition. The malicious instructions sit in metadata you rarely inspect, while the model reads all of it. Two fixes hold up over time: stop trusting metadata you have not verified, and make the underlying data worthless to anyone who manages to walk off with it.

Frequently asked questions