Agentic access needs a new security model for MCP requests

At a glance

What this is: This is an editorial analysis of agentic access over MCP, with the key finding that existing security models break when LLMs are allowed to make internal system requests.

Why it matters: It matters because IAM, NHI, and PAM teams need controls that evaluate each agent action in context, not just authenticate the caller once and trust the session.

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.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Pomerium's analysis of agentic access and MCP security

Context

Model Context Protocol makes it possible for LLMs to request actions inside internal systems, which changes the problem from authentication alone to request-time authorisation. The primary keyword, agentic access, matters here because the control failure is not whether an identity can log in, but whether each action can be evaluated safely at runtime.

The existing model for access control assumed stable human users or predictable service identities with bounded behaviour. Once an agent can decide when to act, which tool to invoke, and how to sequence those actions across systems, the old trust boundary becomes too coarse for practical governance.

Key questions

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. Bind policy to identity, resource, and context at runtime, then limit the tools and data each agent can reach. That approach reduces the risk that a valid session becomes a standing permission channel for unintended actions.

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. VPNs create coarse network trust, and OAuth scopes often overstate what a caller should be allowed to do in a specific moment.

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. If you can only see the login and not the downstream action, the control is too weak for agentic use.

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.

Technical breakdown

Why MCP changes the authorisation model

MCP is a tool-connection layer, not an identity system, but it sits in the path between model output and real system action. That matters because a prompt can now become a request to read data, change records, or trigger workflow operations. Traditional controls often authenticate the caller once and then rely on session trust, which is too blunt when every downstream action can carry different risk. The result is an authorisation problem at the request layer, not just at login.

Practical implication: move enforcement to per-request decisions tied to identity, resource, and context.

Why zero trust breaks when agents act like people

Zero Trust Architecture assumes continuous verification, but many deployments still treat sessions as durable trust containers. Agentic access breaks that assumption because the action may be initiated by a model, not a human, and the request path can span multiple systems in seconds. OAuth scopes and VPN-style perimeter thinking do not express enough context for this decision point. Real-time checks are required because the risk is attached to the action, not just the principal.

Practical implication: define policy around each action, not around the existence of a session.

How identity-aware access differs from ordinary API control

Identity-aware access links the caller, the action, and the target resource so the system can log who or what triggered each request. That is different from generic API gateway control, which may validate traffic but not understand whether the request came from a human, a service account, or an agent. For machine identities, this distinction is critical because privilege often outlives purpose. With agentic workflows, auditability and context become part of the control plane, not just the evidence layer.

Practical implication: require identity context and audit trails for every privileged agent action.

NHI Mgmt Group analysis

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.

Request-level control is the named concept that matters here. In agentic environments, the decisive failure mode is not login abuse but unchecked action initiation. Every privileged request must be treated as a separate governance event because the identity behind it may be non-human, ephemeral, and context-sensitive. The implication is that access reviews and coarse entitlements no longer describe real behaviour well enough for assurance.

MCP increases the importance of identity context across human, NHI, and agent workflows. The same internal system may be reached by a person, a service account, or a model-driven agent, but each one creates a different risk profile and audit expectation. That is why governance must distinguish subject type at the point of action. Teams that collapse those identities into one policy tier will miss the control differences that actually matter.

Autonomous behaviour would collapse even more of the old security model, but MCP already shows the direction of travel. Once tool use is embedded in the request path, the old assumption that access can be safely reviewed after the fact weakens sharply. The practical conclusion is that identity governance has to move closer to runtime, where policy can see purpose, context, and actor type together.

Real-time authorization becomes a governance requirement, not a convenience feature. The combination of tool access, internal data reach, and rapid action sequencing means that delayed controls only document the failure after it has happened. Practitioners should read MCP as evidence that identity security now has to operate at the pace of execution, not the pace of monthly review cycles.

From our research:

• 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.
• Agentic access needs runtime governance because the identity problem is no longer static entitlement, and the OWASP Agentic AI Top 10 frames this as a control-plane issue, not just a policy issue.

What this signals

Request-level authorization is becoming the operational dividing line for agentic access. Teams that still think in terms of login-time trust will struggle to govern MCP-mediated workflows, especially where an internal tool can be reached by more than one principal type. The shift is not just technical. It forces IAM, IGA, and PAM teams to define who can act, when they can act, and under what context the action is valid.

Agentic access expands the identity perimeter faster than most programmes can classify it. With 97% of NHIs carrying excessive privileges, the risk is that new model-driven paths inherit old over-entitlement instead of receiving least-privilege design. That is why MCP governance needs identity-aware policy before broad adoption, not after the first incident.

Continuous verification should now be applied to the action path, not just the user path. The OWASP Agentic AI Top 10 and NIST AI governance guidance both point toward runtime controls, but the practical question for practitioners is simpler: can you prove what the agent was allowed to do at the moment it did it? If not, the programme is observing, not governing.

For practitioners

• Enforce per-request authorisation for agentic workflows Require every MCP-mediated action to be evaluated against identity, target resource, and context before execution. Do not rely on a one-time login or a broad session token to cover subsequent tool use.
• 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. Human-friendly session assumptions should not be reused for agent-driven access paths.
• 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. This reduces the chance that an internal request layer becomes a general-purpose escalation path.
• Instrument audit trails for action, not just authentication Capture which identity initiated the request, what tool was called, what resource was touched, and whether policy allowed it. That evidence is necessary for incident review and for proving that runtime controls are actually working.

Key takeaways

• Agentic access breaks the assumption that a single authenticated session can safely cover all downstream system actions.
• Runtime, request-level authorization is now the control that separates manageable agentic workflows from uncontrolled tool use.
• Identity teams should separate human, service, and agent principals in policy, logging, and revocation workflows before MCP use scales further.

Key terms

• Agentic access: Access in which an AI system can initiate actions inside internal systems rather than only answer questions. The key governance issue is not basic authentication but deciding what each action is allowed to do at runtime, under which context, and with which audit evidence.
• Model Context Protocol: An open protocol that connects models to tools and data sources so they can retrieve information or trigger actions. In security terms, it creates a new decision point where identity, context, and authorisation must be evaluated before a tool call is executed.
• Request-level authorization: A control pattern that evaluates every action individually instead of trusting an already-authenticated session. For agents, this is the practical boundary that determines whether a model can read, change, or trigger something in an internal system.
• Identity-aware access: An access model that uses the caller’s identity type, the target resource, and the action context to make policy decisions. It is especially important when humans, service accounts, and AI agents can all reach the same system through different workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium: What We Heard From RedMonk Analysts And Why Agentic Access Needs a New Security Model. Read the original.