Cerbos

Access control infrastructure, honestly reviewed. What you actually get when you self-host it.

TL;DR

• What it is: Open-source (Apache-2.0) policy decision engine — the thing that decides “can this user do this action on this resource?” without your engineers writing sprawling if/else trees [README][1].
• Who it’s for: Engineering teams building multi-tenant SaaS, regulated-industry products, or AI-powered applications that need auditable, centralized access control. Not a tool a non-technical founder installs themselves.
• Cost savings: Case studies cite $264k/year saved versus in-house authorization builds, and $1M+ saved in development time [1]. Pricing for the managed Cerbos Hub is not publicly listed — requires contacting sales.
• Key strength: Decouples authorization logic from application code entirely. Define policies in YAML, call one API (isAllowed), done. Works across Java, Node.js, Python, Go, .NET, Rust, PHP, Ruby via native SDKs [README].
• Key weakness: This is developer infrastructure. Non-technical founders can’t self-serve this. A developer has to integrate it. The managed Hub pricing is opaque — “talk to an engineer” is the call to action, which signals enterprise pricing [website].

---

What is Cerbos

Cerbos is an authorization engine. It answers one question with sub-millisecond latency: “Can this principal (user, service, AI agent) perform this action on this resource?” You define the rules in YAML policy files. Your application makes an API call. Cerbos returns allow or deny. That’s the core [README].

The problem it solves is real. Without a dedicated authorization layer, permissions logic ends up scattered through your codebase: if-statements in route handlers, role checks in ORM queries, access gates in service methods. Every developer who touches that code interprets the rules slightly differently. Over three years, you have a 1,000-line authorization archaeology project that nobody fully understands and that auditors ask pointed questions about [4].

Cerbos replaces all of that with four concepts [README]:

• Principal: who’s acting (user, service, bot)
• Action: what they want to do (create, read, update, delete, approve)
• Resource: what they’re acting on (invoice, document, patient record)
• Policy: YAML files defining which principals can take which actions on which resources, with optional conditions evaluated at runtime

The Policy Decision Point (PDP) is a stateless Go service that loads these policies from disk, a git repo, an S3 bucket, or a database, then evaluates requests against them. Because it’s stateless, you can scale it horizontally to handle millions of decisions per day — Utility Warehouse runs it “millions of times a day” across their entire service mesh and describes it as something they “don’t even think about anymore. It just works.” [2]

The open-source PDP is Apache-2.0. The commercial layer — Cerbos Hub — adds policy authoring UI, CI/CD policy pipelines, audit dashboards, and (new) on-premise Hub deployment for air-gapped environments [1][README].

As of this review, the GitHub repo has 4,278 stars and is written in Go [merged profile].

---

Why people choose it

Because authorization is the part teams regret doing themselves. The evaluation framework article [4] cites an IDC stat that developers spend ~19% of their time on security tasks, averaging $28k in cost per developer per year. Custom authorization code is a large slice of that. The same article quotes a CTO: “We have Java, NodeJS, React… Cerbos integrates with all of them really well, because it works on an API level… it just works.” [4]

Because RBAC eventually isn’t enough. Simple role-based access control (RBAC) breaks down when your rules need context: a manager can approve expenses only in their own region, a premium customer can access a feature only if their contract includes it, an AI agent can read documents only from the tenant it’s operating on behalf of. Cerbos supports graduated complexity — start with RBAC, add attribute-based conditions (ABAC) where needed, extend to relationship-based (ReBAC) and policy-based (PBAC) patterns without rewriting your integration [README][4].

Because auditors want evidence, not explanations. The compliance article [3] details the cost of audit failures — British Airways’ £183M GDPR fine, Capital One’s $80M penalty, Anthem’s $16M HIPAA settlement. The common thread is that access control was either absent, fragmented, or undocumented. Cerbos logs every decision: who asked, what resource, what action, what outcome, which policy version triggered it. That’s the audit trail regulators want to see [2][3].

