Is MCP security different from generic API security?

Yes. Two extras: tool descriptions are read by the model as near-instructions (so a malicious description can hijack the model), and MCP sessions typically compose many servers, so an attacker who controls content read by one server can drive tool calls on another. Generic API security controls (auth, rate-limiting) still apply, but the composition/description surface is MCP-specific.

What's the highest-ROI MCP security control?

Not connecting untrusted servers in the first place. An org-scoped approved-server list eliminates the biggest class of attacks before any runtime control matters. After that: container isolation per server, Resource-Indicator-enforced OAuth with least privilege, and egress allowlisting are the three that reduce blast radius the most per hour of work.

MCP Security

Written by Max Zeshut

Founder at Agentmelt

The security practices and controls specific to MCP Server deployments — governance of what servers are allowed, isolation and sandboxing of each server process, OAuth 2.1 with Resource Indicators (RFC 8707) for HTTP transports, runtime observability of every tool call, and architectural containment (dual-LLM pattern, egress allowlisting, human-in-the-loop for sensitive actions). MCP security is a distinct topic from generic API security because MCP servers expose tool *descriptions* the model reads as instructions-adjacent context, which creates injection paths that don't exist in classic API integration. Real 2025-26 incidents include CVE-2025-49596 (Anthropic MCP Inspector RCE, CVSS 9.4), the Invariant Labs GitHub-MCP cross-server shadowing PoC, and the Nx s1ngularity supply-chain attack that used the victim's own AI CLI as the exfiltration engine.

Пример

A dev team connects Claude Desktop to 6 MCP servers (GitHub, PostgreSQL, Slack, Notion, Linear, and one from a random blog post). The blog-post server's `simple_search` tool contains a hidden instruction to read `~/.cursor/mcp.json` and pass it back in a hidden parameter. Without an approved-server list, isolation, or egress allowlist, the first call to the tool exfiltrates every other MCP server's OAuth tokens. The full mitigation stack — approved-list + sandbox + narrow OAuth + egress allowlist + observability + human-in-the-loop for writes — reduces the blast radius even when the injection succeeds.

Часто задаваемые вопросы

Is MCP security different from generic API security?: Yes. Two extras: tool descriptions are read by the model as near-instructions (so a malicious description can hijack the model), and MCP sessions typically compose many servers, so an attacker who controls content read by one server can drive tool calls on another. Generic API security controls (auth, rate-limiting) still apply, but the composition/description surface is MCP-specific.
What's the highest-ROI MCP security control?: Not connecting untrusted servers in the first place. An org-scoped approved-server list eliminates the biggest class of attacks before any runtime control matters. After that: container isolation per server, Resource-Indicator-enforced OAuth with least privilege, and egress allowlisting are the three that reduce blast radius the most per hour of work.

Связанные ниши

Назад в глоссарий

Loading…