Secure Access for Model Context Protocol (MCP)

What Is MCP Security and Why Does It Matter in 2025?

The Model Context Protocol (MCP) is reshaping how AI agents interact with data, tools, and infrastructure. By giving agents the ability to query databases, trigger workflows, and update systems autonomously, MCP unlocks new levels of automation. But with this power comes risk.

When a machine can update infrastructure, summarize PII, or make purchases — all from a single prompt — security can’t be static. That’s the challenge of MCP.

Traditional security models weren’t built for autonomous agents.

• OAuth 2.1 covers identity but misses real-time intent

• VPNs can’t support cloud-based LLMs like Claude or ChatGPT

• Static scopes fail to adapt to behavioral context

As Microsoft’s security team and the MCP spec itself warn, scope-based models fail to prevent agent misuse, prompt injection, or confused deputy attacks. We don’t just need authentication—we need continuous, context-aware authorization.

Why Securing MCP Is Different (And Riskier)

MCP is an open standard that connects AI agents (powered by LLMs) to real-world tools and data. It turns chatbots into autonomous operators. Whereas ChatGPT and Claude respond to prompts, MCP agents can act—querying a database, calling an API, or modifying systems. Imagine GPT-based assistants pulling live analytics for a PM or updating server configs for SREs on the fly.

That autonomy introduces unpredictable risk.

Agentic workflows don’t follow traditional rules:

• Intent is inferred, not explicit

• Boundaries are dynamic

• One action can cascade across multiple systems

For example, a simple prompt like “summarize our database” might trigger multiple downstream actions—retrieving sensitive data from various sources. Without fine-grained policy controls, the agent’s behavior becomes a liability.

This means:

• One compromised agent can exfiltrate sensitive data in seconds

• OAuth tokens with broad scopes act as dangerous skeleton keys

• Prompt injection can hijack session behavior in real time

Even the MCP spec admits: security enforcement is left up to the implementor. Proxies should be used — but how they enforce policy is undefined.

Traditional auth isn’t enough for autonomous AI.

We need real-time, Zero Trust enforcement designed for AI-native architectures.

Want to see how Pomerium actually secures an agentic MCP stack? Watch the full demo below:

OAuth vs Zero Trust: Why Real-Time Enforcement Matters for MCP

The MCP specification acknowledges the need for secure enforcement layers — recommending the use of application gateways and proxies. But most early implementations rely solely on OAuth to issue bearer tokens to the agent.

That might validate identity, but it doesn’t authorize intent or behavior.

OAuth ≠ real-time authorization.

OAuth was built for delegated access — not for real-time decisions. It can’t keep up with autonomous agents making high-risk decisions at machine speed.

How OAuth Falls Short for MCP Agents

The Confused Deputy Problem

Imagine an attacker injects a malicious instruction mid-session. The agent executes it — because the token says it can.

Microsoft security researchers have documented how prompt injection can hijack LLMs into performing unauthorized actions, even triggering remote code execution.

Why? Because the agent can act, and nothing is checking if it should.

Static scopes don't understand:

• Why the action is being taken

• Who the true initiator is

• Whether it's appropriate right now

To secure MCP workflows, every request must be evaluated in context:

• The user’s identity

• The tool or system being accessed

• The intent and conditions of the request

OAuth can’t do that. But Pomerium can.

Zero Trust for Agentic AI Architectures

The right security model for MCP-based architectures is Zero Trust.

Zero Trust assumes no implicit trust. Every action — even from a verified identity — must be authorized per request.

For AI agents, this means:

• Evaluate every file access, API call, or update

• Use fine-grained, dynamic policies

• Apply identity, role, context, and intent to each decision

The goal: behavior-based security, not just authentication.

Behavior, Not Just Identity

Pomerium brings Zero Trust to the application layer. It evaluates:

• Who is the agent acting on behalf of?

• What is the agent attempting to do?

• Does this action match the expected behavior in this context?

Instead of static OAuth scopes, Pomerium policies evaluate in real time:

• User role

• Time of day

• Origin of request

• Type of action

