---
title: "A decision point behind your stack, or an execution plane in front of it"
description: "Both products answer the same runtime question for users and for agents: may this principal perform this action on this resource? They differ in where the product sits in the request path, how much of the surrounding identity program comes with it, and how much of your architecture has to change to adopt it."
competitor: "EmpowerID"
reviewed: "3 August 2026"
canonical: "https://www.cerbos.dev/cerbos-vs-empowerid"
source: "https://www.cerbos.dev/cerbos-vs-empowerid"
---

# A decision point behind your stack, or an execution plane in front of it

Both products answer the same runtime question for users and for agents: may this principal perform this action on this resource? They differ in where the product sits in the request path, how much of the surrounding identity program comes with it, and how much of your architecture has to change to adopt it.

## Verdict

**Choose Cerbos when**

- Your team already owns its gateway, agent framework, and secrets manager, and wants a decision layer that does not add another vendor plane to the request path.
- Policy must be a reviewable artifact in your repository, with compile checks and test suites gating every change in CI.
- An Apache 2.0 PDP, published pricing, and a documented exit path are material procurement requirements.
- Authorization has to reach the data layer as a query filter your own ORM executes, rather than as a permitted-resource list the application applies.

**Consider EmpowerID when**

- Credential non-custody or JWS-signed, hash-chained evidence packs are hard requirements to be met by the authorization vendor, because Cerbos provides neither today.
- The programme is identity governance modernization, privileged access management, certification, or SAP identity migration, none of which are Cerbos categories.
- A packaged agent runtime, including an MCP tool gateway, delegation-chain verification, and human-approval gating, is wanted from a single vendor rather than assembled.

## Two integration surfaces for the same decision

EmpowerID is a converged identity platform that has been shipping since 2005, combining identity governance and administration, privileged access management, access management, and a hybrid RBAC, ABAC, and PBAC authorization engine over a SQL Server identity warehouse and a low-code workflow engine. It documents access levels that bundle low-level operations, management roles for delegated administration, business roles and locations, and resource systems for connected applications, and it can act as a Policy Decision Point for integrated external applications.

EmpowerNow is the company's next-generation platform, launched in 2025, and ARIA is the agent-runtime control layer inside it. Its documented architecture is a Gate, Decide, Enforce, Prove pipeline: an AuthZEN PDP built as a FastAPI microservice with a JSON intermediate policy representation, an OAuth Vault that keeps tokens server-side so agents receive outcomes rather than credentials, an MCP tool gateway with policy-scoped tool discovery, an Entitlement Ledger, a WAITING protocol that gates high-risk operations on human approval, and per-action evidence packs that are JWS-signed and hash-chained.

Cerbos combines an Apache 2.0 stateless Cerbos PDP with commercial Cerbos Hub and Cerbos Synapse components. The Cerbos PDP is a single Go binary using YAML or JSON policies with CEL conditions, deployable as a shared service, sidecar, DaemonSet, or selected serverless pattern. It is called by the gateway, agent framework, or MCP server you already run rather than replacing them. Cerbos Hub provides source-agnostic policy lifecycle, build, test, signed distribution, and audit aggregation. Cerbos Synapse provides decision-time enrichment, transformation, caching, and protocol translation.

The useful question is not which product is more modern. EmpowerNow was built recently on an AuthZEN-native PDP and its agent controls are shipped rather than announced. The question is whether you want to adopt an execution plane that sits in your call path and takes custody of your credentials, or call a decision point from the plane you already own and operate.

**EmpowerID** — Particularly fits an identity organization buying a governed agent runtime end to end, or modernizing an existing identity governance program. EmpowerID documents identity governance and administration, privileged access management, access certification, segregation of duties, delegated administration, a low-code workflow engine, an identity warehouse, and a broad connector estate including native SAP connectivity, alongside the authorization engine. ARIA adds credential non-custody, tool-schema pinning, delegation-chain verification, budget and rate constraints, on-behalf-of identity chaining, human-approval gating, and an MCP tool gateway. EmpowerNow publishes SOC 2 Type 2 and ISO 27001:2022 attestations, independently audited.

