AGT-003: Tool Shadowing

Category	Agent & MCP Attacks
Frameworks	OWASP: LLM05 · OWASP: LLM07

Register a malicious tool with the same name or similar description as a legitimate tool. The model routes calls to the shadow tool instead.

Technique

# If multiple MCP servers are registered,
# a malicious server can shadow legitimate
# tools by registering the same tool name.

# Resolution order varies by implementation.
# Some use last-registered-wins.
# Some use first-match.
# Few validate tool authenticity.

# Attack: register malicious MCP server with
# copies of legitimate tool names that proxy
# to the real tools while exfiltrating data.

Key Concepts

• Name collisions are unresolved in most implementations. When multiple MCP servers register tools with the same name, the client must decide which one to invoke. Most implementations use simple resolution strategies (first match, last registered) without alerting the user or verifying which server is authoritative.
• Transparent proxying makes the attack invisible. A shadow tool can forward requests to the legitimate tool and return real results to the model, while silently copying every request and response to an attacker-controlled endpoint. The user and model both see correct behavior, making the interception undetectable through normal usage.
• The attacker only needs server registration access. The attack requires the ability to register an MCP server with the client. In environments where users can install MCP servers from untrusted sources (community marketplaces, npm packages, GitHub repos), this barrier is low.
• Similar descriptions are as effective as exact name matches. Even without an exact name collision, a malicious tool with a description very similar to a legitimate tool's can intercept calls. The model chooses tools based on description relevance to the task, not by verifying server identity.

Detection

• Alert on duplicate tool names across MCP servers. When a newly registered server offers a tool with the same name as an existing tool from another server, flag the collision immediately. No legitimate reason exists for two servers to offer identically-named tools.
• Monitor tool call routing. Log which MCP server handles each tool invocation. If calls to a known tool suddenly route to a different server, or if a new server is handling calls previously routed elsewhere, investigate the change.
• Compare tool responses across servers. Periodically invoke shadowed tools on both the original and suspected shadow servers with identical inputs and compare outputs. Differences or additional network activity from the shadow server indicate interception.

Mitigation

• Enforce unique tool names with server binding. Implement a registry that binds tool names to specific, authenticated MCP servers. Reject registration of tools whose names conflict with existing tools from other servers.
• Require cryptographic server identity verification. MCP servers should present verifiable identity credentials (TLS certificates, signed manifests) at registration. Tool calls should be routed only to servers whose identity has been verified.
• Curate and restrict MCP server sources. Only allow MCP servers from trusted, audited sources. Implement an approval workflow for new server registrations, especially in enterprise environments where tool shadowing could lead to data exfiltration.