• Request path

• Session attributes

• Customer headers

Example:

An agent can query customer records only if it’s acting on behalf of a support engineer, during business hours, from a trusted device.

Same agent. Same token.

But the moment one of those variables changes — it’s blocked.

That’s the difference between permission and authorization.

Here's a real-world example of a Pomerium route policy protecting vanilla HTTP MCP Servers:

routes:
 - from: https://github.localhost.pomerium.io
    to: http://localhost:3020
    policy:
	allow:
  and:
    - domain:
        is: example.com
    mcp: {}
    timeout: 0s

Here's another example of integrating with upstream OAuth2:

routes:
 - from: https://github.localhost.pomerium.io
    to: http://localhost:3020
    allow_any_authenticated_user: true
    mcp: 
      upstream_oauth2:
        client_id: xxxx
        client_secret: xxx
        scopes: ["read:user", "user:email"]
        endpoint:
          auth_url:  "https://github.com/login/oauth/authorize"
          token_url: "https://github.com/login/oauth/access_token"
    timeout: 0s

Restricting MCP tool usage with a Pomerium policy:

routes:
 - from: https://github.localhost.pomerium.io
    to: http://localhost:3020
    policy:
      allow:
       and:
        - domain:
            is: example.com
        - mcp_tool:
            in: [“search”,”fetch”]
    mcp: {}

Full Visibility and Access Audits

With Zero Trust, enforcement and observability go hand in hand.

Zero Trust isn’t just enforcement — it’s observability.

Pomerium logs every decision:

• Who requested access

• What was attempted

• When and where it happened

• Why it was allowed or denied

These logs support:

• Compliance reporting (SOC 2, HIPAA, etc.)

• Security incident response

• Threat detection and real-time monitoring

The new perimeter is intent. And you can’t secure intent with static credentials.

Why Pomerium is the Best MCP Security Gateway

Pomerium is an identity-aware proxy that enforces Zero Trust for agentic workflows.

Think of it as a smart security layer that sits between your agents and MCP servers — making real-time access decisions, enforcing Zero Trust, and logging everything.

How Pomerium Works in an MCP Architecture

1. Authentication: Agent initiates a request. Pomerium authenticates the user via SSO.

2. Issue JWT: Issues a short-lived JWT scoped to request context. Injects identity into headers.

3. Authorization: Evaluates user, system, and action. If approved, forwards the request. If not, blocks it.

4. Logging: Logs every action for auditing, compliance, and real-time monitoring.

At no point does the MCP server see a raw OAuth token. It sees a clean, signed identity assertion from Pomerium — reducing trust sprawl and eliminating token leakage risk.

Additional Security Benefits

Pomerium supports:

• Stripping sensitive headers

• Injecting policy metadata

• Masking/redacting content

• Enforcing session timeouts

• Full support for gRPC, HTTP/2, WebSockets

Every action is auditable. If an agent goes off-script — Pomerium catches it.

MCP turns agents into drivers. Pomerium is the seatbelt, radar, and guardrail — keeping them on track and accountable.

Security Features for MCP Access

Here’s a breakdown of the capabilities Pomerium brings to every agent interaction:

Who Needs MCP Security: Teams That Benefit from MCP Security

Platform & Infrastructure Teams
Pomerium provides a single point of policy management for all MCP access. Rather than implementing auth in each MCP server or managing countless tokens, you declare policies in one place. Pomerium gives you a central policy layer that works across all your environments. No need to update every server. No more scattered logic.

• Drop-in proxy for consistent enforcement

• Define policy once, apply everywhere

• Reduce complexity and misconfiguration

Security & Compliance Teams
Pomerium brings provable control to agentic systems. Every agent action is:

• Authenticated

• Authorized

• Logged

Need to show auditors who accessed what, when, and under what rules? Pomerium makes that traceable. Want to limit access based on geography, role, or device posture? Easy.

It turns zero trust from a concept into a practical control plane.

Developers & Agent Builders
Build your agents and we’ll handle the auth.

With Pomerium in front of your MCP stack:

