Topic · MCP Security

MCP Security

Crawdad Security·Published ·Updated
In short

MCP security is the practice of protecting AI agents that use the Model Context Protocol — the emerging standard that connects agents to external tools and data — from a class of attacks unique to how the protocol handles trust. The core problem is that MCP merges an agent's reasoning and its control flow in a shared context: tool descriptions, metadata, and executable instructions coexist without strong isolation, so attacker-controlled text in a tool can be read by the model as trusted instructions. The result is attacks such as tool poisoning, rug pulls, and cross-server shadowing that have no equivalent in traditional API security.

Key facts

What is the Model Context Protocol (MCP)?

MCP is a standard by which an AI agent discovers and calls external tools — file systems, APIs, databases, and other services. When an agent connects to an MCP server, it requests the server's available tools, and the server returns a description of each: a name, a natural-language description, and an input schema. The agent's model uses those descriptions to decide when and how to call each tool. MCP has been adopted rapidly across the agent ecosystem, and its adoption has outpaced its security posture.

Why is MCP a security risk?

The risk is structural, not incidental. Mature middleware such as REST or gRPC separates concerns: transport is one layer, authentication another, execution another, with clear boundaries between them. MCP does not. It merges reasoning and control flow within a shared semantic context — the context window — where the agent's own instructions, the tool descriptions it reads, the tool responses it receives, and the data it processes all coexist as text, without strong isolation between them. That fluidity is what makes MCP flexible, and it is also what removes the boundary an attacker would otherwise have to cross. Text that the agent is merely supposed to read can be interpreted by the model as instructions to follow.

What are the main MCP attacks?

Tool poisoning is the most prevalent and impactful. Malicious instructions are hidden in a tool's description — text the model reads at the same trust level as its system prompt but the user typically does not see. A poisoned “add” tool, in Invariant Labs' original demonstration, instructed the agent to read the user's SSH private key and exfiltrate it while displaying only “Adds two numbers.” See the dedicated Tool Poisoning page for the full mechanism.

Rug pulls exploit the fact that a tool may be reviewed only once. A server serves a benign tool definition at approval time and swaps in a malicious one later.

Cross-server shadowing lets a malicious server's tool description manipulate the agent's use of a different, trusted server's tools — compromising the agent even with respect to infrastructure it trusts.

Full-schema poisoning (demonstrated by CyberArk) extends tool poisoning beyond the description field: every part of a tool's schema, including parameter names and the input schema itself, enters the model's context and can carry an injection.

Why is the “connect-time vs runtime” gap the root issue?

MCP tool descriptions are inspected, if at all, once — at connect time, when the agent enumerates a server's tools. But tool responses, returned on every call at runtime, flow directly into the model's context with no equivalent inspection. There are two channels by which attacker-controlled text reaches the model at high trust, and typically only one is checked. This unguarded runtime channel is what much of MCP's attack surface exploits, and it is why inspecting a tool's static description is necessary but not sufficient.

How do you secure MCP?

Recommended controls operate at several layers. At the description layer: pin and review tool definitions (treating a change as a dependency update, per Microsoft's guidance), require signed tool manifests, and scan tool metadata for embedded instructions. At the session layer: scope an agent to only the tools a given task requires, rather than every tool a server offers. And at the runtime layer: inspect the concrete actions an agent takes — the file reads, the tool calls, the network egress — because these are the same regardless of how a poisoned description or response was written or obfuscated. A defense that watches the action, on the agent's actual traffic, is not defeated by a payload hidden in a description's Unicode or whitespace, which is the evasion that defeats description scanning alone.

How Crawdad approaches MCP security

Crawdad inspects an agent's actual traffic on the wire — including its MCP tool calls and the responses they return — on the device where the agent runs. Because it evaluates the concrete action rather than trusting the tool description, it addresses the unguarded runtime channel that MCP's connect-time review misses: an obfuscated tool-poisoning payload and a plaintext one produce the same observable action (a sensitive file read, an egress), and Crawdad acts on the action. Crawdad's public benchmark includes supply-chain and tool-abuse attack categories drawn from real MCP-abuse patterns.

A dedicated reference page for the OWASP Agentic Top 10 (ASI04, agentic supply chain) is being added to the Topics section.

Primary sources