How do you secure MCP servers and tool calls?
To secure MCP-based agents, treat MCP tool descriptions, schemas, responses, and server outputs as untrusted context until verified. Pin tool names, descriptions, and schemas; detect drift and shadowing; inspect every tool call before execution; and prevent MCP responses from authorizing actions outside their source-to-sink policy.
- MCP adds tool descriptions, schemas, and responses to the instruction surface.
- Pin tool names and schemas; detect rug-pull drift and tool shadowing.
- Inspect every tool call — name, args, resource, identity, tenant, side effects — before it runs.
- MCP responses are untrusted context: they can inform, but not authorize actions outside policy.
What MCP changes about the attack surface
MCP lets agents discover and call external tools. Tool descriptions and schemas become part of what the model reads, so a malicious or changed server can inject instructions or redefine a tool. Treat everything an MCP server returns as untrusted until verified.
Drift, rug-pulls, and shadowing
Pin tool names, descriptions, and schemas, then detect when they change (a rug-pull) or when a malicious namespace impersonates a trusted tool (shadowing). A JSON-RPC gateway can enforce these checks on tools/list and tools/call. See tool-call security.
Keep MCP responses in their lane
An MCP tool result is an observation, not a command. Source-to-sink policy prevents an MCP response from authorizing exports, credential use, memory writes, or further tool calls outside its authority class — the same discipline described in what is a context firewall.