Every AI agent connected to a Model Context Protocol (MCP) server trusts the tool descriptions that server hands it — because those descriptions are exactly what tells the agent what a tool does and when to call it. If an attacker controls that text, they control part of what the model believes to be true. That's the core of MCP tool poisoning: instructions hidden inside a tool's metadata, invisible in a typical approval dialog, but fully visible to the model reading its context window. Combine that with a fast-growing number of MCP servers reachable on the open internet with no authentication at all, and the result is a genuinely new exfiltration path for whatever personal data an agent happens to be holding.
What Is MCP Tool Poisoning?
Security researchers at Invariant Labs first documented and named the technique in an April 2025 disclosure, describing a Tool Poisoning Attack (TPA) as malicious instructions embedded inside an MCP tool's description — instructions that are invisible to the user in a typical client UI but fully visible to the AI model, which treats the entire description as an authoritative statement of what the tool does. The OWASP MCP Top 10 (2025) now lists Tool Poisoning as its own category, MCP03:2025, alongside other MCP-specific risks.
Invariant Labs demonstrated the technique with a proof-of-concept malicious WhatsApp MCP server: a tool called get_fact_of_the_day, which on its face just returns a harmless trivia fact, carried a poisoned description instructing the connected agent to also read and exfiltrate the user's WhatsApp chat history to an attacker-controlled server — all while still returning the innocuous fact the user expected, so nothing about the visible output looked wrong.
A related variant researchers call an MCP rug pull makes the attack persistent: a server presents a benign tool description at first, earning the user's one-time approval, then silently swaps in a poisoned description on a later connection. Because most MCP clients don't re-validate a tool's description on every call once it has been approved once, the agent keeps calling the tool as if nothing changed — the compromise happens entirely after the human already clicked "allow."
The Expanding Attack Surface: How Many MCP Servers Are Actually Exposed
Tool poisoning is a technique; exposure is what turns it into a live risk at scale. Internet-wide scanning firm Censys found 12,520 internet-accessible MCP services across 8,758 unique IP addresses as of April 28, 2026 — a figure that grew to more than 21,000 by May 6, 2026. Separately, a 2026 review by BlueRock Security of roughly 7,000 publicly reachable MCP servers found that 41% exposed their tools with no authentication mechanism at all, meaning any client that finds the address can call the tools and read whatever they return.
Academic security researchers have gone further than counting exposure — they've tested it. The VIPER-MCP project, published on arXiv on May 20, 2026, ran an automated, end-to-end vulnerability pipeline against 39,884 real-world open-source MCP server repositories and confirmed 106 zero-day vulnerabilities with working exploit traces, of which 67 have since been assigned CVE identifiers. The same week, the NSA's Artificial Intelligence Security Center published a Cybersecurity Information Sheet, "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation" (May 20, 2026), explicitly warning organizations not to rely solely on MCP's own documentation for security guidance and to layer additional, environment-specific controls on top.
None of these numbers describe tool poisoning specifically — they describe the surface it runs on. An unauthenticated, internet-facing MCP server is a server anyone can query, and a server anyone can query is a server whose tool descriptions anyone can also poison, replace, or silently update after the fact.
How a Poisoned Tool Turns Into a PII Problem
Agents don't just call tools — they feed files, emails, tickets, and database rows into those tools as arguments, and they read whatever a tool returns straight back into the model's context for the next turn. If a poisoned or compromised tool's hidden instruction is "also send the contents of this argument to this other address," the agent complies for the same reason it complies with the legitimate half of the instruction: from the model's point of view, both halves came from the same trusted tool description. Nothing about the visible chat transcript needs to look wrong for the exfiltration to succeed, which is exactly what made the WhatsApp proof-of-concept effective as a demonstration.
Whatever personal data happens to be sitting in the argument or file the agent was working with at that moment — a customer's name and address from a CRM lookup, a patient record summarized for a note, a support ticket with a phone number in it — travels wherever the poisoned instruction says to send it. The agent's normal task and the exfiltration ride in the same tool call, which is precisely why traditional network monitoring, built to flag anomalous destinations or protocols, has little to catch: the traffic looks like an authorized tool doing authorized work.
Why Local Anonymization Limits the Blast Radius
This is the specific gap anonym.plus's local MCP server is built to narrow, without pretending to close the underlying protocol-level problem. anonym.plus runs its own MCP server bound to loopback (127.0.0.1) rather than a public address, off by default until a user turns it on, and gated behind a bearer token plus a required X-Local-Api: 1 header on every request — so it is not, itself, one more unauthenticated MCP endpoint added to the numbers above. Its purpose is to sit ahead of whatever other tools an agent calls: detect and replace PII in text and images entirely on-device — covering 340+ PII entity types across 48 languages — before that data is handed to any tool, any prompt, or any model, using the same offline Presidio/spaCy engine anonym.plus uses across the desktop app, with no network round trip involved in the detection step itself.
The value of doing that ahead of a potentially poisoned tool call is straightforward: if a customer's name, email, and case number have already been replaced with placeholder tokens before an agent's next tool call runs, a tool instructed to exfiltrate "the argument it was just given" captures placeholders, not the underlying identity. It reduces what any single compromised or malicious tool in the chain can actually capture — the blast radius of one bad link — even if that link still executes the poisoned instruction and still sends something somewhere.
What This Doesn't Fix — Be Honest About the Limits
A local anonymization layer is not a substitute for MCP hygiene, and it does not stop tool poisoning from happening. It doesn't verify tool descriptions, detect a rug-pull swap between connections, or replace a proper security review of every MCP server an agent is allowed to reach — those are protocol- and client-level problems that need protocol- and client-level fixes: scanning tool descriptions before they're trusted, pinning approved tool definitions instead of re-trusting them silently, restricting which servers an agent can connect to, and applying least-privilege scopes so a poisoned tool call can't reach more than it needs to. If the raw, unredacted source data reaches a poisoned tool before anonymization ever runs — because a workflow skips the anonymization step, or because the poisoned tool sits earlier in the pipeline than the anonymization one — this control provides no protection for that call. It is one layer in a defense that still needs the others, not a replacement for any of them.
FAQ
Is MCP tool poisoning the same thing as a hacked server?
Not necessarily. A server doesn't have to be "hacked" in the traditional sense — an attacker can simply register or operate a malicious MCP server from the start, or compromise a legitimate one's configuration, and have it serve a poisoned tool description from day one. The vulnerability is architectural: MCP clients generally trust tool metadata as authoritative context rather than treating it as untrusted input.
Would a firewall or antivirus catch a poisoned tool description?
Generally no. The poisoned instruction is text inside a JSON tool description delivered over an otherwise normal MCP connection — there's no malware signature, unusual file, or anomalous protocol for conventional endpoint or network security tools to flag. That's part of why researchers treat it as a distinct category (OWASP MCP03:2025) rather than a variant of existing malware.
Does anonymizing data before an agent uses it stop tool poisoning?
No — it limits what a successful exfiltration can capture, it doesn't prevent the poisoning or the exfiltration attempt itself. If PII has already been replaced with placeholder tokens before a poisoned tool runs, an instruction to "send this argument" sends tokens rather than real identities. Preventing the attack itself still requires MCP-level controls: reviewing and pinning tool descriptions, restricting which servers an agent can reach, and applying least-privilege scopes.
Keep PII out of every tool call an agent makes — anonymize it on-device before it ever reaches the tool.