Topic starter
12/06/2026 12:24 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “Why the Managed Context Protocol (MCP) Spec Still Leaves Gaping Security Holes”.
Key questions
Q: What breaks when MCP tools are exposed without policy controls?
A: Without policy controls, MCP tools become a discoverable privilege surface rather than a governed capability set.
Q: Why do bearer tokens create risk in MCP if they are reused across systems?
A: Bearer tokens become risky when they are portable across trust boundaries.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token.
Practitioner guidance
- Define MCP enforcement points Place policy enforcement in front of every MCP-compatible tool so the request is evaluated before the tool executes, not after the token is accepted.
- Bind access to user context Require the initiating user, group membership, and session context to be checked on each tool call instead of trusting bearer-token possession alone.
- Replace reference-server assumptions Treat reference servers as development scaffolding only, and move any production traffic behind deny-by-default controls with full request logging.
Bottom line: MCP makes it easier for AI agents to reach internal tools, but the security decision still has to be enforced by the receiving service, not assumed from the protocol.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
12/06/2026 9:37 am
MCP has exposed a governance gap, not just a protocol gap: the problem is not that AI agents need a shared tool interface, but that the interface is being deployed without an equivalent identity and policy boundary. Once internal tools are reachable through MCP, the burden shifts from the protocol to the enforcement layer. Practitioners should treat MCP as the start of the access design, not the end of it.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations route agent traffic through a policy layer?
A: Yes. Agent traffic needs the same kind of contextual enforcement that protects other sensitive access paths, especially when internal tools can reach customer data or administrative APIs. A policy layer gives the team a decision point that MCP itself does not provide.
👉 Read our full editorial: MCP security gaps expose AI agents to uncontrolled tool access
This post was modified 1 day ago by NHI Mgmt Group