Notifications
Clear all
Topic starter
07/06/2026 8:56 pm
TL;DR: Pomerium’s MCP support and context-aware proxying shift AI agent security toward request-time authorization, short-lived scoped JWTs, and identity-aware access decisions for internal resources, according to WorkOS. The governance issue is that existing IAM models assume stable, reviewable access, while agent workflows now need controls that evaluate each request in context.
NHIMG editorial — based on content published by WorkOS: Pomerium for AI Agent Security: Features, Pricing, and Alternatives
By the numbers:
- Pomerium raised $18 million in funding, including a $13.75 million Series A led by Benchmark Capital in 2024.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Pomerium policy examples for internal applications and infrastructure.
- Detailed comparison of open-source deployment versus the commercial Pomerium Zero model.
- Customer authentication requirements that separate WorkOS from infrastructure access tooling.
- Implementation guidance for MCP-secured agent workflows and proxy-based enforcement.
👉 Read WorkOS's analysis of Pomerium for AI agent security and enterprise auth →
MCP access controls for AI agents: what IAM teams should change?
Explore further
08/06/2026 8:41 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Pomerium and MCP access controls reshape AI agent governance
