Notifications
Clear all
Topic starter
12/06/2026 9:13 pm
TL;DR: MCP turns AI agents into autonomous operators that can query data, trigger workflows, and update systems, but static OAuth scopes, VPNs, and traditional auth models do not capture real-time intent or per-action risk, according to Pomerium. The governance gap is not authentication alone, but continuous, context-aware authorization for agent behaviour.
NHIMG editorial — based on content published by Pomerium: Secure Access for Model Context Protocol (MCP)
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when AI agents rely on static OAuth scopes for MCP access?
A: Static OAuth scopes break because they describe delegated permission at the moment of issuance, not the live intent behind each agent action.
Q: Why do AI agents make Zero Trust more important for identity governance?
A: AI agents make Zero Trust more important because the trust boundary shifts from login to each action the agent performs.
Q: How can security teams know whether MCP authorization is actually working?
A: They should look for evidence that each tool call is being independently judged and that allow or deny decisions are logged with context.
Practitioner guidance
- Move MCP enforcement to the application layer Place an identity-aware proxy or gateway in front of MCP servers so each tool call is authorized against live context instead of relying on bearer-token validity alone.
- Constrain tool permissions by action and context Define policies that distinguish between read, query, update, and administrative actions, then require user role, request origin, and session attributes before allowing each one.
- Log allow and deny decisions with full context Capture who requested access, what tool was attempted, when it happened, and why it was allowed or blocked so investigations can reconstruct agent behaviour.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step policy examples for routing MCP traffic through an identity-aware proxy.
- Concrete route rules for restricting MCP tool usage by request attributes and allowed actions.
- Implementation details for JWT injection, no-token-passthrough, and per-request logging.
- Performance and streaming guidance for gRPC, HTTP/2, and WebSocket-based MCP connections.
👉 Read Pomerium's analysis of secure access for Model Context Protocol →
MCP security for AI agents: are static scopes enough?
Explore further
12/06/2026 11:08 pm
Static scopes are the wrong governance primitive for MCP. Static authorization was designed for request paths where the actor, tool, and intent are stable enough to evaluate at grant time. That assumption fails when an agent can chain actions, select tools dynamically, and change the effective risk of the session after authorization. The implication is that MCP governance cannot be reduced to token issuance or coarse scope design.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when an AI agent with valid access performs an unauthorized action?
A: Accountability sits with the organisation that defined the access boundary, because a valid token does not equal a valid intent decision. In practice, IAM, platform, and security owners need a shared policy model for MCP so that responsibility is not lost between the model, the proxy, and the backend service.
👉 Read our full editorial: MCP security needs context-aware authorization, not static scopes