Because AI agents need authorization too. Cerbos has been vocal about the “AI blast radius” problem — when an AI agent can access everything a user can access, compromised or misbehaving agents become catastrophic. The website frames this explicitly: “Prevent AI over-permissioning and shadow access with Cerbos authorization.” Cerbos supports MCP server security (securing the Model Context Protocol layer), RAG authorization (controlling what documents an AI can retrieve), and agentic system permissions — all using the same YAML policy model [website][2].

---

Features

Based on the README, website, and referenced articles:

Core policy engine:

• YAML policy files: resource policies, principal policies, derived roles [README]
• Context-aware conditions evaluated at runtime using principal/resource attributes [README]
• Two primary APIs: CheckResources (“can this principal do this?”) and PlanResources (“which resources of this type can this principal access?”) [README]
• Query plan adapters that convert PlanResources responses into database queries [README]
• Policies stored in git, disk, S3/GCS/Azure Blob, or supported databases (SQLite) [README]

SDK and integration surface:

• Native SDKs for JavaScript/TypeScript, Python, Java, .NET, PHP, Rust, Go, Ruby [README][website]
• REST and gRPC APIs (call via curl or any HTTP client) [README]
• AI framework integrations, vector database authorization, MCP server security [website]
• Works with any IdP that issues tokens — Auth0, Okta, Entra ID, LDAP [4]

Deployment targets:

• Docker, Kubernetes (service or sidecar), systemd, AWS Lambda [README]
• On-premise, air-gapped, hybrid, cloud [1]
• Scales horizontally — stateless by design [README][4]
• Sub-1ms decision latency at scale [website]

Cerbos Hub (commercial/managed):

• Policy authoring UI with collaborative playgrounds [README]
• CI/CD pipeline for automated policy testing before deployment [README]
• Policy versioning and distribution to PDP fleet [README]
• Audit logs and compliance dashboards [2]
• On-premise Hub deployment (recently added for air-gapped environments) [1]
• Embedded PDP for browser and serverless/edge use cases [README]
• Cerbos Synapse: data enrichment layer that fetches identity, resource, and relationship data from external systems to enrich authorization requests at decision time [website]

Compliance frameworks covered: FedRAMP, SOC 2 & 3, ISO 27001, HIPAA, PCI DSS, GDPR, NIS2, DORA [2][website]

---

Pricing: SaaS vs self-hosted math

This is where the review gets blunt: Cerbos Hub pricing is not publicly listed. The website shows a “Try Cerbos free” entry point and routes everything else to “Talk to an engineer.” That’s a signal — this is enterprise sales pricing, not self-serve SaaS [website].

What you get free:

• The open-source PDP is Apache-2.0 — free to self-host, use commercially, embed, or fork [README]
• Cerbos Hub has a free tier that includes the interactive playground and basic policy management [website]

What likely costs money:

• Hub CI/CD pipelines and policy distribution at scale
• Audit log storage and compliance dashboards
• On-premise Hub deployment [1]
• Embedded PDP for edge/browser use cases [README]
• Support SLAs

Self-hosted cost math:

• PDP software: $0 (Apache-2.0)
• Infrastructure: a PDP pod in your existing Kubernetes cluster costs effectively nothing incremental, or a dedicated 2-vCPU / 4GB container (~$20–40/mo on any cloud)
• Engineering time to integrate: measured in days, not weeks, according to the case studies — one customer deployed “enterprise-ready authorization in 3 weeks” [1]
• Ongoing maintenance: policy changes don’t require code deployments — YAML files update without engineer involvement once the initial integration is done [README]

Versus building your own: The headline numbers from Cerbos case studies: $264k/year saved versus in-house authorization build, $1M+ in development time avoided [1]. I can’t independently verify these, and they come from the Cerbos website rather than third-party audits. But the underlying logic is sound — custom authorization logic compounds in complexity as products grow. Every new resource type, every new role, every compliance requirement adds more if-statements that someone has to maintain.

---

Deployment reality check

The PDP itself is a Go binary distributed as a Docker image. Getting it running in a Kubernetes cluster is a helm install with a values file [README]. That part is genuinely simple.

