Cerbos is an open-source authorization engine that provides fine-grained, policy-based access control for applications, APIs, AI agents, and MCP servers. Written in Go, it evaluates authorization requests against YAML-defined policies with sub-1ms latency — acting as a stateless policy decision point (PDP) that decouples access control logic from application code.
Where MCP-Scan detects vulnerabilities in MCP server configurations, Cerbos solves a complementary problem: controlling which tools an agent can actually use based on user identity and organizational policy.
While Cerbos started as a general-purpose authorization solution for software applications, it has gained traction in the AI security space as organizations deploy AI agents that need granular permission controls. When an AI agent interacts with external tools through MCP (Model Context Protocol), Cerbos determines which tools that agent — and the user behind it — is actually allowed to use.
The project has over 4,300 GitHub stars (as of April 2026) and SDKs for eight programming languages. The latest release at the time of writing is v0.51.0 (February 2026); confirm the current version on github.com/cerbos/cerbos/releases before pinning. The core PDP is open-source under Apache 2.0, with commercial products (Cerbos Hub, Cerbos Synapse) adding centralized management and data enrichment capabilities.
What is Cerbos?
Authorization in traditional applications is already complicated — roles, attributes, contextual conditions, and compliance requirements create a tangled web of access control logic scattered across codebases. AI agents amplify this problem: an agent acting on behalf of a user should inherit that user’s permissions, but the execution happens through tool calls and API chains that existing authorization systems were not designed to handle.
Cerbos solves this by centralizing all authorization decisions in a single policy engine. Applications, APIs, and AI agents send authorization requests (who wants to do what, on which resource, with what context), and Cerbos returns a decision based on YAML policies. The engine is stateless, so it scales horizontally without shared state or session management.
What are Cerbos’s key features?
| Feature | Details |
|---|---|
| Decision Latency | Sub-1ms policy evaluation |
| Policy Format | Human-readable YAML with Git-ops management |
| Access Models | RBAC, ABAC, PBAC (Permission-Based Access Control) |
| Derived Roles | Dynamic role assignment based on contextual conditions |
| APIs | CheckResources and PlanResources endpoints |
| Language SDKs | Go, Java, JavaScript, Python, .NET, PHP, Ruby, Rust |
| AI Authorization | Agent permissions, MCP server tool control, RAG pipeline access |
| Deployment | Kubernetes (sidecar or service), Lambda, containers, edge, air-gapped, on-premise, WebAssembly |
| Compliance | SOC 2, SOC 3, HIPAA, ISO 27001, FedRAMP, GDPR, PCI DSS |
| Latest Release | v0.51.0 (February 2026) |
| Audit Logging | Structured decision logs with policy version lineage |
| Technology | Written in Go (93.4% of codebase), stateless architecture |
How authorization works
Cerbos operates on three core elements: principals (users, applications, or agents requesting access), actions (specific operations like create, read, update, delete), and resources (protected objects with attributes). Every authorization request includes these three elements plus optional context.
The PDP evaluates the request against matching policies and returns an ALLOW or DENY decision. Because the engine is stateless, it can run as a sidecar in Kubernetes, a standalone service, or even inside a Lambda function — scaling independently of the application it protects.
AI agent and MCP authorization
When an AI agent operates through MCP, it calls tools on behalf of a user. Without authorization controls, the agent has access to every tool the MCP server exposes — regardless of whether the user behind the agent should have that access.
Cerbos sits between the agent’s tool request and execution. The MCP server sends the agent’s identity, the requested tool, and the user’s context to Cerbos.
The policy engine evaluates whether that combination is authorized, and the MCP server only exposes the permitted tools. This approach means permissions are enforced consistently whether a human or an AI agent makes the request.
For RAG (Retrieval-Augmented Generation) pipelines, Cerbos controls which documents an agent can retrieve from vector stores (Pinecone, Weaviate, Chroma, Qdrant), ensuring that AI responses only draw from data the requesting user is authorized to access.
Mapped to the OWASP Agentic AI Threats and Mitigations taxonomy, this design directly addresses T6 Excessive Agency (agents calling tools beyond their intended scope) and T7 Tool Misuse (using authorized tools in unauthorized ways) by making every tool invocation pass through an explicit authorization decision. Cerbos also contributes to T1 Memory Poisoning controls when policies restrict which retrievers and document sources an agent can read from in a RAG pipeline.
The same engine supports the OWASP Top 10 for LLM Applications guidance on LLM06 Excessive Agency and the NIST AI RMF Manage function — every ALLOW/DENY decision is a structured audit record that compliance teams can attach to incident reviews and red-team reports.
Commercial offerings
Cerbos Hub is the centralized control plane for policy authoring, testing, versioning, and distribution. It adds visual policy editing, automated testing, and multi-environment deployment management on top of the open-source PDP.
Cerbos Synapse enriches authorization requests by automatically fetching identity, resource, and relationship data from external systems — eliminating the need for applications to assemble context before making authorization calls.
Identity provider integrations
Cerbos integrates with major identity and DevOps platforms:
Cerbos vs OPA
Open Policy Agent (OPA) is the canonical comparison for any authorization engine, and the cerbos vs opa decision question dominates buyer research. The two projects solve overlapping problems with different ergonomics, so the choice usually comes down to policy language, scope, and AI-agent readiness.
Policy language is the most visible difference. OPA uses Rego, a Datalog-inspired language that is expressive but has a learning curve. Cerbos uses YAML with embedded CEL (Common Expression Language) for conditions, which is faster for application engineers to read and review in pull requests but offers less flexibility for cross-resource queries.
Scope and deployment model also diverge. OPA is a general-purpose policy engine — it ships authorization, admission control, data filtering, and config validation under one binary, and Kubernetes admission webhooks via Gatekeeper are a major use case. Cerbos focuses narrowly on application authorization as a stateless PDP and is purpose-built for resource-level decisions in API and agent code paths.
AI agent and MCP support is where Cerbos has a clear advantage. Cerbos ships first-class authorization patterns for AI agents calling tools through MCP and for RAG pipelines reading from vector stores. OPA can be wired into these flows but does not have native primitives for the agent + MCP model — teams typically write custom Rego helpers or pair OPA with separate agent governance tooling.
Ecosystem maturity favors OPA. OPA is a CNCF graduated project with a larger community, more integrations, and longer production track record. Cerbos has a smaller but actively growing community and faster decision latency for the application-authorization workload it targets. For Kubernetes-heavy infrastructure stacks, OPA + Gatekeeper is the safer default; for API and AI-agent authorization, Cerbos is purpose-fit.
How do I get started with Cerbos?
When to use Cerbos
Ideal for teams that need to control what AI agents and MCP-connected tools can do, based on the identity of the user the agent represents. While tools like MCP-Scan detect vulnerabilities in MCP server configurations, Cerbos solves a different problem: ensuring that even a perfectly secure MCP server only exposes the right tools to the right users.
The authorization engine is also valuable beyond AI use cases — any application that needs to decouple access control from business logic benefits from a centralized policy decision point. The AI agent authorization capabilities are an extension of the same core engine.
For a broader overview of AI security tools, see the AI security tools guide. For vulnerability scanning of MCP servers (rather than authorization), see MCP-Scan . For full governance of agentic AI systems including runtime inspection, consider Cisco DefenseClaw .
How much does Cerbos cost?
Cerbos uses an open-core model. The Cerbos Policy Decision Point (PDP) is free and Apache 2.0 licensed, with no usage caps — teams can run unlimited PDP instances on Kubernetes, Lambda, containers, edge, or air-gapped environments without a paid contract.
Commercial value sits in Cerbos Hub, a managed control plane for policy authoring, testing, versioning, and distribution. Cerbos publishes Hub tiering on cerbos.dev/pricing, with a free tier suitable for evaluation and Pro and Enterprise tiers for production policy management; check the vendor pricing page for the current dollar amounts and seat limits.
Cerbos Synapse is a separate commercial add-on that handles data enrichment for authorization requests, fetching identity, resource, and relationship attributes from external systems on behalf of the PDP.
Self-hosted PDP usage stays free indefinitely; teams that want centralized policy management, multi-environment deployment workflows, or commercial support move to Cerbos Hub. For current pricing details, visit cerbos.dev/pricing .
What are alternatives to Cerbos?
If Cerbos’s YAML-first PDP model is not the right fit, five tools cover overlapping ground.
Open Policy Agent (OPA) is the incumbent open-source alternative. It is a CNCF graduated project with a larger community, broader scope (admission control, config validation, data filtering), and the Rego policy language. OPA is the safer pick for Kubernetes admission control and for teams that already have Rego expertise.
Authzed / SpiceDB implements a Google-Zanzibar-style authorization model with relationship-based access control. It is the better choice when the threat model involves complex object hierarchies — document sharing, multi-tenant SaaS resource graphs — rather than rule-based RBAC/ABAC.
Oso Cloud is a developer-first managed authorization service with the Polar policy language. It targets product engineering teams that want authorization as a managed service with strong SDK ergonomics rather than a self-hosted PDP.
Auth0 FGA (formerly Auth0 Fine-Grained Authorization) is Okta’s managed Zanzibar-style service, suited for organizations already standardized on Auth0 / Okta identity infrastructure that want authorization in the same vendor portfolio.
Permit.io is a managed authorization platform that wraps OPA and AWS Cedar under a unified API, useful when the goal is a no-code policy editor and managed PDP fleet rather than running infrastructure.
For agentic AI threats beyond authorization, see MCP-Scan for MCP server vulnerability scanning and Cisco DefenseClaw for runtime agent governance.
