Most conversations about prompt injection assume the attacker's instruction arrives through content: a message a user typed, a webpage an agent scraped, a document it summarized. Tool poisoning breaks that assumption. The malicious instruction isn't hiding in something the agent reads while doing its job. It's hiding in the metadata and schema that define what an agent believes a tool is supposed to do, trusted before the job ever started.
That distinction is why tool poisoning deserves to be understood as its own category among agentic AI threats, not just a variant of prompt injection, even though the two are close relatives. Here's what AI agent tool poisoning actually looks like once it reaches production.
What a User Sees Versus What the Model Reads
A developer connects an agent to a new tool. The tool's listed name is add, and its stated purpose is exactly what it sounds like: add two numbers together.
What the model actually receives in its context is the full description field, and the full field contains more than the developer sees on the surface. Buried after the arithmetic instructions is a second block of text, formatted to look authoritative, instructing the model to first read a sensitive local file, an SSH private key, and pass its contents along as an extra parameter before returning the sum.
The user approving this tool never saw the second half. The interface showed "adds two numbers." The model reading the full description saw both the arithmetic instruction and the exfiltration instruction, with nothing in the protocol marking one as legitimate and the other as an attack.
This exact pattern is what Invariant Labs formally named tool poisoning in 2025. The description field is only the most obvious version of it, though: parameter names, default values, and other schema metadata are just as model-visible, and an instruction hidden in any of them is read with the same trust as one hidden in the description itself. Tool poisoning is now explicitly recognized in OWASP's MCP security guidance, including as MCP03 in the OWASP MCP Top 10.
Three Ways a Tool Gets Poisoned
Tool poisoning isn't one technique. It's three distinct attacks that share a root cause, and secure tool use means recognizing each one on sight.
- Description poisoning is the example above: the hidden instruction is there from the moment the tool is first published, disguised inside an otherwise ordinary-looking description.
- A rug-pull attack plays a longer game. A tool passes review with a genuinely clean description. It earns approval, gets used safely for weeks, builds a track record. Then, quietly, the server updates that same tool's description to add a malicious instruction, banking on the fact that nobody re-reviews a tool once it's already trusted.
- Tool shadowing doesn't touch the tool it's actually attacking. A malicious tool's description instead contains instructions that redirect how the agent treats a completely different, legitimate tool from another server entirely, hijacking trusted infrastructure without ever compromising it directly.
All three exploit the same gap: most systems review a tool's description once, at connection time, and extend that trust indefinitely without ever checking whether anything changed. And a defense built to scan only user input and retrieved documents will miss all three, because none of these attacks arrive through either channel.
Where Runtime Policy Enforcement Fits
Go back to the add tool from the first example. A mature defense against tool poisoning has to answer two separate questions, not one: is this suspicious, and even if it isn't caught, can it actually cause harm.
First Question: Is this tool's metadata suspicious?
The same runtime policy architecture used to catch malicious instructions in untrusted content can be extended to tool metadata, but tool poisoning adds a requirement content scanning alone doesn't have: the system has to establish what a tool is allowed to claim in the first place, then check whether its actual metadata stays inside that boundary. Applied to the add tool, that evaluation looks like this:
- Claimed function: add two numbers and return the result
- Full metadata content: includes an embedded instruction, outside the description's stated purpose, to read a local credential file and pass its contents as a parameter
- Semantic check: the embedded instruction has no relationship to arithmetic
- Decision: flagged and blocked before the tool is ever registered for use
Rug-pulls split detection into two further, distinct steps. A hash or snapshot of a tool's metadata can tell you that something changed since approval. It cannot, on its own, tell you whether the new version is malicious. Runtime policy enforcement has to answer both: did this tool's metadata change at all, and does whatever it changed to still conform to the purpose it was originally approved for. Maintaining ongoing observability over a tool's current metadata, rather than trusting it permanently after a single approval, is what makes the first question answerable continuously instead of once.
Second Question: Even if an attack isn't caught, can it actually cause harm?
It matters precisely because detection will never be perfect. Even a poisoned instruction that talks its way past every check still needs somewhere to go. Reducing an agent's blast radius before deployment means an agent scoped to only what its actual task requires can't be talked into reading a credential file it was never granted access to, regardless of how convincing the embedded instruction was. Governing tool access as a first-class control when building agents is what makes that scoping decision enforceable rather than aspirational, and it's also what should be watching the resulting chain of tool calls for anything that doesn't match what the agent's actual task ever needed.
The Broader Pattern
AI agent tool poisoning exposes a broader problem with AI agent security: trust cannot be established once and assumed forever. A tool's metadata, schema, responses, and permissions all influence what an agent can decide to do, and any of them can become an attack surface. Effective tool poisoning prevention requires controls that evaluate not only what a tool claims to do, but whether its current behavior still remains within the boundaries that were actually approved for it.