Pomerium

Identity-aware access proxy implementing zero-trust network access (ZTNA). Pomerium sits in front of internal applications and services, authenticating every request via OIDC/OAuth2 and enforcing policy-based authorization without a VPN. Replaces VPN + firewall rules with identity-verified, context-aware access control. REST API and policy-as-code (YAML/Rego) for programmatic access route management. Pomerium Zero (cloud-managed) or self-hosted.

Evaluated Mar 06, 2026 (0d ago) v0.x
Homepage ↗ Repo ↗ Security zero-trust access-proxy identity kubernetes vpn-replacement sso open-source
⚙ Agent Friendliness
58
/ 100
Can an agent use this?
🔒 Security
91
/ 100
Is it safe for agents?
⚡ Reliability
77
/ 100
Does it work consistently?

Score Breakdown

⚙ Agent Friendliness

MCP Quality
--
Documentation
80
Error Messages
75
Auth Simplicity
75
Rate Limits
80

🔒 Security

TLS Enforcement
100
Auth Strength
92
Scope Granularity
88
Dep. Hygiene
85
Secret Handling
88

Apache 2.0 open source, actively maintained. Zero-trust model — every request verified, no implicit trust. Device trust via mTLS client certificates. Full audit logs of all access decisions. OIDC-based identity verification. SOC2 for Enterprise. Cryptographic routing for Pomerium Zero tunnels.

⚡ Reliability

Uptime/SLA
75
Version Stability
78
Breaking Changes
75
Error Recovery
80
AF Security Reliability

Best When

You want to eliminate VPN for internal service access while providing identity-verified, audited access to developers and agents via zero-trust principles.

Avoid When

You need to protect public-facing user applications — Pomerium is for internal/corporate access, not customer-facing authentication.

Use Cases

  • Provide agent workers and developers secure access to internal services (databases, admin UIs, monitoring) without VPN using identity-verified access proxy
  • Protect internal agent APIs and services with identity-aware authentication — only authenticated agents with valid OIDC tokens can reach protected upstream services
  • Implement device trust for agent access — Pomerium can enforce that only managed devices with valid certificates can access sensitive internal services
  • Replace VPN for remote developer access with cryptographically-verified, audited access to internal services via Pomerium's TCP tunneling mode
  • Secure Kubernetes internal services (dashboards, monitoring, CI/CD) with Pomerium in front — no public exposure, identity-verified access from anywhere

Not For

  • Public-facing application authentication — Pomerium protects internal services; use Auth0, Clerk, or WorkOS for public-facing user authentication
  • Teams that genuinely need a VPN for non-web protocols — Pomerium supports TCP tunneling but is primarily HTTP(S) proxy; full VPN solutions cover more protocols
  • Simple single-service setups — if you have one internal service to protect, a simpler solution (Cloudflare Tunnel, nginx + auth) may be sufficient

Interface

REST API
Yes
GraphQL
No
gRPC
Yes
MCP Server
No
SDK
No
Webhooks
No

Authentication

Methods: oauth2 oidc
OAuth: Yes Scopes: Yes

Pomerium authenticates users via any OIDC provider (Google, Okta, Azure AD, GitHub, Keycloak, etc.). Policy enforcement uses user claims from OIDC token. Service accounts for machine-to-machine access via JWT. TLS client certificates for device trust.

Pricing

Model: open_source
Free tier: Yes
Requires CC: No

Apache 2.0 open source. Community edition is fully functional for most use cases. Pomerium Zero provides managed connectivity (no port forwarding required). Enterprise adds RBAC, device trust management, and compliance features.

Agent Metadata

Pagination
none
Idempotent
Full
Retry Guidance
Not documented

Known Gotchas

  • Pomerium requires a public domain and HTTPS for authentication callbacks — self-hosted deployment requires valid TLS certificates and DNS; local development setup is non-trivial
  • Session cookies are per-user browser session — machine-to-machine agent access requires service account JWT tokens, not cookie-based auth; this is a separate configuration path
  • Policy configuration is YAML or Rego — policy changes require Pomerium restart or hot-reload depending on configuration; agents cannot dynamically update policies via API in community edition
  • Upstream service address configuration is proxied through Pomerium — agents accessing internal services must use Pomerium's public URL, not direct internal addresses; all traffic flows through the proxy
  • OIDC provider callback URLs must be registered in the identity provider — misconfigured callbacks result in authentication loop failures that are confusing to debug
  • TCP tunneling (for non-HTTP protocols) requires pomerium-cli on the client side — agent environments accessing TCP-proxied services (databases, SSH) must have pomerium-cli installed
  • Pomerium Zero (managed) vs self-hosted have different configuration models — documentation examples may mix the two; verify which deployment model applies to your setup

Alternatives

Full Evaluation Report

Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Pomerium.

$99

Scores are editorial opinions as of 2026-03-06.

5215
Packages Evaluated
26151
Need Evaluation
173
Need Re-evaluation
Community Powered