The Model Context Protocol (MCP) has made it dangerously easy to connect agents to tools, but it has failed to secure the connection by default. A new analysis highlights that the current MCP authorization spec explicitly states that "Authorization is OPTIONAL for MCP implementations." This means most servers in the wild ship without any enforcement mechanism, allowing agents to invoke tools without revealing who they are, whose credentials they use, or why they are making the call. For teams operating under UK regulatory scrutiny, this lack of visibility is a compliance nightmare waiting to happen.

The Gap in the Protocol

While the spec builds on OAuth 2.1 and requires resource indicators (RFC 8707) to bind tokens to specific servers, it does not mandate that servers accept these tokens or reject those issued for other entities. Consequently, a well-built server only knows about itself, lacking visibility into the broader agent inventory or audit requirements. This isolation creates a security vacuum where shadow servers and unvetted agents can interact with sensitive data without oversight. The solution lies in deploying an MCP gateway, a proxy that brokers every JSON-RPC call between agents and servers, acting as a policy enforcement point rather than a simple API gateway.

Core Functions of an MCP Gateway

A robust gateway must handle four critical jobs: Identity, Per-tool Authorization, Audit, and Approved Server Cataloguing. Instead of sharing service accounts, each agent receives a unique credential, with the gateway exchanging tokens so downstream servers only see tokens minted for them. Access is decided at the individual tool level, allowing granular controls like permitting a support agent to read tickets but denying bulk exports. Furthermore, the gateway filters tools/list responses to prevent agents from discovering tools they cannot use, reducing the surface area for prompt injection attacks. Every call is logged with agent, user, tool, and argument fingerprints, sending data to your SIEM rather than a vendor dashboard.

Real-World Failures and UK Compliance

The need for gateways is not theoretical. In June 2025, Asana took its MCP server offline after a logic flaw exposed data across organizations, affecting roughly 1,000 customers. Similarly, the npm package postmark-mcp was compromised in September 2025, with version 1.0.16 secretly BCC'ing outgoing emails to an attacker. On the client side, CVE-2025-6514 in mcp-remote allowed malicious servers to trigger OS command execution during the handshake. In the UK, while no law mandates an MCP gateway, the NCSC's agentic AI guidance from August 2026 emphasizes unique identities, deny-by-default networking, and immutable logs. Financial firms face further pressure from the FCA's PS26/2, which requires registers of material third-party arrangements by March 2027.

Key Takeaways

  • MCP authorization is optional, leading to widespread security gaps in current implementations.
  • Gateways enforce per-tool permissions and identity management, preventing agents from accessing unauthorized data.
  • Recent incidents involving Asana and postmark-mcp demonstrate the risks of unvetted server connections.
  • UK regulatory guidance from the NCSC and FCA aligns closely with the controls provided by MCP gateways.
  • Data residency questions are critical; verify where the data plane, logs, and control plane physically reside before signing with vendors.

The Bottom Line

Stop trusting your agents implicitly. The MCP spec gives you the primitives for security, but it refuses to enforce them. Deploy a gateway to turn optional authorization into mandatory policy, or risk explaining to regulators why your AI agents had free rein over your data.