Topic starter
10/06/2026 12:54 am
TL;DR: MCP systems let agents chain tool calls across billing, CRM, and support workflows, but the real failure mode is authorization drift, not authentication bypass, according to Pomerium. Session-based trust and coarse network controls break down when one delegated request can expand into multiple unintended actions.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “MCP Security: Why MCP Is an Authorization Crisis”.
Key questions
Q: What breaks when MCP authorisation is only checked at session start?
A: The system loses the ability to judge whether later tool calls still match the original intent.
Q: Why do authorised MCP sessions still create data security risk?
A: Because approval to call a tool does not guarantee the payload is safe.
Q: How do security teams know whether MCP authorization is actually working?
A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently.
Practitioner guidance
- Preserve originating identity through delegation Bind the human or workload principal to each downstream tool call so billing, CRM, and support services can evaluate the real actor, not a flattened agent identity.
- Evaluate authorisation on every tool invocation Treat each MCP action as a fresh decision point and require policy checks on the exact parameters, method, and target resource before execution.
- Move controls to Layer 7 enforcement Apply context-aware policy where the request semantics are visible, because network boundaries and service-to-service authentication cannot judge intent.
Bottom line: MCP shifts the security problem from authentication to authorisation because agents can chain valid actions beyond the original user’s intent.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 hours ago by NHI Mgmt Group
11/06/2026 2:28 am
Authorization, not model safety, is the core MCP governance problem. The article is right to move the debate away from prompt filtering and toward the control plane that decides what an agent may do. MCP makes the agent an active decision-maker, which means the security question becomes whether delegated authority is still bounded when tool selection and execution happen inside the same runtime path. Practitioners should treat MCP as an authorization architecture problem, not an AI content problem.
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.
- Only 5.7% of organisations have full visibility into their service accounts, which means most environments cannot reliably trace non-human access paths end to end.
A question worth separating out:
Q: How can teams reduce the blast radius of tool-using agents?
A: Limit the tools, parameters, and data domains an agent can reach, and evaluate each invocation against the originating principal and task scope. The goal is to prevent a single delegated request from becoming broad data access or cross-system action without a fresh authorization decision.
👉 Read our full editorial: MCP security is an authorization crisis for AI agents
12/06/2026 4:02 am
Authorization drift is the correct name for MCP risk: the failure is not that an attacker breaks authentication, but that valid authority keeps expanding after the initial delegation decision. Pomerium’s analysis is useful because it shows the system can remain technically functional while the governance model becomes inaccurate. The practitioner takeaway is that delegated execution needs a new authorisation boundary, not just better model safety.
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: What is the difference between agent delegation and ordinary service-to-service access?
A: Ordinary service-to-service access usually assumes a stable workload and a narrow purpose, while agent delegation can select tools, chain requests, and shift context mid-task. That makes the authorisation decision dependent on semantics and intent, not just on credentials or network path.
👉 Read our full editorial: MCP security is an authorization crisis for AI agents
This post was modified 5 hours ago by NHI Mgmt Group