Pomerium and MCP access controls reshape AI agent governance

At a glance

What this is: This is an analysis of how MCP-aware proxying changes AI agent access from broad, preprovisioned permissions to request-time authorization tied to identity and context.

Why it matters: It matters because IAM teams governing NHI and agentic workflows need controls that can evaluate each agent request in context, not just certify standing access after the fact.

Context

Model Context Protocol, or MCP, gives AI agents a structured way to request tools and data from external systems. The security problem is not the protocol itself but the access model around it: when an agent can decide what to ask for at runtime, static entitlements and coarse network trust stop matching the real decision point.

WorkOS’s source article uses Pomerium to show a different access pattern for internal resources. Rather than assuming an agent’s privileges are known and stable in advance, the proxy evaluates identity, device posture, location, time, and policy at request time. That shifts the governance question from who was provisioned access to what the agent is allowed to do in this exact session.

For IAM and NHI programmes, this is a control-design issue as much as an architecture issue. MCP-linked agent activity creates a boundary where request-time authorization, short-lived tokens, and contextual policy become the governing layer for internal systems.

Key questions

Q: What breaks when AI agents rely on static OAuth scopes for MCP access?

A: Static OAuth scopes break because they describe delegated permission at the moment of issuance, not the live intent behind each agent action. In MCP, the agent can chain tool calls, change context, and trigger downstream effects that were never visible when the scope was granted. Security teams need per-action authorization, not just valid authentication.

Q: Why do short-lived credentials matter more for agentic AI than for ordinary apps?

A: Agentic systems can request, use, and discard access inside a narrow runtime window, so long-lived credentials create unnecessary exposure between actions. Short-lived credentials reduce the time available for misuse and make revocation meaningful at task completion. They matter because the control problem is runtime access, not only initial authorisation.

Q: How do you know if MCP security controls are actually working?

A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Q: How should teams separate internal agent governance from customer IAM?

A: They should treat them as different problems. Internal agent governance governs what service accounts, proxies, and workflows can reach inside the environment, while customer IAM governs who can use a SaaS application and how their identity is synchronized. Blending the two creates control confusion and usually leaves one side under-governed.

Technical breakdown

Why MCP changes the authorization point

MCP standardises how an AI agent asks for tools and data, but it does not decide whether that access should be allowed. That decision has to happen outside the agent, at a policy enforcement point that can inspect identity, requested resource, source context, and policy conditions before the tool call reaches the backend. In practice, this is closer to API gateway authorisation than classic interactive login. The important distinction is that the agent’s reasoning process is not a trust boundary. If the agent can be prompted into a new action, the control must still evaluate the request independently.

Practical implication: place authorization outside the agent and make every MCP request pass through a separate enforcement layer.

Short-lived scoped JWTs and task-scoped access

Short-lived JWTs reduce exposure by limiting both time and scope, but the real governance shift is that access becomes task-scoped rather than identity-scoped for long periods. A token issued for minutes and tied to a specific resource narrows blast radius if an agent is misused or a credential is exposed. That pattern also aligns with zero standing privilege thinking: access exists only long enough for the task to complete. For AI agents, this matters because continuous operation often tempts teams to issue broad, reusable credentials that are easier to manage but much harder to govern.

Practical implication: issue short-lived, resource-specific credentials for agent tasks instead of reusable long-lived secrets.

Context-aware proxying vs traditional VPN trust

Traditional VPNs extend network trust, while context-aware proxying grants access only after evaluating identity, posture, and policy. That difference matters for internal resources because it removes the assumption that being connected to the network implies being trusted to use everything on it. For AI agents, the proxy can check where the request originated, whether it matches approved infrastructure, and whether the requested operation fits policy. This is a more precise control surface than network-level access because the decision is made per request, not per tunnel.

Practical implication: replace network-wide trust with per-request policy checks for agents and the systems they reach.

Threat narrative

Attacker objective: The objective is to coerce an AI agent into reaching internal data or tools beyond its intended scope.

