Why the Managed Context Protocol (MCP) Spec Still Leaves Gaping Security Holes

TL;DR — MCP gives AI agents a shared way to invoke tools and complete tasks. But the spec lacks core security features. There is no built-in authorization, no identity enforcement, and no way to apply context-aware policy. Teams relying on reference servers are exposing internal APIs without guardrails. Pomerium applies Zero Trust controls to every request, adding identity, context, and policy enforcement at Layer 7.

Standards, hype, and the expanding AI attack surface

Managed Context Protocol (MCP) is becoming the standard for how AI agents interact with tools. It introduces a shared format, common terminology, and interoperable communication patterns.

This makes it easier to build agentic workflows across vendors, models, and environments. It lowers the barrier to experimentation and reduces integration complexity.

It also opens up a new surface area. When tools are made more accessible to agents, they also become more accessible to attackers or misconfigured agents.

The spec does not provide security controls to mitigate this.

What MCP leaves out: authorization, context, and least privilege

There are four critical areas where the MCP spec offers no protection:

• Authorization (AuthZ): MCP tool calls are expected to be validated by the receiving service. Most tools do not implement fine-grained authorization, so endpoints are often left open.

• Bearer token control: The spec encourages bearer token usage but does not guide how those tokens should be scoped or validated. Many teams pass long-lived tokens without expiration or audience restrictions.

• Contextual enforcement: There is no requirement to tie a request to the initiating user, team, or session. As a result, tools cannot distinguish whether a request is appropriate in context.

• Least privilege: Access is binary. Either a tool is exposed, or it isn't. The spec does not support policy layers to restrict usage based on identity, role, or environment.

These gaps are not edge cases. They affect every MCP-based deployment in dev and production environments. 

OAuth tokens and reference servers are not enough

Teams commonly use reference servers to bootstrap MCP deployments. These implementations are helpful for getting started but are not designed for secure production environments.

Many reference servers:

• Accept bearer tokens with no scoping or expiration

• Forward traffic without verifying the identity behind the request

• Operate without a deny-by-default posture

• Lack audit logging or session validation

There have been deployments where agents passed OAuth tokens directly from LLMs to tool servers. These tokens were accepted and processed without challenge. Access was granted based only on possession of the token.

This is not intentional negligence. It's the result of assuming that the protocol or the reference server handles more than it does.

Pomerium secures MCP with identity and policy enforcement

Pomerium acts as a reverse proxy in front of your tools. It evaluates every incoming request and applies access controls based on policy, user identity, and session context.

What this means in practice:

• Only verified users or agents can access protected resources

• Requests are evaluated against declarative policy rules

• Context like group membership, time, or environment can influence access

• Full logs are generated for every decision

This creates a Zero Trust enforcement layer around your MCP infrastructure. Access becomes explicit, traceable, and auditable.

Using Claude (or other LLMs) with internal tools, safely

Imagine routing internal data into Claude through an MCP-compatible tool server. The goal is to answer support tickets using live customer data.

Without Pomerium:

• Any agent that reaches the endpoint with a token can access the tool

• There is no verification of the user behind the prompt

• Access is not scoped to role, session, or prompt type

With Pomerium:

• Only requests initiated by authenticated support reps are allowed

• Group membership and session context are verified

• Access is logged with full traceability

You define the rules, and Pomerium enforces them at the network layer.

Get started with Pomerium for MCP

Pomerium supports MCP workflows by enforcing identity-, policy-, and context-aware access controls in front of your MCP-compatible tools.

To secure MCP traffic:

1. Deploy Pomerium Zero in your environment

2. Route inbound agent traffic through Pomerium

3. Define policies that gate access by identity, group, or session context

4. Monitor activity in your logs

See full setup instructions in the Pomerium docs