• No more embedding OAuth flows in every agent

• No need to manage or rotate long-lived credentials

• No manual identity in downstream services — just clean, signed JWTs

Pomerium simplifies security. Developers get a safe-by-default system that doesn’t slow them down.

Why Pomerium for MCP Security?

Prompt Injection Mitigation

Agents can be manipulated — but Pomerium mitigates downstream risk.

Even if a prompt injection confuses the agent, Pomerium’s policy engine still evaluates the action, not just the input. If the agent attempts something unauthorized:

• It’s blocked

• It’s logged

• It’s contained

Pomerium decouples agent behavior from system access.

Centralized Policy Enforcement

No more scattered access logic. Pomerium enforces policy as a consistent control layer for:

• Dev, staging, and prod

• All MCP APIs and endpoints

• Internal or external-facing agents

Update policies centrally. Apply them instantly — no need to redeploy apps or update config files.

Centralized Identity & SSO

Connect Pomerium to your existing Identity Provider — Okta, Azure AD, Google Workspace, etc.

Agents inherit user-level identity, which powers downstream controls:

• Clean attribution (every action tied to a user)

• Finer-grained permissions

• Easier onboarding/offboarding of access

Per-Action Authorization

Static tokens are not enough to properly secure MCP servers or agents.

Pomerium checks every request against live policy:

• Who made the request?

• What is being accessed?

• Is this action allowed right now?

Use policies that evaluate user role, time of day, IP geolocation, device posture — even request body metadata. Enforce Zero Trust at the action level.

Centralized Logging & Telemetry

Every allow or deny decision is logged — with full context:

• Who made the request

• What they tried to access

• When it happened

• Why it was allowed or denied

All logs are ready to feed into your SIEM, so you can monitor or alert in real time.

No Token Passthrough

Pomerium ensures agents never directly handle credentials to your MCP servers.

Instead of letting tokens float between agents and internal services, Pomerium:

• Validates external identity tokens (e.g., OAuth)

• Translates them into short-lived, scoped JWTs

• Injects them into requests as identity assertions

This means:

• No raw tokens are exposed to agents

• Nothing sensitive is stored client-side

• Backend services trust Pomerium’s signed identity, not arbitrary bearer tokens

Your services don’t need to verify OAuth flows. They simply trust that Pomerium already did.
It’s a clean separation of concerns: the agent drives the request, but Pomerium controls the keys.

This drastically reduces the risk of:

• Token leakage

• Misuse by compromised agents

• Lateral movement from credential sprawl

You own the proxy. You own the trust boundary.

Side-by-Side Comparison

MCP Security Demo: See Pomerium in Action

Explore our MCP demo app. It showcases:

• Agent attempts to call sensitive services

• Policies blocking out-of-scope behavior

• Complete traceability and visibility

Want to meet with the team to dive deeper? Book a demo ->

MCP Security FAQ

Q: Is Pomerium compatible with the official MCP specification?

A: Yes. Pomerium works at the network/application layer and is fully transparent to MCP’s protocols. MCP uses JSON-RPC over HTTP(S), which Pomerium can proxy without issue (including support for HTTP/2 and streaming). In fact, the MCP spec itself anticipates that proxies or gateways will be used for security – Pomerium fulfills exactly that role. You don’t need to modify MCP clients or servers; you simply configure them to communicate through Pomerium (similar to how you’d set up a reverse proxy). Pomerium adds authentication and authorization on top of MCP without breaking the protocol. This means you can adopt Pomerium for security and still remain 100% compliant with the MCP spec.

Q: Does using Pomerium replace OAuth in our MCP implementation?

