MCP security gaps: what IAM teams need to do now

TL;DR: MCP standardises how AI agents invoke tools, but the spec leaves authorization, identity enforcement, and contextual policy to downstream services, creating uncontrolled access paths through reference servers and bearer tokens, according to Pomerium. The security model still treats access as binary, which is too weak for agentic workflows that need traceable, context-aware control.

NHIMG editorial — based on content published by Pomerium: Why the Managed Context Protocol (MCP) spec still leaves gaping security holes

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

Questions worth separating out

Q: What breaks when MCP tools rely on bearer tokens alone?

A: Bearer tokens prove possession, not purpose.

Q: Why do MCP deployments complicate NHI governance?

A: MCP connects agents to tools in a way that can blur the line between a legitimate workload request and an uncontrolled execution path.

Q: How do security teams know if MCP access is actually being governed?

A: Look for evidence that every tool request is evaluated against policy, not just accepted at the endpoint.

Practitioner guidance

• Insert a request-enforcement layer in front of every MCP tool Route agent traffic through a proxy or gateway that evaluates identity, group membership, and session context before the tool endpoint is reached.
• Remove long-lived bearer tokens from MCP pathways Replace broad bearer tokens with scoped, audience-bound credentials that expire quickly and are tied to the initiating identity.
• Scope tool permissions to the smallest usable function Break MCP exposure into narrow tool sets so an agent can only invoke the actions it genuinely needs.

What's in the full article

Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:

• A request-by-request enforcement pattern for MCP traffic in front of internal tools.
• The practical differences between reference-server convenience and production-ready access control.
• How identity, group, and session context can be used to gate tool invocation.
• An example workflow for safely routing internal data into an MCP-compatible assistant.

👉 Read Pomerium's analysis of MCP security gaps and Zero Trust enforcement →

MCP security gaps: what IAM teams need to do now?

Explore further

View Full Forum →  |  NHI Foundation Course →