MCP Security Needs Four Layers, Not Just a Gateway

Over thirty CVEs hit MCP deployments in the first sixty days of 2026, with scans showing 38% of servers lacking authentication on critical endpoints and 43% vulnerable to command execution. A CVSS 8.8 SSRF in Azure MCP Server (CVE-2026-26118) leaked managed identity tokens, proving that inbound authentication at a gateway alone is not sufficient protection.

The core argument is that MCP security should be modeled as four distinct control layers rather than one protocol feature: safe tool execution, an isolated management plane, a bounded outbound trust boundary, and semantic integrity. Gateways excel at authentication, authorization, and audit, but they cannot verify that tool handlers execute safely, cannot isolate inspectors and admin consoles, cannot police a server's own outbound calls, and cannot detect when previously approved tool definitions silently change (rug-pull attacks).

For engineers running MCP in production, the practical takeaway is concrete: CI gates that flag unsafe execution patterns, network isolation for management tooling, manifest pinning with diff-based review at registration, and behavioral baselines for outbound traffic are all implementable now, without waiting on protocol changes. With enterprise adoption outpacing the security specification's maturity, this operational discipline is the near-term substitute for a finished standard.