A: Pomerium can augment or replace the need for custom OAuth handling in your MCP workflow. If you’ve been using OAuth 2.x for authentication, you can continue to use your Identity Provider – Pomerium will integrate with it and use those identities. What Pomerium replaces is the application of OAuth tokens directly between agents and servers. Instead of agents managing access tokens for each MCP server, Pomerium handles the OAuth flow with your IdP, then enforces policy on each request. In short, you still have OAuth/OIDC under the hood for identity, but you no longer need to embed OAuth logic in your agents or accept tokens at your MCP servers. Pomerium’s approach is more robust than vanilla OAuth because it adds contextual authorization and eliminates trust in static scopes. TSo you can think of it as using OAuth for authentication, but Pomerium for authorization. If you already have OAuth tokens, Pomerium can even consume and validate them (e.g., via OIDC integration), then still apply its fine-grained policy on top. It’s the best of both worlds: continue leveraging your IdP, while gaining a powerful authorization layer.

Q: What if we use hosted LLMs or external AI services (e.g. OpenAI, Anthropic Claude) in our workflow?

A: Pomerium can still help secure the connections between your hosted AI agents and your internal tools. For example, if you have a ChatGPT plugin or a Claude integration that needs to access an internal MCP server or API, you can put Pomerium in front of that internal endpoint. The external AI service would then need to authenticate to Pomerium (e.g., using an OAuth client credential or a service account identity that you control). Pomerium would ensure that even a hosted agent only accesses what it’s supposed to. Admittedly, with third-party AI services you can’t run Pomerium inside their environment, but you can absolutely protect everything on your side. Any call from the AI to your systems goes through Pomerium’s proxy. This means you can impose policies like “Claude can only retrieve data from this one database and nothing else,” or “the ChatGPT plugin can only call our MCP server read-only.” In summary, even with hosted LLMs, you secure the integration point: Pomerium sits between the external AI and your internal services, acting as an identity-aware gatekeeper. This approach complements whatever built-in auth those services provide (for instance, you might give the AI a scoped API token to hit Pomerium, and Pomerium then adds your org’s policy on top of that request).

Q: What’s the performance impact of adding Pomerium?

A: Negligible. Pomerium is built on the highly optimized Envoy Proxy, which is used at massive scale across the industry. It’s designed to handle thousands of requests per second with sub-millisecond latency overhead per request. In most cases, the bottleneck remains the LLM or the backend service, not the proxy. Pomerium’s authorization check is in-memory and efficient, and it can maintain persistent connections to backend MCP servers for optimal throughput. We’ve observed that for typical MCP interactions (which are often I/O-bound or involve waiting on the LLM), the added delay from Pomerium’s check is negligible – on the order of a few milliseconds. Additionally, Pomerium supports horizontal scaling: you can run multiple proxy instances if you have very high load, and they will share state via the control plane. The bottom line is that you gain security and logging at virtually no noticeable cost. In fact, many users find that the ability to cache session info and reuse connections through Pomerium can even improve overall efficiency. So, you can deploy Pomerium with confidence that your agents will still operate at machine speed, now just with much safer guardrails.

Q: How does Pomerium handle MCP’s ongoing connections or streaming data?

A: MCP often involves persistent connections (for example, an agent maintaining a session to a server to stream data or keep context). Pomerium can proxy long-lived connections and even bi-directional streams. It fully supports WebSockets and HTTP/2 streaming. When an MCP client first initiates a connection, Pomerium will perform the authN/authZ check at the start. Once established, the traffic can flow through. If your policies need to apply to individual messages in a stream, you can structure the MCP API calls such that each action still goes through an authorization step (e.g., separate RPC calls). Pomerium can’t interpret the content of a binary stream (it’s not inspecting and filtering inside the JSON-RPC messages), but it controls the session at the protocol level. You can also configure timeouts or re-auth requirements for long connections. For instance, you might require the agent to re-auth after an hour, or disconnect if the user’s role changes. In essence, Pomerium ensures the connection establishment and any discrete RPC calls are authorized. The streaming data within an allowed session flows at wire speed. And of course, all such connections are encrypted (Pomerium terminates TLS and can enforce TLS to the backend), and auditable – if an agent is maintaining a 30-minute session to a sensitive tool, you’ll know it and can even cut it off by policy if needed.

The future of software is autonomous. But autonomy without governance is a risk.

Pomerium turns agentic freedom into security confidence.

Secure your MCP stack today.

[Start Now →] [Book Demo →]