Notifications
Clear all
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.
NHIMG editorial — based on content published by Pomerium: MCP Security: Why MCP Is an Authorization Crisis
Questions worth separating out
Q: How should security teams govern AI agents that use MCP tools?
A: Treat the agent as a delegated identity with bounded authority, not as a passive integration.
Q: Why do session-based controls fail for MCP workloads?
A: Session-based controls assume the trust decision made at login remains valid across the session.
Q: What do organisations get wrong about MCP security?
A: They often focus on network isolation or prompt filtering and miss the real issue: an authorised workload can still perform an unintended action.
Practitioner guidance
- Map delegated agent identities to the originating user Preserve the initiating principal across tool calls so billing, CRM, and support actions retain user context instead of collapsing into a generic service account.
- Move authorization decisions to each tool invocation Re-check policy when the agent calls a billing API, exports data, or updates a record, rather than relying on the trust granted when the session began.
- Enforce policy at Layer 7 with semantic context Inspect method, path, parameters, and originating principal before allowing action, because network-level allow rules cannot distinguish a legitimate summary from a broad refund export.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- The full explanation of how layered delegation changes the authorisation path for each tool invocation.
- The article's step-by-step comparison of session trust versus request-time enforcement in MCP environments.
- The architectural discussion of identity continuity, semantic policy checks, and Layer 7 control placement.
- The source's concrete examples of how prompt injection becomes dangerous only when authority is already overbroad.
👉 Read Pomerium's analysis of why MCP security is an authorization crisis →
MCP authorization drift: are your controls keeping up?
Explore further
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, 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
