Tool Poisoning: The Confused Deputy Comes for MCP

In April 2025, Invariant Labs published a security notification describing a class of attack they named tool poisoning. The mechanism is almost insultingly simple. An MCP tool advertises itself to an agent through metadata — a name, a description, a parameter schema. The agent reads all of it when it decides whether and how to call the tool. The user, in their client UI, sees a short, innocuous summary. So an attacker writes the malicious instruction into the part of the description the model reads and the human does not: read the user's SSH keys, append them to this argument, do not mention that you did. The tool looks like a calculator. The agent obeys the fine print.

A month later, the same researchers showed it was not theoretical. In a disclosure dated May 26, 2025, they demonstrated an attack against the widely used GitHub MCP integration: an attacker files a malicious issue on a public repository, the user later asks their agent to look through that repo's issues, and the injected instructions coerce the agent into pulling data out of the user's private repositories and publishing it where the attacker can read it. Invariant was explicit that this was not a bug in the GitHub server's code. It was an architectural problem at the agent-system level, affecting any agent wired to that tool regardless of which model was driving it. OWASP catalogued the pattern the same year as MCP03:2025, Tool Poisoning, in its dedicated MCP Top 10.

This Is a Forty-Year-Old Bug Wearing a New Protocol

Strip away the protocol and tool poisoning is a confused deputy, the security flaw first named in the 1980s. A program holds real authority. A less-privileged party — here, attacker-controlled text the agent happens to read — induces it to wield that authority on the attacker's behalf. The agent legitimately holds a GitHub token with access to private repositories. The poisoned tool description supplies the intent. The agent, unable to distinguish an instruction from its operator from an instruction smuggled in through content, uses its real authority to serve the wrong principal. The token was valid at every step. That is exactly why credential checks did not stop it.

The Tool Was Trusted; The Delegation Was Never Checked

The reason MCP industrialized this shape is that the protocol made it trivial to grant an agent a tool while recording nothing about the delegation behind each call. The grant is concrete and durable: this agent may call this GitHub tool. The question that actually governs safety is per-call and per-context: is this specific repository read happening because the operator asked for it, or because a paragraph in an issue told the agent to? MCP carries the grant. It does not carry the answer. So the agent treats "I am allowed to call this tool" as if it settled "I should make this particular call on behalf of this particular request." Those are different claims, and the gap between them is where the exfiltration lives.

It is tempting to file tool poisoning under prompt injection and reach for a better content filter. That treats the symptom. You can harden the model against one phrasing and the attacker writes another; the agent is doing what an obedient instruction-follower does. The disease is that a trusted capability was exercised on untrusted intent with no boundary between them, and no record of who delegated the agent to act on that intent. A filter asks the agent to be careful. An authorization boundary makes the dangerous call unreachable regardless of what the description says. Only the second survives an adversary who controls the text the agent reads.

Scope the Tool, Not Just the Prompt

Real defense against tool poisoning is delegated authorization enforced at the tool boundary. The agent that reads public issues should not, in the same context, hold a live grant to read private repositories and a path to publish externally — that combination is the lethal trifecta, and it should be unreachable by construction rather than discouraged by instruction. Each tool call should carry the delegation that justifies it, so a read triggered by attacker content fails the authorization check that a read requested by the operator would pass. Tool descriptions are attacker-controllable input; the authority a tool can exercise must be decided by policy you control, not by metadata a server hands you.

Start by Seeing What Your Tools Can Reach

You cannot scope a delegation chain you have never mapped. The first move is to look. The Agent Environment Review enumerates, for each agent, which tools it can call over MCP, what authority each of those tools actually holds downstream, and which combinations put private data, untrusted input, and an exfiltration path in the hands of the same principal. It reads this from metadata, local-first, without uploading your source or your secrets. It does not score you. It shows you which of your tools are deputies waiting to be confused, and which boundaries were never drawn around them.

Read the Full Argument

The Authorized Agent: Identity, Authorization, and Audit for AI Agents in Production is Book One in the DeepSweep.ai Thesis series. It develops delegation, tool authority, and proof from first principles into a runtime authorization model for production agents.

Available now on Amazon: https://www.amazon.com/dp/B0GWV9FGDF

DeepSweep is the productized thesis. The book is where it begins.