MCP Security: Tool Poisoning Defense

New to the building blocks? See the primers on what tool calling is and what an AI agent is first.

What is tool poisoning?

Tool poisoning is an attack that embeds malicious instructions in the metadata of an MCP tool, such as its description, parameter names, or default values. The model treats that metadata as ground truth when it plans, so the hidden instructions become part of what it tries to do.

The technique was first disclosed by Invariant Labs in April 2025, which named it the Tool Poisoning Attack. Their core finding was simple and uncomfortable: a model reads tool descriptions before choosing a tool, and MCP places a lot of trust in those descriptions without validation or user transparency.

Crucially, the payload is invisible to the person. The user sees a clean tool name in the interface, while the poisoned instructions sit in metadata the model reads but the interface never shows.

Why MCP is vulnerable

MCP is not insecure by accident. Its openness is the point, and that same openness widens the attack surface.

Two design facts combine to create the risk. First, the model consumes the full tool description and schema, but the user usually sees only a short name. Second, anyone can publish a server, so an agent may load tools from sources no one has vetted.

Put together, an attacker can ship a tool that looks like "add two numbers" while its description quietly instructs the model to read your SSH keys. This is why tool poisoning is classed as a form of indirect prompt injection, where the malicious instruction comes from a tool or its output rather than the user.

The main MCP attack classes

Tool poisoning is the headline, but it travels with a family of related attacks. Knowing the taxonomy helps you defend the whole surface, not just one entry point. OWASP now tracks tool poisoning as a top MCP risk.

Attack	What it does
Tool poisoning	Hides instructions in a tool's description or schema so the model acts on them.
Rug pull	A tool changes its description or behavior after you approve it, sometimes only on a later load.
Shadowing	A malicious server manipulates the agent's use of a different, trusted tool, for example redirecting where emails are sent.
Command injection	A poorly built server passes model or user input into a shell or query without validation.
Confused deputy	A remote server is tricked into using its own higher privileges to act for an attacker.
Token passthrough	A server forwards a client's token downstream without checking it was issued for that server.

The first three abuse the model's trust in tool metadata. The last three are classic application-security flaws that MCP inherits when servers are built or deployed carelessly.

The lethal trifecta

To judge real danger, look for a combination security researcher Simon Willison calls the lethal trifecta. It names the three ingredients that make an agent genuinely exploitable.

Those ingredients are access to private data, exposure to untrusted content, and the ability to send data out. An agent with all three can be poisoned into reading your secrets and exfiltrating them, which is precisely the tool-poisoning scenario.

The practical lesson is to break the trifecta. If an agent handles sensitive data, restrict what untrusted tools it can load, or cut off its ability to reach arbitrary external endpoints.

Defending local servers

Most developer setups run servers locally over stdio, where the main risks are poisoned or untrusted tools. A few habits remove most of the exposure.

Treat every tool description and schema as untrusted input. The payload can hide in names, parameter types, and defaults, not just the description text, so review the whole definition.

Vet servers before you install them. Read the source, not just the tool names. Prefer servers with a clear provenance, and keep an allowlist of the ones you trust.

Pin tool definitions. Record a tool's description and schema on first use, then flag any later change. This is the direct defense against rug pulls, where a tool mutates after approval.

Enforce least privilege. Do not give an agent a file-reading or shell tool unless the task needs it. As covered in the tutorial on building a custom MCP server, scope each server tightly and validate every input.

Keep a human in the loop. Require explicit approval for sensitive or destructive actions, and show the user the full tool description, not just its name.

Scan your servers. Use a scanner such as mcp-scan, the open-source tool the original researchers released to detect poisoned descriptions in your configuration.

Defending remote servers

Remote servers over Streamable HTTP add network and identity risks on top of the tool risks above. Here the official MCP security guidance is the authority, and three rules stand out.

Never use token passthrough. A server must not accept a client's token and forward it to a downstream API without checking the token's audience. Passing it through breaks the audit trail and lets a compromised server hit the downstream service directly.

Prevent the confused deputy. A proxy server must enforce per-client consent, an exact redirect-URI match, and the OAuth state parameter, so an attacker cannot slip their own authorization code into the flow.

Use OAuth 2.1 with scoped, short-lived tokens. Issue a fresh token bound to the specific server and tool that needs it, rather than reusing one broad credential. Deny by default, and grant per-tool scopes.

A security checklist

Use this before you connect any MCP server to a model that can act.

• Vet and allowlist every server, and read its source.
• Pin tool descriptions and schemas, and alert on changes.
• Scan configurations for poisoned metadata.
• Least privilege: grant only the tools the task requires.
• Human approval for sensitive or irreversible actions.
• Validate inputs and outputs in every tool you build.
• Remote: OAuth 2.1, audience-checked tokens, no passthrough, per-client consent.
• Sandbox local servers and isolate their file and network access.
• Log every tool call with its arguments and result.

Monitoring and incident response

Prevention is not enough on its own. You also need to see what your agents did, which is what turns a suspected incident into an answerable question.

Log each step of the loop: the prompt, the tool call, the arguments, and the downstream action. Tie those together so you can trace a single request end to end. Watch for unexpected tools, unusual arguments, or calls to external endpoints you did not expect.

When something looks wrong, revoke the server's access, pull its tool definitions, and compare them against your pinned versions. This aligns with the evidence-first, auditable posture behind ModelRefs methodology.

Common mistakes

Most MCP breaches trace back to misplaced trust.

The frequent errors:

• Installing servers without reading their source.
• Auto-approving tool calls, so a human never sees the description.
• Granting broad file or shell access by default.
• On remote servers, token passthrough: forwarding a credential the server never validated.

Fixing these is mostly about defaults. Make approval explicit, permissions narrow, and trust something you verify rather than assume.

Sources

• Invariant Labs, MCP Security Notification: Tool Poisoning Attacks (April 2025) — the original disclosure, plus the rug pull and shadowing variants.
• OWASP, MCP03:2025 Tool Poisoning (MCP Top 10) — tool poisoning as a recognized top MCP risk.
• Model Context Protocol, Security Best Practices (official) — confused deputy prevention, the token passthrough prohibition, per-client consent, and session security.

The mcp-scan scanner referenced above is the open-source tool released by Invariant Labs alongside the original disclosure.

Methodology: attack classes and defenses are asserted in ModelRefs' own voice as the reference layer, cross-checked against the original Invariant Labs research, the OWASP MCP Top 10, and the official MCP security guidance on 17 Jul 2026. This article is defensive and intentionally omits working exploit code.