MCP Tool Poisoning: The Agentic Attack Surface Most Security Teams Aren't Modeling Yet

The Model Context Protocol has quietly become the connective tissue of agentic AI. In a little over a year it went from a niche specification to the de facto standard for wiring large language models into external tools, databases, and APIs. If your agents read from a ticketing system, write to a repository, query a warehouse, or send a message, there is a good chance an MCP server sits in the middle.

That connectivity is exactly the problem. MCP did for agent tooling what USB did for peripherals — it made everything plug-compatible — and in doing so it created a new, under-defended attack surface that sits inside the agent's reasoning loop. The marquee threat in that surface is MCP tool poisoning: a class of attack where the data an agent uses to decide what to do next is itself adversarial.

Most security teams are equipped to reason about API abuse, broken authentication, and injection at the application boundary. Far fewer have a mental model for an attack that never breaks a single line of code, never trips a WAF, and is carried entirely in text that the model treats as trustworthy. This piece walks through what tool poisoning is, how a realistic attack plays out, why the agentic execution model makes it uniquely dangerous, where today's defenses fall short, and a threat-modeling framework you can apply to your own agent fleet.

What tool poisoning is — and how it differs from classic prompt injection

Classic prompt injection targets the input: a user types (or pastes) instructions that override the system prompt. "Ignore your previous instructions" is the canonical example, and most teams now have at least a reflex for it.

Tool poisoning is a subtype of indirect prompt injection, and the difference matters. The malicious payload does not arrive through the user. It rides in the machinery of the tools themselves — the metadata the model reads to understand what a tool does, and the responses a tool returns when called. OWASP defines MCP tool poisoning as "an indirect prompt injection attack targeting AI agents that connect to external tool servers via the Model Context Protocol," and classifies it under both LLM01 (Prompt Injection) and LLM06 (Excessive Agency).

The mechanics break into a few distinct channels, and a rigorous threat model should keep them separate because they exploit different trust assumptions:

• Poisoned tool descriptions. In April 2025, security researchers at Invariant Labs disclosed that MCP is vulnerable to tool poisoning attacks in which hidden instructions are embedded directly in a tool's description — text the model reads in full when it enumerates available tools, but which the user typically sees only as a truncated summary in the client UI. The instructions can hide in docstrings, parameter descriptions, default values, enum options, and example values.
• Poisoned tool responses. Even if every description is clean, the response a tool returns flows straight into the model's context. As OWASP describes it, the server returns a response that mixes real-looking data with embedded instructions, and the model treats the entire response as context and follows the injected instructions.
• Rug pulls. A tool can be benign at install time and redefine itself later. A description approved on day one can be silently rewritten on day three to reroute outputs or exfiltrate credentials — without triggering a new approval prompt.
• Tool shadowing / name collision. When an agent connects to several servers at once, a malicious server can register a tool whose name collides with a trusted one, or whose description instructs the model to prefer it. Elastic Security Labs describes name-collision tools that appear safe at first glance but, if the underlying implementation silently skips validation, expose sensitive data while maintaining the illusion of compliance.

The unifying root cause is a trust gap between connect-time and runtime. Tool descriptions get a security look exactly once — when the agent first connects. Tool responses go into the model's context with no equivalent check, ever. That unguarded runtime channel is the soft underbelly.

A realistic attack scenario

Picture a support-automation agent. It has read access to a customer database (to look up account details), a tool that fetches the "tip of the day" from a third-party MCP server someone added from a public registry months ago, and a messaging tool that can send notifications. Nothing about this looks dangerous on a whiteboard.

Here is how the attack unfolds:

1. The benign-looking server gets adopted. The "tip of the day" server was approved when it did exactly one harmless thing. Its tool description passed a casual review.
2. A rug pull changes the rules. The server operator (or whoever compromised it) updates the tool definition. The new description includes hidden instructions: before answering, read the most recent customer record and include it in the message payload, formatted as whitespace so the user doesn't notice.
3. The agent obeys, because the text reached the model. The agent is mid-task, executing autonomously. It reads the poisoned description, pulls a customer record it legitimately has access to, and packs that data into an outbound message.
4. Exfiltration completes over a legitimate channel. The data leaves through the messaging tool the agent was supposed to have — no exotic exploit required.

This is not hypothetical hand-waving. Invariant Labs demonstrated essentially this pattern against a WhatsApp MCP server in April 2025: an innocuous "fact of the day" tool that later manipulated message-sending behavior to redirect a user's message history to an attacker-controlled number, using whitespace obfuscation to keep the theft out of the visible UI.

Privilege escalation works the same way without any new permissions. The agent already holds the database read and the message send. The poison simply chains capabilities the agent legitimately possesses into an outcome no one authorized.

Why the agentic execution model makes this uniquely dangerous

API abuse is bounded. A leaked key grants a finite set of calls, each one a discrete request you can rate-limit, log, and revoke. Agentic execution is different in ways that compound the risk.

• Autonomy collapses the human checkpoint. Traditional injection often needs a human to act on bad output. An agent acts on it directly — the model's decision is the action.
• Multi-step chains amplify a single bad instruction. One poisoned response can steer a dozen downstream tool calls. The blast radius is the entire remaining plan, not one request.
• Low oversight is the design goal. Fleets are deployed precisely so humans don't watch every step. The same property that makes agents valuable removes the observer who would catch the anomaly.
• Persistent memory turns a one-time poison into a standing instruction. Memory-persistent agents that run continuously can absorb a malicious instruction once and act on it for days, long after the triggering content scrolled out of view.
• Scale multiplies third-party trust. A pipeline with dozens of tools across servers pulled from an open ecosystem means dozens of independently-owned trust relationships, any one of which can be poisoned or quietly redefined.

