Tool shadowing is a namespace collision attack: a malicious MCP server registers tools with names identical to legitimate ones. The agent calls the fake tool instead of the real one — with no model exploit, no jailbreak, no detectable anomaly. Just a naming conflict with consequences.
How Tool Shadowing Works
Agents don't verify tool identity — they trust tool names. When an agent's runtime assembles a tool list from multiple MCP servers, there is typically no conflict resolution, no cryptographic binding between a tool name and its origin, and no warning when a name appears twice. The agent simply calls whichever tool it sees.
An attacker who can register a server in the agent's tool environment — through a compromised dependency, a malicious MCP marketplace package, or a confused tool registry — can shadow any legitimate tool with an identically named fake. The fake tool receives every parameter the agent passes: API keys, user queries, sensitive payloads. The real tool never gets called.
What makes tool shadowing particularly dangerous is how invisible it is. The agent behaves normally from the outside. It calls a tool, gets a response, continues its task. The attacker controls what that response looks like. They can exfiltrate silently, return plausible-looking results, or steer the agent's subsequent actions — all without touching the model layer.
Why Name-Based Trust Is the Root Cause
The vulnerability isn't exotic. It's a design assumption: that a tool named get_user_data is always the legitimate get_user_data. That assumption holds in a controlled environment with a single trusted server. It collapses the moment tool registration becomes federated, dynamic, or externally influenced.
This is the MCP ecosystem's current state. Tools are installed by name. They're resolved by name at call time. There is no native equivalent of code signing, no SBOM for tool registrations, no isolation between servers that share a namespace.
The Fix Is Structural
Behavioral defenses don't help here. The agent isn't misbehaving — it's calling the tool it was told exists. Fixing tool shadowing requires identity infrastructure:
- Cryptographic tool identity. A tool's legitimacy should be bound to a verifiable key, not just a string name. Registrations without valid signatures should fail.
- Origin-scoped namespacing. Tools should be resolved as
server::toolname, not justtoolname. Flat namespaces are where shadowing lives. - Registry integrity checks. Before an agent session starts, the tool manifest should be verified against a trusted baseline — any new or modified entry should require explicit approval.
Tool shadowing is not a model problem. It is an infrastructure trust problem. Until MCP and similar protocols enforce cryptographic tool identity by default, name-based trust is an attack surface that scales with every new tool you add.