**Cerbos** — Fits engineering-owned services and agents where the team already runs its own gateway, agent framework, and secrets manager, and wants fine-grained authorization without introducing a new plane in the request path. Policies are YAML or JSON with CEL conditions, reviewed in pull requests, compiled and tested in CI. The Apache 2.0 Cerbos PDP is self-hosted and runs independently or connects to Cerbos Hub for signed policy distribution without a per-decision Cerbos Hub round trip. For supported JavaScript environments, Cerbos Hub's commercial ePDP evaluates Cerbos Hub-managed bundles in-process through WebAssembly. Cerbos Hub is available as an enterprise on-premise deployment, including restricted and air-gapped environments.

- **What has to change to adopt it** — Cerbos is a decision the application, gateway, or MCP server calls, so the request path, credential storage, and orchestration stay where they are. Adopting ARIA means placing its gateway in the call path and moving token custody into its vault. That is a coherent architecture, and it is also a larger change that overlaps with the API gateway, AI gateway, and secrets manager many teams already run.
- **Who owns the policy artifact** — Cerbos policies are files in your repository with compile checks and test suites in CI. EmpowerNow policy is documented as a JSON intermediate representation with a five-tier inheritance cascade and structured operation references, managed inside the platform. Ask each vendor to demonstrate a policy change as a pull request containing a failing test, then a promotion and a rollback.
- **How much program comes with the product** — EmpowerID's centre of gravity is the identity program: governance, privileged access, certification, and enterprise connectors, with authorization as one pillar. Cerbos ships one product and composes with whatever identity governance you already run. If the buyer is the identity organization, that breadth is the product; if the buyer is engineering, it is scope you pay for and operate.

## What enterprise buyers ask for

Verified against public documentation on 3 August 2026. The links beside each row point to Cerbos or neutral standards sources; competitor sources informed the research but are not linked here. EmpowerID and EmpowerNow architecture statements below reflect the vendor's own published documentation rather than independent verification.

