Pomerium and MCP access controls reshape AI agent governance

At a glance

What this is: This is WorkOS’s analysis of how Pomerium applies zero-trust, identity-aware access controls to AI agent workflows, with the key finding that runtime authorization and short-lived tokens matter more than broad network access.

Why it matters: It matters because IAM teams now have to separate customer authentication, internal infrastructure access, and AI agent authorization into different control planes instead of treating them as one problem.

By the numbers:

• Pomerium raised $18 million in funding, including a $13.75 million Series A led by Benchmark Capital in 2024.

👉 Read WorkOS's analysis of Pomerium for AI agent security and enterprise auth

Context

Pomerium is an identity-aware proxy that changes the access model from network trust to request-by-request authorization. That matters for AI agent security because agent workflows often need internal infrastructure access without inheriting broad, persistent network reach. The primary issue is not just access control, but whether existing IAM and ZTNA models can keep pace with agent-mediated requests and MCP-based tool calls.

For enterprise teams, the real governance question is how to separate internal service access from customer authentication in B2B AI applications. WorkOS frames that boundary clearly: one control plane handles who can use the application, another handles what can reach internal resources. That distinction is increasingly important as AI agents sit between users, apps, directories, and backend systems.

Key questions

Q: How should security teams govern AI agents that access internal infrastructure?

A: Security teams should treat AI agents as non-human identities that need request-time authorization, not broad network trust. Put an enforcement layer in front of internal tools, scope access narrowly, and expire credentials quickly. The goal is to control each tool request before it reaches the backend, especially when agents operate through MCP or similar delegated access paths.

Q: Why do AI agents complicate zero-trust architecture?

A: AI agents complicate zero-trust architecture because they generate dynamic access requests that can change by task, context, and prompt content. Traditional controls often assume a known user, a stable device, and a predictable session. Agents can break those assumptions by requesting tools, combining privileges, and operating continuously without a human decision loop.

Q: What do security teams get wrong about short-lived credentials for AI agents?

A: Teams often assume short-lived credentials are enough on their own. They reduce exposure time, but they do not fix over-broad scope, weak policy boundaries, or unsafe tool access. If the agent can request sensitive resources freely during the token’s lifetime, the control only limits duration, not misuse.

Q: Should organisations use the same identity controls for internal agents and customer authentication?

A: No. Internal agent access and customer authentication solve different problems and should not be governed by the same control plane. Customer authentication needs SSO, directory sync, and lifecycle management, while internal agents need runtime access control, scoped credentials, and policy enforcement at the infrastructure boundary.

Technical breakdown

How identity-aware proxying changes AI agent access paths

An identity-aware proxy evaluates each request before it reaches a protected application or service. Instead of assuming trust based on VPN membership or network location, it checks identity, device context, groups, and policy logic at request time. For AI agents, that means the proxy can enforce access boundaries around internal APIs, databases, and tools without forcing the agent itself to make security decisions. This is a stronger pattern than broad network exposure because the enforcement point sits outside the agent runtime.

Practical implication: place the authorization decision in a proxy or policy layer, not inside the agent workflow.

Model Context Protocol and runtime authorization

MCP standardises how AI agents request tools and data, but it does not by itself guarantee safe access. The security issue is that an agent can be prompted or manipulated into requesting resources outside its intended scope. A policy enforcement point can inspect the MCP request, validate identity and context, and block access before the request reaches the backend system. That makes authorization external to the model, which is crucial when prompt injection or tool misuse is in play.

Practical implication: treat MCP as an integration layer, then add an external control that validates each tool request.

Short-lived scoped JWTs and the end of broad agent credentials

Short-lived JSON Web Tokens reduce the time window in which a compromised credential can be abused. When the token is scoped to a specific resource and expires quickly, the agent does not need a long-lived secret to keep working. This pattern is especially relevant for continuously running agents, because it shifts credential handling away from persistent secrets and toward narrowly scoped, time-bound access. It also reduces the blast radius of compromise if an agent or workload is tampered with.

Practical implication: replace durable credentials for agent workflows with short-lived, resource-scoped tokens.

Threat narrative

Attacker objective: The objective is to turn an AI agent’s legitimate access path into a route to internal systems, data, or privileged operations that should have remained out of reach.

1. Entry occurs when an attacker or malicious prompt reaches an AI agent through an MCP-integrated workflow that can request internal resources.
2. Credential access or abuse follows when a long-lived agent credential, broad token, or over-permissive service account can be reused beyond its intended scope.
3. Impact occurs when the agent is able to reach internal systems, APIs, or databases that should have been constrained by request-time policy enforcement.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Request-time authorization is now a baseline requirement for AI agent governance: AI agents do not fit governance models built around broad, durable network access. When an agent can request tools dynamically through MCP or similar interfaces, access must be evaluated at the point of use, not granted as a standing entitlement. The implication is that identity teams must separate infrastructure access from application authentication and treat each agent request as a policy decision.