What’s less simple is the integration work:

What you actually need to set up:

• Kubernetes or Docker environment (existing cluster is fine)
• Policy files written in Cerbos YAML syntax — there’s a learning curve here, but the format is well-documented
• Application-side SDK integration: replacing your existing if/else authorization code with cerbos.isAllowed() calls
• A storage backend for policies (git repo works, S3 works, disk in a ConfigMap works)

What the realistic integration looks like: A new service with minimal existing authorization: a skilled backend developer can integrate Cerbos in 1–3 days. A legacy service with scattered if/else authorization logic across dozens of files: plan for a week to identify all the decision points, model them as Cerbos resources, and migrate the checks [4].

What can go sideways:

• Policy modeling requires upfront thinking. You need to decide what your “resources” are, what “actions” map to, and what attributes principals and resources carry. Getting this wrong means rewriting policies later.
• The PlanResources API (for filtered list queries) requires query plan adapters — official adapters exist for several ORMs, but if yours isn’t covered you write your own [README].
• Air-gapped and on-premise Hub deployment is newly available but flagged as “new release” on the website [1] — consider it less battle-tested than the standard cloud Hub.
• No purely independent third-party reviews were available at time of writing — the sourced articles are either Cerbos-authored or from the Cerbos website. User testimonials on G2 or Trustpilot were not included in the research inputs, so community sentiment is harder to assess than for more consumer-facing tools.

---

Pros and cons

Pros

• Apache-2.0 license. Commercial use, redistribution, embedding in your own product — no restrictions, no “Fair-code” limitations, no sudden license changes [README].
• Language-agnostic API. REST/gRPC means it works from any stack. Official SDKs for eight languages means most teams don’t even need to hand-roll HTTP calls [README][4].
• RBAC → ABAC → ReBAC without rewriting your integration. Start simple, add complexity as requirements grow. The API surface stays the same [README][4].
• Sub-1ms decision latency at demonstrated scale. Utility Warehouse runs it millions of times daily across their service mesh [2][website].
• Stateless PDP scales horizontally. No shared state to manage, no database bottleneck in the critical authorization path [README][4].
• Audit logs built-in. Every decision is logged with the policy version that triggered it — exactly what compliance audits require [2][3].
• AI system authorization support. MCP server security, RAG authorization, and agentic permission controls using the same policy model — not a bolted-on feature [website][2].
• Cerbos Synapse (data enrichment layer) solves the hard problem of fetching dynamic context (relationships, external attributes) at authorization time without your app having to assemble it [website].

Cons

• This is developer infrastructure, not a no-code tool. A backend developer needs to integrate it. Policies are YAML files checked into git. Non-technical founders cannot self-service this [README].
• Hub pricing is opaque. Enterprise sales pricing without published tiers makes it hard to budget. “Talk to an engineer” is the only path [website].
• Policy modeling requires design work upfront. Poorly modeled resources/actions create technical debt that’s painful to refactor once the PDP is in production [4].
• On-premise Hub is newly released. The air-gapped deployment option is marked as “new” — early adopters in high-security environments should expect rough edges [1].
• No independent third-party reviews in this research. All sourced articles are Cerbos-authored. Community review aggregators (G2, Trustpilot) weren’t included in the research inputs. The real-world frustration signals are harder to assess than for tools with broader consumer coverage.
• Smaller community than OPA. The Open Policy Agent (CNCF project) has a larger open-source community. Cerbos’s 4,278 stars is solid but not in the OPA tier. Less third-party tooling, fewer blog posts, smaller Stack Overflow surface area [merged profile].

---

Who should use this / who shouldn’t

Use Cerbos if:

• You’re building a multi-tenant SaaS product and need to enforce per-tenant permissions cleanly across services.
• You’re in a regulated industry (fintech, healthcare, legal tech) where audit-ready access control logs aren’t optional.
• Your authorization logic has grown past simple role checks and you’re tired of the maintenance burden.
• You’re building AI agents and want to control what they can access with the same rigor as human users.
• You want Apache-2.0 licensing — no commercial restrictions, no vendor lock-in risk.

