AI agent tool poisoning

How it works

MITRE ATLAS names three places a tool an AI agent already trusts can be poisoned: its stated definition or instructions, its underlying implementation, or the response it returns at runtime. None of the three touches the agent’s own prompt or model weights — the attack lands entirely on the tool’s side of the call, which an agent has no routine reason to re-examine once the tool has been added.

OWASP describes the resulting gap for the common case, a tool served over the Model Context Protocol: a description is reviewed once, at connection time, while its responses “go straight into the LLM context with no equivalent check” on every later call. Invariant Labs, which first disclosed the pattern, adds a human-facing gap: a model sees a tool’s full description, hidden instructions included; a user usually sees only a simplified version. Indirect prompt injection is the usual channel that turns poisoned content into an action once it reaches the agent’s context.

Why it matters

Tool count has outgrown any process for re-checking them. ATLAS says agent tools have “exploded in popularity” across thousands of MCP servers, with “safeguards … often not in place.”

That is not hypothetical. In September 2025, Koi Security found what its CTO called “the world’s first sighting of a real-world malicious MCP server”: npm package postmark-mcp passed as a working tool through fifteen releases before one later version quietly BCC’d every email it sent to an outside address, downloaded 1,643 times before removal. Postmark, the real provider it impersonated, said it had never published such a package. ATLAS now cites the incident as its own reference case, an example of the AI supply chain compromise a poisoned tool travels through to reach a victim.

Questions and answers

Is AI agent tool poisoning the same as MCP tool poisoning?

MCP tool poisoning is the specific case where the poisoned tool is served over the Model Context Protocol. AI agent tool poisoning is the broader technique MITRE ATLAS defines as AML.T0110, covering any agent tool whose definition, implementation, or runtime responses have been corrupted, whatever protocol or integration delivers it to the agent.

How is this different from AI supply chain compromise?

AI supply chain compromise is the broader category of an adversary compromising how an AI artifact reaches a victim, covering models, data, and software generally. ATLAS lists AI Agent Tool as one specific compromise vector inside that category, one way a poisoned tool can be introduced. AI agent tool poisoning is the narrower technique that covers what happens once an agent actually invokes that tool.

Has AI agent tool poisoning happened outside a lab?

Yes. In September 2025, security firm Koi Security identified a package on npm named postmark-mcp that had passed as a working tool through 15 releases before a later version quietly added code that copied every email the tool sent to an outside address. Postmark, the real email service the package impersonated, said it had never published such a package. MITRE ATLAS now cites this incident as its own reference case for the technique.

Does anything mitigate AI agent tool poisoning?

MITRE ATLAS maps no dedicated mitigation to AML.T0110 in the current collection, unlike some neighboring techniques. Until one exists, the practical defense is the same one that applies to any supply-chain risk: checking where a tool comes from and who maintains it, not only what it appeared to do the one time it was reviewed.