- What is MCP tool poisoning? MCP tool poisoning is an attack in which malicious instructions are hidden inside the description of a tool exposed through the Model Context Protocol (MCP). The AI agent reads and follows them; the user never sees them.
- Why it works: an agent treats every tool description as trusted context. Tool poisoning turns that trust into an indirect prompt injection.
- What it can do: exfiltrate SSH keys and credentials, redirect messages, or make the agent misuse other, legitimate tools.
- Main variants: hidden instructions in tool descriptions, rug pulls (a tool changes after you approve it) and tool shadowing (one server manipulates how the agent uses another server’s tools).
- First defense: know which MCP servers and tools your agents and repositories use, vet them before adoption, pin versions and restrict what each agent can reach.
Tool poisoning explained #
MCP tool poisoning is a type of attack against AI agents that use the Model Context Protocol, the open standard that lets agents connect to external tools and data sources. Every MCP server publishes a list of tools with a name, a description and parameters. The agent’s model reads those descriptions to decide when and how to call each tool.
In a tool poisoning attack, the attacker hides instructions inside that metadata. A tool that looks like a harmless calculator can carry text telling the model to read a private file and pass its contents as a parameter. The user approving the tool sees a short, innocent label. The model sees, and follows, the full description.
Security researchers named and disclosed the attack class in April 2025, describing it as a specialized form of indirect prompt injection. Their proof of concept exfiltrated SSH keys and MCP configuration files through a poisoned “add” tool. Since then, the OWASP community has documented MCPtool poisoning as a distinct attack, and academic benchmarks such as MCPTox have tested it against real-world MCP servers.
Why tool poisoning works? #
Tool poisoning exploits a gap between what humans review and what models read:
- Descriptions are trusted context. MCP clients pass tool descriptions to the model as instructions about how to use the tool, so text hidden there carries real authority.
- Users see a summary. Most interfaces show a tool’s name and a short label, not the full description or parameter schema.
- Agents act with real access. A coding agent often has file system, shell and network access, plus the developer’s credentials. Whatever the poisoned instruction asks, the agent can usually do.
- MCP servers are third-party code. Many are installed from public registries in a single command, with little review.
That is why tool poisoning sits at the intersection of two risks: prompt injection and the software supply chain.le?
Types of MCP tool poisoning #
Tool poisoning takes several forms. All of them abuse the agent’s trust in tool metadata.
MCP tool poisoning and the OWASP frameworks #
MCP tool poisoning maps directly onto the OWASP risk lists for AI applications:
ASI04 Agentic Supply Chain Vulnerabilities, ASI01 Agent Goal Hijack and ASI02 Tool Misuse in the OWASP Top 10 for Agentic Applications. Our guide to the OWASP Agentic AI Top 10 explains each risk with pipeline examples.ate exploitability, and AI Remediation opens fix pull requests where developers work.
LLM01 Prompt Injection in the OWASP Top 10 for LLM Applications, since tool poisoning is a form of indirect prompt injection.
How to prevent it? #
No single control stops tool poisoning. These practices reduce the risk and the damage:
- Inventory every MCP server and tool. You can’t vet, pin or restrict tools you don’t know your agents use.
- Vet servers before adoption. Prefer verified publishers, review the full tool descriptions and parameters, and check the package itself for malicious code.
- Pin versions and detect changes. Lock MCP server versions and re-review when a tool definition changes, so a rug pull can’t happen silently.
- Apply least privilege. Give each agent only the tools, files and credentials its task needs, and avoid long-lived, broad tokens.
- Isolate agents. Run agents in sandboxes with restricted network access, so a poisoned instruction can’t reach your secrets or send data out.
- Require approval for sensitive actions. Keep a human in the loop for actions that send data, change permissions or touch production.
- Log tool calls. Record which tools an agent calls and with which parameters, so you can investigate anomalies.
How Xygeni helps reduce tool poisoning risk? #
Xygeni addresses the parts of MCP tool poisoning that leave evidence before an agent runs:
- Inventory: Xygeni AI Security discovers the MCP servers, tools, agents and models in your repositories, maps which agent calls which MCP server, and exports everything as an AI-BOM.
- Over-privileged agents: it flags MCP and tool servers with elevated privileges and long-lived credentials in agent configurations, which limit what a poisoned instruction can reach.
- Malicious instructions: it reviews the skills and agent instruction files that steer agents, catching malicious instructions no signature can see.
- Malicious packages: many MCP servers are distributed as npm or PyPI packages. Malware Early Warning analyzes new package versions as they are published, and Shield blocks malicious packages on developer workstations before they install.
FAQ #
MCP tool poisoning is when an attacker hides instructions inside the description of a tool an AI agent can use. The agent reads the hidden text and follows it, for example by leaking files, while the user only sees a harmless tool name.
Tool poisoning is a form of indirect prompt injection. The difference is where the malicious instruction lives: in the tool metadata the agent trusts, rather than in a document, web page or user message.
A rug pull happens when an MCP server changes a tool’s definition after you have approved it. The tool you reviewed is no longer the tool your agent uses, so pinning versions and re-reviewing changes is essential.
Start with an inventory of every MCP server and tool your agents and repositories use. Then review each one for its publisher, the permissions it needs and how it is installed. Tools such as Xygeni AI Security build that inventory automatically from your code.
