Tool Shadowing in Model Context Protocol: How the Attack Works
A technical walkthrough of how tool shadowing exploits MCP tool discovery and resolution, how it relates to tool poisoning and prompt injection, and which architectural and runtime controls reduce the risk.
Tool Shadowing at a Glance
- Attack surface Tool name, description, and schema fields exchanged during MCP tool discovery.
- Trigger A malicious server’s tool metadata, not an invoked malicious tool.
- Target Agent behavior toward a separate, trusted server’s legitimate tool.
- Root cause No mandatory cross-server namespace isolation or provenance verification in MCP.
What Is Tool Shadowing in MCP
Model Context Protocol, introduced by Anthropic in late 2024, defines a client-host-server architecture in which servers expose tools that agents discover through a list or describe call. Each tool is presented to the agent with a name, a free-text description, and a JSON Schema input definition. The MCP specification treats this metadata as originating from the server and instructs operators to treat it as untrusted unless the server itself is known and trusted.
Tool shadowing exploits that trust gap. A malicious or compromised server connects to an agent session alongside one or more trusted servers and registers a tool whose name or description is engineered to influence how the agent behaves toward a legitimate tool exposed by a different, trusted server. Independent security research from Invariant Labs, published in April 2025 under the broader category of tool poisoning, documented this shadowing effect: the manipulated outcome affects a trusted tool’s use, while the malicious tool that carries the instruction may never be called at all. This distinguishes tool shadowing from attacks that depend on execution of the malicious component.
How MCP Tool Discovery Creates the Shadowing Condition
Tool discovery in MCP is dynamic. Tool lists are fetched at session or connection time, which means a server can present different metadata across sessions, and a client can end up holding tool definitions from multiple servers simultaneously within a single agent context. Because tool descriptions are natural-language text that gets passed directly into the model’s context window, they function as an instruction channel distinct from user-facing prompts, yet they are rarely filtered with the same scrutiny.
MCP does not define a protocol-level rule preventing two connected servers from registering tools with identical or similar names, and it does not require cryptographic verification of tool identity or provenance. How naming collisions and cross-server metadata are resolved depends entirely on the client or host implementation. In practice, this means an agent’s decision about which tool to call, or how to interpret the output of a trusted tool, can be shaped by descriptive text supplied by an unrelated, untrusted server present in the same session. Standard application-layer input and output sanitization does not inherently catch this, because the content is model-context data rather than a conventional user input field.
Tool Shadowing vs. Tool Poisoning vs. Prompt Injection
These patterns overlap in practice, but they are not identical. The distinctions below are drawn from how tool shadowing is described relative to the broader tool-poisoning category and to prompt-style instruction channels in MCP deployments.
| Pattern | Primary vector | What is affected | Does the malicious tool need to run? |
|---|---|---|---|
| Tool shadowing | Crafted tool name or description from an untrusted or compromised MCP server in the same session | How the agent interprets or uses a legitimate tool from a different, trusted server | No; metadata alone can be enough |
| Tool poisoning (broader category) | Malicious or manipulated tool metadata and related discovery content, as documented in research that includes shadowing | Agent tool selection, interpretation, or trust assumptions tied to exposed tools | Not always; depends on the specific technique |
| Prompt injection | Adversarial natural-language instructions, typically in user-facing or retrieved content | Model behavior through the prompt or adjacent context channels | N/A; the issue is instruction injection rather than tool registration |
In MCP, tool descriptions are natural-language content that enters the model context. That makes them an instruction channel distinct from user-facing prompts, even though teams often scrutinize prompts more carefully than tool metadata exchanged at discovery time.
Governance and Runtime Enforcement
Because tool shadowing operates through metadata that MCP itself does not mandate isolating or verifying, mitigation depends on controls enforced outside the base protocol, at the client, host, or runtime layer. This includes logging full tool registration payloads, including name, description, schema, and server identifier, at connection time to support later diffing and audit. It also includes policy enforcement points that gate tool execution against an allow-list tied to server identity rather than tool name, and requiring re-approval workflows when a previously approved server’s metadata changes.
Trussed AI provides runtime governance for enterprise AI agents, including runtime policy enforcement, agent identity and permissions, tool approval workflows, and audit logging that can be applied to MCP-connected agent sessions. These capabilities address the governance gap described above, enforcing least-privilege tool exposure and provenance-based execution decisions rather than relying on tool name or description matching alone. They do not eliminate the underlying protocol ambiguity, which remains a specification-level consideration for MCP client and host implementers.
Architectural Controls That Reduce Shadowing Risk
The following controls sit above the base MCP protocol. They reduce the conditions that allow one server’s metadata to influence the use of another server’s tools.
-
Namespace isolation
Enforce server-scoped tool identifiers so identical or similar tool names from different servers cannot be conflated by the agent’s resolution logic.
-
Provenance binding
Bind tool execution decisions to a verified server identity rather than to name or description matching alone.
-
Session segmentation
Limit concurrent connections to multiple untrusted or unverified MCP servers within a single agent session, since shadowing conditions require co-presence of trusted and untrusted tool metadata.
-
Immutable metadata baselines
Capture and hash tool descriptions and schemas at approval time so later changes, a related but distinct risk sometimes called a rug pull, can be detected separately from initial shadowing.
-
Least-privilege tool exposure
Restrict which tools are visible to the agent per session or task rather than exposing the full aggregate tool set from every connected server.
Signals That Indicate Possible Tool Shadowing
Use these indicators during review of registration logs, session behavior, and approval history. None of them is definitive on its own; together they help identify sessions where cross-server metadata may be influencing trusted tools.
- Tool registration logs showing near-identical names or descriptions submitted by different servers in the same session
- Agent tool-selection behavior toward a trusted tool that changes after a new, unrelated server is connected
- Tool metadata that differs between sessions for a server previously approved without modification
- Absence of server-scoped namespacing in client or host tool resolution logic
- No re-approval event recorded despite a change in a connected server’s tool description or schema
- Consequential tool calls proceeding without a logged human approval step tied to server identity
Reduce MCP Tool Shadowing Risk
Runtime governance and least-privilege tool-call enforcement give security teams visibility and control over MCP tool registration and execution before it reaches production agents.
Explore Runtime Governance