Notifications
Clear all
Topic starter
12/06/2026 9:14 pm
TL;DR: MCP is moving agent actions into internal systems, and the current security model was not built for that shift, according to Pomerium’s discussion with RedMonk analysts. Real-time, request-level authorization is now the control point that determines whether human, service, and agent identities can be governed safely.
NHIMG editorial — based on content published by Pomerium: What We Heard From RedMonk Analysts And Why Agentic Access Needs a New Security Model
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern agentic access through MCP in enterprise environments?
A: Start by treating each model-driven request as a separate authorization event.
Q: Why do traditional VPN and OAuth controls fall short for AI agents?
A: They were built for durable sessions and predictable principals, not for identities that can initiate actions dynamically inside a workflow.
Q: How can teams tell whether agentic access controls are actually working?
A: Look for evidence that every privileged action is logged with actor type, target resource, and policy decision, and that denied requests are being blocked before execution.
Practitioner guidance
- Enforce per-request authorisation for agentic workflows Require every MCP-mediated action to be evaluated against identity, target resource, and context before execution.
- Separate human, service, and agent identities in policy Tag each principal type distinctly so approval logic, logging, and revocation workflows can reflect the actual actor.
- Limit tool scope to the narrowest required action set Map each agent to a constrained set of permitted operations and review those permissions by use case, not by platform.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- Live demo details showing how request-level enforcement works across humans, services, and agents.
- The specific architecture used to inspect and authorise MCP requests before execution.
- Practical walkthrough material for teams evaluating context-aware access controls in enterprise environments.
- The source article's framing of an "Agentic Access Management" model and how the demo was presented.
👉 Read Pomerium's analysis of agentic access and MCP security →
MCP requests and agentic access: what IAM teams need to rethink?
Explore further
12/06/2026 11:10 pm
Agentic access exposes a trust model built for stable identities, not runtime decision-makers. The authorisation assumptions behind VPNs, broad OAuth scopes, and session-based approvals were designed for predictable principals. When an agent can independently decide to act, those assumptions fail because the risk surface shifts to the moment of execution. Practitioners should treat this as a structural governance mismatch, not a tuning problem.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when an AI agent makes an inappropriate internal system request?
A: Accountability should sit with the team that defined the agent’s permissions, approvals, and monitoring, not with the model itself. Governance needs a named owner for the workflow, because the agent is only one part of the control chain and cannot carry accountability on its own.
👉 Read our full editorial: Agentic access needs a new security model for MCP requests
