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.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “Secure Access for Model Context Protocol (MCP)”.
Key questions
Q: How should security teams govern managed MCP access for AI clients?
A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task.
Q: Why do static OAuth scopes fail for agentic workflows?
A: Static scopes fail because they assume the action set is known when access is granted.
Q: What are the signs that MCP authorisation is too coarse?
A: Warning signs include broad bearer tokens reaching internal services, the same scope covering many tools, approvals that never consider request context, and audit logs that show only login events instead of per-action decisions.
Practitioner guidance
- Define per-action policy for MCP servers Evaluate each file access, API call, and system update against live context such as user role, request path, device posture, and time of day before the action is forwarded.
- Remove raw bearer tokens from the agent path Translate external identity into short-lived signed assertions at the proxy so MCP services never receive reusable OAuth tokens from the agent itself.
- Separate authentication from authorisation in design reviews Review MCP architectures to confirm that login success does not automatically permit tool use, data access, or workflow execution.
Bottom line: MCP changes the identity problem because agent sessions can move from data retrieval to system action without a new human checkpoint.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 11:08 pm
Static scopes are a provisioning assumption, not an agent control. They assume access can be granted in advance and evaluated later, but MCP agents act at runtime with behaviour that can change inside a single session. That makes scope-based governance too coarse for the actual decision point. Practitioners need to treat each tool call as a new authorisation event.
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: How do Zero Trust controls apply to MCP server security?
A: Zero Trust applies by forcing each tool call through policy, context, and revocation rather than trusting an established session. For MCP, that means per-request authorization, isolated execution, and continuous auditability so a compromised agent or server cannot keep acting unchecked.
👉 Read our full editorial: MCP security needs context-aware authorization, not static scopes
This post was modified 2 days ago by NHI Mgmt Group