| Requirement | Cerbos | EmpowerID |
| --- | --- | --- |
| Where the decision point sits in the request path | BEHIND YOUR STACK — Cerbos ships as a standalone binary or container and supports shared-service, sidecar, DaemonSet, and selected serverless patterns. Your existing gateway, service, agent framework, or MCP server calls it. A standalone or Cerbos Hub-connected PDP evaluates locally without a per-decision Cerbos Hub round trip. | IN-PATH PLANE — EmpowerID can act as a PDP for integrated external applications over its REST APIs. The EmpowerNow and ARIA architecture is documented as an execution plane, with a policy and tool gateway intercepting before execution plus an orchestration service, which overlaps with gateways many teams already operate. |
| Policy authoring and source of truth | GIT NATIVE — Cerbos uses YAML or JSON resource, principal, derived-role, and scoped policies with CEL conditions. Policies can live in Git, compile and test in CI, or use Cerbos Hub's source-agnostic policy stores and managed distribution pipeline. | PLATFORM-CENTRIC — The suite models access through platform objects: access levels bundling low-level operations, management roles, business roles and locations, and resource systems. EmpowerNow policy is a JSON intermediate representation with a five-tier inheritance cascade and op:{app}:{object}.{action} operation references, managed inside the platform. |
| Policy testing and CI/CD lifecycle | BUILT IN — The Cerbos CLI compiles policies and runs YAML test suites, so a policy change can fail a build like any other artifact. Cerbos Hub adds managed validation, signed bundle builds, and distribution across Git, API, SDK, CLI, CI/CD, and browser-upload workflows. | VERIFY — EmpowerNow publishes a documentation site, but no CLI policy compiler, policy test-suite runner, or Git and CI bundle pipeline was found in public sources as of 3 August 2026. This is an absence of public evidence rather than a proven absence, so ask how a policy change is reviewed, tested, promoted, and rolled back. |
| Agent and MCP runtime controls | DECISION LAYER — Cerbos is the decision point your MCP server, agent framework, or gateway calls before a tool executes. Cerbos Synapse adds protocol translation, including Envoy ext_authz and AuthZEN endpoints, plus decision-time enrichment. Cerbos does not ship a packaged agent runtime, tool gateway, or approval workflow. | BUILT IN — ARIA documents five sequential rails: SHA-256 tool-schema pinning, delegation-chain verification, AuthZEN PDP evaluation, budget, TTL and rate constraints, and on-behalf-of token exchange. It adds policy-scoped tool discovery, a WAITING protocol for human approval on high-risk operations, and bring-your-own orchestration. This is a material EmpowerID strength. |
| Credential custody at execution | OUT OF SCOPE — Cerbos returns a decision and does not hold, broker, or inject credentials. Token custody stays with your existing secrets manager and execution boundary. If credential non-custody must be delivered by the authorization vendor, Cerbos does not provide it. | BUILT IN — The documented OAuth Vault keeps tokens server-side across an authorization, retrieval, and execution zone split, so the agent receives an outcome rather than a credential, with DPoP sender-constrained tokens. Cerbos has no equivalent. |
| Decision evidence and audit | STRUCTURED LOGS — When enabled, Cerbos emits structured decision logs to file, Kafka, local storage, or Cerbos Hub, including decision context and matched-policy metadata. Cerbos Hub adds managed collection and search. | SIGNED RECEIPTS — ARIA documents per-action evidence packs rather than logs, binding request, policy decision, execution result, and an execution-environment fingerprint, JWS-signed and hash-chained to the previous receipt for tamper detection. This is a material EmpowerID strength. |
| AuthZEN compatibility | INTEROP PARTICIPANT — The current Cerbos PDP partially implements documented AuthZEN endpoints, Cerbos Synapse natively exposes AuthZEN endpoints, and Cerbos has participated in published interoperability testing. For disclosure, Alex Olivier of Cerbos is one of the current AuthZEN Working Group cochairs. | FULL SURFACE — EmpowerID appears in the published AuthZEN interoperability results across evaluation, batched evaluations, and the subject, resource, and action search scenarios. EmpowerNow documents batch semantics of execute_all, deny_on_first_deny, and permit_on_first_permit. |
| List filtering in the data layer | QUERY PLAN — PlanResources returns a datastore-agnostic filter plan that documented adapters translate into native queries for Prisma, Drizzle, Mongoose, Convex, SQLAlchemy, and ChromaDB through LangChain, so conditions are applied by the database rather than in application code. | SEARCH API — The AuthZEN search endpoints return permitted subjects, resources, or actions, and the suite supports precalculated access for before-the-fact reporting. Confirm how a permitted-resource set is applied to a large or paginated table in your own data layer. |
| Identity governance, privileged access, and connectors | NOT IN SCOPE — Cerbos consumes the roles and attributes your identity systems already manage and enforces them at runtime. It does not provide joiner-mover-leaver provisioning, access certification, segregation-of-duties analytics, privileged access management, or an application connector estate. | BUILT IN — Documents identity governance and administration, privileged access management, certification, delegated administration, a low-code workflow engine, an identity warehouse aggregating connected systems, and a connector estate including native SAP connectivity. SaaS and on-premise installations are documented with equivalent functionality. |
| Open source, SDK coverage, and pricing transparency | APACHE 2.0 — The Cerbos PDP is Apache 2.0 with gRPC and REST APIs and official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel. Cerbos publishes Cerbos Hub pricing, including a $0 proof of concept tier; Cerbos Hub and licensed Cerbos Synapse capabilities are commercial. | COMMERCIAL — The platform is closed source, with three patent applications filed in May 2025. EmpowerID publishes a modular pricing page naming each module and its licensing unit, including a PDP and PBAC module licensed per authorizing Person object per month, but list prices are contact-sales and no public pricing for EmpowerNow or ARIA was found as of 3 August 2026. Integration is documented around REST APIs, OAuth-registered applications, mTLS with request signing, and a Python client library. |

### Sources