1. Entry occurs through an MCP request issued by an AI agent to a protected internal resource, where the request itself becomes the access event.
2. Credential abuse is constrained by short-lived scoped JWTs, which reduce the value of intercepted access but still require policy enforcement at issuance time.
3. Impact is limited to the exact resource and operation the policy allows, so unauthorized prompt-driven requests are blocked before they reach backend systems.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Access review assumptions collapse when MCP requests define the real decision point: access review processes were designed for privileges that persist long enough to be reviewed. That assumption fails when an AI agent requests access per action and discards it immediately after use. The implication is not merely more review activity, but a governance model that recognises request-time authorization as the control boundary.

Ephemeral credential trust debt is now the hidden risk in agent workflows: short-lived tokens reduce exposure, but they do not eliminate the governance debt created when teams still reason about access in durable roles and entitlements. The article shows why agent security depends on binding access to context, not on reusing service-account style privileges. Practitioners need to treat every reusable credential as accumulated trust debt.

MCP authorization layer: the most useful control boundary is not inside the agent but between the agent and the protected resource. That boundary lets identity, device, time, and policy govern each request before tool execution. In NHI terms, the question is no longer who owns the agent, but what the proxy allows the agent to do right now.

Zero standing privilege becomes operationally relevant for AI agents, not just humans: continuous agent execution makes standing access especially hard to justify because the task can change faster than a recertification cycle can react. The article’s model pushes governance toward issuance-time decisions, short validity windows, and policy checks that survive prompt manipulation. Practitioners should reframe agent access as temporary capability, not persistent entitlement.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Authorisation Guide

What this signals

Request-time authorization is the governance shift IAM teams need to absorb: AI agents do not behave like stable human users or batch jobs, so entitlements that look sensible at provisioning time can be wrong by the time the agent acts. Programmes should move more decisions into the access request itself and less into periodic review cycles.

Ephemeral credential trust debt: the more an environment relies on reusable service-account style access for agents, the more hidden standing privilege it accumulates. That debt shows up when a prompt injection or unexpected tool call can still ride existing permissions into internal resources.

The strongest control pattern here is to separate internal resource access from customer authentication and from the agent’s own reasoning. That keeps enterprise identity flows intact while forcing agent actions through a policy layer that can evaluate context before access is granted.

For practitioners

• Define request-time authorization for MCP traffic Enforce policy at the proxy or gateway so each MCP call is checked against identity, resource, and context before backend access is granted.
• Replace long-lived agent credentials with short-lived scoped tokens Issue minute-scale credentials bound to specific resources and operations so a compromised agent cannot reuse the same access across tasks.
• Separate internal agent access from customer authentication Keep internal infrastructure access controls distinct from enterprise SSO, directory sync, and customer-facing identity flows in B2B applications.
• Treat prompt injection as an authorization test Assume an injected instruction can change what the agent asks for, then verify the request is denied unless policy explicitly permits that resource and action.
• Audit which privileges persist beyond a single task Identify service accounts and agent tokens that remain valid after the work is complete, because those are the easiest paths to misuse.

Key takeaways

• MCP makes AI agent access a request-time problem, not a provisioning-time problem, and that changes where governance has to sit.
• Short-lived scoped credentials reduce agent blast radius, but only when they are paired with a policy layer that inspects each request.
• IAM teams should separate internal resource control from customer identity flows because the two governance problems are not the same.

Key terms

• MCP Access Control List: An MCP access control list defines which users, groups, or agents can call specific MCP tools or capabilities. It lets teams apply least privilege at the tool layer instead of granting broad access to an entire server, which is essential when multiple agents share the same integration surface.
• Request-time Authorisation: Request-time authorisation is the practice of checking policy at the moment an action is attempted rather than only at login or provisioning. For AI agents, this matters because identity context and tool choice can change during a session, so earlier decisions may no longer be valid.
• Short-Lived JWT: A short-lived JWT is a signed token with an expiration window tight enough to limit replay and stale access. In agentic workflows it acts as a transferable proof of user identity, allowing downstream tools to trust the caller without maintaining a separate identity store.
• Context-Aware Proxy: A context-aware proxy is an access control layer that evaluates identity and request context before allowing traffic to reach an application. It extends identity-aware access by considering factors such as device health, user authorization, and policy conditions, making enforcement more adaptive than perimeter-based networking.

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 building or maturing an IAM programme, it is worth exploring.