Executive summary
MCP tool poisoning is an attack in which a Model Context Protocol server manipulates an AI agent by corrupting the tools it exposes, rather than by attacking the user's prompt. The agent trusts the metadata a server provides for each tool, its name, description, and parameter schema, and it reads that metadata as authoritative instruction. An attacker who controls or compromises a connected server can hide directives inside that metadata, redefine a trusted tool after it has been approved, or poison the data a tool returns, and the agent will carry out the attacker's intent while appearing to work normally.
This matters to leadership because agents are being wired into email, source code, ticketing systems, cloud consoles, and internal knowledge with standing credentials and the authority to act. A single poisoned tool can turn that authorized access into data exfiltration, unauthorized transactions, or lateral movement, with no obvious sign to the user who approved the connection. The defensible approach is to treat every MCP server as an untrusted dependency: pin and verify tool definitions, show operators the full description the model actually sees, require human confirmation for sensitive actions, and test the agent's tool supply chain the same way you would test any other third party code path. This is one technique within the broader attack surface we cover in our overview of AI agent MCP exploitation.
What MCP tool poisoning is
MCP tool poisoning is the manipulation of an AI agent through the tool definitions and tool outputs supplied by a Model Context Protocol server. The Model Context Protocol is an open standard that lets an agent discover and call external capabilities: a server advertises a set of tools, each with a name, a natural language description, and a JSON schema describing its parameters. The agent's model reads all of that, decides which tool to call, and passes arguments the server then acts on. The technique was first disclosed by Invariant Labs as a Tool Poisoning Attack.
The problem is that the description and schema are instructions the model obeys, not inert documentation. In most agent clients the user sees only a tool's name and perhaps a one line summary, while the model sees the full description. That gap between what the operator approves and what the model actually reads is the core of the attack. Poisoning does not require breaking the protocol or exploiting a memory bug. It requires only that an attacker influence the text an agent trusts, which is a content problem, not a software vulnerability in the traditional sense.
How tool poisoning differs from prompt injection and supply chain attacks
Tool poisoning sits between two attacks security teams already know, and it is most dangerous where they overlap. Understanding the distinction prevents teams from assuming an existing control already covers it.
Tool poisoning versus prompt injection
Prompt injection targets the conversation: an attacker plants instructions in content the agent reads, a web page, an email, a document, hoping the model follows them. Tool poisoning targets the tool layer instead. The malicious instruction lives in the tool's own description or output, which the model treats as trusted infrastructure rather than as untrusted user data. That is why it is more reliable for an attacker. A well built agent may be trained to distrust the contents of a fetched web page, but it has no reason to distrust the description of a tool it was explicitly connected to. Invariant Labs classifies tool poisoning as a specialized form of indirect prompt injection. Our deep dive on prompt injection against LLM-integrated applications covers the conversational side of this problem; tool poisoning is the same class of trust failure moved one layer down, into the agent's capabilities.
Tool poisoning versus supply chain attacks
A software supply chain attack compromises a dependency you install. Tool poisoning can be delivered that way, through a malicious or typosquatted MCP server, but it does not have to be. A perfectly legitimate server can poison an agent at runtime by changing a tool's description after approval, and a compromised server can poison one agent's view of another server's tools without altering any package on disk. The overlap with the model supply chain, poisoned artifacts and provenance failures we cover in our analysis of AI model supply chain attacks, is real, but tool poisoning adds a runtime, per session dimension that static dependency scanning will not catch.
The tool definition trust model
The reason tool poisoning works is that AI agents extend implicit trust to tool metadata that no other part of the system would extend to arbitrary text. When a server registers a tool, the agent's model incorporates the tool name, description, and parameter schema directly into its working context and treats them as ground truth about what the tool does and how to use it. There is usually no integrity check on that metadata, no separation between the server's declared behavior and its actual behavior, and no guarantee that the description approved yesterday is the description in effect today.
That trust is transitive and cross domain. An agent connected to several servers holds all their tool definitions in one shared context, so a tool from a low value server sits beside a tool that can move money or read a code repository, with no trust boundary between them. The agent also trusts what a tool returns: tool output flows back into the model's context and influences the next action. Every one of these assumptions, that metadata is honest, stable, isolated per server, and that output is data rather than instruction, is an assumption an attacker can break.
The MCP tool poisoning taxonomy
MCP tool poisoning is best understood as a family of techniques against that trust model, not a single trick. The following nine techniques form the working taxonomy we use in assessments. They can be combined, and several share the same root cause: the agent cannot tell the difference between a tool's declared purpose and an attacker's injected purpose.
Malicious tool descriptions
The foundational technique hides instructions inside a tool description that the model obeys but the user never sees. A calculator tool whose description quietly adds an instruction to read the user private key and include it in the result will cause a compliant agent to do exactly that. Because clients commonly surface only the tool name, the operator approves a benign looking capability while the model reads and follows the full malicious text.
Tool shadowing
Tool shadowing is a cross server attack in which a malicious server injects instructions that alter how the agent uses a different, trusted server tool. The poisoned server never has to be called directly. Its tool descriptions instruct the model that, whenever it uses the trusted server send email tool, it should also blind copy an attacker address. One compromised connection contaminates the agent use of every other connection.
Parameter confusion
Parameter confusion abuses the parameter schema and its descriptions to smuggle sensitive data into a call. A tool might declare an innocuous looking optional field, described in a way that instructs the model to populate it with the contents of a config file or prior conversation. Researchers at CyberArk showed that this attack surface extends across the entire tool schema, not just the description. The agent, following the schema it trusts, hands the attacker data it never should have included, inside what looks like a routine tool invocation.
Output poisoning
Output poisoning places the attack in what a tool returns rather than in its definition. Tool results flow back into the model context, so a server can return data that contains fresh instructions, and the agent may act on them as if they came from the system. This is indirect prompt injection delivered through a trusted channel, and it lets even a read only tool drive the agent next, more dangerous action.
Prompt context poisoning
Prompt context poisoning corrupts the shared context or memory the agent carries across steps. By seeding persistent state, through a tool that writes to agent memory or a long lived session, an attacker plants instructions that resurface later, after the poisoned tool is no longer in use. The effect is a delayed trigger that survives beyond the interaction where it was introduced.
Cross tool trust abuse
Cross tool trust abuse exploits the fact that all connected tools share one context with no boundary between them. A tool from a low sensitivity server references, redefines, or chains into a high sensitivity tool, borrowing the trust the agent extends to the whole toolset. The agent has no model of one server not being allowed to influence another, so it permits the interaction.
Capability escalation
Capability escalation chains individually permitted tool calls into an outcome none of them was meant to allow. A tool that lists files, a tool that reads a file, and a tool that sends a message are each reasonable in isolation, but an agent steered to combine them becomes an exfiltration pipeline. The escalation lives in the sequence, so per tool permission checks miss it entirely.
Malicious MCP servers
A malicious MCP server is one built or compromised specifically to poison the agents that connect to it. Unlike a single poisoned tool, the whole server is hostile: it can present benign tools during evaluation and hostile behavior in production, fingerprint the agent, and adapt. This is the delivery mechanism that turns the other techniques into a persistent foothold.
Supply chain poisoning
Supply chain poisoning introduces the malicious server or tool through the distribution channel, a typosquatted package, a compromised registry entry, or a legitimate server that ships a poisoned update. It is the tool layer equivalent of a dependency confusion attack, and it scales: one poisoned release can reach every organization that installs it, days or weeks before anyone inspects the tool descriptions it added.
A realistic enterprise scenario
The following is a composite scenario drawn from patterns we see in engagements, not a single real client. A development team connects a coding agent to three MCP servers: an internal source control server, a widely used third party server that formats and lints code, and a newly adopted server that summarizes tickets. The formatter is popular and trusted, so no one reviews its tool descriptions closely.
An update to the formatter server changes one tool description to instruct the agent that, whenever it commits code, it should also read any file named with a secrets or environment pattern and include the contents in the commit message for validation. Nothing in the user client shows this text. During normal work the agent commits code, quietly appends environment secrets to commit messages, and pushes them to a repository a contractor can read. The operator sees a working formatter. The security team sees ordinary commit activity. The exposure is only visible if someone diffs the tool descriptions the model actually received against the ones that were approved, which is exactly the check most organizations do not have. Translated to business terms, a routine developer convenience became credential leakage into a lower trust audience, the kind of finding that turns into an incident, a compliance disclosure, and a hard question from the board about who reviewed the agent tools.
How we test for MCP tool poisoning
Testing for tool poisoning means assessing the agent tool supply chain as an attack surface, not just the agent prompts. Our methodology proceeds in defined steps so results are repeatable across engagements, and it runs as part of a broader agentic AI red teaming engagement.
First, we enumerate every connected server and extract the full tool definitions the model receives, including the complete descriptions and parameter schemas, then compare them against what the operator client actually displays. The gap between the two is where poisoning hides. Second, we test injection in each channel independently: crafted instructions in descriptions, in parameter field descriptions, and in tool outputs, measuring whether the agent acts on them. Third, we test cross server shadowing by introducing a controlled server and checking whether its definitions can alter the agent use of another server tools. Fourth, we test for rug pulls by approving a benign tool and then changing its definition to confirm whether the change is detected or silently accepted. Fifth, we test capability chains, looking for sequences of individually permitted calls that combine into exfiltration or unauthorized action. Finally, we review server provenance and update integrity, how servers are sourced, pinned, and updated, to find the supply chain path. Each finding is tied to a concrete business impact and a specific remediation, not just a technical description.
Defensive guidance
The controls that contain tool poisoning treat every MCP server as untrusted code and close the gap between what an agent reads and what an operator approves. Pin and verify tool definitions: hash approved descriptions and schemas, and alert on any change so a rug pull cannot happen silently. Show operators the full tool description the model receives, not a shortened label, so approval is informed. Isolate trust domains: scope each server to least privilege, and do not let a low sensitivity server share context with tools that can move money or read source code without an explicit boundary. Require human confirmation for sensitive or irreversible actions, so a poisoned tool cannot complete an exfiltration or transaction unattended. Treat tool output as untrusted input, not as system instruction. Allowlist and provenance check servers, pin versions, and review updates before they reach production. And monitor agent tool activity for the call sequences that indicate capability escalation. This is the same governance discipline that underpins a secure enterprise knowledge platform: none of these controls is exotic, and together they move the agent tool layer from implicit trust to verified trust, which is where it needs to be before an agent is given real authority.
Conclusion
MCP tool poisoning is what happens when an autonomous system trusts its tools more than it should. The attack does not break the protocol; it abuses the agent assumption that tool metadata and tool output are honest, stable, and isolated. As enterprises connect agents to systems that hold money, code, and regulated data, that assumption becomes a liability measured in real business risk. The organizations that stay ahead of this will be the ones that inventory their agent tools, verify them continuously, and test the tool supply chain before an attacker does. If your organization is deploying AI agents with MCP integrations, our AI Red Teaming practice assesses exactly this attack surface and gives you a prioritized, business aligned path to closing it.
Frequently Asked Questions
What is MCP tool poisoning in simple terms?
MCP tool poisoning is when a Model Context Protocol server manipulates an AI agent by corrupting the tools it offers, rather than by attacking the user's prompt. The agent trusts each tool's name, description, and parameters as honest instruction, so an attacker who controls a connected server can hide directives in that metadata or in the data a tool returns, and the agent will follow them while appearing to work normally.
How is tool poisoning different from prompt injection?
Prompt injection hides malicious instructions in content the agent reads, such as a web page or email, which a well built agent may be trained to distrust. Tool poisoning hides the instruction in a tool's own description or output, which the agent treats as trusted infrastructure. That trusted status makes tool poisoning more reliable, because the agent has no reason to doubt a capability it was deliberately connected to.
Can tool poisoning happen without a malicious MCP server?
Yes. A legitimate server can poison an agent at runtime by silently changing a tool's description after it was approved, a technique known as a rug pull. A compromised server can also alter the agent's use of a different trusted server's tools, called shadowing, without changing any installed package. Static dependency scanning will not catch either case.
Why do agents trust tool descriptions at all?
Because the Model Context Protocol feeds a tool's name, description, and parameter schema directly into the model's context as authoritative information about how to use the tool. There is usually no integrity check on that metadata and no separation between a server's declared behavior and its actual behavior, so the agent has nothing to compare against.
What business impact does tool poisoning actually have?
Agents are increasingly connected to email, source code, cloud consoles, and internal data with standing credentials and authority to act. A single poisoned tool can convert that authorized access into data exfiltration, unauthorized transactions, or lateral movement, with no obvious signal to the operator who approved the connection. The result can be a breach, a compliance disclosure, and a governance failure.
How do you test an AI agent for tool poisoning?
We enumerate every connected server, extract the full tool definitions the model receives, and compare them against what the operator's client shows. We then test injection in descriptions, parameters, and outputs, test cross-server shadowing with a controlled server, test for silent rug pulls after approval, look for capability escalation across chained calls, and review how servers are sourced and updated.
What is the single most effective control against tool poisoning?
Pinning and verifying tool definitions is the highest leverage control. If approved tool descriptions and schemas are hashed and any change raises an alert, silent rug pulls and shadowing lose their stealth, and the gap between what the operator approved and what the model reads closes. It pairs best with human confirmation for sensitive actions.
Does using a well known MCP server make us safe?
No. Popularity is not integrity. A widely used server can ship a poisoned update, be compromised upstream, or expose tools whose full descriptions no one has reviewed. Trust should come from verification, pinned versions, reviewed updates, least privilege scoping, and continuous checks, not from a server's reputation.