Tool Name Exploitation in AI Agent Frameworks

An AI agent trusts a tool's name and description the same way it trusts a direct instruction from its system prompt. That single design choice, repeated across nearly every agent framework built in the last two years, means tool metadata is an input channel anyone can write to. It's an input channel, and adversaries have figured out how to write to it.

Agent frameworks connect language models to the outside world through tool definitions, each one made up of a function name, a set of parameters, and a plain-English description of what the tool does and when to use it. Those definitions get loaded straight into the model's operating context at runtime, right alongside its actual instructions. The model has no reliable way to tell a genuine description from a rewritten one. Both arrive in the same format, at the same trust level, read by the same process. That's the structural crack everything else in this piece falls through.

The connective tissue that made this attack surface universal

Anthropic's Model Context Protocol, released in late 2024, gave the industry a shared standard for how agents find tools and talk to them. Before MCP, every framework rolled its own plumbing. After it, one protocol started carrying the weight for most of them.

OpenAI adopted MCP in March 2025. Google DeepMind announced support was coming shortly after. By December 2025, the Linux Foundation had taken over stewardship of the project, which is usually a sign a technology has stopped being one vendor's bet and started being infrastructure. Downloads across the official MCP SDKs passed 150 million. The wiring underneath agents from competing companies and frameworks that otherwise have almost nothing in common produces this shared vulnerability, which is visible in the fact that it's no longer a niche developer tool.

MCP pulls tool descriptions, parameter schemas, and (once a tool actually runs) its response content, and loads them into the agent's context, either at session start or on demand, depending on implementation. Response content appears in the agent's context only after a tool gets called, not while the agent is browsing what's available. But the descriptions and schemas can load before a human ever weighs in. That's the entry point. Manipulate what's sitting in that schema, and every agent that connects through MCP is reading your version of events as gospel.

Six distinct ways adversaries manipulate tool metadata, and what each one does

Researchers haven't lumped this into one catch-all "tool injection" bucket. They've named and tested it as several separate attack families, each with its own mechanics.

Attractive Metadata Attack (AMA) rewrites a tool's name, description, and parameter schema so the model prefers it over the legitimate option, no prompt injection needed, no access to the model's weights required. It works purely because the metadata reads as more relevant or more capable than the real tool sitting next to it. Presented at NeurIPS 2025, AMA pulled off attack success rates between 81% and 95% across realistic tool-use scenarios, across those scenarios. It worked without access to model weights or prompt-level intervention, relying entirely on how metadata is read. This isn't a gap that better prompting closes.

ToolTweak. Where AMA rewrites metadata once, ToolTweak iterates on it, tuning tool names and descriptions round after round until the agent picks the malicious tool far more often than chance would predict. Baseline selection rates around 20% climbed as high as 81% after the attack was applied. And the attack transferred: something tuned against an open-source model worked against closed-source ones too. That means an attacker doesn't need inside access to the target system. They can rehearse the exploit somewhere cheap and public, then aim it somewhere expensive and locked down.

Tool Shadowing. A malicious MCP server registers a tool with a name or description close enough to a legitimate one to intercept the agent's calls. The attacker never has to convince the agent to pick their tool on purpose, proximity and naming overlap are enough to redirect the exchange.

From research to production: the CVEs and incidents that confirm these are not theoretical

None of this stayed in a lab.

CVE-2025-54136, nicknamed MCPoison, hit Cursor IDE and carries a CVSS score of 8.8. Check Point Research disclosed it. What it formalized was the "rug pull": a tool that behaves correctly during review, then changes its behavior after it's already trusted and wired into a workflow. That's the first time this pattern got a catalog number and a severity score attached, rather than just a conference talk.

CVE-2025-6514, found in the mcp-remote package by JFrog's security research team and published July 9, 2025, scored a 9.6. The package had over 437,000 downloads. The vulnerability enabled full remote code execution on a client machine, triggered simply by connecting to an untrusted MCP server. Not a demo. Not a proof of concept. A real client operating system, actually compromised, through a channel most reviewers would have filed under "configuration" rather than "attack surface."

A documented proof-of-concept against a WhatsApp MCP server showed a malicious server, sitting in the same agent context as the legitimate one, quietly instructing the agent to pull a user's message history and send it to an outside phone number, without any user prompt triggering it. A companion test against GitHub MCP servers used a related technique, indirect prompt injection through a malicious repository Issue, to pull private repository contents out through the agent.

Then there's postmark-mcp, an npm package that gave agents an email-sending tool. Fifteen versions shipped clean. Version 1.0.16 quietly added a blind copy of every outgoing message to an address the maintainer didn't disclose. Nobody had to trick anyone into installing something malicious. The poison arrived in a routine update to something already trusted, which is exactly the supply-chain version of the rug pull.

Why tool poisoning is structurally different from prompt injection

Prompt injection is aimed at a conversation. It targets one session, touches one user, and dies when that session closes. Patch the input, close the chat, move on.

Tool poisoning is aimed at a relationship. Once malicious instructions sit inside a tool's metadata, they touch every session and every user who connects to that tool going forward, not just the one interaction where someone got unlucky. And the tool doesn't even need to run to do damage: loading a poisoned description into context can be enough to steer the agent, before a single function call executes.

When does an agent actually re-check whether a tool deserves its trust? At registration, usually. Maybe at onboarding. After that, the decision is made and it stays made. There's no built-in moment where the agent goes back and re-evaluates a tool it already accepted, which is precisely how the postmark-mcp backdoor sat invisible for fifteen versions.

And the channel itself hides in plain sight. JSON Schema fields. Tool descriptions fetched at session start. Structured metadata that looks, to a security reviewer scanning for injection strings, like configuration rather than instruction. That's the whole point of the exploit: it doesn't look like an attack because it isn't shaped like one.

What conventional governance frameworks are not built to catch

Most existing security frameworks were built for a different kind of system: short-lived, supervised by a human at each step, narrowly scoped in what it's allowed to touch. Researchers surveying agentic AI and cybersecurity argue that governance and assurance mechanisms built for non-autonomous systems don't capture what happens when agents run with memory, persistent tool access, and the ability to chain one tool's output into another tool's input. Memory poisoning and cascading tool failures fall outside what those older frameworks were ever asked to watch for.

Static compliance checklists are a snapshot. They tell a reviewer what a tool looked like on the day it was approved, and nothing about what it looks like six versions later. A rug pull, by definition, happens after the checklist gets filed away.

Vendor risk assessments have the same blind spot. They evaluate stated functionality and security posture once, at onboarding, and then move on to the next vendor. They don't sit there monitoring what a tool's metadata is telling an agent at 2 a.m. on a Tuesday, three months after the assessment closed.

And generic prompt injection defenses, built to watch the conversation layer, simply aren't pointed at the right thing. They don't inspect tool description fields. They don't parse parameter schemas for embedded instructions. They don't look at what comes back in a tool's response payload for language the model might read as a command. One might argue that's a gap in scope rather than a design flaw, and that's fair, but the practical result is the same either way: the exact channel adversaries are using sits outside what these defenses were ever built to check.