OSS authorization policy engine with declarative YAML/JSON policies. Apache-2.0. Sub-millisecond ABAC decisions; sidecar or embedded deployment. Strong fit for fine-grained per-action authorization in microservices and AI agent stacks.
Cerbos is an OSS authorization policy engine specifically for application authorization — Apache-2.0 license, sub-millisecond decisions, declarative YAML/JSON policies. Cerbos Hub is the managed offering with policy distribution + audit. Pick Cerbos when you need application-level authorization decoupled from your application code: 'can this user perform this action on this resource' answered by a policy engine, not by if-statements scattered across your app. Materially focused on app-authz, distinct from OPA's general-purpose policy language and from infrastructure-policy tools like Kyverno.
Cerbos's positioning is the trust insight: by externalizing authorization to a policy engine, you make access decisions auditable, testable, and reviewable independent of application logic. From a Trust Before Intelligence lens, this is the highest leverage point in L5 — every read, write, or action becomes a policy decision recorded in an audit log. Cerbos's per-decision logs (with full context: principal, resource, action, derived roles, effective rule) make compliance audit dramatically easier than scattered authorization logic. The policy-as-code model means you can review authz changes the same way you review application code.
Sub-millisecond policy decisions in-memory. Policies compile to native code paths; no runtime parsing. Performance is among the best in the L5 category.
Declarative policy YAML + condition expressions (CEL — Common Expression Language). Closer to readable policy than imperative auth code. N=5.
Native ABAC — its core purpose. Per-action, per-resource, per-derived-role decisions with full context (principal attributes, resource attributes, environment). The strongest P score in the catalog.
Sidecar deployment, multi-cloud, K8s-native. Embedded mode for ultra-low-latency. Cerbos Hub for managed multi-cluster policy distribution.
Decision logs capture full context: principal, resource, action, derived roles, effective rule. Strong C dimension. Cap rule N/A.
Decision logs with full context per request. Policy compilation explanation. Why-was-this-decision-made answer is queryable. T=5.
G1=Y (native ABAC), G2=Y (decision logs), G3=N, G4=Y (policy versioning + reproducibility), G5=N, G6=Y (compliance-relevant). 4/6 -> 5 lenient (governance is its purpose).
O1=Y (Prometheus metrics built-in), O2=Y (decision audit traces enable tracing across services), O3=N (no per-decision cost in self-hosted; Cloud has limited), O4=Y (decision-log alarms catch policy violations fast), O5=N, O6=N. 3/6 -> 4.
A1=Y (sub-ms decisions), A2=Y (policy updates propagate fast via Cerbos Hub), A3=Y (in-memory policy cache), A4=Y (sidecar redundancy via deployment topology), A5=Y (production deployments documented), A6=Y (parallel decision evaluation). 6/6 -> 4 (capped to maintain consistency with peer scoring).
L1=Y (resource entities have stable identity in policies), L2=N, L3=N, L4=N, L5=Y (action + resource + derived role taxonomy IS policy semantics), L6=N. 2/6 -> 4 lenient (policy lexicon is rich and precise).
S1=Y (policy decisions deterministic), S2=Y (typed condition variables), S3=Y (decision result reproducible from same policy + context), S4=Y (typed schemas for principal/resource), S5=N (Cerbos doesn't validate input data quality), S6=Y (decision metrics flag policy anomalies). 5/6 -> 4.
Best suited for
Compliance certifications
Cerbos (OSS) holds no compliance certifications. Cerbos Hub (managed) provides SOC 2 Type II compliance; verify current attestation status. Self-hosted Cerbos inherits substrate compliance. The decision-log architecture supports compliance audit dramatically — every authz decision is recorded with full context, simplifying access-review for SOC 2 / ISO 27001 / HIPAA evidence collection.
Use with caution for
Choose OPA for general-purpose policy (infrastructure, K8s admission, app-authz). Cerbos wins on app-authz ergonomics + decision-log richness; OPA wins on breadth + Rego's universal applicability. Both Apache-2.0; both CNCF-graduated.
View analysis →Choose OpenFGA for relationship-based access control (ReBAC, Zanzibar-style — 'user can edit document because they're in this group'). Cerbos wins on attribute-based policies; OpenFGA wins on graph-relationship-based authz at hyperscale.
View analysis →Same Zanzibar-style positioning as OpenFGA. Cerbos vs SpiceDB: pick by relationship-based vs attribute-based. They're not competing on the same axis.
View analysis →AWS managed Cedar-based authz. Cerbos wins on portability + OSS posture; AWS wins on managed compliance + AWS-native integration. Cedar (used by AWS Verified Permissions) is conceptually close to Cerbos's policy model but AWS-locked.
View analysis →Role: L5 application-authz policy engine. Sidecar or embedded deployment evaluating per-request 'can this user do this action on this resource' decisions in sub-millisecond time.
Upstream: Receives decision requests from application services via SDK (Go, Java, Python, JS, .NET, Ruby, PHP, Rust). Receives policy definitions from Cerbos Hub (managed) or GitOps deployment (OSS).
Downstream: Returns allow/deny decisions to caller. Emits decision logs to durable storage (S3, Kafka, OpenSearch). Emits Prometheus metrics for L6 observability.
Mitigation: Conduct an authorization audit; identify all authz checks in app code; migrate to Cerbos policies systematically. Don't deploy Cerbos as 'one more authz layer'; deploy it as 'THE authz layer' with a migration plan.
Mitigation: Configure decision log sink to S3, Kafka, or OpenSearch. Validate retention policy. Test decision-log delivery under failure scenarios.
Mitigation: Use Cerbos's testing framework (cerbos compile + test). CI gates: policy must pass tests before merge. Test cases cover positive (should allow) and negative (should deny) for each rule.
Mitigation: Deploy at minimum 2 sidecars per pod or 2 replicas of central Cerbos service. Use circuit breaker in client SDK; on Cerbos failure, default-deny + alert (NEVER default-allow).
Mitigation: Use Kyverno or OPA Gatekeeper for K8s admission. Use OPA for general policy beyond app-authz. Cerbos is purpose-built for application authorization; don't stretch it.
Cerbos policies enforce per-patient + per-role access. Decision logs ship to SIEM. SOC 2 + HIPAA evidence collection becomes 'export decision logs for the audit window'. Policies versioned in Git; access changes reviewable as PRs.
Cerbos sidecars deployed per service. SDK calls return decision in <10ms (network roundtrip + sub-ms policy eval). Authz policies live in one place; service code calls Cerbos rather than duplicating if-statements.
Cerbos's overhead isn't justified for trivial authz. The investment pays off at scale (multi-tenant, multi-service, complex roles). For tiny authz models, scattered code is fine — until it isn't.
This analysis is AI-generated using the INPACT and GOALS frameworks from "Trust Before Intelligence." Scores and assessments are algorithmic and may not reflect the vendor's complete capabilities. Always validate with your own evaluation.