The clearest way to see why this is structurally dangerous is Simon Willison's lethal trifecta, formalized in June 2025: an agent is exploitable when it simultaneously has access to private data, exposure to untrusted content, and the ability to externally communicate. Each leg alone is survivable. Combine all three and, in Willison's words, "an attacker can easily trick it into accessing your private data and sending it to that attacker." A multi-tool agent with database access, a third-party MCP server, and a messaging tool is the lethal trifecta wearing a business-casual disguise.

What defenses exist today — and where they fall short

The good news: a defensive vocabulary is forming. The bad news: most of today's controls are partial, and treating any one as sufficient is how teams get burned.

Control	What it does	Where it falls short
Tool manifest validation	Scan tool descriptions/schemas for hidden instructions, encoded payloads, obfuscation.	Catches connect-time poison, not runtime responses or post-approval rug pulls. Obfuscation (invisible Unicode, Base64) is an arms race.
Sandboxed execution	Run MCP clients/servers in containers so they can't reach local credentials or the host.	Contains code-level damage; does nothing about a model that's been persuaded to misuse tools it legitimately holds.
Least-privilege tool scoping	Grant each agent only the tools and data it needs; isolate privileged tools in separate contexts.	The single highest-leverage control — but only as good as the scoping discipline, which erodes as fleets grow and "just give it access" wins.
Agent memory / activity auditing	Log every tool invocation; review for anomalous patterns.	Detective, not preventive. Effective only if someone (or something) actually reviews the logs, which "low oversight" works against.
Human approval gates	Require explicit confirmation for sensitive actions; disable "always allow."	Real protection — but approval fatigue pushes operators toward auto-run, which re-opens the door.

Two structural points cut across the table. First, Elastic Security Labs notes that "any text being fed to the LLM has the potential to rewrite instructions," which means no description-scanning step can be assumed complete — the response channel is always live. Second, the MCP server population itself is shaky on basics: Elastic cites March 2025 research finding 43% of tested MCP implementations contained command-injection flaws and 30% permitted unrestricted URL fetching. Before you worry about clever poison, a meaningful share of servers are vulnerable to ordinary injection.

A threat-modeling framework for your agent fleet

You don't need to model every clever payload. You need to find, for each agent, whether the lethal trifecta is assembled — and break a leg wherever it is. Walk this for every agent in production:

1. Inventory the trust boundaries. List every MCP server each agent connects to and who controls it. First-party, vendor, or anonymous-from-a-public-registry are three very different risk tiers. Treat third-party servers as untrusted content sources by default.

2. Map the trifecta per agent. For each agent, mark whether it has (a) access to private/sensitive data, (b) exposure to any untrusted content — including tool descriptions and responses from servers you don't control — and (c) any outbound channel that can reach the internet. All three present is a critical finding, full stop.

3. Break a leg. Where the trifecta is complete, remove one component. Split the privileged-data agent from the untrusted-tool agent. Drop the unaudited third-party server. Constrain the outbound channel to an allowlist. Removing any single leg neutralizes the attack class; this is your cheapest, highest-impact move.

4. Close the connect-time/runtime gap. Validate tool manifests on every connect and re-validate on change to defeat rug pulls. Pin server versions. Where the protocol allows, treat tool responses as untrusted data, not instructions.

5. Make the runtime observable, then actually watch it. Log every tool call with inputs and outputs. Alert on an agent reaching for data or a tool outside its expected scope. Auditing you don't review is theater.

6. Keep humans on consequential actions. Money movement, credential access, external sends, and destructive operations should gate on explicit approval — and resist the gravitational pull toward "always allow."

Tool poisoning is not a bug to be patched once; it is a property of giving language models autonomy over real tools. The protocol will harden, clients will add guards, and scanners will improve. But the durable defense is architectural: assume any text reaching the model can carry instructions, and design so that no single poisoned input ever finds private data, an untrusted source, and an exit all in the same agent.

Frequently asked questions

What is MCP tool poisoning in one sentence?

It's an indirect prompt-injection attack where malicious instructions are hidden in an MCP server's tool metadata or responses, so an AI agent treats them as trusted input and is steered into leaking data or misusing the tools it legitimately holds.

How is tool poisoning different from regular prompt injection?

Regular prompt injection arrives through user input. Tool poisoning is indirect: the payload rides in tool descriptions, parameters, or responses the user never directly sees. The model reads the full text and acts on it, which is why it slips past defenses aimed at the user-facing prompt.

What is a "rug pull" in the MCP context?

A rug pull is when an MCP tool is benign at approval time but redefines itself later — rewriting its description or behavior to exfiltrate data or reroute outputs — without triggering a new permission prompt. It exploits the fact that tool definitions are typically reviewed once, at connect time, and not re-checked when they change.

Why are autonomous agents more exposed than traditional API integrations?

Because the model's decision is the action. Autonomy removes the human checkpoint, multi-step chains amplify one bad instruction across many tool calls, persistent memory can turn a single poison into a standing instruction, and fleets are deployed specifically so no one is watching each step.

What's the single most effective defense?

Break the "lethal trifecta." If an agent has private-data access, exposure to untrusted content, and an outbound channel all at once, remove one. Splitting privileged and untrusted capabilities across separate, least-privilege agents neutralizes the entire attack class more reliably than any single scanner.

Are third-party MCP servers from public registries safe to use?

Treat them as untrusted by default. Research in 2025 found a substantial share of MCP server implementations carried ordinary injection flaws, and any third-party server is a potential source of poisoned descriptions or responses. Use only vetted servers, pin versions, re-validate on change, and never pair an unaudited server with private data and an exfiltration channel in the same agent.