- [Cerbos deployment patterns](https://docs.cerbos.dev/cerbos/latest/deployment/)
- [Cerbos Hub decision points](https://docs.cerbos.dev/cerbos-hub/decision-points.html)
- [Cerbos policy authoring](https://docs.cerbos.dev/cerbos/latest/policies/)
- [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/policy-stores.html)
- [Cerbos compile and test](https://docs.cerbos.dev/cerbos/latest/policies/compile.html)
- [Testing Cerbos policies](https://docs.cerbos.dev/cerbos/latest/tutorial/04_testing-policies.html)
- [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/)
- [Cerbos APIs and SDKs](https://docs.cerbos.dev/cerbos/latest/api/index.html)
- [Cerbos PDP overview](https://docs.cerbos.dev/cerbos/latest/index.html)
- [Cerbos audit configuration](https://docs.cerbos.dev/cerbos/latest/configuration/audit.html)
- [Cerbos Hub audit collection](https://docs.cerbos.dev/cerbos-hub/audit-log-collection.html)
- [Cerbos AuthZEN API](https://docs.cerbos.dev/cerbos/latest/api/index.html)
- [AuthZEN interoperability](https://authzen-interop.net/docs/intro/)
- [AuthZEN Working Group](https://openid.net/wg/authzen/)
- [Cerbos query-plan adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html)
- [Cerbos policy model](https://docs.cerbos.dev/cerbos/latest/policies/index.html)
- [Consuming JWT claims](https://docs.cerbos.dev/cerbos/latest/recipes/jwt-claims.html)
- [Cerbos licence](https://github.com/cerbos/cerbos/blob/main/LICENSE)
- [Cerbos pricing](https://www.cerbos.dev/pricing)

Compiled from public vendor documentation in August 2026. Three names matter and are not interchangeable: EmpowerID is the converged identity suite founded in 2005, EmpowerNow is the next-generation platform launched in 2025, and ARIA is the agent-runtime layer inside EmpowerNow. Details change, so verify current capabilities with both vendors before you decide.

## The difference is the integration surface, not the vintage

EmpowerNow is designed to sit in the execution path and hold credentials. Cerbos is designed to be called from a path you already own.

EmpowerNow's documented pipeline is Gate, Decide, Enforce, Prove: intercept before execution, evaluate through an AuthZEN PDP, apply runtime constraints, then emit a cryptographic receipt. ARIA implements that as five sequential rails on every agent action, comprising SHA-256 tool-schema pinning, delegation-chain verification, PDP evaluation, budget, TTL and rate constraints, and on-behalf-of token exchange, with denial as the default when any rail fails. It is a coherent architecture and it is shipped, not slideware.

The cost of that coherence is adoption surface. The gateway has to be in the call path, the OAuth Vault has to hold the tokens, and the tool catalogue has to be fronted by the platform. In organizations that already run an API gateway, an AI gateway, a secrets manager, and an agent framework, that is an overlap to resolve rather than a gap to fill, and it makes the vendor a dependency of every governed request.

Cerbos occupies the other position deliberately. The PDP is called by whatever is already in the path, including an execution boundary shaped exactly like ARIA's, and it does not take custody of credentials or traffic. That is a smaller promise: Cerbos supplies the decision, and the surrounding enforcement, credential isolation, and evidence remain the architecture's responsibility. Where those surrounding controls are required and nobody owns them yet, EmpowerNow answers more of the problem in one purchase.

This is not a legacy-versus-modern comparison and should not be argued as one. EmpowerNow launched in 2025 on a FastAPI PDP with a native AuthZEN surface, and EmpowerID has been shipping a converged identity platform since 2005.

## Both have a real policy model; only one is a file you review

EmpowerNow's JSON intermediate representation with five-tier inheritance is a genuine policy model. The public difference is the toolchain around it.

EmpowerNow policy is documented as a JSON intermediate representation with structured rules, a five-tier inheritance cascade from GLOBAL through DOMAIN_SHARED, CROSS_ENVIRONMENT, and DOMAIN_ENVIRONMENT to APPLICATION, and operation references in the form op:{app}:{object}.{action}. The established EmpowerID suite models access separately through access levels that bundle low-level operations, management roles, business roles and locations, and resource systems. Both are structured models, not click-through wizards, and should not be characterized as such.

Cerbos policies are YAML or JSON resource, principal, derived-role, and scoped policies with CEL conditions. Scoped policies handle multi-authority hierarchies, and scopePermissions can require that a child scope only narrows what its parent allows, which is the same organizational problem an inheritance cascade solves. The difference is where the artifact lives: in a repository, diffed in a pull request, compiled by the Cerbos CLI, and covered by YAML test suites that fail a build.

No CLI policy compiler, policy test-suite runner, or Git and CI bundle pipeline was found in EmpowerNow's public sources as of 3 August 2026. That is an absence of public evidence, not proof of absence, and it should be put to the vendor as a question rather than asserted as a fact. The concrete request is a policy change demonstrated as a pull request containing a failing test, followed by a promotion and a rollback.

## Two controls Cerbos does not provide

Credential non-custody and signed, hash-chained receipts are shipped EmpowerNow capabilities with no Cerbos equivalent today.

The OAuth Vault splits authorization, credential retrieval, and execution into separate zones so that an agent receives an outcome rather than a token, with DPoP sender-constrained tokens on the issued credentials. Cerbos has no equivalent and is not trying to have one: it returns a decision, and credential custody stays with your secrets manager and execution boundary. If the requirement is that the authorization vendor also removes credentials from the agent's reach, that is EmpowerNow's answer and not ours.

ARIA emits per-action evidence packs rather than logs, binding the request, the policy decision, the execution result, and an execution-environment fingerprint, JWS-signed and hash-chained to the previous receipt so tampering is detectable. Cerbos decision logs are structured, filterable, and exportable to file, Kafka, local storage, or Cerbos Hub, and they capture decision context and matched-policy metadata, but they are not signed or chained today. Presenting them as equivalent would not survive a technical review.

What Cerbos does offer as control evidence is different in kind: the policy itself is a versioned artifact with full change history, the test suite demonstrates that the control behaves as intended, and schema validation constrains the inputs. For many audit programmes that combination plus decision logs into a SIEM is sufficient. For programmes that need per-action cryptographic proof, including those scoping against EU AI Act record-keeping obligations, it is not, and that should be established before a proof of concept rather than after.

## AuthZEN keeps the choice reversible, and the scope line clear

Both products speak AuthZEN, so you can test either decision point against your own scenarios instead of arguing feature matrices.

Cerbos and EmpowerID both appear in the published AuthZEN interoperability results. Cerbos Synapse exposes the AuthZEN endpoints natively, and the Cerbos PDP partially implements them alongside its own gRPC and REST APIs. Confirm the exact endpoint set and specification version each vendor supports in production for the integration you actually intend to build.

The value of the standard is that the decision point stays replaceable. Rather than comparing endpoint checklists, point both PDPs at the same corpus of your own scenarios and compare decisions, latency, and failure behavior directly. That test tells you more than any table on this page, and making it possible is why Cerbos invests in the standard: for disclosure, Alex Olivier of Cerbos is one of the current AuthZEN Working Group cochairs.

The scope boundary is the clearer decision line. EmpowerID documents provisioning, access certification, segregation of duties, privileged access management, delegated administration, a low-code workflow engine, an identity warehouse, and native SAP connectivity. Cerbos does none of that by design. It consumes the roles and attributes those systems manage and enforces them at runtime inside applications, which makes the two complementary in an estate that needs both rather than alternatives to be scored against each other.

## Prove the decision layer before touching the execution path

Separate three workstreams that are easy to conflate: policy translation, enforcement placement, and credential custody. Only the first has to move for Cerbos to be worth evaluating, and it is the one that carries the least risk.

| EmpowerID or EmpowerNow concept | Cerbos | Notes |
| --- | --- | --- |
| Access level bundling low-level operations | Actions in a resource policy rule | Expand each bundle into the discrete actions it grants so the resulting policy is reviewable rather than opaque. |
| Management role, business role, and location | Principal roles, derived roles, and scoped policies | Derived roles cover conditional membership; scoped policies cover organizational hierarchy where a child scope may only narrow its parent. |
| JSON IR policy with five-tier inheritance | Resource and principal policies with scopePermissions | Map each inheritance tier to a scope and decide explicitly whether the tier narrows or overrides, because the two produce different decisions. |
| op:{app}:{object}.{action} operation reference | Resource kind plus action name | Preserve identifiers so both engines receive equivalent inputs during shadow comparison. |
| AuthZEN evaluation or batched evaluations call | CheckResources request, or the AuthZEN endpoint | Normalize both responses to allow or deny plus outputs before comparing; batch semantics differ and must be held constant. |
| AuthZEN resource search result | PlanResources query plan plus a data-layer adapter | This changes where filtering happens. Compare returned record sets and pagination behavior, not just the permitted set. |
| ARIA rail evaluation on an agent tool call | PDP check from your MCP server or agent framework | Cerbos covers the policy rail only. Schema pinning, delegation verification, budgets, and credential injection stay with your execution boundary. |

### A migration that does not start by moving your credentials

1. **Scope** — Decide first whether credential non-custody and signed receipts are requirements or roadmap. If they are requirements, qualify honestly before spending effort on translation.
2. **Capture** — Build a corpus of representative principals, resources, actions, and context, including at least one agent tool call and one filtered list.
3. **Translate** — Express one authorization domain as Cerbos policies, mapping inheritance tiers to scopes explicitly, and encode the expected decisions as policy tests that run in CI.
4. **Shadow** — Call the Cerbos PDP alongside the incumbent without enforcing its result, then compare normalized decisions and reconcile every mismatch as an input, semantic, or output difference.
5. **Adapt** — For list endpoints, translate PlanResources output through the adapter for your ORM and compare returned records and pagination against the search-endpoint result.
6. **Cut over** — Move enforcement only after decision parity, query semantics, latency, and failure behavior meet the acceptance criteria, leaving credential custody and the execution path untouched.

Credential non-custody and signed receipts do not map to Cerbos. If they are in scope, keep the incumbent on those controls or implement and validate them explicitly in your own execution boundary.

## Where Cerbos is not a direct replacement

The products overlap at the runtime authorization decision. They diverge on credential handling, evidence, packaged agent controls, and the entire identity governance programme.

| Capability | Cerbos approach | Guidance |
| --- | --- | --- |
| Credential isolation at execution | Cerbos returns a decision and never holds, brokers, or injects credentials. There is no Cerbos equivalent of the OAuth Vault. | Keep credential custody with your secrets manager and execution boundary, or retain EmpowerNow on that control. |
| Signed, hash-chained decision evidence | Cerbos decision logs are structured and exportable but are not cryptographically signed or chained today. Policy-as-code history and test suites are the available control evidence. | If per-action cryptographic proof is an audit requirement now, treat it as a gap rather than a roadmap item and scope accordingly. |
| Packaged agent runtime controls | Cerbos supplies the policy decision an MCP server, gateway, or agent framework calls. Schema pinning, delegation-chain verification, budget and rate constraints, approval gating, and tool discovery are not Cerbos features. | Inventory which rails you already have. If none exist and nobody owns them, a packaged runtime is a legitimate reason to prefer EmpowerNow. |
| Identity governance, PAM, and connectors | Cerbos is not an IGA or PAM product. It consumes the roles and attributes those systems manage rather than provisioning, certifying, or vaulting them. | Run Cerbos alongside your identity governance platform; do not scope it as a replacement. |
| AuthZEN endpoint coverage | The Cerbos PDP partially implements the documented AuthZEN endpoints, and Cerbos Synapse exposes them natively. EmpowerNow additionally documents the AuthZEN search endpoints. | If a specific AuthZEN endpoint is a hard integration requirement, confirm current Cerbos support before committing. |

## Adoption cost and the cost of leaving

Cerbos policies, repository history, and tests remain under your control, and Apache 2.0 permits continued use of the Cerbos PDP. Cerbos Hub can source policies from Git, APIs, SDKs, CLI, CI/CD, or browser upload, then validate, test, sign, and distribute bundles. Migrating the Cerbos-specific policy model to another engine would still require work.

EmpowerNow's policy model is a platform-managed JSON intermediate representation with a five-tier inheritance cascade and structured operation references, and the platform is closed source with patent applications filed in May 2025. No public policy compiler, test runner, or export tooling was found as of 3 August 2026, so request policy export samples, a documented review and promotion workflow, and an exit test before purchase.

Adoption cost matters as much as exit cost here. ARIA is designed to sit in the execution path and take custody of tokens, which makes the vendor a dependency of every governed request and overlaps with the API gateway, AI gateway, and secrets manager many organizations already run. Cerbos is called by whatever is already in the path, including an execution boundary shaped exactly like ARIA's. Both vendors appear in published AuthZEN interoperability results, so the standard is the practical way to test either PDP against your own scenarios rather than against a feature matrix.

## Use Cerbos as the decision layer inside the architecture you own

Cerbos is the stronger choice when application and platform teams need an open PDP, policy as code, local decisions, managed distribution, and query-plan filtering in their own data layer, without handing the request path or the credentials to a new vendor plane. Prove it with one policy change containing an attribute condition, one filtered list, and one agent tool call. Implement them as Cerbos policies and tests, distribute through Git or Cerbos Hub, run shadow decisions against the incumbent, and apply a PlanResources result to the real data layer. Keep EmpowerNow where its credential vault, signed evidence packs, packaged agent rails, or identity governance breadth are verified requirements rather than assumed ones.

## Questions you are probably asking

### EmpowerID governs agents at runtime with signed receipts and a credential vault. Does Cerbos do that?

Not as a packaged bundle, and it is worth being direct about that. Cerbos is the decision point, not the credential boundary: it does not hold or inject tokens, and its decision logs are structured and exportable but not signed or hash-chained today. What Cerbos does provide is the authorization decision inside whatever execution boundary you build or buy, including one shaped like ARIA's, called from your MCP server or agent framework before a tool runs. If signed receipts and credential non-custody must come from the authorization vendor this quarter, say so early and evaluate them as requirements rather than roadmap.

### How should we compare AuthZEN support across the two?

Both vendors appear in the published interoperability results, which is what makes a head-to-head test practical. EmpowerID's published coverage spans evaluation, batched evaluations, and the search scenarios; the Cerbos PDP partially implements the documented endpoints and Cerbos Synapse exposes them natively. Rather than scoring endpoint checklists, point both at your own scenarios and compare decisions, latency, and failure behavior, then confirm the endpoint set each vendor supports in production for the integration you plan to build. For disclosure, Alex Olivier of Cerbos is one of the current AuthZEN Working Group cochairs.

### We are modernizing identity governance or migrating SAP identity management. Should we look at Cerbos?

Not for that programme. Cerbos is not an identity governance product and does not replace one: no provisioning, certification, segregation-of-duties analytics, or privileged access management, and no equivalent connector estate. EmpowerID's depth there is genuine and long-standing. Cerbos consumes the roles and attributes your identity governance system manages and enforces them at runtime inside your applications, so the two sit side by side rather than competing.

### Their engine is a hybrid of RBAC, ABAC, and PBAC with precalculated access. Is Cerbos as expressive?

Cerbos combines roles, derived roles, attributes, and request context in CEL conditions, with scoped policies for multi-authority hierarchies where a child scope can be constrained to only narrow its parent. The larger difference is when evaluation happens. Precalculated access supports before-the-fact reporting, which is genuinely useful for review and certification; Cerbos evaluates per request against the context supplied at that moment. Test both against the rules that depend on runtime attributes such as record state, relationship, or request context rather than on static assignment.

### How should we compare operational footprint?

Ask each vendor what the decision point needs in your cluster. Cerbos is a single stateless Go binary with no external datastore required for evaluation, deployable as a sidecar, DaemonSet, shared service, or a WebAssembly ePDP in supported JavaScript runtimes. EmpowerNow's documented PDP runtime is a FastAPI microservice with a layered policy and decision cache backed by Redis. Rather than trading benchmark numbers, ask what happens when the cache tier is unavailable, and what the decision cache lifetime means the day you revoke an entitlement, given that continuous authorization is a stated goal for both of us.

## The short version

**Cerbos strengths**

- Sits behind the request path, so your existing gateway, agent framework, MCP server, and secrets manager stay in place
- Uses YAML or JSON policies with CEL conditions, compiled and unit-tested in CI and reviewed in pull requests
- Ships as a single stateless Go binary across shared-service, sidecar, DaemonSet, selected serverless, and WebAssembly ePDP patterns
- Provides gRPC and REST APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel
- Returns query plans through PlanResources with documented adapters for Prisma, Drizzle, Mongoose, Convex, SQLAlchemy, and ChromaDB
- Apache 2.0 PDP with public pricing, a free tier, and a documented on-premise option for Cerbos Hub Enterprise

**Weigh with EmpowerID**

- A shipped agent-runtime bundle with schema pinning, delegation verification, budget and rate constraints, on-behalf-of chaining, human-approval gating, and an MCP tool gateway
- Credential non-custody through the documented OAuth Vault, which Cerbos does not provide
- JWS-signed, hash-chained per-action evidence packs, which Cerbos decision logs are not today
- AuthZEN coverage that includes the search endpoints in the published interoperability results
- Identity governance, privileged access management, certification, delegated administration, and a connector estate including native SAP integration
- Twenty years of converged-platform delivery, with SOC 2 Type 2 and ISO 27001:2022 attestations

Send us one of your real authorization scenarios, however messy, including an agent tool call if that is where you are heading. We will model it in Cerbos policies and run it with you.