Short-lived tokens reduce exposure, but they do not solve the trust problem created by agent-mediated execution: A scoped JWT limits the window of abuse, yet the larger issue is whether the workflow assumes a stable operator behind the request. That assumption weakens when the actor is autonomous enough to request, combine, and sequence tool use independently. Practitioners should read this as a control-plane boundary issue, not merely a credential hygiene issue.

Model Context Protocol access creates an identity boundary that existing IAM tooling often does not model explicitly: MCP requests are not just API calls, and they are not just model outputs. They are delegated execution paths that combine identity, context, and tool access in one transaction. The practical consequence is that security architecture needs a named policy layer for agent tool use, or the boundary between allowed and unsafe execution remains implicit and brittle.

Infrastructure access and customer authentication are different governance problems, even when they sit in the same product stack: The article correctly separates internal access control from enterprise SaaS authentication. That distinction matters because directory sync, SSO, and customer lifecycle governance solve a different identity problem than proxying access to internal infrastructure. Teams that collapse those control planes usually end up overloading one system with two incompatible jobs.

Runtime access control is becoming the identity blast radius governor for machine-driven systems: The most durable control pattern here is not a bigger perimeter, but narrower execution scope. By constraining what an agent can reach, when it can reach it, and through which policy checks, practitioners reduce the damage that follows prompt injection, credential misuse, or policy drift. That is the direction the identity security market is moving, and teams should design for it now.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how hard it is to govern machine access once it leaves the cleanest parts of the stack.
• That visibility gap connects directly to Top 10 NHI Issues, where over-privilege and secret sprawl remain the recurring failure modes.

What this signals

Scoped runtime control is becoming the practical test for whether an IAM programme can handle AI agents. Teams that still treat agents as ordinary service accounts will miss the new boundary: access is no longer only about who authenticates, but about what each request is allowed to do in context. That is why the control plane has to sit closer to execution than to provisioning.

Identity blast radius is now the more useful planning metric than raw credential count. If a token can only reach one resource for a few minutes, compromise is constrained; if a broad service account can reach multiple internal systems, the same workflow becomes a lateral movement path. The programme question is whether your current design narrows damage at the request layer or only documents it after the fact.

The strongest forward signal here is that AI agent governance is converging with workload identity, ZTNA, and privileged access design. Teams should expect more demand for policy enforcement points that understand MCP, directory context, and short-lived access, because those are the controls that turn agent activity into something governable.

For practitioners

• Separate internal access from customer authentication Use one control plane for B2B customer identity features such as SSO and directory sync, and a different one for internal resource access. Do not force a single product or policy layer to govern both sides of the boundary.
• Enforce request-time policy for agent tool use Place policy checks at the proxy or gateway that evaluates every MCP request against identity, context, and resource scope before the request reaches internal systems.
• Replace durable agent secrets with short-lived scoped tokens Issue credentials that expire quickly and only allow the minimum resource set needed for the current task. Reissue access per request or per session instead of allowing persistent reuse.
• Audit where agents bypass human-paced access review Identify workflows where agent access is provisioned once and then reused repeatedly without a meaningful review trigger. Rebuild those paths so access is checked at runtime rather than assumed to be stable.
• Map AI agent access to zero-trust enforcement points Tie internal agent access to a zero-trust proxy or equivalent enforcement layer that can inspect identity, context, and destination before allowing traffic through.

Key takeaways

• AI agent access becomes materially safer only when enforcement happens at request time, not after broad access has already been granted.
• Short-lived credentials help, but the real control is narrow scope plus an external policy boundary around each tool request.
• Enterprises should keep internal agent access and customer authentication on separate governance tracks because they solve different identity problems.

Key terms

• Identity-aware proxy: An identity-aware proxy is an enforcement layer that checks who or what is making a request before it reaches a protected resource. It sits in the request path and applies policy using identity, context, and destination, which makes it useful for controlling both human and machine access.
• Model Context Protocol: Model Context Protocol is a standard for connecting AI agents to tools and data sources through structured requests. In security terms, it creates a new delegation boundary, so access control has to validate the request itself rather than trusting the model or the session by default.
• Scoped token: A scoped token is a credential restricted to a defined resource, action, or time window. For machine identities it limits what the token can do if it is exposed, but it only works well when the surrounding policy model also constrains where and how the token can be used.
• Zero-trust access: Zero-trust access is a model that assumes network location alone is not a reason to trust a request. For AI agents and other non-human identities, it means each request is verified against policy, context, and identity before any internal resource is exposed.

Deepen your knowledge

MCP access controls, scoped credentials, and runtime authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for AI agents and internal infrastructure access, it is worth exploring.

This post draws on content published by WorkOS: Pomerium for AI Agent Security: Features, Pricing, and Alternatives. Read the original.