Wait on it if:

• Your product has simple, static permissions (two roles, no conditions). A basic middleware check in your framework is fine. Cerbos would be over-engineering for this.
• You don’t have a backend developer to own the integration. This is not a no-code SaaS you can configure in a browser.
• You need Hub pricing before budgeting. Contact them first, get a quote, then decide.

Pick OPA instead if:

• You need the deepest CNCF ecosystem integration — OPA is the standard choice for Kubernetes policy enforcement, service meshes, and infra-level authorization.
• Your team already knows Rego (OPA’s policy language) and you want policy uniformity across infra and application layers.
• Community size and third-party tooling volume are decision criteria.

Pick Permit.io instead if:

• You want a SaaS-first experience with a polished UI for non-engineers to manage permissions.
• You’d rather pay a monthly fee than own infrastructure at all.
• Your compliance requirements permit data leaving your environment.

---

Alternatives worth considering

• OPA (Open Policy Agent) — CNCF project, broader infra ecosystem, Rego policy language is more expressive but steeper learning curve than Cerbos YAML. Apache-2.0. The standard for Kubernetes and service mesh authz.
• Casbin — Open source, code-centric, supports many access control models. Less opinionated than Cerbos, which means more assembly required.
• Permit.io — SaaS-first, polished no-code UI for permission management. Good for teams that want to move faster and are fine with managed infrastructure.
• Ory Keto — Open source, implements Google’s Zanzibar model (relationship-based access control). Strong choice if ReBAC is your primary requirement.
• AWS Verified Permissions — Fully managed, uses the Cedar policy language, tight AWS integration. No self-hosting option, AWS lock-in.
• Auth0 Fine-Grained Authorization — Good if you’re already in the Auth0 ecosystem. Not open source.
• Roll your own — The default choice that Cerbos exists to replace. Technically free, practically expensive once the codebase matures.

---

Bottom line

Cerbos solves a real engineering problem: authorization logic that starts as a handful of if-statements and ends as an unmaintainable mess spread across every service in your stack. The Apache-2.0 PDP is genuinely well-designed — stateless, fast, language-agnostic, and models complex access control patterns without asking you to learn a domain-specific language.

The honest limitation is audience fit. Cerbos is developer infrastructure. A non-technical founder can’t install or configure it. The payoff is real — case studies cite $264k/year in savings versus in-house builds [1], and the compliance story (audit-ready logs, GDPR/SOC2/HIPAA coverage) matters for anyone building in regulated markets [2][3]. But someone on your engineering team has to own the integration, own the policy files, and own the deployment.

If that’s you, or you have that person: the open-source PDP is worth evaluating seriously. If the “talk to an engineer” pricing wall is a concern, get the quote before you build a dependency on Cerbos Hub. The PDP itself costs nothing to run.

If you need Cerbos deployed and don’t have the engineering bandwidth, upready.dev handles exactly this kind of infrastructure setup.

---

Sources

1. Cerbos — Self-Hosted On-Premise Cerbos Hub (official product page, features and case studies). https://www.cerbos.dev/features-benefits-and-use-cases/self-hosted-authorization
2. Cerbos — Stay Secure and Audit-Ready as AI Enters Production (security teams solutions page). https://www.cerbos.dev/for-security-teams
3. Anna Paykina, Cerbos Blog — “Staying Compliant - What You Need to Know” (November 21, 2025). https://www.cerbos.dev/blog/staying-compliant
4. Alex Olivier, Cerbos Blog — “Framework for Evaluating Authorization Providers and Solutions” (January 26, 2026). https://www.cerbos.dev/blog/framework-evaluating-authorization-providers-solutions

Primary sources:

• GitHub repository and README: https://github.com/cerbos/cerbos (4,278 stars, Apache-2.0 license)
• Official website: https://www.cerbos.dev
• Pricing page: https://www.cerbos.dev/pricing