Cerbos
Open-source, language-agnostic authorization server that evaluates RBAC and ABAC policies defined in YAML/JSON, deployable as a sidecar or service with a gRPC/REST API.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Self-hosted by default — no data leaves your infrastructure. Open-source codebase is auditable. Auth configuration is operator responsibility; misconfiguration can expose unauthenticated endpoints. Cerbos Hub adds managed security controls.
⚡ Reliability
Best When
You need a self-hosted, open-source authorization server with strong policy-as-code workflows, compliance auditability, and no per-check cloud egress.
Avoid When
You want zero infrastructure to manage and prefer a fully managed SaaS authorization API with a UI for non-technical policy editors.
Use Cases
- • Evaluate fine-grained access control decisions in real time by calling the check API from any service or agent
- • Define and version-control human-readable YAML policies that express who can do what under which conditions
- • Audit all authorization decisions with structured decision logs for compliance and debugging
- • Run fully offline or air-gapped authorization without any external SaaS dependency
- • Test authorization policies in CI/CD pipelines using Cerbos' built-in policy testing framework
Not For
- • Teams that need a fully managed cloud service with no infrastructure to operate — Cerbos Hub exists but the core is self-hosted
- • Identity management, user authentication, or token issuance — Cerbos only handles authorization decisions
- • Relationship-based access control at massive scale (billions of tuples) — use Zanzibar-native systems like SpiceDB for that
Interface
Authentication
Auth method depends on deployment configuration. Self-hosted instances can be unauthenticated (internal network), mTLS, or JWT-gated. Cerbos Hub (cloud) uses API keys. Flexible but requires operator configuration.
Pricing
Core server is Apache 2.0 licensed and free. Cerbos Hub adds a managed control plane; pricing is usage-based.
Agent Metadata
Known Gotchas
- ⚠ Policy files must be loaded at startup or via the Admin API; dynamic policy changes require an Admin API call or server restart depending on deployment mode
- ⚠ The `principal` object must include all attributes referenced in policies — missing attributes silently evaluate as undefined, which may cause unexpected DENY decisions
- ⚠ gRPC is the preferred transport for performance; REST is available but some advanced features (batch checks) are better supported via gRPC
- ⚠ Cerbos does not store user or resource state — the calling agent must supply all relevant attributes in every check request, which increases payload size for attribute-rich policies
- ⚠ Policy condition syntax uses CEL (Common Expression Language); CEL type errors in conditions fail silently as DENY in some versions rather than returning an evaluation error
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Cerbos.
Scores are editorial opinions as of 2026-03-06.