# Cerbos — full reference corpus > End-to-end enterprise authorization management platform. This file is the > complete text of every reference document on cerbos.dev, concatenated. It is > the companion to https://www.cerbos.dev/llms.txt, which is the curated index. This file is large: 70 documents, roughly 570KB of markdown, on the order of 146,000 tokens. If that does not fit the context you have left, fetch https://www.cerbos.dev/llms.txt and follow it to the individual documents instead — every one of them is served on its own as markdown. Each document below is delimited by `` and ``, where the URL serves that document on its own. Every document keeps its own YAML frontmatter — title, description, canonical, source, and where they apply author, date and tags. Not included here, because they are unbounded or are contract text: - Blog articles — index at https://www.cerbos.dev/blog, each served as https://www.cerbos.dev/blog/.md - News — index at https://www.cerbos.dev/news, each served as https://www.cerbos.dev/news/.md - The full text of each customer case study — the index below carries every customer's outcomes and links to the study, each served as https://www.cerbos.dev/customers/.md - Legal and contract text — code of conduct, DPA, privacy policy, terms of service, trademark guidelines, trusted tester agreement, each served as https://www.cerbos.dev/.md For the complete page listing, see https://www.cerbos.dev/sitemap.md. --- title: "Cerbos: authorization for enterprise software and AI" description: "Enforce fine-grained, contextual, and continuous authorization across applications, gateways, workloads, and AI agents." canonical: "https://www.cerbos.dev" source: "https://www.cerbos.dev/index.md" --- # Authorize every identity. Govern every action. Enforce fine-grained, contextual, and continuous authorization across applications, gateways, workloads, and AI agents. Cerbos is an end-to-end authorization management platform. Policies are authored once as human-readable YAML, managed centrally, and enforced at runtime by stateless Policy Decision Points deployed alongside your services — in the cloud, on-premise, or air-gapped. It replaces the authorization logic scattered through application code with a single call that returns an allow or deny decision, evaluated against the principal, the resource, and the context of the request. RBAC, ABAC, ReBAC and PBAC are all expressed in the same policy language. ## Make roles and permissions an asset, not a chore - **Faster app development** — Externalize authorization and prioritize your app’s core functionalities. Leverage a plug-and-play, API-based approach, designed to integrate with your existing systems and accelerate development, saving you months of implementation time. - **Flexible to changing requirements** — Adapt to evolving business needs and regulatory requirements with policy-based authorization. Centralized management which integrates into governance frameworks, enabling changes without compromising compliance. - **Increased security at scale** — Ensure least-privilege access across all apps and services in your architecture. Implement fine-grained, zero trust runtime access controls to protect your data and systems from evolving threats at runtime. ## Build roles and permissions in minutes - **Pre-built integrations and policies** — Get up and running in minutes with SDKs and starter projects for common frameworks, servers, ORMs and identity providers. [Ecosystem](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) - **Permissions aware data filtering** — Generate dynamic conditions to query and filter based on the access policy for each object and principal. [Query filtering](https://www.cerbos.dev/features-benefits-and-use-cases/permission-aware-data-filtering) · [Data-filtering for RAG](https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag) - **Beyond RBAC/ABAC** — Implement context-aware role definitions and attribute-based access control for adaptable, granular security policies. [RBAC](https://www.cerbos.dev/features-benefits-and-use-cases/rbac) · [ABAC](https://www.cerbos.dev/features-benefits-and-use-cases/abac) ## Iterate with ease - **Human-readable** — Manage policies in configuration instead of code. [Low-code](https://www.cerbos.dev/features-benefits-and-use-cases/human-readable-authorization) - **Policy Playground** — Experiment with policies in a safe environment and get simulated results in real time. [Playground](https://www.cerbos.dev/features-benefits-and-use-cases/cerbos-playground) - **GitOps testing** — Implement a CI/CD workflow with GitOps. Reduce human errors and enhance security. [GitOps & CI/CD](https://www.cerbos.dev/features-benefits-and-use-cases/gitops-and-ci-cd) - **Stateless and scalable** — Stateless decision points run in your environment or at the edge. [Stateless authZ](https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization) ## Deploy without risk - **Audit trails** — Capture all actions attempted and decisions made by your Cerbos policies. ISO27001, SOC2, HIPAA compliant. [Audit logs](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) - **Coordinated rollout and monitoring** — Centralized management and real-time policy deployment to keep authorization synchronized across your application. [Coordinated rollout](https://www.cerbos.dev/features-benefits-and-use-cases/coordinated-rollout-and-monitoring) - **Low-latency** — Decisions are made locally at runtime in sub-milliseconds without requiring any cloud lookups. [Low-latency](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models) - **Flexible deployment models** — Self-hosted, compatible with air-gapped, high security environments. Deploy with serverless functions or a sidecar model. [Deployment](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models) ## Cerbos benefits for different roles - **Developers** — Replace complicated authorization logic with a single call and allow product owners or security teams to manage access without touching code. [Implement authZ once](https://www.cerbos.dev/for-developers) - **Product Managers** — Define and evolve complex policies without requiring further developer time. [Plug and play collaborative authZ](https://www.cerbos.dev/for-product-teams) - **Security teams** — Track and audit access requests, grants and denials without without requiring further developer effort. [Low-code collaborative authZ](https://www.cerbos.dev/for-security-teams) - **Architects** — Design a truly zero trust application architecture with externalized authorization. [Secure your architecture](https://www.cerbos.dev/for-architects) ## Secure non-human identities at scale Manage permissions for workloads, microservices, AI agents, and API clients with flexible, policy-driven authorization. ## Centralized management, decentralized decisioning - Define RBAC and ABAC policies in a single source of truth. - Manage, govern and audit access control from a central Policy Administration Point. - Deploy distributed Policy Decision Points (PDP) locally alongside applications and services for local decisioning at runtime ## What our users say about Cerbos > "It's weird to say an outside company has our back, but Cerbos does. It's the people. It's their open-source code: it's high quality, you can read it, it does what it says on the tin" > > — Rob, Principal Engineer, Utility Warehouse > "It's a good feeling being able to say yes to almost any permissioning requirement." "Cerbos is small, contained and easy to implement. It 100% delivers on the promise of abstracting away the complexity of decision making." > > — Joe, Software Engineer, 9fin > "We're not worried about scaling because we can easily increase our load on Cerbos. It will also be easy for us to change how we're distributing policies as we reach different points of scale." > > — David, Senior Software Engineer, Salesroom > "We went from one user - every role, to a world where there are many users - many roles. And the product, it relies on Cerbos to actually bring the value that we want to bring to customers. All of our customers are relying on Cerbos, by relying on the product, which is of course relying on Cerbos." > > — Joe, CEO & Co-Founder, Nook > "Instead of thinking of how much time Cerbos has saved us, I think about how much time it didn't cost us. It didn't cost us any time. Cerbos just works. I don't have to think about it. It's as simple as that." > > — Chuck, Head of Engineering, Salesroom > "One of our big considerations was speed. We have strict latency tolerances. When it comes to Cerbos - you can call it a hundred times during a request and it doesn't matter. It's incredibly fast." > > — Steve, Staff Engineer, Complex > "If it wasn't for Cerbos, one thing is for sure - we would've launched later than we did. As a result, we would have less customers. And the maintenance part is also very important. Our technical team would be dealing with daily stuff regarding access controls, access logs. Now, we don't have to spend any time on that." > > — Engin, Head of Product and Growth & Co-Founder, Debite > "Cerbos policy writing is quite flexible, and deploying as a unit microservice as well. Cerbos "doesn't get in the way" once integrated, that's the best part." > > — Rounak, Founding Engineer, CommandK > "It is easy to implement and provides a solution for a problem that is often not properly addressed." > > — Romina, Tech Lead, Wizeline > "Having the separation of the permissions from the code base just makes the code base more elegant. It makes the permissioning more elegant. It means they're centralized, so they're not tied to specific endpoints. And ultimately it means that different business owners have the ability to actually make updates." > > — Henry, CTO & Co-Founder, Nook > "Just discovered your embedded testing framework. This is probably the best balance between hyperfocused functionality and embedded tooling I've ever seen in an open source project. Damn, good work!" > > — Rasmus, CTO, Firtal ## Next steps - [Book a demo](https://www.cerbos.dev/workshop) - [Try Cerbos Hub for free](https://hub.cerbos.cloud/) - [Cerbos PDP](https://www.cerbos.dev/product-cerbos-pdp.md) — the open-source decision engine - [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub.md) — the management control plane - [Pricing](https://www.cerbos.dev/pricing.md) - [Documentation](https://docs.cerbos.dev) - [Index for agents](https://www.cerbos.dev/llms.txt) — every document on this site, with its markdown URL - Command line: `npm install -g cerbosctl`, or `brew tap cerbos/tap && brew install cerbos` --- title: "Join us" description: "Current open roles and how to apply." date: "2021-04-01T00:00:00.000Z" canonical: "https://www.cerbos.dev/join-us" source: "https://www.cerbos.dev/join-us" --- # Join us on our mission to make permissions simple. We are looking for passionate team members to join us in our journey. Cerbos is on a mission to make the implementation of access-control in modern, cloud-native applications as painless as possible. No more writing and rewriting custom permissions implementations, and lots more time for developers to focus on building amazing products that delight their customers. ##### Highlights - 🚀 Well funded start-up with world class investors - ✈️ Travel and events - 🔑 Work with the founders - 💰 Competitive salary & perks - 🌍 Work from anywhere ##### Why are we building Cerbos? In software development, a huge amount of time and effort is expended on building and maintaining bespoke authorization for the system under development. Our vision is to remove that toil by building a full-featured authorization system that can be integrated into any project and evolves with it as requirements change. From prototype to planet-scale SaaS, Cerbos will grow and scale with your application and free developers to concentrate on your core product. ##### Why join our journey? - We are striving to build a truly global, fully distributed company that embraces diversity and openness. - Every new member that joins us will have a disproportionately large impact on our users, product, and business; as well as the culture and future of the company. - Our founders have a great track record from working at global tech giants to building successful tech companies. ##### We value the following skills - Passion for creating a delightful, best-in-class experience for developers who are trying to address a hard problem. - Humble, empathetic people who can work just as well independently and as part of a team. - People who choose simplicity over complexity. - Good verbal and written communication skills in English. ## Current Open Roles

B2B Growth Marketer (Enterprise & Developer Audience)

   We’re looking for a **_T-shaped B2B Growth Marketer_**—someone who thrives on hands-on execution across multiple marketing channels and B2B tactics. This is a rare, high-impact role ideal for an ex-startup growth marketer with experience targeting B2B/B2D enterprise audiences. You should be **_obsessed with overachieving, growth strategies, and analytics_**. If you read every Reforge article and get excited about running experiments, optimizing campaigns, and scaling demand generation, we want to hear from you. ##### Responsibilities - Define and optimize our enterprise lead generation motion in collaboration. - Lead and execute ABM, CROs, performance marketing, and B2B lead generation campaigns—hands-on, data-driven execution. - Analyze and optimize marketing performance—deep dive into analytics to refine channel strategy and conversion rates. - Identify and establish strategic partnerships—affiliates, co-marketing, and industry collaborations. - Drive pipeline growth and customer acquisition across multiple channels. - Run structured growth experiments to validate hypotheses, optimize conversion rates, and increase net revenue retention. - Build and manage our growth tech stack, selecting and integrating tools for automation, analytics, and campaign management. ##### Required Skills & Experience - Strong analytical skills with hands-on experience in B2B revenue attribution, marketing attribution modeling, HubSpot reporting, and GA4 analytics. - Hands-on ABM and multi-touch marketing experience, including campaign execution, lead generation, and pipeline acceleration. - Performance marketing expertise, covering ad setup, creative strategy, optimization, and in-depth reporting. - Proven experience in demand generation, including webinars, enterprise events & conferences, whitepapers, and content-driven lead acquisition. - Experience marketing to enterprise B2B audiences/ICPs, with a deep understanding of long sales cycles and complex decision-making processes. - Affiliate and partnership marketing experience, managing co-marketing, referrals, and industry collaborations. - 5+ years in growth marketing, PMM, or B2B/SMB SaaS marketing, with a focus on demand creation, customer acquisition, and pipeline growth. - Experience building and managing a marketing tech stack for automation, reporting, and optimization. - Strong understanding of developer or technical audience marketing—you don’t need to code, but you must know how to engage technical buyers. - Portfolio of successful (or unsuccessful) B2B/SMB/enterprise marketing campaigns and experiments. ##### About You - You’re not just a performance marketer, product marketer, or campaign specialist—you thrive in all areas of growth. - You’re technically curious. - You have an experimentation mindset. You iterate relentlessly, measure what works, and pivot when needed. You treat failure as learning and optimize every initiative for impact. - You’re highly autonomous. You take ownership of projects, execute independently, and proactively remove roadblocks. - You focus on business impact. You align marketing initiatives with revenue growth, always asking, “How does this drive results?” - You have high execution standards. You deliver quality work at speed, leveraging AI and automation while ensuring customer-facing content is polished and strategic. - You take initiative. You don’t wait for instructions—when you see an opportunity or problem, you act. - You thrive in a startup environment. You own your work, move fast, and solve problems creatively. "Not my job" is not in your vocabulary. If you’re an ex-startup founder, we definitely want to talk! 🚀 ##### Why Join Cerbos? Cerbos is at the forefront of the rapidly growing, multibillion-dollar authorization industry, helping enterprises simplify permission management at scale. We are proud to be open-source first company and a trusted authorization solution for enterprise products, scale-ups, and everyone building with security in mind. Working at Cerbos is challenging but also fun! Here’s why you’ll love being part of our team: - 🚀 High-impact role—shape the future of our growth strategy. - 🌍 Fully remote—work from anywhere, with a diverse global team. - 👨‍💻 Founded by experienced leaders—proven track record in scaling tech companies. - 💸 Well-funded startup—backed by world-class investors. - ✈️ Opportunities for travel and speaking engagements (if you want to engage with developers). - 💰 Competitive salary and perks. ##### How to Apply If this sounds like a fit, please apply! Send us: - Your CV - Your B2B marketing portfolio (it can be as simple as your work examples) - Your answer to: "What was your most successful B2B campaign?" 📩 Email your application to join.us@cerbos.dev We will follow up with every candidate who sends the required CV, portfolio, and answer to the question. **Interview process:** 1. CV and portfolio review. 2. Soft skills interview. Hard skills interview. 3. Paid test task. 4. Cultural fit interview.
If any of the above roles resonate with you, please get in touch. You can reach us by emailing us your CV, writing portfolio, and demo apps at [join.us@cerbos.dev](mailto:join.us@cerbos.dev). We are currently not accepting candidates referred to us through HR agencies or recruiters. --- title: "Glossary" date: "2022-02-28T00:00:00.000Z" canonical: "https://www.cerbos.dev/glossary" source: "https://www.cerbos.dev/glossary" --- # Glossary ## ABAC Attribute-based access control (ABAC), also known as policy-based access control for IAM, defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. ## Authentication It is the act of proving an assertion, such as the identity of a computer system user. It tells who you are. ## Authorization Is the function of specifying access rights/privileges to resources. It tells what you can do. ## Cerbos Engine / Server Also known as Cerbos Policy Decision Point (PDP) is the heart of Cerbos, a central piece of software that processes all the requests. It is built for modern, containerised microservice environments with support for both x86-64 and ARM64 architectures, comprehensive observability integrations (metrics, distributed tracing), REST and gRPC endpoints, and native GitOps support (CI tooling, push-to-deploy). ## Policy Policy is a deliberate system of guidelines to guide decisions and achieve rational outcomes. A policy is a statement of intent and is implemented as a procedure or protocol. ## Principal The entity which is being authorised to perform an action. It can be a person/user, a service or any other identity ## Resource The entity that the principal is requesting access to. These are typically the main objects that the policy is being applied to. ## Action The action that the principal is requesting access to. It is a verb that is used to describe the type of access that is being requested. ## Playground A playground, playpark, or play area is a place designed to provide an environment for developers that facilitates play and test a specific technology. ## SDK Software Development Kit, is a collection of software development tools in one installable package. They facilitate the creation of applications by having a compiler, debugger within a software framework. ## RBAC Role Based Access Control. It is a policy-neutral access-control mechanism defined around roles and privileges. The components of RBAC such as role-permissions, user-role and role-role relationships make it simple to perform user assignments. ## ReBAC (Relationship-based Access Control)is a feature that allows admins to set up a system of delegated administration with which users can self-manage their relationships to digital assets. ## YAML (Yet Another Markup Language) is a human-readable data-serialization language. It is commonly used for configuration files and in applications where data is being stored or transmitted. --- title: "FAQ" date: "2022-02-28T00:00:00.000Z" canonical: "https://www.cerbos.dev/faq" source: "https://www.cerbos.dev/faq" --- # FAQ ## What is authorization? Authorization is the process of giving 'something' the ability to access 'somewhere'. When it comes to IT, this can be a process, an API call, a user, an application trying to access a resource, another application, or a feature. ## How does Cerbos work? Cerbos is an enterprise authorization solution built to secure access across complex, distributed environments, SaaS products, and regulated systems. It externalizes authorization logic from application code, making access control consistent and centrally managed across all services, saving months of dev time while ensuring compliance and security. Cerbos enables authorization logic to be written as policy outside of your application code, replacing the complex checks with a simple call out to a Cerbos which returns an ALLOW or DENY based on the data in the context provided and the current live policies. Policies are defined as human-readable YAML and are stored either on disk, Cloud Storage, a Git repo, or a database. Policies define the resources in the system, what actions can be taken upon them. Based on information about the principal/user making the request and what resource is being accessed conditions can be defined which are computed on the fly for fine-grained access control. As the policy is now abstracted outside of the application logic, business requirements can change and policies updated without having to make any code changes or releases. ## How does Cerbos integrate into my app? Where complicated permission logic would have been done previously, it is replaced with a call out to check the permissions against a deployed Cerbos instance. This call requires 3 bits of information: - *Principal* - who is making the request - *Resource* - what are they trying to access - *Action(s)* - what are they trying to do to the resource For simplicity, integration into your application can be done via using one of the Cerbos SDKs: - [Go](https://pkg.go.dev/github.com/cerbos/cerbos/client) - [Java](https://github.com/cerbos/cerbos-sdk-java) - [NodeJS](https://github.com/cerbos/cerbos-sdk-node) - [.NET](https://github.com/cerbos/cerbos-sdk-net) - [Ruby](https://github.com/cerbos/cerbos-sdk-ruby) - [Python](https://github.com/cerbos/cerbos-sdk-python) - [PHP](https://github.com/cerbos/cerbos-sdk-php) - [Rust](https://github.com/cerbos/cerbos-sdk-rust) You can also integrate with any other language via making an [HTTP or gRPC](https://docs.cerbos.dev/cerbos/latest/api/index.html) call to the Cerbos instance. You can find out more in our [Quickstart Guide](https://docs.cerbos.dev/cerbos/latest/quickstart.html). ## How do I deploy Cerbos? Cerbos is designed to be run in your infrastructure to ensure the fastest possible response to authorization checks. You can deploy Cerbos via: - Deploying a pre-built [binary](https://docs.cerbos.dev/cerbos/latest/installation/binary.html) - Running the [container](https://docs.cerbos.dev/cerbos/latest/installation/container.html) - Deploying a [Helm Chart](https://docs.cerbos.dev/cerbos/latest/installation/helm.html) ## Does Cerbos support Role-based Access Control (RBAC)? Access control based on user roles (i.e., a collection of access authorizations a user receives based on an explicit or implicit assumption of a given role). Role permissions may be inherited through a role hierarchy and typically reflect the permissions needed to perform defined functions within an organization. A given role may apply to a single individual or several individuals. Yes, Cerbos supports three kinds of policies: derived roles, resource policies, and principal policies. The first type, derived roles, is a way of augmenting those broad roles with contextual data to provide more fine-grained control at runtime. ## What is Attribute-based Access Control (ABAC)? Attribute-based Access Control (ABAC), also known as policy-based access control for IAM, defines an access control paradigm whereby access rights are granted to users through the use of policies that combine attributes. The policies can use any type of attribute (user attributes, resource attributes, object, environment attributes, etc.). This model supports Boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. For example: IF the requester is a manager, THEN allow read/write access to sensitive data. Unlike role-based access control (RBAC), which employs pre-defined roles that carry a specific set of privileges associated with them and to which subjects are assigned, the key difference with ABAC is the concept of policies that express a complex Boolean rule set that can evaluate many different attributes. ## How does Cerbos connect with my Authentication/Identity Provider (Auth0, Active Directory, Social, etc) Cerbos is designed in such a way that you can bring your own identity as the source of the principal information, for example, Okta, Auth0, WorkOS amongst others. We have several example integrations available on our [Ecosystem](/ecosystem) page. ## Does Cerbos support multi-tenant systems? Yes, this can be achieved by having [policy conditions](https://docs.cerbos.dev/cerbos/latest/policies/conditions.html) which check the resource being accessed belongs to a tenant that the principal has access to. Furthermore, [Scoped Policies](https://docs.cerbos.dev/cerbos/latest/policies/scoped_policies.html) allow for per-tenant variation of policies to meet the most demanding requirements. ## Is Cerbos stable and production-ready?? Cerbos is very stable at this point. We don't envision any major breaking changes in the near future, but we would love to get your feedback. ## Can I deploy Cerbos to AWS Lambda or Google Cloud Run? You can deploy the Cerbos to any environment which supports running containers such as Lambda, Cloud Run, Fargate, GKE, AKS, and similar systems. We have released a [AWS Lambda Docker Image](https://github.com/cerbos/cerbos-aws-lambda) which handles calling Cerbos from a function. ## How is Cerbos different from library-based authorization systems? Cerbos' service-based approach has many advantages: * Cerbos doesn't require you to learn a completely new policy programming language - policies are defined in simple-to-read YAML which can be managed outside of development teams. * Cerbos is external to your application. Having policies defined centrally, authorization logic is available to any service that calls for it, and any changes are immediately propagated without having to recompile and redeploy each component of your applications. * Cerbos is simple to deploy. To get it up and running all you need to do is run the container and point it to the location of your policies. ## How does Cerbos support tags? Cerbos does not make any assumptions about the state of your resources. You can pass in whatever useful information you think is pertinent in the attributes and write a policy rule that makes use of that information. ## What SDKs does it have out of the box? Official SDKs include the following: - [Go](https://pkg.go.dev/github.com/cerbos/cerbos/client) - [Java](https://github.com/cerbos/cerbos-sdk-java) - [NodeJS](https://github.com/cerbos/cerbos-sdk-node) - [.NET](https://github.com/cerbos/cerbos-sdk-net) - [Ruby](https://github.com/cerbos/cerbos-sdk-ruby) - [Python](https://github.com/cerbos/cerbos-sdk-python) - [PHP](https://github.com/cerbos/cerbos-sdk-php) - [Rust](https://github.com/cerbos/cerbos-sdk-rust) ## How can Cerbos support a React or similar web app’s UI Cerbos provides an abstraction layer between the app and the authorization system and simplifies the connection between them by leveraging its API. We recommend returning the permissions along with the data being used to power your UI so that it is always in sync with the policies. ## How can Cerbos support a mobile app? Cerbos is decoupled from the frontend of the application and its authorization checks can be used to power any number of channels. --- title: "Contact Cerbos" description: "Contact Cerbos: sales and demos, technical support, the community Slack, security disclosures, press, and our registered company details." date: "2026-08-21T00:00:00.000Z" canonical: "https://www.cerbos.dev/contact" source: "https://www.cerbos.dev/contact" --- # Contact Cerbos How to reach the team, and which route is the fastest for what you need. Cerbos builds the authorization management platform used by engineering, security and platform teams to authorize every identity and govern every decision. Whichever route you take below, a person answers — there is no ticket queue between you and the team that builds the product. #### Talk to an engineer [Book a session](/workshop) with a Cerbos engineer. These are working sessions rather than sales calls: bring your authorization model, your current implementation, or a requirement you are not sure how to express as policy, and you will leave with an answer and usually a working policy. Enterprise evaluations, proof-of-concept scoping and migration planning all start here. #### Technical support and questions - **Community Slack** — [community.cerbos.dev](https://community.cerbos.dev). The fastest route for implementation questions. Cerbos engineers and other users are in there daily. - **Email** — [help@cerbos.dev](mailto:help@cerbos.dev) for support, account questions and anything you would rather not ask in public. - **GitHub** — [github.com/cerbos](https://github.com/cerbos) for bug reports, feature requests and pull requests against the open-source Policy Decision Point, the SDKs and the integrations. - **Documentation** — [docs.cerbos.dev](https://docs.cerbos.dev) covers installation, policy authoring, the API and every SDK. #### Try Cerbos without talking to anyone You do not need to contact us to start. [Cerbos Hub](https://hub.cerbos.cloud/) has a free tier and self-serve sign-up, the [Cerbos PDP](/product-cerbos-pdp) is Apache-2.0 licensed and runs locally with a single container, the [playground](/features-benefits-and-use-cases/cerbos-playground) needs no account at all, and API credentials for a policy store are generated by you in the Hub UI. Pricing is [published in full](/pricing) rather than quoted on request. #### Security disclosures Report a suspected vulnerability in Cerbos or in this website to [help@cerbos.dev](mailto:help@cerbos.dev). Please include enough detail to reproduce the issue, and give us a reasonable window to respond before disclosing publicly. Our SOC 2 Type II and ISO 27001 evidence, subprocessor list and data processing terms are collected on the [legal page](/legal). #### Partnerships, press and careers - **Partnerships** — the [partner programme](/partner-programme) covers technology and solution partners, including the terms and how to apply. - **Press and analysts** — [info@cerbos.dev](mailto:info@cerbos.dev). - **Careers** — open roles are listed on [join us](/join-us); applications go to [join.us@cerbos.dev](mailto:join.us@cerbos.dev). - **Legal notices** — [legal@cerbos.dev](mailto:legal@cerbos.dev). #### Company details Cerbos is a trading name of **Zenauth Ltd**, registered in England and Wales, company number 13249733. Registered office: 86-90 Paul Street, 3rd Floor, London EC2A 4NE, United Kingdom. For anything else, [help@cerbos.dev](mailto:help@cerbos.dev) reaches the whole team. --- title: "Cerbos PDP" description: "The open-source Cerbos policy decision point: stateless, sub-millisecond authorization deployed alongside your services." canonical: "https://www.cerbos.dev/product-cerbos-pdp" source: "https://www.cerbos.dev/product-cerbos-pdp" --- # Cerbos PDP ## Implement fast, flexible and scalable access control with ease The Cerbos Policy Decision Point (PDP) provides a simple, yet powerful solution for authorization that can be up and running in minutes. Cerbos PDP helps you separate your authorization process from your core application code, making your authorization system infinitely scalable, more secure and easier to change as your application evolves. - Fast and secure - Plug and play - Developer-friendly [Documentation](https://docs.cerbos.dev/cerbos/latest/index.html) ## Fast and secure - **Flexible deployment models** — Self-hosted, compatible with air-gapped, high security environments. Deploy with serverless functions or a sidecar model. [Deployment](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models) - **Near-instantaneous response times** — Stateless design enabling sub-millisecond policy evaluation without having to synchronize application state or rely on slow network fan-out. [Stateless](https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization) - **Full auditing and accountability** — Compliance with ISO27001, SOC2, and HIPAA with real-time change logs. Keep track of every request and action. [Audit logs](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) - **Row-level authorization** — Decouple data filtering requests from the code via a query plan API, managed by the same policies as application access. [Row-level authZ](https://www.cerbos.dev/features-benefits-and-use-cases/permission-aware-data-filtering) · [Data-filtering for RAG](https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag) ## Plug and play - **Bring your own identity** — Cerbos supports integration with any authentication provider. [Ecosystem](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) - **Designed for full stack architectures** — Cerbos PDP uses an API-first approach. Seamlessly integrate with frameworks. [Integrations](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) - **SDKs for multiple languages** — Including Javascript, Python, Go, Ruby, PHP, and more. [Ecosystem](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) - **RBAC, ABAC and more** — Cerbos offers context-aware role definitions and attribute-based access control. [RBAC](https://www.cerbos.dev/features-benefits-and-use-cases/rbac) · [ABAC](https://www.cerbos.dev/features-benefits-and-use-cases/abac) · [PBAC](https://www.cerbos.dev/features-benefits-and-use-cases/pbac) ## Developer friendly - **Define policies in YAML** — Human readable configurations for better cross-functional collaboration and communication [YAML](https://www.cerbos.dev/features-benefits-and-use-cases/human-readable-authorization) - **Testable with GitOps** — Manage, test and deploy fine-grained access control policies using a CI/CD/GitOps workflow. [GitOps & CI/CD](https://www.cerbos.dev/features-benefits-and-use-cases/testable-authorization) - **Management API** — Add or update policies using the Cerbos Admin API to simplify administration functions. [Admin API](https://www.cerbos.dev/features-benefits-and-use-cases/admin-api) - **No vendor lock-in** — As a stateless, self-hosted solution, Cerbos can run on public / private clouds, serverless platforms, or your data center [No lock-in](https://www.cerbos.dev/features-benefits-and-use-cases/no-cloud-vendor-lock-in) ## Use cases - **Application permissions** — Fine grained context aware permissions. [Go beyond roles](https://www.cerbos.dev/features-benefits-and-use-cases/application-permissions) - **Product packaging** — Provide trials, feature bundles and custom packages for customers. [Manage entitlements](https://www.cerbos.dev/features-benefits-and-use-cases/product-packaging) - **Enterprise ready** — Manage complex organizational requirements. [Org permissions](https://www.cerbos.dev/features-benefits-and-use-cases/support-enterprise-organizations) - **Multi-tenant SaaS** — Support multiple customer environments at scale. [Tailored access](https://www.cerbos.dev/features-benefits-and-use-cases/multi-tenant-saas) - **Deploy and synchronize PDP at scale** — Save time managing and synchronizing every PDP across all your apps and services, decreasing deployment overhead. - **Authorize anywhere** — Unlock authorization everywhere - within browsers, serverless architectures, embedded devices, and at the edge with one solution. - **Collaborate across teams** — Collaborate, validate, and test policies real-time in an IDE environment that’s accessible to non-technical stakeholders and quickly adapt to changing app requirements. --- title: "How the Cerbos authorization management platform works" description: "How the Cerbos authorization management platform works: the four components, the reference architecture, and the path to adopting it one service at a time." canonical: "https://www.cerbos.dev/how-it-works" source: "https://www.cerbos.dev/how-it-works" --- # How the Cerbos authorization management platform works Authorize every identity, govern every action and prove every decision from one platform. Fine-grained, contextual, and continuous authorization with full audit trails across applications, gateways, workloads, and AI agents. [Talk to an expert](https://www.cerbos.dev/workshop) ## Cerbos is an end-to-end authorization management platform Four components work together to give your team a single layer that governs every action and access decision. - **Cerbos Hub — Policy Administration Point** — Authorization management. Cerbos Hub is the control plane for policy authoring, testing, versioning, distribution, and audit visibility. Hub provides end-to-end policy management out of the box. - **Cerbos Synapse — Enrichment and Orchestration** — Data and integration. Synapse fetches identity, resource, and relationship data from external systems to enrich authorization requests, and translates infrastructure protocols into Cerbos policy checks. - **Cerbos PDP — Policy Decision Point** — < 1 ms decision time. PDP is an open source authorization engine that evaluates requests against policies and returns access decisions. It's stateless, high-performance, and built to scale horizontally. - **Cerbos PEP SDK — Policy Enforcement Point** — Native SDKs. Cerbos PEPs are language-native client libraries that connect applications directly to PDPs to enforce real-time access decisions, with SDKs available for all major languages. [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub) · [Cerbos Synapse](https://www.cerbos.dev/product-cerbos-synapse) · [Cerbos PDP](https://www.cerbos.dev/product-cerbos-pdp) · [Cerbos PEP SDK](https://www.cerbos.dev/ecosystem) ## Cerbos reference architecture The complete picture of Cerbos in production. A defense in depth architecture with consistent enforcement from the edge to the data layer. > This is where teams grow into, not where they begin. Pick one component, like your API gateway or a single service, and go from there. [Speak to an engineer](https://www.cerbos.dev/workshop) · [See how it works](https://www.youtube.com/watch?v=f8S111ms-Ck) ## Start with one service You don't need to roll out Cerbos everywhere on day one. The platform is built for incremental adoption alongside your existing authorization. 1. **Instrument** — Add Cerbos to one service. Set your first policies to allow everything so nothing changes for your users. Your existing authorization keeps running. 2. **Validate** — Cerbos logs every decision it would make. Compare those against what your current system decides, in real time, and tune your policies with real traffic. 3. **Enforce** — When you're confident, turn enforcement on. Expand to the next service from there. [Book a go-live session](https://www.cerbos.dev/workshop) · [Read documentation](https://docs.cerbos.dev/) --- title: "Cerbos Synapse" description: "The Cerbos enrichment and orchestration layer: assembles identity, resource and relationship context from external systems, and connects enforcement points through the protocols they already speak." canonical: "https://www.cerbos.dev/product-cerbos-synapse" source: "https://www.cerbos.dev/product-cerbos-synapse" --- # Cerbos Synapse Assemble identity, resource, and relationship context from your IdPs, databases, and APIs, and connect enforcement points through the protocols they already use for consistent authorization decisions *Unified authorization context* ## Real-time context from your data fabric - **Centralized authorization context** — Fetch identity, resource, relationship data at decision time for true zero-trust authorization, without custom middleware or PEP code. - **Consistent enforcement across your stack** — Apply the same authorization policies across application APIs, gateways, data platforms, infrastructure, and AI agents. - **Native protocol translation** — Connect gateways, message queues, data platforms and infrastructure systems to Cerbos using their native authorization hooks. - **Govern authorization data centrally** — Control how authorization attributes are fetched, cached, and injected into decisions from one platform layer. - **Support complex access models** — Combine attributes, relationships, and external data sources without complicating policies or slowing down the policy engine. - **Millisecond enrichment at scale** — Built-in caching with per-source TTLs keeps hot-path enrichment fast and protects upstream systems from per-request query load. ## AI agents carry minimal identity context. Cerbos fills the gap. - **Identify the human behind every agent request** — Synapse can fetch the delegating user's profile from your IdP and pass both identities to the policy engine in one call. - **Evaluate agent and human together** — One policy call evaluates what the agent is allowed to do and whether the user behind it is authorized to trigger that action. - **No standing privilege for non-human identities** — Access is never assumed from a previous decision. Every agent request is checked against the current policy at request time. - **Let agents discover what's allowed** — Query planning returns the full set of resources an agent can access on behalf of a user, with the same enrichment applied. - **Full audit trail for every agent decision** — Capture the enriched authorization request and decision outcome for full traceability across agent and human access decisions. *Developer-ready integrations* ## Works with your existing tools, workflows, and infrastructure - **Identity provider enrichment** — Fetch user profiles, groups, and attributes from Okta, Entra ID, Cognito, LDAP, and other identity providers. - **Infrastructure integrations** — Authorize access from API Gateways, messaging queues, data platforms, deployment pipelines, and other systems using the authorization protocols they support. - **Data sources and databases** — Retrieve identity and resource attributes from SQL databases, graph stores, and internal APIs. - **Custom extensions** — Build custom data sources, protocol adapters, and request transformations in any language that compiles to WebAssembly. ## What teams build with Synapse - [AI agent guardrails](https://www.cerbos.dev/features-benefits-and-use-cases/agentic-authorization) - [MCP server security](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers) - [RAG authorization](https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag) - [AI gateway governance](https://www.cerbos.dev/features-benefits-and-use-cases/ai-gateway-authorization) - [Application permissions](https://www.cerbos.dev/features-benefits-and-use-cases/application-permissions) - [Multi-tenant SaaS access control](https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies) - [Programmatic permission management](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-policies) - [Legacy application authorization](https://www.cerbos.dev/features-benefits-and-use-cases/legacy-app-authorization) ## What customers say > When I did an audit, I found that the cost of managing authorization and authentication in-house over the entire lifespan of the company was in the 7 figures. Cerbos saved that. Deploying Cerbos has allowed our engineers to spend their time on what really matters for our success. > > — Chuck Hardy, Head of Engineering @Salesroom > Having to modify authorization is a five-minute job now. Having to troubleshoot authorization is a five-minute job. So that has actually allowed the team to spend more time where it really matters on the platform. > > — Karen Kim, CEO @Human Managed > We rely on Cerbos to make authorization decisions across the whole mesh - millions of times a day. And it’s fast. We don’t even think about it anymore. It just works. > > — Rob Crowe, Principal Engineer @Utility Warehouse > We went from one user - every role, to a world where there are many users - many roles. And the product, it relies on Cerbos to actually bring the value that we want to bring to customers. All of our customers are relying on Cerbos, by relying on the product, which is of course relying on Cerbos. > > — Joe Lines, CEO & Co-Founder @Nook > One of our big considerations was speed. We have strict latency tolerances. When it comes to Cerbos - you can call it a hundred times during a request and it doesn't matter. It's incredibly fast. > > — Steve High, Staff Engineer @Complex > The main reason we switched to Cerbos was to have a sophisticated authorization software to help organize and handle our authorization. We wanted to focus on domain related features and spend less time backtracking and fixing issues with our authorization. > > — Lead Software Developer at @BarrierSystems > Cerbos enables us to go to market very quickly, compared to an in-house solution. It allows us to offer new products faster, because creating or editing policies is so easy. > > — Engin Attar, Head of Product and Growth, Co-Founder @Debite > We got the foundation set. Now we can scale and include more complex policies. And we can grow in the right direction and with the right security thanks to Cerbos authorization management. > > — Edgar Rivera, CTO @4gcapital > Having the separation of the permissions from the code base just makes the code base more elegant. It makes the permissioning more elegant. It means they're centralized, so they're not tied to specific endpoints. And ultimately it means that different business owners have the ability to actually make updates. > > — Henry Arnold, CTO & Co-Founder @Nook > We're not worried about scaling because we can easily increase our load on Cerbos. It will also be easy for us to change how we're distributing policies as we reach different points of scale. > > — David Workman, Senior Software Engineer @ Salesroom > Offering dynamic roles and permissions makes us more competitive in the market. We’re providing companies with a software that can be adapted to their workflows. > > — Ibrahim Bou Ncoula, CTO @Supy > We can create unlimited conditions, attributes, and parameters at any level of granularity without writing any code. It allows us to deliver truly personalized services quickly, securely, and at scale. > > — Karen Kim, CEO @Human Managed [Talk to an engineer](https://www.cerbos.dev/workshop) · [Try Cerbos](https://hub.cerbos.cloud/) --- title: "Cerbos Hub" description: "The managed control plane for Cerbos: author, test, distribute and audit authorization policy across every deployment." canonical: "https://www.cerbos.dev/product-cerbos-hub" source: "https://www.cerbos.dev/product-cerbos-hub" --- # Cerbos Hub ## Author, test, and iterate **Web IDE for building policies** Create policies in YAML with our policy wizard, and use the playground to define, validate, and test authorization rules. **Real-time group collaboration** Pair programmers or different team members to edit and review policies like a Google doc. Push authorization policy files changes directly from the Playground IDE to your Github repo. **Test-driven development (TDD)** All tests are executed in the Cerbos Hub CI pipeline before policy is rolled out to PDPs. ## Distribution, orchestration and monitoring **Policy testing** A managed CI/CD pipeline builds and tests every new commit to the policy repository following Git-ops principles. **Policy orchestration** Cerbos Hub keeps policies up-to-date by coordinating each new rollout to all PDPs across your infrastructure. **Decision point monitoring** Observability into all deployed PDPs, with instance logs, deployed policy version details and metrics in a single screen. ## Authorize anywhere **In your infrastructure** Whether on-premise, cloud, functions, or Kubernetes, Cerbos Hub simplifies testing and distribution keeping policy in sync. **Serverless architectures** Works in Vercel, Netlify, AWS Lambda & CloudFront, Google Cloud Functions, and Azure Functions. **At edge & embedded devices** Pre-compiled libraries provide local execution for edge devices such as security hardware and cameras. **In browser runtime** Make local, in-browser authorization calls for React, Angular, and front-end frameworks, powered by WebAssembly. ## Unified audit trail **Capture every decision** Every decision made by a Cerbos PDP is captured - know exactly which principal, did which action on which resource, and whether it was allowed or not. **Decision lineage** Audit logs provide not just the decision, but also how it was reached. Every record provides the specific policy, version, and releases which was responsible for the decision being made. **Collated across environments** Cerbos Hub collects and aggregates decision logs from every connected PDP, in every environment they are deployed. ## Per-tenant custom policies Allow teams or end users to create tenant-specific custom roles programmatically, with testing, auditability, and governance built in. [Read more](https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies) ## Dynamic policies Programmatically create and update policies from any business event - no custom pipelines or fragile sync logic. [Read more](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-policies) ## Authorization for non-human identities Manage permissions for workloads, microservices, AI agents, and API clients with flexible, policy-driven authorization. [Read more](https://www.cerbos.dev/features-benefits-and-use-cases/authorization-non-human-identities) ## MCP server security Dynamically control which AI agents can access specific MCP server tools with policy-based decisions, reducing security risks and simplifying audits. [Read more](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers) ## AI systems and RAG data protection Maintain data security and compliance with fine-grained authorization for your RAG and LLMs. [Read more](https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag) ## Loved by engineers. Approved by leadership. - **Externalized authorization** — Define authorization in policy, not code. Reuse across tenants, AI workflows, and environments. - **One unified policy layer** — Centralize and manage access across apps, APIs, AI systems, and workloads from a single control point. - **75% fewer authZ bugs and incidents** — Validate and test access policies automatically before every deployment. - **Deploy new tenant policies in seconds** — Roll out tenant-specific access rules without code changes. > Cerbos is plug and play. Developers can get Cerbos up and running in minutes. All the configuration there is fits in one nice little file. I can onboard a new developer onto Cerbos in an hour. > > — Steve High, Staff Engineer ## Loved by engineers. Approved by leadership. - **100x faster launch** — Deploy new roles and personas instantly. - **90% faster changes** — Adjust permissions on the fly to meet new access needs. - **$500k saved yearly** — Eliminate the need for custom-built authorization infrastructure. - **100% audit ready** — Centralized logs SOC2, HIPAA, ISO 27001, PCI DSS, and GDPR. > One of our favorite features is the audit logs because it allows us to understand what is happening in the black box. We’ve never had that before. > > — Rob Crowe, Principal Engineer --- title: "Cerbos pricing" description: "Cerbos pricing by monthly active principals, across the open-source PDP and Cerbos Hub packages." canonical: "https://www.cerbos.dev/pricing" source: "https://www.cerbos.dev/pricing" --- # Cerbos pricing ## Open source Distributed policy decision points. Policy enforcement points via SDK and ORM integrations. **Free forever** — Run anywhere: on-premise or cloud Access to: - YAML-based policy definition - Audit logs - CI/CD & IDE tooling - Git, Disk, Cloud or DB-based storage - Community support ## Proof of Concept Ideal for when you want to try out Cerbos in your local environment **$0/month** — Up to 100 monthly active principals* Open source features, plus - 1 workspace, 2 developers - 2 Playgrounds - 2 simultaneous PDPs - Up to 5 custom tenants - 5 policy builds per week - 1 week of unified audit logs - Enrichment & integrations via Cerbos Synapse - In-browser/serverless authorization - Managed CI/CD pipeline - Community support ## Development When you are ready to build with Cerbos Hub **From $25/month** — First 100 monthly active principals* included PoC features and more - 3 workspaces, 5 developers - Up to 5 Playgrounds - Up to 10 simultaneous PDPs - Up to 20 custom tenants - 100 policy builds per week - 3 months of unified audit logs - Uptime SLA - Live Chat support ## Production Production-grade authorization management with no limits **From $933/month** — First 5000 monthly active principals* included DEVELOPMENT features and more - Unlimited workspaces & developers - Unlimited Playgrounds - Unlimited simultaneous PDPs - Unlimited custom tenants - Unlimited policy builds per week† - 1 year of unified audit logs - Uptime SLA - Live Chat support ## Enterprise Support, training, and SLA for production-grade authorization at scale. Custom plans to suit your needs **Let's chat** — Custom plans/pricing to suit your needs Access to - SSO support - Self-hosted Cerbos Hub - Custom audit log retention - Custom training support - Enterprise support SLA - Phone support - Quarterly training ## * What is a principal? "Principal" is a term for a user or service. For most applications, the terms "user" and "principal" are interchangeable because the application is only used by humans. However, Cerbos can also authorize other applications, services, bots or any other non-human identities which access your system. For example, If your application has 3000 monthly active users and 15 monthly non-human identities, you’ll have 3015 monthly active principals. ⠀ † Fair usage policy applies. ## Got questions? We've got answers. - **How does the pricing work?** — Cerbos pricing is based on the number of Monthly Active Principals requiring authorization decisions. - **On which marketplaces can I find Cerbos?** — Cerbos is currently available on [AWS Marketplace.](https://aws.amazon.com/marketplace/seller-profile?id=d6473d62-2e0d-4e9b-98fa-d99d9a344758) - **Does Cerbos Hub run in the cloud?** — Cerbos Hub runs in the cloud and manages the PDPs that are running in your environment. Cerbos PDPs still run in your environment to guarantee security, fastest response time and highest SLA. - **What are Monthly Active Principals (MAPs)?** — It is the number of unique principals that are authorized during one calendar month. - **Can I go back to using the open source Cerbos PDP solution, if I have been using Cerbos Hub?** — Yes. In order to make the switch, first you will have to start hosting your own policy files ([here are the options](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html)) and then change your PDPs' configuration to point at them. - **Will I receive dedicated support if I am using Cerbos Hub?** — Contact us if you require an SLA and a dedicated Cerbos team member will reach out. Otherwise, join our [Slack community](https://community.cerbos.dev/) to receive community-based support. - **Can I cancel my Cerbos Hub subscription at any point?** — Yes, you can cancel at any time. - **Where can I find the full terms of service?** — Check out our full [Terms of Service](https://www.cerbos.dev/tos) and [Privacy Policy](https://www.cerbos.dev/privacy-policy). - **How do I find out more about creating a custom plan?** — [Schedule a call with us.](https://rb.gy/wgoe8v) --- title: "Cerbos for architects" description: "How Cerbos fits an existing architecture: decoupled authorization that integrates with the identity, data and deployment stack you already run." canonical: "https://www.cerbos.dev/for-architects" source: "https://www.cerbos.dev/for-architects" --- # Cerbos for architects ## Externalized authorization for your enterprise applications - **Policy based access control** — Ensure dynamic and flexible access control with policy-driven decisions. Adapt to changing access needs with ease, define access based on multiple conditions and contexts, and manage policies within your existing governance processes. [PBAC](https://www.cerbos.dev/features-benefits-and-use-cases/pbac) - **Decision level audit logs** — Achieve transparency, accountability, and compliance with Cerbos' comprehensive audit logging. Feed application decision logs into your existing SIEM tooling for end-to-end visibility. Audit logs in Cerbos Hub capture authorization decisions across all PDP instances in a central, collated feed. [Audit logs](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) - **Distributed decisioning, centrally managed** — Use Cerbos Hub's unified platform to enable collaborative authoring, iteration, and management of authorization policies by developers and product teams. Maintain consistent, transparent, and adaptable authorization logic across all applications. [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub) ## Why Cerbos? - **Flexible deployment models** — Self-hosted, compatible with air-gapped, high security environments. Deploy with serverless functions or a sidecar model. [Deployment](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models) - **Open source** — Cerbos PDP source code is freely available under Apache 2.0 license. [GitHub](https://github.com/cerbos) - **Built for scale** — Cerbos is containerized, stateless, and scales horizontally to handle increasing demands. [Scalability](https://www.cerbos.dev/features-benefits-and-use-cases/scalability) - **Centralized management** — Use Cerbos Hub for policy management, collaboration, and streamlined deployment. [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub) - **Supported authentication providers** — Use any identity provider to authenticate your users. Use Cerbos to enforce access controls. Cerbos natively supports JWT for integration with numerous authentication providers, such as: JWT, Auth0, Okta, and others. [Authentication support](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) - **Fine-grained access control** — Achieve precise control over resource access via RBAC and ABAC policy. [RBAC](https://www.cerbos.dev/features-benefits-and-use-cases/rbac) · [ABAC](https://www.cerbos.dev/features-benefits-and-use-cases/abac) - **No lock-in** — Maintain full ownership of where policies are stored, and deploy onto any platform. [No lock-in](https://www.cerbos.dev/features-benefits-and-use-cases/no-cloud-vendor-lock-in) - **Thriving community** — Join an active community of Cerbos users and connect directly with our engineers. [Slack community](https://community.cerbos.dev) ## The Impact of Cerbos > "We can run Cerbos next to our application, and can have as many instances running as we need to. So we can have one dedicated host we're running it on. And so there's much less risk of it going down and taking everything down without us knowing about it all, without being completely out of our control, like the host solution might be." > > — David, Senior Software Engineer > "One of our favorite features is the audit logs because it allows us to understand what is happening in the black box. We’ve never had that before and we didn’t know we needed it." > > — Rob, Principal Engineer > "Throwing the entire concern of authorization across to Cerbos really did increase my velocity, which in turn increases velocity downstream from me. It has allowed the team to deliver top-tier user experience and concentrate on faster app iterations." > > — Steve, Staff Engineer > "I categorized Cerbos as just one of those things I probably don't have to think about. And that's a very valuable thing to me cause there's a lot of things that take up even a small percentage of our mind space. And if we can just leave it be in the corner and know that we'll be protected. And if something goes wrong, they will do everything in their power to resolve. It gives you that extra bit of confidence." > > — Chuck, Head of Engineering > "Having the separation of the permissions from the code base just makes the code base more elegant. It makes the permissioning more elegant. It means they're centralized, so they're not tied to specific endpoints. And ultimately it means that different business owners, i.e. Joe, in our case, because he's the only one who's not a developer, have the ability to actually make updates." > > — Henry, CTO & Co-Founder --- title: "Cerbos agent skills" description: "Install the Cerbos agent skills in Claude Code, Codex, Cursor or any coding agent, and have it write, test and ship Cerbos authorization policies." canonical: "https://www.cerbos.dev/agent-skills" source: "https://www.cerbos.dev/agent-skills" --- # Cerbos agent skills Cerbos keeps access rules in policies instead of your application code, and your app asks it for each decision. Our skills teach your coding agent to write, test and enforce those policies, and ship them through Cerbos Hub. Paste this into your coding agent. ```text Set up Cerbos using cerbos.dev/agents.md ``` Works in Claude Code, Codex, Cursor, Copilot, Gemini CLI, Grok and most other agents. The agent asks before it installs anything. ## Install it in your agent Each agent installs the same plugin from the cerbos/skills repository, and updates from it with one command. ### Claude Code ```bash claude plugin marketplace add cerbos/skills claude plugin install cerbos-skills@cerbos-skills ``` Update with claude plugin marketplace update cerbos-skills. ### Codex ```bash codex plugin marketplace add cerbos/skills codex plugin add cerbos-skills@cerbos-skills ``` Update with codex plugin marketplace upgrade cerbos-skills. ### Cursor ```bash git clone --depth 1 https://github.com/cerbos/skills ~/.cursor/plugins/local/cerbos-skills ``` Then reload the window, and update with git pull in that folder. On a Teams or Enterprise plan, an admin can add https://github.com/cerbos/skills as a team marketplace instead. ### GitHub Copilot CLI ```bash copilot plugin marketplace add cerbos/skills copilot plugin install cerbos-skills@cerbos-skills ``` Update with copilot plugin update cerbos-skills. ### Gemini CLI ```bash gemini extensions install https://github.com/cerbos/skills ``` Update with gemini extensions update cerbos-skills. ### Grok ```bash grok plugin install cerbos/skills --trust ``` ### Claude Cowork Open Settings, then Plugins. Add the marketplace cerbos/skills, sync it, then browse to cerbos-skills and install it. Cowork keeps it up to date. ### Other agents ```bash npx skills add cerbos/skills ``` Copies the skills into the skills folder of OpenCode or any other agent. Update with npx skills update. ## What the plugin runs The plugin contains skills only. It has no hooks, no MCP servers and no background processes, and it sends no data anywhere itself. Your agent asks before running commands the skills don't pre-approve, and the README lists what each skill runs. Policy uploads and decision logs go to your own Cerbos Hub workspace, and only once you set them up. [See what each skill runs](https://github.com/cerbos/skills#what-the-plugin-runs) ## From prompt to policy Tell your agent who should be able to do what, in your own words. You usually don't need to name Cerbos. The starter skill, cerbos, recognizes an access-control problem, works out which parts of Cerbos it needs and hands off to the skill that builds them. 1. **Describe the rule.** Tell your agent who can do what, in plain words. The session above started from this one sentence. 2. **Get policies with tests.** Your agent writes the Cerbos policy and its test suite, then compiles both until every test passes. 3. **Enforce it in your code.** It adds a Cerbos SDK check to your code. The SDK asks a policy decision point (PDP), a Cerbos service beside your app. 4. **Ship it through Cerbos Hub.** Create a free Hub account and approve the sign-in. Your agent connects your PDP, so rule changes ship without a release. [Sign up for Cerbos Hub](https://hub.cerbos.cloud/) ## What the agent produced A recorded Claude Code session with the Cerbos skills on a sample Express app, condensed to its main steps. Prompt: "Managers can approve expenses for their own team, up to $5,000. Add that." ### Policy `cerbos/policies/resource_policies/finance/expense.yaml` ```yaml apiVersion: api.cerbos.dev/v1 resourcePolicy: version: "default" resource: "expense" schemas: principalSchema: ref: "cerbos:///principal.json" resourceSchema: ref: "cerbos:///resources/expense.json" rules: # Managers sign off their own team's expenses; anything over $5,000 needs someone else. - name: manager-approves-own-team-up-to-5000 actions: ["approve"] roles: ["manager"] effect: EFFECT_ALLOW condition: match: all: of: - expr: R.attr.team == P.attr.team - expr: R.attr.amount <= 5000 ``` ### Tests `cerbos/policies/resource_policies/finance/expense_test.yaml` ```yaml name: ExpenseApprovalTest description: Managers approve their own team's expenses up to $5,000 principals: sales_manager: id: maria roles: ["manager"] attr: team: sales sales_employee: id: maria roles: ["employee"] attr: team: sales resources: sales_1200: kind: expense id: exp-1 attr: { team: sales, amount: 1200, submittedBy: sam, status: pending } engineering_1200: kind: expense id: exp-3 attr: { team: engineering, amount: 1200, submittedBy: sam, status: pending } sales_5000: kind: expense id: exp-5000 attr: { team: sales, amount: 5000, submittedBy: sam, status: pending } sales_5000_01: kind: expense id: exp-5001 attr: { team: sales, amount: 5000.01, submittedBy: sam, status: pending } tests: - name: Manager approves own team's expense within the limit input: principals: [sales_manager] resources: [sales_1200, sales_5000] actions: [approve] expected: - principal: sales_manager resource: sales_1200 actions: { approve: EFFECT_ALLOW } - principal: sales_manager resource: sales_5000 actions: { approve: EFFECT_ALLOW } - name: Manager cannot approve over $5,000 input: principals: [sales_manager] resources: [sales_5000_01] actions: [approve] expected: - principal: sales_manager resource: sales_5000_01 actions: { approve: EFFECT_DENY } - name: Manager cannot approve another team's expense input: principals: [sales_manager] resources: [engineering_1200] actions: [approve] expected: - principal: sales_manager resource: engineering_1200 actions: { approve: EFFECT_DENY } - name: Non-manager cannot approve input: principals: [sales_employee] resources: [sales_1200] actions: [approve] expected: - principal: sales_employee resource: sales_1200 actions: { approve: EFFECT_DENY } ``` ### Test run `cerbos compile` ``` $ cerbos compile cerbos/policies Test results └──ExpenseApprovalTest (resource_policies/finance/expense_test.yaml) [5 OK] 5 tests executed [5 OK] ``` ### Route `src/server.js` ```javascript import { HTTP } from "@cerbos/http"; const cerbos = new HTTP(process.env.CERBOS_URL ?? "http://localhost:3592"); // ... app.post("/expenses/:id/approve", async (req, res, next) => { const expense = expenses.get(req.params.id); if (!expense) return res.sendStatus(404); // Rules live in cerbos/policies/resource_policies/finance/expense.yaml. let allowed; try { allowed = await cerbos.isAllowed({ principal: { id: req.user.id, roles: req.user.roles ?? [], attr: { team: req.user.team } }, resource: { kind: "expense", id: expense.id, attr: expense }, action: "approve", }); } catch (err) { return next(err); } if (!allowed) return res.sendStatus(403); expense.status = "approved"; expense.approvedBy = req.user.id; res.json(expense); }); ``` ### End-to-end check `curl against a local Cerbos server` ``` Local Cerbos server on cerbos/policies, then POST /expenses/:id/approve Sales manager approves a $1,200 sales expense 200 Sales manager approves a $7,500 sales expense 403 Sales manager approves a $300 engineering expense 403 Engineering employee (not a manager) approves a $300 expense 403 Engineering manager approves a $300 engineering expense 200 ``` ## Try prompting your agent Copy a prompt into Claude Code, Codex, Cursor, Copilot, Gemini CLI, Grok or any agent with the skills installed. Each one names the skill it uses. - "Only managers should see salary fields in the employee API. Set that up. Follow the cerbos skill." - "Turn this access-control spec into Cerbos policies with tests. Follow the cerbos-policy skill." - "Filter the documents list so people only see records they're allowed to view. Follow the cerbos-pep-integration skill." - "Hide the delete button for users who can't delete this project. Follow the cerbos-embedded-pdp skill." - "Our MCP server exposes tools to an agent. Only let it call the ones the current user is allowed to. Follow the cerbos-pep-integration skill." - "Move the permission checks scattered through this codebase into Cerbos policies. Follow the cerbos-authz-migration skill." - "Set up Cerbos Hub for this repository and connect our PDP. Follow the cerbos-hub-setup skill." - "Why was this request denied? Here's the decision log entry. Follow the cerbos-audit-insights skill." ## What your agent learns Eight skills cover authorization from the first design question to the audit trail. Your agent reads a skill's full instructions only when your request calls for it. - **`cerbos`** — Starts here, and picks the parts of Cerbos your request needs. - **`cerbos-policy`** — Resource and role policies, conditions and test suites. - **`cerbos-pep-integration`** — SDK checks in eight languages, list filtering and agent tool calls. - **`cerbos-hub-setup`** — Policy stores, deployments, PDP connections and rollback. - **`cerbos-embedded-pdp`** — Checks in the browser, at the edge and in serverless, in WebAssembly. - **`cerbos-audit-insights`** — Decision logs, masking, and why a request was denied. - **`cerbos-synapse-extension`** — Adds data to requests and enforces policy at gateways. - **`cerbos-authz-migration`** — Moves checks out of code or off OPA, Casbin, OpenFGA and others. ## When the rule changes Raise the limit from $5,000 to $10,000. Hard-coded, the rule lives in every service that checks it, so each one changes and ships on its own. In Cerbos, it lives in one policy. ### Hard-coded in each service - `expenses-api` (JavaScript) needs Edit → Pull request → Review → Build → Deploy - `approvals-worker` (Go) needs Edit → Pull request → Review → Build → Deploy - `finance-reports` (Python) needs Edit → Pull request → Review → Build → Deploy ### In one Cerbos policy Edit the policy → Review the change → Cerbos Hub tests it and updates every PDP, once for every service. ### Same request, different answers A sales manager approves a $7,500 sales expense on Tuesday, mid-rollout. - `expenses-api` (shipped Monday) hard-coded allows it, and with Cerbos allows it. - `approvals-worker` (ships Wednesday) hard-coded denies it, and with Cerbos allows it. - `finance-reports` (ships Friday) hard-coded denies it, and with Cerbos allows it. Until the last service ships, the answer depends on which service the request reaches. With Cerbos, every PDP has the new limit within seconds. Example services. The same holds for however many services check the rule. ## Give your agent a place to ship Cerbos Hub tests the policies your agent writes, rolls them out to every PDP and keeps an audit trail of decisions. Start on the free Proof of Concept plan. [The Cerbos platform handles more than 2 billion authorization checks a month.](https://www.cerbos.dev/about) [Create a free Cerbos Hub account](https://hub.cerbos.cloud/) · [Read the documentation](https://docs.cerbos.dev/cerbos/latest/index.html) ## Further reading - [An agent skill for writing authorization policies](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies) - [Using the policy skill in Claude Code](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-claude-code) - [Using the policy skill in Cursor](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-cursor) - [Building Cerbos Synapse extensions with an agent skill](https://www.cerbos.dev/blog/agent-skill-for-building-cerbos-synapse-extensions) --- title: "Cerbos for developers" description: "Replace scattered permission checks with policy: define access once, enforce it with a single SDK call, and hand policy management to product and security teams." canonical: "https://www.cerbos.dev/for-developers" source: "https://www.cerbos.dev/for-developers" --- # Cerbos for developers ## How in-house authorization becomes your bottleneck Whether you built it from scratch or it's buried in your application code, the result is the same: scattered logic, constant rewrites, and compliance work that never ends - all for a problem that's already been solved. - **You're reimplementing the same logic everywhere** — Authorization checks scattered across microservices, APIs, and frontend layers. Every new surface means duplicating logic, diverging behavior, and debugging inconsistencies across services. - **Every change means touching code** — New tenant? New role? New feature flag? Each one requires code changes, engineering review, and a full redeployment - for what should be a configuration update. - **You're responsible for auditing and compliance** — Hardcoded authorization means you also own the audit trail. Building logging, evidence collection, and compliance reporting from scratch - on top of the authorization logic itself. ## Cerbos externalizes and centralizes authorization End-to-end authorization across applications, infrastructure, and AI systems with a unified policy engine, data layer, and control plane. ## Cerbos Hub Cerbos Hub is the control plane for policy authoring, testing, versioning, distribution, and audit visibility. Hub provides end-to-end policy management out of the box. ## Cerbos Synapse Synapse fetches identity, resource, and relationship data from external systems to enrich authorization requests, and translates infrastructure protocols into Cerbos policy checks. ## Policy enforcement points Cerbos PEPs are language-native client libraries that connect applications directly to PDPs to enforce real-time access decisions, with SDKs available for all major languages. ## Implement authorization once, scale everywhere Define access in policy, enforce it with one SDK call, and let product and security teams manage changes through Cerbos - without touching your code. - **One API call replaces your entire authorization layer** — Replace scattered if/else permission blocks with a single Cerbos SDK call. Define access rules in declarative policy, reusable across every service, tenant, and environment. You implement authorization once - Cerbos handles the rest. - **Offload policy management to product and security teams** — Roles, permissions, and tenant-specific rules are managed through Cerbos - not your codebase. Product owners and security teams get direct control over access logic. You don't get pulled into every permissions change. - **No need to build auditing or compliance magic** — Every authorization decision is logged automatically with full context - who, what, when, why. Audit trails, compliance evidence, and decision visibility come built in. You don't build it; you don't maintain it. - **Never reimplement authorization across services** — One policy engine serves every app, API, microservice, and AI agent in your stack. Add new services without duplicating authorization logic. The same policies apply everywhere - consistently, automatically. - **Fits your infrastructure - deploy anywhere** — Deploy in cloud, self-hosted, on-premise, or air-gapped environments. Native SDKs for every major language. Git-native policy delivery through your existing CI/CD. Cerbos plugs into your stack - you don't rearchitect around it. ## Use cases - [AI agent guardrails](https://www.cerbos.dev/features-benefits-and-use-cases/agentic-authorization) - [MCP server security](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers) - [RAG authorization](https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag) - [AI gateway governance](https://www.cerbos.dev/features-benefits-and-use-cases/ai-gateway-authorization) - [Application permissions](https://www.cerbos.dev/features-benefits-and-use-cases/application-permissions) - [Multi-tenant SaaS access control](https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies) - [Programmatic permission management](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-policies) - [Legacy application authorization](https://www.cerbos.dev/features-benefits-and-use-cases/legacy-app-authorization) ## Works with your existing tools, workflows, and infrastructure See how Cerbos replaces scattered permissions logic with a single API call, and lets you hand off policy management for good. ## Further reading - [Mapping business requirements to authorization policy](https://www.cerbos.dev/blog/mapping-business-requirements-to-authorization-policy) - [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) - [Agent skill for writing authorization policies](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies) - [Authorization proof of concept guide](https://www.cerbos.dev/blog/authorization-poc-guide) - [Service to service authorization](https://www.cerbos.dev/blog/service-to-service-authorization) - [Who owns authorization in a large engineering organization?](https://www.cerbos.dev/blog/who-owns-authorization-in-large-engineering-organization) - [Filtering data using authorization logic](https://www.cerbos.dev/blog/filtering-data-using-authorization-logic) - [AI agents, the Model Context Protocol, and the future of authorization guardrails](https://www.cerbos.dev/news/securing-ai-agents-model-context-protocol) - [Multi-hop delegation for AI agents, explained](https://www.cerbos.dev/blog/multi-hop-delegation-ai-agents) - [Best AI agent security and governance tools](https://www.cerbos.dev/blog/best-ai-agent-security-and-governance-tools) --- title: "Standardized authorization with AuthZEN" description: "AuthZEN, the OpenID Foundation standard for a vendor-neutral API between policy enforcement points and policy decision points, and how Cerbos implements it." canonical: "https://www.cerbos.dev/authzen" source: "https://www.cerbos.dev/authzen" --- # Standardized authorization with AuthZEN AuthZEN defines a vendor neutral request/response API format between Policy Enforcement Points and Policy Decision Points. Cerbos is part of the working group making this standard a reality for enterprises. ## Why authorization needs a standard? AuthZEN is a new standard from an OpenID Foundation working group that aims to make authorization interoperable across apps, APIs, and services. It sets out how a policy enforcement point, such as an application or API gateway, communicates with a policy decision point, the external engine responsible for authorization decisions. Cerbos is the part of the working group, helping to test, improve and promote AuthZEN. - **Lack of interoperability** — Proprietary authorization solutions create vendor lock-in and make it difficult to integrate best-of-breed components. - **Inconsistent policy enforcement** — Authorization logic is often embedded within apps, leading to fragmented and inconsistent access rules across the enterprise. - **Difficult to audit** — Without centralized authorization, it is difficult to see access policies and decisions. - **Development overhead** — Development teams keep rebuilding authorization, wasting time and resources. ## The pillars of AuthZen standard - **Vendor interoperability** — Avoid vendor lock-in and use the best authorization components for your needs, thanks to a standardized API. - **Improved security posture** — Enhance security and simplify compliance with a unified and auditable authorization framework. - **Dynamic, fine-grained access** — Enable real-time, context-aware authorization decisions that go beyond static roles and permissions. ## How it works AuthZEN defines a standard interface between Policy Enforcement Points and Policy Decision Points, enabling interoperability across different vendors and platforms. ## Supported by major providers AuthZEN is being adopted by major PDP and gateway providers, ensuring a wide range of support and interoperability. - **PDP providers** - **Gateway providers** ## Powered by the community - **Alex Olivier** — CPO and Co-Founder at Cerbos - **Allan Foster** — Member Board Of Directors at IDPro - **Sean O’Dell** — Staff Security Engineer at Disney - **Gerry Gebel** — ex-VP Product and Standards at Strata Identity - **David Brossard** — CTO at Axiomatics - **Omri Gazitt** — Previously CEO at Aserto ## Further reading - [AuthZEN: standards-based authorization for enterprises](https://www.cerbos.dev/blog/authzen-standards-based-authorization-for-enterprises) - [OpenID AuthZEN is official, and Cerbos is ready](https://www.cerbos.dev/blog/openid-authzen-is-official-cerbos-is-ready) - [Cerbos named a Sample Vendor for AuthZEN in the Gartner Hype Cycle for Digital Identity](https://www.cerbos.dev/blog/cerbos-named-sample-vendor-authzen-gartner-hype-cycle-for-digital-identity) - [OpenID documentation](https://openid.github.io/authzen/) - [Building a scalable authorization system: a step-by-step blueprint](https://solutions.cerbos.dev/building-a-scalable-authorization-system) --- title: "Cerbos and Radiant Logic" description: "Zero Trust requires fine-grained policies built on a foundation of high-quality identity data." canonical: "https://www.cerbos.dev/partners/radiantlogic" source: "https://www.cerbos.dev/partners/radiantlogic" --- # Cerbos and Radiant Logic Zero Trust requires fine-grained policies built on a foundation of high-quality identity data. ## Radiant Logic as Policy Information Point Radiant Logic seamlessly aggregates, correlates, normalizes and presents a wide range of identity sources unavailable at any other single point in the network. Each View of the correlated data can be filtered and formatted exactly to the needs of each policy engine in a highly scalable, performant, and available structure. ## Cerbos as Policy Decision Point Cerbos is the authorization mechanism ensuring each user or actor in a system is granted access to ONLY the resources allowed to them. Write, test and manage fine-grained access control policies in a user-friendly interface, and keep policies synchronized across your stack. ## Combined Benefits Cerbos makes access decisions by evaluating policy rules against Radiant Logic’s aggregated set of identity data. ### Least-privilege by default - Radiant Logic ensures the completeness of your identity data, enabling fine-grained access decisions based on accurate and up-to-date data. - Cerbos simplifies the management of granular policies, enabling you to write more detailed access rules without adding code bloat. ### Continuous monitoring to support governance and compliance - Radiant Logic surfaces high-quality data on who has access to what, and provides actionable insights into how you can improve user roles and access levels. - Cerbos provides detailed audit logs showing who is allowed or denied access to what, constantly verifying the efficacy of your access policies. ## Next steps - [Get in touch with Radiant Logic](https://www.radiantlogic.com/contact-us/) - [Model your policies with Cerbos](https://www.cerbos.dev/features-benefits-and-use-cases/cerbos-playground) --- title: "Cerbos partner programme" description: "The Cerbos partner programme: partner types, benefits and how the programme works." canonical: "https://www.cerbos.dev/partner-programme" source: "https://www.cerbos.dev/partner-programme" --- # Cerbos partner programme ## Partner with Cerbos Bring fine grained authorization to the enterprise software and AI systems your customers are building, without years of in-house engineering. More than 2 billion authorization checks a month across SaaS & regulated industries. ## Why partner with Cerbos Authorization is hard to build and harder to maintain. Partnering with Cerbos lets you give customers a proven answer, and open a new line of revenue at the same time. - **More billable work** — Authorization projects, access governance and zero trust implementations become a practice you can deliver and bill against. - **A product you don't have to build.** — Add enterprise authorization to your stack instead of building a bespoke solution for every client. - **Stronger outcomes for your clients** — Give clients fine grained authorization and access governance they can actually maintain, and become the team that brought it to them. - **Upskill your team** — Your consultants build real expertise in authorization and Zero Trust, the skills clients are asking for, backed by our solution architects and onboarding. ## Choose your type of partnership Whether you build software, deliver it for your clients, or sell it alongside your own products, there's a way to work with us. - **Technology and resell partners** — Data, identity, cloud and dev platforms we work alongside, plus partners who bundle or resell Cerbos with their own products. Joint customers get authorization that fits the stack they already run. - **System integrators and consultancies** — Design and deliver authorization for your clients as part of larger identity and platform projects, backed by our architects. It becomes repeatable, billable work, and your clients get authorization they can maintain. ## How it works 1. **Apply** — Fill in the short form by clicking the button below. 2. **Talk it through** — Our partnerships team will schedule a call about the opportunity and the commercials. 3. **Get enabled** — Onboarding, technical training and architect support so your team is ready. 4. **Grow together** — Ongoing support and architect access as you bring Cerbos to your customers. ## Let's work together Tell us what you're building and we'll find the fit that helps your business grow. - [Success stories](/customers) - [How Cerbos works](/how-it-works) - [OpenID AuthZEN standards](/authzen) - [Documentation](https://docs.cerbos.dev) --- title: "Features, benefits and use cases" description: "Every Cerbos feature, benefit and use case in one index: what each page covers, and its markdown where one is served." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases" source: "https://www.cerbos.dev/features-benefits-and-use-cases" --- # Features, benefits and use cases What Cerbos does, grouped as the section itself groups it. Each entry links to the page and, where one is served, to its markdown. ## Benefits - **Decoupled authorization** — Separate your authorization logic from core application code for enhanced security and maintainability. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/decoupled-authorization) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/decoupled-authorization.md) - **Scalability** — Ensure your authorization processes scale seamlessly with your user base. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/scalability) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/scalability.md) - **Private by design** — Ensure complete control and peace of mind by keeping your data within your environment. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/private-by-design) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/private-by-design.md) - **Security standards** — Align with prevalent security standards like HIPAA, PCI DSS, and GDPR. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/security-standards) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/security-standards.md) - **Advanced observability** — Gain insights into your authorization processes and decisions. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/advanced-observability) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/advanced-observability.md) - **Authorize anywhere** — Empower your authorization with on-device and edge capabilities. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/authorize-anywhere) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/authorize-anywhere.md) - **Human readable authorization** — Implement and update authorization policies with low-code, human-readable configuration. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/human-readable-authorization) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/human-readable-authorization.md) - **Testable authorization** — Ensure the reliability of your authorization policies with built-in testing capabilities. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/testable-authorization) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/testable-authorization.md) - **No cloud or vendor lock-In** — Deploy on any platform, ensuring independence and adaptability. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/no-cloud-vendor-lock-in) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/no-cloud-vendor-lock-in.md) - **Simplified policy testing and distribution** — Validate, test, and roll out policy updates with a fully managed pipeline. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/simplified-policy-testing-and-distribution) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/simplified-policy-testing-and-distribution.md) - **Centralized management** — Unify your authorization strategy in one central hub. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/centralized-management) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/centralized-management.md) - **Coordinated rollout and monitoring** — Seamlessly coordinate, rollout, and monitor your policies with Cerbos Hub. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/coordinated-rollout-and-monitoring) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/coordinated-rollout-and-monitoring.md) - **Zero Trust security** — Adopt a security model that assumes breach and verifies every request. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/zero-trust-security) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/zero-trust-security.md) - **Embed anywhere** — Empower your authorization with on-device and edge capabilities. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/embed-anywhere) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/embed-anywhere.md) - **Standardized authorization** — Achieve interoperability, auditability and consistent policy enforcement in accordance with AuthZEN standards. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/authzen) - **On-premise & air-gapped** — Run Cerbos Hub inside your environment. Keep policies and audit data under your control. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/on-premise-air-gapped) ## Features - **RBAC (Role-based access control)** — Manage user permissions based on predefined roles within your organization. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/rbac) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/rbac.md) - **ABAC (Attribute-based access control)** — Define access controls based on user attributes and environmental conditions. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/abac) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/abac.md) - **Policy-Based Access Control (PBAC)** — Ensure dynamic and flexible access control with policy-driven decisions. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/pbac) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/pbac.md) - **Permissions-aware data filtering** — Efficiently filter data at the source, ensuring only authorized data is fetched. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/permission-aware-data-filtering) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/permission-aware-data-filtering.md) - **Stateless authorization** — Ensure real-time access decisions without managing application states, while benefiting from unlimited scaling. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization.md) - **Audit logs** — Maintain a comprehensive record of all authorization activities for accountability and compliance. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs.md) - **Cerbos Playground** — Experiment, test, and understand Cerbos policies in a sandboxed environment. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/cerbos-playground) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/cerbos-playground.md) - **REPL (Read-eval-print loop)** — Quickly test and evaluate policy and conditions. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/read-eval-print-loop-repl) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/read-eval-print-loop-repl.md) - **Flexible policy conditions powered by Google CEL** — Experiment with writing CEL conditions, enjoy a seamless policy development experience. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-policy-conditions-powered-by-google-cel) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-policy-conditions-powered-by-google-cel.md) - **Scoped policies** — Define precise access controls tailored to specific scenarios. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/scoped-policies) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/scoped-policies.md) - **Role policies** — Author permissions from a role’s point of view, not just the resource, and enforce least privilege by default. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/role-policies) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/role-policies.md) - **Derived roles** — Dynamically derive roles based on contextual information. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/derived-roles) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/derived-roles.md) - **GitOps & CI/CD** — Implement a reliable CI/CD workflow with Cerbos' GitOps approach and take advantage of GitHub Actions support. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/gitops-and-ci-cd) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/gitops-and-ci-cd.md) - **Ecosystem** — Integrations and SDKs for popular languages. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) - **Flexible deployment models** — Deploy Cerbos in a way that aligns with your infrastructure needs. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models.md) - **Admin API** — Simplify administration functions with the Cerbos Admin API. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/admin-api) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/admin-api.md) - **WebAssembly (WASM) embedded Policy Decision Points** — Take advantage of Cerbos Hub’s unique, flexible approach to authorization by leveraging WASM for embedded PDPs. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/wasm-embedded-pdp) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/wasm-embedded-pdp.md) - **IDE plugins** — Accelerate your development workflow and ensure that your policies are error-free with real-time syntax checking. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/ide-plugins) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/ide-plugins.md) ## Use cases - **AI security** — Policy-driven access control and full decision logging for AI agents and agentic workflows. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security.md) - **Dynamic authorization for MCP servers** — Secure your MCP server tools from day one. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers.md) - **Access control for RAG** — Apply permissions-aware data filtering to your RAG architecture. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag.md) - **AI gateway authorization** — Control which LLMs, tools, and agents each identity can reach through your AI gateway. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/ai-gateway-authorization) - **Agentic commerce security** — Authorize every AI agent transaction before money moves. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/agentic-commerce) - **Legacy application authorization** — Secure legacy apps with policy-based authorization, audit trails, and context-aware access control. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/legacy-app-authorization) - **Application permissions** — Implement context-aware authorization for granular access control. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/application-permissions) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/application-permissions.md) - **Multi-tenant SaaS** — Scale your SaaS offering with controlled, audited, and isolated environments. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/multi-tenant-saas) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/multi-tenant-saas.md) - **Per-tenant custom policies** — Define and manage tenant-specific policies dynamically for every tenant, customer, or organizational unit. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies.md) - **Dynamic policies** — Create, update and deploy policies programmatically to save engineering hours and accelerate releases. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-policies) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-policies.md) - **Authorization for non-human identities** — Secure every AI agent, workload identity, service, and API client in your ecosystem. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/authorization-non-human-identities) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/authorization-non-human-identities.md) - **Support enterprise organizations** — Manage the intricate requirements of large enterprises with ease [Page](https://www.cerbos.dev/features-benefits-and-use-cases/support-enterprise-organizations) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/support-enterprise-organizations.md) - **Product packaging** — Offer trials, feature bundles, and custom packages with Cerbos policies. [Page](https://www.cerbos.dev/features-benefits-and-use-cases/product-packaging) · [Markdown](https://www.cerbos.dev/features-benefits-and-use-cases/product-packaging.md) --- title: "WebAssembly (WASM) embedded Policy Decision Points" description: "Cerbos Hub introduces a unique, flexible approach to authorization by leveraging WebAssembly (WASM) for embedded Policy Decision Points (PDPs)." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/wasm-embedded-pdp" source: "https://www.cerbos.dev/features-benefits-and-use-cases/wasm-embedded-pdp" --- # WebAssembly (WASM) embedded Policy Decision Points Cerbos Hub introduces a unique, flexible approach to authorization by leveraging WebAssembly (WASM) for embedded Policy Decision Points (PDPs). ## Lightweight and compatible Take advantage of a stateless and scalable authorization system that seamlessly integrates into your environment. Unlike the standard open source PDP, an embedded PDP can be deployed as a library instead of a service at edge, on client devices and in serverless environments. Cerbos Hub delivers this feature by creating a policy file on CDN, pre-compiled and ready to be loaded into your application, all whilst maintaining the same API as the PDP service. Since launching embedded PDPs, we have heard consistent feedback from teams using client-side authorization at scale: more control over bundle contents, tenant isolation in multi-tenant applications, security controls for sensitive authorization logic. We have delivered on that feedback with ePDP Rules - a new way to configure exactly what policies are served to which clients, with enterprise-grade security built in. ## Advantages of an embedded PDP * Easier front-end policy checks: The lightweight design lets your application make decisions on UI rendering faster, and without making a call to the backend * Portability: Usable in serverless environments like Vercel and Netlify. * Reduce latency: Process authorization decisions directly on the user's device. Or distribute your authorization logic closer to the user by embedding it at the edge, ensuring rapid response times and reduced central server loads. * Security and consistency: As Cerbos Hub distributes policies for both the Policy Decision Points (PDPs) and the WebAssembly modules - any changes to policy are reflected everywhere with no extra work. Ensure a consistent and unified approach to policy enforcement. ## Learn more about stateless and scalable authorization - [Scalability in authorization](https://www.cerbos.dev/features-benefits-and-use-cases/scalability) — Discover the importance of having an authorization layer which can scale up in both volume and complexity. - [Stateless authorization](https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization) — Ensure real-time access decisions without the overhead of managing application states. - [Decoupling authorization](https://www.cerbos.dev/features-benefits-and-use-cases/decoupled-authorization) — Simplify authorization, restoring clarity and control to development teams. - [Fine-grained control for embedded policy bundles with ePDP Rules](https://www.cerbos.dev/blog/epdp-rules-fine-grained-control-for-embedded-policy-bundles) — A new way to configure exactly what policies are served to which clients, with enterprise-grade security built in. - [Where to implement authorization in your architecture](https://youtu.be/03XgWf_7dzI) — Find out more in the following video. - [How do we distribute Cerbos](https://youtu.be/Rvw0DTTQmSw) — Find out more in the following video. - [Community discussions on ABAC](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Join the conversation and learn from the experiences of other Cerbos users --- title: "Stateless authorization" description: "Empower your applications with Cerbos' stateless authorization, ensuring real-time access decisions without the overhead of managing application states." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization" source: "https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization" --- # Stateless authorization Empower your applications with Cerbos' stateless authorization, ensuring real-time access decisions without the overhead of managing application states. ## Understanding stateless authorization Stateless authorization means that every access decision is made based on the current request and the latest policy, without relying on any stored session or state information. This ensures that decisions are always based on the most up-to-date data, eliminating synchronization issues and slow network fan-outs. ### Fast, reliable and scalable - **Real-time decisions:** Always make access decisions based on the latest data, ensuring accurate and timely authorization. - **Scalability:** Without the need to manage authorization state, scale your authorization services seamlessly as your user base grows. - **Efficiency:** Stateless design means faster response times, enhancing user experience as there is no data fetching required to make a decision - everything is in-memory. ## Master stateless authorization with Cerbos - [Integration tips](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) — Seamlessly integrate stateless authorization into your applications - [How Cerbos works](https://www.youtube.com/watch?v=_bF4JjUMJkY) — Find out more in the following video - [Scalability](https://www.cerbos.dev/features-benefits-and-use-cases/scalability) — Benefits of having an authorization layer which can scale up in both volume and complexity - [The Stack Overflow podcast](https://www.cerbos.dev/blog/the-stack-overflow-podcast-going-stateless-with-authorization-as-a-service) — Going stateless with authorization-as-a-service - [The importance of stateless architecture in authorization systems](https://www.cerbos.dev/blog/the-importance-of-stateless-architecture-in-authorization-systems) — What stateless is, how it's implemented, and why it's so beneficial to real-world systems such as authorization services - [The future is stateless](https://www.cerbos.dev/blog/the-future-is-stateless-its-time-to-ensure-your-security-is-as-scalable-as-your-business) — It’s time to ensure your security is as scalable as your business - [Authorization as a service](https://www.cerbos.dev/blog/authorization-as-a-service) — Find out what benefits authorization as a service provides - [Where to implement authorization in your architecture](https://youtu.be/03XgWf_7dzI) — Find out more in the following video - [Community insights](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with experts and peers to explore the full potential of stateless authorization --- title: "Scoped policies with Cerbos" description: "Tailor your authorization to specific contexts. With Cerbos' scoped policies, achieve granular control, ensuring the right access for the right scenario." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/scoped-policies" source: "https://www.cerbos.dev/features-benefits-and-use-cases/scoped-policies" --- # Scoped policies with Cerbos Tailor your authorization to specific contexts. With Cerbos' scoped policies, achieve granular control, ensuring the right access for the right scenario. ## Understanding scoped policies In the realm of authorization, one size doesn't fit all. Different situations demand different access controls. Scoped policies allow you to define authorization rules tailored to specific contexts or scenarios, ensuring that permissions are granted or denied based on the exact circumstances of a request. ### Precision, flexibility, and contextual awareness - **Precision in authorization:** Define policies that cater to specific scenarios, ensuring that access controls are as precise as they can be. - **Dynamic context evaluation:** Cerbos evaluates the context of each request in real-time, applying the most relevant scoped policy. - **Flexibility in definition:** Whether it's based on user roles, time of day, IP address, or any other context, scoped policies can be tailored to fit. - **Seamless integration:** Scoped policies work harmoniously with other Cerbos features, ensuring a cohesive authorization experience. - **Enhanced security:** By narrowing down permissions to specific contexts, reduce the risk of unauthorized access or breaches. ![scoped policies diagram](/assets/scoped-policies-diagram.svg) ## Dive deeper into scoped policies - [Scoped policies documentation](https://docs.cerbos.dev/cerbos/latest/policies/scoped_policies.html) — A comprehensive guide on creating, managing, and optimizing scoped policies with Cerbos - [Advanced multi-tenant SaaS authorization with Cerbos](https://www.cerbos.dev/blog/multi-tenant-saas-authorization-role-policies-and-scoped-resource-policies) — Role policies and scoped resource policies - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community for insights, best practices, and innovative use cases related to scoped policies --- title: "Role policies with Cerbos" description: "Author permissions from a role’s point of view, not just the resource, and enforce least privilege by default." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/role-policies" source: "https://www.cerbos.dev/features-benefits-and-use-cases/role-policies" --- # Role policies with Cerbos Author permissions from a role’s point of view, not just the resource, and enforce least privilege by default. ## Understanding role policies Role policies in Cerbos provide a structured approach to defining permissions based on orientations around a role that can be assigned to a user or a non-human identity. They allow teams to specify which actions a particular role can perform on various resources, facilitating clear and manageable access control without having to augment the underlying resource policies. During access checks, Cerbos evaluates role policies that match the principal's role and scope first. If multiple role policies apply, their permissions are combined, and then this is used as a permission-narrowing mechanism to limit which actions on resources are allowed. ### Precision and enhanced security - **Role-centric definition:** Permissions are grouped by role, specifying what actions that role can perform on various resources, and removing the need for new roles to be added to the resource policies. - **Inheritance and narrowing:** Role policies inherit from parentRoles. These parents can be roles defined in an Identity Provider (IdP) or other role policies within Cerbos. A role policy can only _narrow_ the permissions granted by its parentRoles. It cannot grant permissions that are not already allowed by the parents. - **Scope-aware:** Role policies are inherently scope-aware. A role policy defined with a scope attribute will only apply to principals acting within that specific tenant context. - **Implicit deny:** Actions not explicitly listed in allowActions within a matching rule are implicitly denied for that rule. The policy as a whole represents an exhaustive view of what is allowed on that resource. ## Dive deeper into role policies - [Advanced multi-tenant SaaS authorization with Cerbos](https://www.cerbos.dev/blog/multi-tenant-saas-authorization-role-policies-and-scoped-resource-policies) — Role policies and scoped resource policies - [Empower your SaaS platform with robust, policy-enforced multi-tenancy](https://www.cerbos.dev/features-benefits-and-use-cases/multi-tenant-saas) — Ensuring controlled, audited, and isolated environments for each tenant - [Community insights on role policies](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community, learning from real-world role-policies scenarios --- title: "Read–eval–print loop (REPL)" description: "Developer tooling to quickly test and evaluate policy and conditions." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/read-eval-print-loop-repl" source: "https://www.cerbos.dev/features-benefits-and-use-cases/read-eval-print-loop-repl" --- # Read–eval–print loop (REPL) Developer tooling to quickly test and evaluate policy and conditions. ## What is REPL? REPL, or read–eval–print loop, is an interactive computing environment. It takes single user inputs, evaluates them, and returns the result to the user. This simple yet powerful tool allows developers to test snippets of code without the need to run full-fledged programs, making it an invaluable tool for debugging, learning, and iterative development. ### Elevate your experience with Cerbos' integration of REPL - **Instant feedback:** Test policies and conditions on-the-fly without waiting having to run the Cerbos service. - **Iterative development:** Quickly prototype and refine your code, enhancing productivity. - **Debugging made easy:** Load existing policies into the REPL and evaluate simple requests to debug real world use cases. - **Learning and exploration:** New to Cerbos or a particular feature? Use REPL to learn interactively. ### REPL with Cerbos ```yaml -> :let request = { > "principal":{"id":"john","roles":["employee"],"attr":{"scope":"foo.bar.baz.qux"}}, > "resource":{"id":"x1","kind":"leave_request","attr":{"scope":"foo.bar"}} > } -> hierarchy(R.attr.scope).ancestorOf(hierarchy(P.attr.scope)) _ = true ``` Cerbos' REPL is designed with developers in mind. It's not just about executing code; it's about enhancing the overall development experience. With features like ablilty to load existing policies in, execute specific conditions and sensible keybaord shortcuts, the Cerbos REPL is a swiss army knife of tooling. ## Dive into the world of REPL - [Documentation](https://docs.cerbos.dev/cerbos/latest/cli/cerbos.html#repl) — Get started with REPL in Cerbos - [Community insights](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on REPL --- title: "Role-based access control (RBAC)" description: "Ensure that only users with a specific role can access certain resources or perform specific actions." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/rbac" source: "https://www.cerbos.dev/features-benefits-and-use-cases/rbac" --- # Role-based access control (RBAC) Ensure that only users with a specific role can access certain resources or perform specific actions. ## What is Role-Based Access Control (RBAC)? Role-based access control (RBAC) is an approach to restricting system access to authorized users. In RBAC, permissions are associated with roles, and users are assigned appropriate roles. This ensures that only users with the necessary role can access certain resources or perform specific actions. ## What are the benefits of RBAC? RBAC is a helpful control model used by organizations to establish and police access to their digital resources. RBAC is widely accepted as an effective method of access control, particularly for organizations with an IT infrastructure and requirements that span a multitude of systems and applications. With RBAC roles and privileges can be easily assigned to users effectively regulating their activity within the system, reducing the threat of unauthorized access to sensitive information and ensuring the integrity of data that is vital to the smooth operation of the enterprise. ### RBAC in action with Cerbos ```yaml apiVersion: api.cerbos.dev/v1 resourcePolicy: version: default resource: rbacExample rules: # If the principal's role is ADMIN then all the actions are allowed. - actions: - "*" effect: EFFECT_ALLOW roles: - ADMIN # If the principal's role is USER or MANAGER then creating and reading is allowed. - actions: - create - read effect: EFFECT_ALLOW roles: - USER - MANAGER # If the principal's role is MANAGER then they can also update - actions: - update effect: EFFECT_ALLOW roles: - MANAGER ``` In this policy for a purchase order a user is granted permission to do defined actions based on their role. Admins can do all actions, users can create and read, and managers can also update a PO. [Try out this pre-built policy in the Cerbos Playground](https://play.cerbos.dev/p/skeRbxNPqJo654372b8SMGmQBOZW00Ib) ## Key components of role-based access control The following represent the key characteristics of a role-based access control system and are common to all such systems regardless of the size of the organization or the complexity of its digital infrastructure. **Roles**: For the purposes of access to digital assets roles are typically assigned based on job functions, responsibilities and other attributes. For instance, within a given organization roles may include admin, manager and employee. Each role is then assigned a variety of permissions based on the person’s job description. Some will have extremely limited access while others will have carte blanche. **Permissions**: RBAC relies on permissions being assigned to various roles. These permissions specify which digital assets a user will have access to along with the specific actions they will be able to perform in relation to those assets. For example, both an employee and a manager may be able to view a certain file but only the manager will have permission to alter its content or delete it. **Users**: Without users, there is no need for role-based access controls. Users are those individuals, processes or applications that need to interact with the system. Each user is assigned a role based on their responsibilities. In some cases, a user may be assigned more than one role. **Resources**: Resources - also referred to as “objects” - are those digital assets users will need to access, manipulate or perhaps execute. Resources include files, databases, servers, scripts and other components of the computer infrastructure. ## Establishing Relationships Between Roles and Permissions RBAC establishes both roles and permissions and then combines them in a way that ensures the integrity of an organization’s digital resources. Basic RBAC principles include: * **Establishing roles**: Before roles can be assigned they must be established. * **Defining permissions**: Permissions are based on the digital assets involved and their sensitivity. * **Assigning permissions to roles**: Each role is then assigned one or more permissions. * **Assigning roles**: Roles are then assigned to the various users. * **Least privilege**: Roles are assigned using the principle of least privilege whereby users are given the minimum access they need to perform their designated functions. * **Access control**: Once roles have been assigned they are used to provide access control. ## Conclusion Role-based access control offers a variety of benefits including scalability, simple administration and robust accountability via a clear audit trail. Organization-wide changes can be automatically implemented by simply modifying a given permission or role. This makes RBAC one of the most cost-effective methods of access control for large organizations. ## Deep dive into RBAC - [Resource policies documentation](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html) — Comprehensive guide on implementing policies with Cerbos - [Cerbos Playground demo](https://www.cerbos.dev/blog/cerbos-playground-dive-into-the-rbac-policy-generator) — RBAC policy generator - [Role management](https://www.cerbos.dev/blog/lets-talk-about-role-management-planning-user-roles-for-your-application) — Learn how to plan roles for your application - [RBAC best practices](https://www.cerbos.dev/blog/role-based-access-control-best-practices) — Discover 11 top tips when it comes to RBAC - [Community discussions on RBAC](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Join the conversation and learn from the experiences of other Cerbos users --- title: "Permissions-aware data filtering" description: "Filter data according to user access privileges when fetching records from the data storage." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/permission-aware-data-filtering" source: "https://www.cerbos.dev/features-benefits-and-use-cases/permission-aware-data-filtering" --- # Permissions-aware data filtering Filter data according to user access privileges when fetching records from the data storage. ## What is permissions-aware data filtering? Permissions-aware data filtering is the process of fetching data based on a principal's access level. Instead of retrieving all the data and then filtering out unauthorized content, this approach fetches only the data the principal is allowed to access, ensuring efficiency and enhanced security. Based on the access policies, Cerbos provides a list of conditions to apply in your data query, in order to only fetch the correct data points. ### Permissions-aware data filtering with Cerbos Use the Cerbos query plan to dynamically filter data retrieval according to your authorization policies. Based on the access policies, Cerbos provides a list of conditions to apply in your data query, in order to only fetch the correct data points. - **Efficient retrieval:** Fetch only the necessary data, reducing the load on your databases and ensuring faster response times. - **Enhanced security:** By only retrieving allowed data, you minimize the risk of accidental data leaks or exposure. - **Dynamic adjustments:** As authorization policy changes, the filtering logic adjusts in real-time, ensuring up-to-date access control. - **Seamless integration:** Cerbos' query plans can be mapped into your existing data fetching layer. Alternatively, use reference one of Cerbos' implementations for [Prisma](https://cerbos.dev/ecosystem/cerbos-prisma), [SQLAlchemy](https://cerbos.dev/ecosystem/cerbos-sqlalchemy), [Mongoose](https://cerbos.dev/ecosystem/cerbos-mongoose). Policies can be consistently applied across various layers of the technology stack: - **Data Layer:** Controlling access to raw data in databases and data warehouses. - **API Layer:** Enforcing permissions for data accessed programmatically. - **Application Layer:** Enforcing access controls within software applications. - **AI Layer:** Ensuring AI agents and chatbots respect user permissions. ## Mastering permissions-aware data filtering - [Data filtering documentation](https://docs.cerbos.dev/cerbos/latest/api/index.html#resources-query-plan) — Dive deep into the mechanics of setting up and optimizing data filtering with Cerbos - [Data filtering guide](https://www.cerbos.dev/blog/filtering-data-using-authorization-logic) — Unlock the full potential of data filtering with these tips - [Data filtering for RAG and LLMs](https://docs.cerbos.dev/cerbos/latest/recipes/ai/rag-authorization/) — Apply data filtering to your RAG architecture to place guardrails around your LLMs. - [Fine-grained control for embedded policy bundles with ePDP Rules](https://www.cerbos.dev/blog/epdp-rules-fine-grained-control-for-embedded-policy-bundles) — A new way to configure exactly what policies are served to which clients, with enterprise-grade security built in. - [The Cerbos ecosystem](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) — Find out more about ORMs - [Community insights on permissions-aware data filtering](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and learn from real-world implementations --- title: "Policy-Based Access Control (PBAC)" description: "PBAC is an authorization model where access decisions are driven by centrally managed policies that sit outside the application code. This guide covers how PBAC works, when to use it, how it compares to RBAC and ABAC, and how to implement it with Cerbos." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/pbac" source: "https://www.cerbos.dev/features-benefits-and-use-cases/pbac" --- # Policy-Based Access Control (PBAC) PBAC is an authorization model where access decisions are driven by centrally managed policies that sit outside the application code. This guide covers how PBAC works, when to use it, how it compares to RBAC and ABAC, and how to implement it with Cerbos. ## What is policy-based access control (PBAC)? Policy-based access control (PBAC) is an authorization model where access decisions are governed by declarative policies that live outside the application. Instead of checking roles or permissions inline with the code, every request is evaluated against a set of policies by a dedicated policy engine. The engine takes in the principal, the action, the resource, and any contextual data, then returns an allow or deny based on the rules defined in those policies. The defining trait of PBAC is that the policy itself is a first-class artifact. It is authored, versioned, tested, and deployed independently of the application. That separation is what lets teams change access logic without redeploying services and what lets non-engineers reason about, audit, and contribute to access rules. ## How PBAC works At its core PBAC is about one thing. The access decision comes from a policy, not from logic hard-coded into each application. The policy is a declarative, standalone artifact that defines who can do what under which conditions, and every request is evaluated against it. The policy is the unit you author, version, test, and reason about. How that policy gets evaluated at runtime is a separate question. Most externalized authorization setups answer it with three roles, a separation that the XACML model first described and that the [OpenID AuthZEN](https://www.cerbos.dev/authzen) spec has since modernized for application authorization. The Policy Administration Point (PAP) is where policies are authored and managed. In a modern PBAC setup this looks like a Git repository, a policy authoring UI, or both, with versioning, testing, and deployment handled like any other code artifact. The Policy Decision Point (PDP) is the engine that evaluates a request against the policies and returns a decision. It receives the request context, runs it through the policy logic, and produces an allow or deny. The PDP is stateless in well-designed implementations, which is what makes it possible to scale. The Policy Enforcement Point (PEP) sits inside the application or service. It intercepts the request, packages up the context, asks the PDP for a decision, and enforces the answer. Cerbos provides PEP SDKs for all major languages, including JavaScript, Go, Python, Java, .NET, Rust, PHP, and Ruby so the integration is a single function call. This separation is the foundation of externalized authorization management (EAM). It moves authorization out of the application into a dedicated layer that can be tested and evolved on its own. It is not unique to PBAC, the same architecture runs role-based and attribute-based rules just as well. What PBAC adds is the policy as the thing you manage. [How Cerbos works](https://www.cerbos.dev/how-it-works) ## How to implement PBAC with Cerbos Cerbos is a purpose-built PBAC engine. Policies are written in YAML, conditions are expressed in Google's CEL, and the Cerbos PDP evaluates them against the request context at runtime. The PDP is stateless, runs anywhere (containers, Kubernetes, edge), and handles millions of checks per second. Here's a working example. In this policy, a user is granted permission to view a resource only when both conditions are met. Their department attribute equals "IT" and the resource type attribute equals "confidential": ```yaml apiVersion: api.cerbos.dev/v1 resourcePolicy: version: default resource: pbacExample rules: - actions: - VIEW effect: EFFECT_ALLOW roles: - USER condition: match: all: of: - expr: request.principal.attr.department == "IT" - expr: request.resource.attr.type == "confidential" ``` The policy lives in Git. It is tested in CI like any other code, validated against schemas, and deployed to running PDPs without restarts via [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub). When the access rules change, you update the policy, not the application. For scenarios where the policy needs data that does not travel with the request, [Cerbos Synapse](https://www.cerbos.dev/product-cerbos-synapse) enriches the call before it hits the engine. It can pull a user's department from your identity provider, a customer's subscription tier from your database, or a device's trust level from your MDM, so the policy can evaluate against complete context. ## Key components of PBAC Every PBAC implementation, regardless of vendor, has the same building blocks. **The policy language** is how rules are expressed. Some systems use a domain-specific language like Rego. Cerbos uses YAML for structure and CEL for conditions. The language choice matters because it determines who can read, write, and audit policies. YAML and CEL are readable enough that product managers, security teams, and compliance reviewers can follow the logic without learning a new syntax. **The policy engine** is the runtime that evaluates a request against the policies. Performance and isolation are the two things that matter here. Cerbos built a [custom decision engine](https://www.cerbos.dev/blog/from-opa-to-our-own-engine-cerbos) after hitting limitations with OPA's Rego model, and the result is up to 17x faster than the OPA-based predecessor it replaced. **Attributes and context** feed the evaluation. A policy can reference attributes on the principal (role, department, tenant), the resource (owner, classification, status), the action, and the environment (time, region, device trust). The more context the engine has, the more nuanced the decisions can be. **The policy lifecycle** covers authoring, testing, versioning, and distribution. Cerbos treats policies the same way a team treats application code, with Git-native workflows, CI validation, coverage reports, breaking-change detection, and audit logs of every decision. Cerbos Hub handles propagation to running PDPs without restarts. ## Benefits of PBAC The case for PBAC over simpler models rests on three things. Separation of concerns, expressiveness, and operational maturity. - **Separation of concerns.** Authorization logic lives outside the application. Engineers ship features, security and product teams own the rules, and the two can move independently. When a policy needs to change, you change the policy, not the codebase. One Cerbos customer, [Human Managed](https://www.cerbos.dev/customers/human-managed), summed it up as "having to modify authorization is now a five-minute job." - **Expressiveness.** Roles alone cannot capture conditions like "users can read records they own", "managers can approve orders under $10K in their region", or "service accounts can only call this endpoint from inside the cluster". PBAC handles all of these with policy conditions instead of role explosion. That is the same thing ABAC promises, but PBAC frames it around the policy as the unit of management rather than the attributes themselves. - **Operational maturity.** Because policies are first-class artifacts, you get version control, code review, automated testing, and structured audit logs. For regulated industries this is the difference between an authorization layer you can explain to an auditor and one you cannot. Cerbos Hub produces structured audit logs that meet SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR requirements. [PBAC is back: why policy-based access control is trending again](https://www.cerbos.dev/blog/policy-based-access-control-enterprise-security) [When authorization is static, risk accumulates silently](https://www.cerbos.dev/blog/risks-of-static-authorization) ## PBAC vs RBAC, ABAC, and ReBAC The lines between authorization models are blurrier in practice than the names suggest. The honest framing is that PBAC is less a competing model and more a pattern for managing whichever model you pick. [RBAC](https://www.cerbos.dev/features-benefits-and-use-cases/rbac) (role-based access control) grants access by assigning users to roles. It is the simplest model and the right starting point for most applications. It breaks down when access rules need context beyond the role, which is usually around the time a team finds itself adding roles like "manager_eu_finance_q3_2026_temp." [ABAC](https://www.cerbos.dev/features-benefits-and-use-cases/abac) (attribute-based access control) evaluates attributes of the user, resource, action, and environment. It handles the nuance RBAC cannot, but the attribute-driven framing leaves the question of how policies are managed open. ReBAC (relationship-based access control) models access through relationships between entities, like "users can read documents in folders they have access to." It suits systems where the permission structure mirrors a graph. PBAC does not replace any of these. It is a pattern for managing access rules as policy artifacts, regardless of whether those rules are role-based, attribute-based, or relationship-based. In Cerbos, a single policy file can mix role checks, attribute conditions, and relationship logic, with the policy itself as the unit of governance. ## When PBAC makes sense A few patterns make PBAC clearly the right call. Multi-tenant SaaS is the most common one. When the same user role means different things in different tenants, or when each customer needs slightly different access rules, embedding that logic in code creates a maintenance problem that gets worse with every new tenant. PBAC lets you express tenant-specific rules in policy and avoid duplicating the application per customer. Regulated industries like fintech and healthcare have requirements that map directly to policy conditions. A doctor can read records only for patients currently under their care. A financial analyst can export data only for their own region. A contractor has access only during their contract period. These are all policy checks, and the structured audit trail is what makes them defensible to auditors. Enterprise applications with complex org structures benefit from PBAC when permissions reflect reporting lines, cost centers, geographic units, or clearance levels. Encoding that into roles creates fragility. Encoding it into policies keeps it maintainable as the organization evolves. Microservices and API authorization are a good fit because PBAC gives you a single, consistent authorization layer across services without coupling each service to its own access logic. The PDP runs as a sidecar or shared service, every microservice calls it the same way, and the policy logic lives in one place. AI agents and non-human identities are the newest category. We cover this in its own section below. [Multi-tenant SaaS authorization](https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies) [Designing an authorization model for an enterprise](https://www.cerbos.dev/blog/designing-an-authorization-model-for-an-enterprise) [3 most common authorization designs for SaaS products](https://www.cerbos.dev/blog/3-most-common-authorization-designs-for-saas-products) ## Challenges of PBAC and how Cerbos addresses them The main objections teams raise are around complexity, performance, and operational burden. Each one has a concrete answer. **Policy complexity.** A policy language is more powerful than role assignments, and that power can turn into sprawl if there is no discipline around it. Cerbos addresses this with YAML structure that is readable by non-engineers, schema validation that catches mistakes before they ship, a [Playground](https://play.cerbos.dev/) for iterating on policies with execution traces, and CI integrations that run coverage reports and flag breaking changes on every commit. **Latency.** A separate authorization service adds a network hop. The Cerbos decision engine evaluates policies in under a millisecond, the PDP runs locally as a sidecar so there is no cross-network call, and the engine itself is [up to 17x faster](https://www.cerbos.dev/blog/cerbos-vs-opa) than the OPA-based version it replaced. For most applications the overhead is well inside the normal noise of a request. **Operational overhead.** Running a separate authorization service sounds like more work. In practice the [alternative](https://www.cerbos.dev/blog/why-external-authorization) is authorization logic spread across every service in the system, which is harder to audit and harder to change. Cerbos Hub handles policy propagation across all running PDPs without restarts and produces a structured audit log of every decision, which is usually a net reduction in operational work, not an increase. **Migrating off existing code.** Most teams come to PBAC with authorization already embedded in their application. The realistic path is to introduce the PDP behind a feature flag for one resource type, validate it against the existing logic, then expand. Customers like [Salesroom](https://www.cerbos.dev/customers/salesroom) describe the result as "I categorized [Cerbos] as just one of those things I don't have to think about." [Mapping business requirements to authorization policy](https://www.cerbos.dev/blog/mapping-business-requirements-to-authorization-policy) [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) ## PBAC for AI agents and non-human identities AI agents calling tools on behalf of users break the assumptions most authorization systems were built on. The agent has its own identity, but it is also acting for a human with their own permissions. A single misconfiguration affects every action the agent takes across every system it reaches. PBAC is a natural fit because the policy can reason about both identities in the same check. The agent might have broad tool access, but the policy can restrict it based on the human's clearance, the sensitivity of the resource, the time of day, or any other contextual condition. The agent does not get standing privilege, and every action is evaluated against the policy at request time. The same pattern works for service-to-service calls, CI/CD pipelines, and any other non-human caller. The combination of PBAC and Cerbos Synapse means the policy engine can pull the human's profile from the IdP, the agent's metadata from the platform, and any resource attributes from the source system, then evaluate them together in a single decision. [Guardrails for AI agents](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security) [Zero-trust for AI: Securing MCP servers](https://solutions.cerbos.dev/zero-trust-for-ai-securing-mcp-servers) ## Getting started with PBAC The fastest way to see what a PBAC implementation looks like is to write a policy in the [Cerbos Playground](https://play.cerbos.dev/), where you can edit YAML, run test cases, and see execution traces in the browser. From there the [quickstart](https://docs.cerbos.dev/cerbos/latest/quickstart.html) walks through running the PDP locally and wiring up an SDK call, and [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub) handles policy management and distribution once you are ready to deploy. ## Explore PBAC further - [Resource policies documentation](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html) — Implementing policies with Cerbos - [Conditions documentation](https://docs.cerbos.dev/cerbos/latest/policies/conditions.html) — How to write conditions in policies - [PBAC is back](https://www.cerbos.dev/blog/policy-based-access-control-enterprise-security) — Why PBAC is trending again - [Example PBAC policy in the Playground](https://www.cerbos.dev/blog/cerbos-playground-dive-into-the-rbac-policy-generator) — Try a pre-built policy - [What is dynamic authorization?](https://www.cerbos.dev/blog/what-is-dynamic-authorization) — How it works, why it’s essential for distributed systems, how it differs from RBAC - [Per-hop PBAC](blog/per-hop-pbac-delegation) — Enforcing scope at every delegation step - [Community discussions on PBAC](https://community.cerbos.dev/) — Join the conversation with other Cerbos users --- title: "IDE plugins" description: "Accelerate your development workflow and ensure that your policies are error-free with real-time syntax checking." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/ide-plugins" source: "https://www.cerbos.dev/features-benefits-and-use-cases/ide-plugins" --- # IDE plugins Accelerate your development workflow and ensure that your policies are error-free with real-time syntax checking. ## Editor configurations Scheme for all Cerbos files (policies, test suites and test data) are published and made avaliable to configure your IDE. With these setup, your existing tooling with provide realtime validation, autocomplete functionality and links to documentation when working with your policy. Whether you're using Neovim, JetBrains IDEs, or Visual Studio Code, we've got you covered. ### Smooth policy authoring
ide-plugins
Our IDE integrations are designed to make your policy authoring process as smooth as possible. With real-time syntax checking and context-sensitive suggestions, you can focus more on the logic of your policies and less on debugging syntax errors. Happy coding! ## Links to resources - [Documentation](https://docs.cerbos.dev/cerbos/latest/policies/authoring_tips.html) — Check out Cerbos' policy authoring tips - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on IDE plugins --- title: "Seamless authorization with GitOps & CI/CD" description: "Elevate your authorization workflows with Cerbos, integrating the power of GitOps and CI/CD for reliable, testable, and streamlined policy deployments." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/gitops-and-ci-cd" source: "https://www.cerbos.dev/features-benefits-and-use-cases/gitops-and-ci-cd" --- # Seamless authorization with GitOps & CI/CD Elevate your authorization workflows with Cerbos, integrating the power of GitOps and CI/CD for reliable, testable, and streamlined policy deployments. ## Understanding GitOps & CI/CD in authorization In the realm of modern software development, GitOps and CI/CD are revolutionizing how we manage, test, and deploy code. When applied to authorization, these principles ensure that access control policies are consistently tested, validated, and deployed, reducing human errors and enhancing security. ### Reliable, testable, and developer-friendly workflows - **GitOps aligned:** Instead of relying on static roles, Cerbos adjusts access controls in real-time based on the prevailing context, ensuring accurate and adaptive authorization. - **Testable authorization:** Write tests alongside your authorization logic, ensuring comprehensive coverage and accurate decisions. With Cerbos Hub, every policy change undergoes rigorous compilation, validation, and testing. - **CI/CD integration:** Implement a robust CI/CD workflow with Cerbos, allowing you to test and deploy intricate access control policies with utmost confidence. - **Configurable deployments:** With Cerbos Hub's CI pipeline, deploy based on branches, tags, or commits, offering flexibility in how you roll out policies to Authorization Decision Points across environments. - **Developer-friendly:** Cerbos Hub is designed with developers in mind, offering workflows that seamlessly integrate with your existing development and deployment processes. ## Master GitOps & CI/CD with Cerbos - [Documentation](https://docs.cerbos.dev/cerbos/latest/policies/compile) — Implement and define tests against your authorization policy - [GitOps guide](https://www.cerbos.dev/blog/why-using-gitops-for-authorization-and-access-control-is-a-good-idea) — Why using GitOps for authorization and access control is a good idea - [How do we distribute Cerbos](https://youtu.be/Rvw0DTTQmSw) — Find out more in the following video - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community for insights, tips, and real-world GitOps and CI/CD use cases --- title: "Flexible policy conditions powered by Google CEL" description: "Experiment with writing CEL conditions, enjoy a seamless policy development experience." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/flexible-policy-conditions-powered-by-google-cel" source: "https://www.cerbos.dev/features-benefits-and-use-cases/flexible-policy-conditions-powered-by-google-cel" --- # Flexible policy conditions powered by Google CEL Experiment with writing CEL conditions, enjoy a seamless policy development experience. ## Seamless policy development Google Common Expression Language, CEL, enables Cerbos policies to offer powerful capability to define conditions that are evaluated against the data provided in the request. CEL is a robust language designed for simplicity, speed, and safety. With Cerbos' interactive REPL, you can experiment with writing CEL conditions, providing a seamless experience for policy development. ## Key features ### Operators and functions: - **Logical operators:** Define conditions using common logical operations to check for values, compare attributes and more. - **Built-in functions:** Utilize a wide range of built-in functions and operators in CEL such as working with lists, maps and timestamps. - **Cerbos-specific extensions:** Use Cerbos-specific functions for handling hierarchies, IP addresses, and more. ### Policy variables and auxiliary data: - **Avoid duplication:** Define variables to avoid repetitive condition expressions. - **Auxiliary data:** Access additional data sources, like JWT, in your policies. ### Basic CEL condition example ```yaml condition: match: all: of: - expr: request.resource.attr.status == "PENDING_APPROVAL" - expr: > "GB" in request.resource.attr.geographies ``` Using the power of CEL, conditions can be as fine-grained as your business requirements, making use of all the request context to compute an authorization decision. ## Links to resources - [Documentation](https://docs.cerbos.dev/cerbos/latest/policies/conditions.html) — Learn more about conditions - [ABAC](https://www.cerbos.dev/features-benefits-and-use-cases/abac) — Ensure that only users with the necessary attributes can access certain resources or perform specific actions - [Google CEL](https://github.com/google/cel-spec) — Learn more on GitHub - [Community insights](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on CEL --- title: "Flexible deployment with low-latency" description: "Maximize efficiency and responsiveness with Cerbos' adaptable deployment models. Seamlessly integrate into your infrastructure, ensuring instantaneous authorization checks." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models" source: "https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models" --- # Flexible deployment with low-latency Maximize efficiency and responsiveness with Cerbos' adaptable deployment models. Seamlessly integrate into your infrastructure, ensuring instantaneous authorization checks. ## Understanding deployment flexibility and low-latency Authorization is in the blocking path of every request in an application, so ensuring permission checks are performant is key. Cerbos is designed to run locally to your application - inside of your infrastructure - with no requirement to go out to the internet to make decisions, keeping it secure and low latency. ### Adaptable, fast, and efficient - **Multiple deployment models:** Whether you prefer Cerbos as a sidecar, service, or function, it integrates seamlessly with your existing setup. - **Stateless authorization:** Cerbos ADP ensures real-time decisions based on the latest data, eliminating the need for application state synchronization or slow network fan-outs. - **Low-latency checks:** With Cerbos running in your environment, authorization decisions are made locally, ensuring instantaneous checks without cloud lookups. - **Serverless to sidecar:** Achieve unmatched scalability with deployment options ranging from serverless functions to sidecar models, catering to diverse application needs. - **Simplified management with Cerbos Hub:** Manage deployments across multiple environments effortlessly, ensuring policies remain synchronized and up-to-date. - **Universal deployment options:** From on-premise setups to cloud environments, and even Kubernetes, Cerbos Hub ensures smooth testing and distribution. ## Master flexible deployment with Cerbos - [Deployment guide](https://docs.cerbos.dev/cerbos/latest/deployment/) — A walkthrough on various deployment models and best practices - [Ecosystems](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) — Deploy and host the self-hosted Cerbos solution in your environment - [Where to implement authorization in your architecture](https://www.youtube.com/watch?v=_bF4JjUMJkY) — Find out more in the following video - [How do we distribute Cerbos PDP](https://www.youtube.com/watch?v=Rvw0DTTQmSw) — Check out the video - [The Stack Overflow podcast](https://www.cerbos.dev/blog/the-stack-overflow-podcast-going-stateless-with-authorization-as-a-service) — Episode: Going stateless with authorization-as-a-service - [The future is stateless](https://www.cerbos.dev/blog/the-future-is-stateless-its-time-to-ensure-your-security-is-as-scalable-as-your-business) — It’s time to ensure your security is as scalable as your business - [Where to implement authorization in your architecture](https://youtu.be/03XgWf_7dzI) — Find out more in the following video - [Community deployment tips](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to learn about innovative deployment strategies and real-world use cases --- title: "Derived roles" description: "Harness the power of context-driven roles with Cerbos. Adapt to real-time changes and ensure precise access controls tailored to each user's unique situation." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/derived-roles" source: "https://www.cerbos.dev/features-benefits-and-use-cases/derived-roles" --- # Derived roles Harness the power of context-driven roles with Cerbos. Adapt to real-time changes and ensure precise access controls tailored to each user's unique situation. ## What are derived roles? Derived roles are dynamic roles granted to a principal for the scope of a single request based on specific conditions or contexts, rather than being statically assigned. They allow for more granular and adaptive access controls, by deriving roles from attributes like user behaviour, time of day, location, or any other contextual information. ### Adaptive, precise and efficient - **Dynamic adaptation:** Instead of relying on static roles, Cerbos adjusts access controls in real-time based on the prevailing context, ensuring accurate and adaptive authorization. - **Reduce repetition:** Business logic for common scenarios and conditions can be defined once in a derived role, then re-used across different resource policies. ### Sample derived policy ```yaml apiVersion: api.cerbos.dev/v1 derivedRoles: name: common_roles definitions: - name: OWNER parentRoles: ["USER"] condition: match: expr: request.resource.attr.ownerId == request.principal.id ``` A derived role of OWNER is granted to the principal for the scope of the check, in the case where the ownerId attribute of the resource is equal to the id of the principal making the request (ie they are the owner). ## Master derived roles with Cerbos - [Derived roles documentation](https://docs.cerbos.dev/cerbos/latest/policies/derived_roles.html) — Understand the intricacies of crafting and managing derived roles with our guide - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to explore innovative use cases and best practices for derived roles --- title: "Cerbos Playgrounds" description: "Experiment, learn, and prototype with our interactive authorization sandbox. Write, test, and debug Cerbos policies in your browser or in your Cerbos Hub account." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/cerbos-playground" source: "https://www.cerbos.dev/features-benefits-and-use-cases/cerbos-playground" --- # Cerbos Playgrounds Experiment, learn, and prototype with our interactive authorization sandbox. Write, test, and debug Cerbos policies in your browser or in your Cerbos Hub account. ## What is the Cerbos Playground? The Cerbos Playground is an interactive online environment where users can write, test, and visualize Cerbos policies in real-time. It's designed to help both newcomers and experienced developers understand and experiment with Cerbos' capabilities without any setup or installation. Open source PDP users can take advantage of our public playground. Cerbos Hub includes a private playground with collaborative features and a live connection to a development PDP. - **Instant feedback:** Write policies and see immediate results, streamlining the learning process. - **Zero setup:** Dive straight into Cerbos without any installations or configurations. - **Safe environment:** Experiment freely without any risks to your actual systems or data. - **Sample policies:** Get started fast with pre-built examples for common application permission models. ### Advanced collaboration and testing features in the Cerbos Hub Playground Organizations using Cerbos Hub can create an unlimited number of different playgrounds for testing different versions and iterations of their authorization policies. Users within the same organization can collaborate on policies in real time just like a Google doc. And Hub users have the ability to create a live connection with a local PDP in a development environment for faster, hassle-free policy testing and iteration. [Check out the Cerbos Hub Playground here.](https://hub.cerbos.cloud/?utm_source=website&utm_medium=content&utm_campaign=playground) - Real-time collaborative editing: Experience an editing environment where multiple users can work on policies simultaneously. Ideal for pair programming sessions, team reviews, and collaborative policy development. Ideal for reducing errors and enhancing policy reliability. - Instant feedback and testing: Provides real-time feedback on changes, helping to quickly identify and resolve issues, and accelerate your policy development process. It also features an automated test runner, streamlining the policy testing process. - Cohesive experience: Supports the creation of playgrounds directly from GitHub repositories for a cohesive development cycle. - Policy evolution support: Facilitates the evolution of authorization policies with ease, integrating into your Git-based workflow. Encourages iterative development and continuous improvement of policy logic. - Jumpstart with new policies: The RBAC policy generator enables users to create role-based access control policies using a simple, no-code wizard. Complete with a pre-defined test dataset which can be used for troubleshooting and further experimentation. - Verification of how policies work: The API request simulator allows users to simulate API requests without running a local policy decision point (PDP) and view the output of the Check Resources and Query Plan Resources APIs for any combination of user and resource. - Real-time policy testing: Connecting a PDP to the Playground supports developers in establishing a live connection between their development environment and the Hub Playground, enabling the testing of authorization policies in real-time. [#videoitems#] ### Essential policy testing in the Cerbos public playground Our public playground is a web browser environment you can use to experiment with policies. You can save and share your policies with your teammates by creating and account. And when you’re done you can export your files and check them into your repo for use with Cerbos Hub. ### Pre-built example policies | **Use case** | **Language** | **Policy Playground** | **GitHub** | **Video** | | ------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Multi-tenant SaaS | YAML | Multi-tenant SaaS Policy | Repo | N/A | | SaaS Workspaces | YAML | SaaS Workspaces Policy | N/A | N/A | | HRIS Application | Python | Leave Policy | HR Demo Repository | Video (7m) | | Expense Application | Node | Expense Policy | Expense Demo Repository | Video (4m) | | Online Store | Go | E-commerce Policy | Repo | N/A | | Express + JWT | Node | CRUD Policy | Repo | N/A | | Product Packaging | YAML | Product Policy | N/A | N/A | ## Further resources on the Cerbos Playgrounds - [Documentation for the Cerbos Hub Playground](https://docs.cerbos.dev/cerbos-hub/playground) — Explore features and setup details. - [Cerbos Public Playground](https://play.cerbos.dev/) — Get started with the Cerbos Playground now - [Cerbos Hub Playground policy testing](https://www.cerbos.dev/news/new-tools-for-effortless-policy-creation-and-testing-in-cerbos-hub) — Dive into the new features that further simplify how developers write, test, and iterate on authorization policies. Updates include the RBAC policy generator, API request simulator, and connecting a local PDP. - [Community insights](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Need help with modeling your application and building your policies? Get in touch with the Cerbos team and learn from other Cerbos users in our slack community --- title: "Streamlined administration with the admin API" description: "Programmatically manage authorization logic by dynamically adding or updating policies in real-time with Cerbos' admin API." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/admin-api" source: "https://www.cerbos.dev/features-benefits-and-use-cases/admin-api" --- # Streamlined administration with the admin API Programmatically manage authorization logic by dynamically adding or updating policies in real-time with Cerbos' admin API. ## Understanding the admin API In the realm of authorization, the ability to swiftly and efficiently manage policies is paramount. The admin API serves as a bridge, allowing administrators to interact with a running Cerbos instance, ensuring that policy changes are not just easy, but instantaneous. ### Dynamic, efficient and seamless - **Real-time policy updates:** No need to restart or manually intervene. Update policies on-the-fly with the admin API. - **Simplified administration:** Reduce the complexity of administrative tasks by using a dedicated API tailored for policy management. - **Integration ready:** Easily integrate the Admin API with your existing applications with the client SDKs. ## Master the admin API with Cerbos - [Admin API documentation](https://docs.cerbos.dev/cerbos/latest/api/admin_api.html#policy-management) — A detailed guide on how to utilize the admin API for various administrative tasks - [Sample integration guide](https://www.cerbos.dev/blog/dynamic-policy-management-with-the-admin-api) — Learn how to integrate the admin API with your existing tools and dashboards - [Community insights](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community for insights, best practices, and innovative use cases with the admin API --- title: "Attribute-Based Access Control (ABAC)" description: "ABAC is an authorization model that controls access based on attributes of the user, the resource, the action, and the environment. This guide covers how it works, when to use it, and how to implement it with Cerbos." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/abac" source: "https://www.cerbos.dev/features-benefits-and-use-cases/abac" --- # Attribute-Based Access Control (ABAC) ABAC is an authorization model that controls access based on attributes of the user, the resource, the action, and the environment. This guide covers how it works, when to use it, and how to implement it with Cerbos. ## What is attribute-based access control (ABAC)? Attribute-based access control (ABAC) is an authorization model that evaluates a set of attributes to decide whether a user or system should be allowed to perform a given action on a given resource. Rather than assigning permissions through roles alone, ABAC looks at the full context of a request: who is asking, what they want to do, what resource they're acting on, and the conditions under which the request is happening. ## How ABAC works Every ABAC authorization decision follows the same basic flow. An application sends a request describing who is asking (the principal), what they want to do (the action), and what they want to do it to (the resource). The policy engine evaluates that request against a set of rules, comparing attributes on each side, and returns an allow or deny. The power comes from what goes into those attributes and how flexibly you can write conditions over them. A role alone tells you someone is a "manager." Attributes can tell you they're a manager in the Berlin office, working on a Tuesday, on a company-managed device, accessing a document they created. Each of those facts can influence the decision. ## How to implement ABAC with Cerbos Cerbos implements ABAC through resource policies written in YAML, with conditions expressed in Google's CEL. Each policy targets a resource type and defines what actions are allowed under what conditions. The policy engine, Cerbos PDP, evaluates these conditions at request time against the attributes supplied in the authorization check. Here's a working example. In this policy for a purchase order, a user is granted permission to do defined actions based on their role and attributes. Admins can do all actions, users can create, and managers can also update a PO. Users can also read a purchase order if the isPublished attribute is TRUE or the ownerId attribute of the purchase order is equal to their userID: ```yaml apiVersion: api.cerbos.dev/v1 resourcePolicy: version: default resource: abacExample rules: # If the principal's role is ADMIN then all the actions are allowed. - actions: - "*" effect: EFFECT_ALLOW roles: - ADMIN # If the principal's role is USER or MANAGER then creating is allowed. - actions: - create effect: EFFECT_ALLOW roles: - USER - MANAGER # If the principal's role is USER they read a resource as # long as it is published or owned by the user - actions: - read effect: EFFECT_ALLOW roles: - USER condition: match: any: of: - expr: request.resource.attr.isPublished == true - expr: request.resource.attr.ownerId == request.principal.id # If the principal's role is MANAGER then they can also update - actions: - update effect: EFFECT_ALLOW roles: - MANAGER ``` For more complex scenarios where attributes need to come from external systems, Cerbos Synapse can enrich the request before it reaches the policy engine, pulling department data from your directory, subscription tier from your database, or device trust level from your MDM. ## The four types of attributes in ABAC ABAC policies draw on four categories of attributes. **Subject attributes** describe the person or system making the request. Job title, department, team, geographic location, security clearance, and whether the request is coming from a human or a service account are all subject attributes. In practice these often come from your identity provider, your user directory, or a JWT. **Resource attributes** describe the object being acted on. A file has a classification level, an owner, a creation date, and a project tag. A database record has a tenant ID, a status, and a sensitivity flag. These attributes travel with the resource and don't require policy changes to reflect new conditions. **Action attributes** describe what the subject wants to do. Read, write, delete, approve, publish, and execute are all actions. ABAC policies can apply different rules to different actions on the same resource type. **Environment attributes** add context beyond the subject and resource. Time of day, IP address, geographic region, device trust level, and network type are environment attributes. These are what make ABAC genuinely dynamic: the same user accessing the same resource can get a different outcome depending on where or when they're asking. [Deep dive into ABAC components and key concepts](https://www.cerbos.dev/blog/abac) ## Benefits of ABAC The main argument for ABAC over simpler models is that it handles complexity without requiring you to model that complexity in your role structure. In role-based access control (RBAC), you grant access by assigning roles. When your access requirements get more nuanced, you add more roles. That works up to a point, then you hit what engineers call "role explosion," a proliferation of roles that becomes difficult to manage, audit, or reason about. ABAC sidesteps this by expressing the nuance in policy conditions rather than in role definitions. Granularity is the other major advantage. With ABAC you can enforce decisions at a fine level without hardcoding them into your application. A policy that says "users can only edit records they own" - something which is contextual, based on the request and can’t just be a role - requires zero changes to your application logic when business rules shift. You update the policy. For regulated industries, ABAC also maps naturally to compliance requirements. GDPR, HIPAA, and SOC 2 all require that access decisions be driven by legitimate need and context, not just organizational hierarchy. ABAC policies can express and enforce those requirements directly, and a solution like Cerbos produces a complete audit trail of every decision. [Full RBAC vs ABAC comparison](https://www.cerbos.dev/blog/rbac-vs-abac) [Enterprise access control: ABAC vs RBAC in service-oriented architectures](https://www.cerbos.dev/blog/enterprise-access-control) ## When ABAC makes sense **Multi-tenant SaaS** is where ABAC earns its keep most often. When the same user role means different things in different organizations, you need attribute-based conditions to express those differences without duplicating your entire policy set per tenant. **Regulated industries** like fintech and healthcare have requirements that map directly to attribute conditions. A doctor can only access records for patients currently under their care. A financial analyst can only export data from their own region. A contractor has access only during their contract period. These are all attribute checks that roles can't easily express. **Enterprise applications** with complex org structures benefit from ABAC when permissions need to reflect reporting lines, cost centers, geographic units, or clearance levels. Encoding all of that into roles creates fragility that grows over time. Attribute conditions are more maintainable as the organization evolves. **Microservices and API authorization** benefit from ABAC because you can apply consistent policy logic across services without coupling your authorization model to any specific service's internal data structure. [How to implement scalable multitenant authorization](https://www.cerbos.dev/blog/how-to-implement-scalable-multitenant-authorization) [Designing an authorization model for an enterprise](https://www.cerbos.dev/blog/designing-an-authorization-model-for-an-enterprise) [3 most common authorization designs for SaaS products](https://www.cerbos.dev/blog/3-most-common-authorization-designs-for-saas-products) ## ABAC and related models ABAC doesn't exist in isolation. It's one of several authorization models, and the lines between them are blurrier in practice than the names suggest. Policy-based access control (PBAC) is closely related. Where ABAC emphasizes the role of attributes, PBAC emphasizes the policy itself as the unit of management. In Cerbos, policies are YAML files managed in Git, tested in CI, and deployed independently of your application. That's the PBAC pattern applied to an attribute-based engine, and the two models overlap significantly in modern implementations. [PBAC is back: why policy-based access control is trending again](https://www.cerbos.dev/blog/policy-based-access-control-enterprise-security) [What is dynamic authorization and why does it matter?](https://www.cerbos.dev/blog/what-is-dynamic-authorization) ## ABAC for AI agents and non-human identities AI agents calling tools on behalf of users create an authorization problem that role-based models handle poorly. An agent has its own identity, but it's also acting on behalf of a human who has their own attributes and permissions. Which set governs the decision? The right answer is both. Cerbos evaluates the attributes of the agent and the delegating user together in a single policy check. An agent might have broad tool access, but the policy can restrict it based on the human's clearance level, the sensitivity of the resource being accessed, or the time of day. This is ABAC applied to non-human identities, and it prevents the standing privilege problem that makes agent security difficult. The same pattern applies to microservice-to-microservice calls, CI/CD pipelines, and any other non-human caller. Roles alone can't capture the context of what a service is doing, on behalf of whom, and under what conditions. Attribute-based policies can. [Dynamic authorization for AI agents: a guide to fine-grained permissions in MCP servers ](https://www.cerbos.dev/blog/dynamic-authorization-for-ai-agents-guide-to-fine-grained-permissions-mcp-servers) [Guardrails for AI agents](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security) ## Explore ABAC further - [Resource policies documentation](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html) — Comprehensive guide on implementing policies with Cerbos - [Conditions documentation](https://docs.cerbos.dev/cerbos/latest/policies/conditions.html) — Find out how to implement conditions in policies - [Key components of ABAC](https://www.cerbos.dev/blog/abac) — Find out more in this blog post - [Community discussions on ABAC](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Join the conversation and learn from the experiences of other Cerbos users --- title: "Zero Trust security" description: "Adopt a security model that assumes breach and verifies every request." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/zero-trust-security" source: "https://www.cerbos.dev/features-benefits-and-use-cases/zero-trust-security" --- # Zero Trust security Adopt a security model that assumes breach and verifies every request. ## What is Zero Trust? Zero Trust is not just a security model; it's a strategic approach to cybersecurity that operates on the principle of "never trust, always verify." It shifts the focus from traditional perimeter-based security models to one that continuously authenticates and authorizes every access request, regardless of its origin. At its core, Zero Trust relies on three foundational principles: verify explicitly, enforce least privilege access, and assume breach. This approach ensures that security is integrated into the design process, making it an inherent part of the IT management and development lifecycle. ### Zero Trust with Cerbos Cerbos streamlines the integration of roles, permissions, and access control mechanisms, crucial for implementing a Zero Trust architecture. Whether in monolithic systems or microservices, Cerbos simplifies and secures authorization across different parts of your tech stack. It differentiates between authentication (AuthN) and authorization (AuthZ), focusing on the latter to control permissions within the system dynamically. - **Flexibility and scalability:** Easily adapts to organizational growth and the evolving complexity of roles and permissions. - **Granular control:** Fine-grained authorization controls facilitate implementing least privilege access, a key Zero Trust principle. - **Unified authorization layer:** Across monolithic and microservice architectures, ensuring consistent and secure access control. - **DevOps integration:** Manage policies with standard software development tools, enhancing agility and security by design. - **Stateless and scalable:** Designed to fit into various deployment models, be it on-prem or in the cloud, using Kubernetes or bare-metal installations, ensuring high performance and scalability. ### Implementing Zero Trust Cerbos centralizes authorization decisions, making them accessible across your environment—from backend services to frontend applications. With YAML policies and Google's Common Expression Language (CEL), Cerbos offers a clear, human-readable format for complex authorization logic. This not only makes authorization transparent and testable but also decouples it from core application code, aligning with DevOps practices for policy management. ## Explore Zero Trust further - [Cerbos: Why and what](https://www.cerbos.dev/blog/cerbos-why-and-what) — Learn how Cerbos can help you solve your authorization headache - [Importance of data security for startups](https://www.cerbos.dev/blog/the-importance-of-data-security-for-startups) — Startups are being exposed to increasing cyber threats, learn how to safeguard your business - [Community discussions on Zero Trust](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Join the conversation and share experiences with other Cerbos users --- title: "Testable authorization with Cerbos" description: "Ensure the accuracy and reliability of your authorization policies. With Cerbos, get real-time feedback, continuous testing, and a collaborative IDE for a seamless and confident policy development experience." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/testable-authorization" source: "https://www.cerbos.dev/features-benefits-and-use-cases/testable-authorization" --- # Testable authorization with Cerbos Ensure the accuracy and reliability of your authorization policies. With Cerbos, get real-time feedback, continuous testing, and a collaborative IDE for a seamless and confident policy development experience. ## The importance of testable authorization Authorization policies are critical to the security and functionality of applications. Errors can lead to unauthorized access or hinder legitimate users. Testable authorization ensures that policies work as intended, providing a safety net against potential oversights and vulnerabilities. ### Real-time feedback, continuous testing, and collaborative development - **Instant feedback loop:** As you draft or modify policies, get immediate feedback, ensuring that errors are caught and rectified on the spot. - **Continuous testing with Cerbos Hub:** Benefit from Cerbos Hub's automated testing capabilities, ensuring that your policies are always in their best shape. - **Collaborative IDE:** Cerbos Hub's collaborative online IDE allows teams to develop, iterate, and test policies together, fostering a unified approach to authorization. - **GitOps workflow integration:** Seamlessly integrate your authorization policy development with your git-based workflow, ensuring consistency and reliability. - **Troubleshooting made easy:** With real-time feedback and testing, troubleshooting becomes a breeze, even during the development phase. - **Policy Playground:** A dedicated environment to experiment, test, and understand the impact of policy changes, ensuring that you're always confident in your deployments. ### Sample test suite for a Cerbos policy ```yaml expected: - resource: document#1 principal: user#1 actions: create: EFFECT_ALLOW read: EFFECT_ALLOW update: EFFECT_ALLOW delete: EFFECT_DENY - resource: document#1 principal: admin#2 actions: create: EFFECT_ALLOW read: EFFECT_ALLOW update: EFFECT_ALLOW delete: EFFECT_ALLOW ``` Create detailed test suites for each of your types of users and resources and define the expected decision for each action. These tests can run on every change to policy to ensure expected results. ## Master testable authorization with Cerbos - [Testing documentation](https://docs.cerbos.dev/cerbos/latest/policies/compile.html) — A detailed guide on leveraging Cerbos' testing capabilities for robust authorization policies - [GitOps guide](https://www.cerbos.dev/blog/why-using-gitops-for-authorization-and-access-control-is-a-good-idea) — Why using GitOps for authorization and access control is a good idea - [Cerbos Hub Playground policy testing](https://www.cerbos.dev/news/new-tools-for-effortless-policy-creation-and-testing-in-cerbos-hub) — Dive into the new features that further simplify how developers write, test, and iterate on authorization policies. Updates include the RBAC policy generator, API request simulator, and connecting a local PDP. - [How BarrierSystems took advantage of policy testing](https://www.cerbos.dev/customers/barriersystems) — Learn how our customer used policy testing to achieve faster time to market and improved customer experience - [Community tips on testing policies](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to learn best practices and innovative testing strategies --- title: "Simplified policy testing and distribution" description: "A fully managed pipeline for validating, testing and rolling out policy updates." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/simplified-policy-testing-and-distribution" source: "https://www.cerbos.dev/features-benefits-and-use-cases/simplified-policy-testing-and-distribution" --- # Simplified policy testing and distribution A fully managed pipeline for validating, testing and rolling out policy updates. ## What is a managed CI pipeline? Managing and testing policies can be a daunting task, especially when ensuring they are consistently applied across various platforms. Cerbos Hub is designed to alleviate these challenges by providing a managed CI pipeline that simplifies policy testing and distribution. With Cerbos Hub, you get all the robust capabilities of the Cerbos Policy Decision Point (PDP) without the complexities of manual setups and distributions. ### Simplify policy testing and distribution with Cerbos - **Managed CI Pipeline:** Forget the hassles of setting up and managing your CI pipeline. Cerbos Hub takes care of it, ensuring efficient policy testing and distribution. - **Policies in your control:** While Cerbos Hub manages the pipeline, your policies remain in your GitHub repo, giving you full control and easy accessibility. - **Seamless integration:** Cerbos Hub is designed to work in harmony with Cerbos PDP, ensuring that your policies are consistently and effectively applied. ### Demonstration ![simplified policy screenshot](/assets/simplified-policy-screenshot.webp) Maximize your policy management efficiency with Cerbos Hub, ensuring streamlined testing and distribution while retaining full control. ## Links to resources - [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub) — Discover all the features and capabilities of Cerbos Hub - [Documentation](https://docs.cerbos.dev/cerbos-hub) — Get started with Cerbos Hub - [GitOps & CI/CD](https://www.cerbos.dev/features-benefits-and-use-cases/gitops-and-ci-cd) — Learn more about Cerbos' reliable, testable, and streamlined policy deployments - [Testable authorization](https://www.cerbos.dev/features-benefits-and-use-cases/testable-authorization) — Ensure the accuracy and reliability of your authorization policies - [Testing policies](https://docs.cerbos.dev/cerbos/latest/tutorial/04_testing-policies.html) — Tutorial - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on policy testing and distribution --- title: "Align with top-tier security standards using Cerbos" description: "Ensure you are able to easily demonstrate your compliance with international security standards through Cerbos' policies and audit logs." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/security-standards" source: "https://www.cerbos.dev/features-benefits-and-use-cases/security-standards" --- # Align with top-tier security standards using Cerbos Ensure you are able to easily demonstrate your compliance with international security standards through Cerbos' policies and audit logs. ## The imperative of security standards in today's digital landscape In an era where data breaches and cyber threats are rampant, adhering to recognized security standards isn't just a best practice—it's a necessity. These standards, such as HIPAA, GDPR, SOC2, PCI DSS, ISO27001, and CCPA are designed to safeguard sensitive information and ensure that organizations maintain a robust security posture. Non-compliance can lead to hefty fines, reputational damage, and loss of customer trust. A component of adhering to these standards is rigorous access control, which can be handled thorough Cerbos' policies and audit logs. ### Demonstration of access control compliance ```json { "timestamp": "2023-01-05T15:51:13.150492178Z", "requestId": "01GP1A25FW6BVX9JWYM9M6T0Z0", "principal": { "id": "sally", "roles": ["USER"], "attr": { "region": "EMEA", "department": "SALES" } }, "resource": { "kind": "expense", "id": "expense1", "attr": { "status": "PENDING", "amount": "40", "region": "EMEA", "vendor": "Expense 1", "approvedBy": "frank", "createdAt": "2023-01-03T15:45:55.461Z", "ownerId": "sally" } }, "action": "view", "effect": "EFFECT_ALLOW", "policy": "resource.expense.vdefault", "effectiveDerivedRoles": ["OWNER"] } ``` This sample log entry indicates that user "sally" was allowed to view "expense1" based on the expense resource policy (default version). These logs are a critical part of ensuring your compliance when it comes to access control. ## Achieve and maintain access control compliance with Cerbos - [Audit logs documentation](https://docs.cerbos.dev/cerbos/latest/configuration/audit) — Understand the intricacies of setting up and managing audit logs with Cerbos - [Staying compliant – What you need to know](https://www.cerbos.dev/blog/staying-compliant) — Understand the key elements of compliance that should be prioritized - [More on audit logs](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) — Discover the importance of audit logs, and Cerbos' audit log capabilities - [Importance of data security](https://www.cerbos.dev/blog/the-importance-of-data-security-for-startups) — Mitigate risks and cultivate trust among customers - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with peers and learn from their experiences on audit logging and access control compliance with Cerbos --- title: "Boundless scalability for modern authorization" description: "Empower your enterprise with Cerbos - a solution designed to grow with you, ensuring robust authorization from day one and beyond." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/scalability" source: "https://www.cerbos.dev/features-benefits-and-use-cases/scalability" --- # Boundless scalability for modern authorization Empower your enterprise with Cerbos - a solution designed to grow with you, ensuring robust authorization from day one and beyond. ## Why scalability matters in authorization Authorization is in the blocking path of every request to an application. Unlike authentication which can be cached for a time period, authorization needs to be evaluated on every call. Having an authorization layer which can scale up in both volume and complexity is key to ensure you don't run into any bottlenecks as your user base grows. ### Built for growth, engineered for performance - **Stateless design:** Cerbos' stateless nature ensures rapid decision-making based on the latest data, eliminating concerns about application state synchronization or network delays. - **Flexible deployment models:** Whether you prefer serverless functions, a sidecar model, or traditional container deployments, Cerbos fits right in, offering unmatched scalability. - **Separation of concerns:** By decoupling authorization from core application code, Cerbos ensures that your authorization logic remains scalable, secure, and adaptable, even as your application evolves. - **Shared or dedicated:** Choose between a shared service model where Cerbos serves multiple services or a dedicated sidecar model running alongside your application, catering to your specific scalability needs. - **Container-ready:** Cerbos is designed to run anywhere a container can, ensuring you can scale across any environment or platform. - **Enterprise-ready:** From startups to large enterprises, Cerbos is engineered to handle the demands of any business size, ensuring robust authorization from the get-go. ## Master scalability with Cerbos - [Sample deployment](https://docs.cerbos.dev/cerbos/latest/deployment/) — Scaling with Cerbos - [Where to implement authorization in your architecture](https://www.youtube.com/watch?v=03XgWf_7dzI) — Find out more in the following video - [Scalable authorization](https://www.cerbos.dev/blog/website-planet-how-cerbos-helps-developers-scale-authorization-faster-cheaply-q-a-with-emre-baran) — How Cerbos helps devs scale authorization faster & cheaply - [Empower enterprise organizations](https://www.cerbos.dev/features-benefits-and-use-cases/support-enterprise-organizations) — Navigate the intricate maze of enterprise structures with Cerbos' powerful and intuitive policies - [Deployment models](https://www.cerbos.dev/features-benefits-and-use-cases/flexible-deployment-models) — Maximize efficiency and responsiveness with Cerbos' adaptable deployment models - [Stateless authorization](https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization) — Ensure real-time access decisions without the overhead of managing application states - [Where to implement authorization in your architecture](https://youtu.be/03XgWf_7dzI) — Find out more in the following video - [How do we distribute Cerbos](https://youtu.be/Rvw0DTTQmSw) — Find out more in the following video - [Community insights](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community for insights, tips, and real-world scalability use cases --- title: "Your data never leaves your environment" description: "With Cerbos, your data never leaves your environment, giving you complete control and peace of mind." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/private-by-design" source: "https://www.cerbos.dev/features-benefits-and-use-cases/private-by-design" --- # Your data never leaves your environment With Cerbos, your data never leaves your environment, giving you complete control and peace of mind. ## Private by design Cerbos Policy Decision Points run along side your application service - be it inside your kubernetes cluster, as a service inside your VPC or right on the VM running your application on-premise. Every authorization check is evaluated locally and no data is sent out over the internet. ### Complete control over your data - **In-environment operation:** Cerbos runs entirely within your environment, ensuring no data leakage. - **No external dependencies:** All processing and decision-making happen locally, eliminating the need for external calls that might compromise data. - **Full data ownership:** Your data never leaves your perimeter, ensuring you remain the sole custodian. - **Compliance ready:** By retaining data within your boundaries, comply with stringent data protection regulations with ease. Cerbos is designed with data protection at its core. By operating solely within your environment and avoiding external dependencies, Cerbos ensures that your data remains yours, always. This not only provides security but also ensures compliance with global data protection standards. ## Deep dive into resources - [Documentation](https://docs.cerbos.dev/cerbos/latest/deployment/index.html) — Cerbos deployment models - [Staying compliant – What you need to know](https://www.cerbos.dev/blog/staying-compliant) — Understand the key elements of compliance that should be prioritized - [Where to implement authorization in your architecture](https://youtu.be/03XgWf_7dzI) — Find out more in the following video - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on keeping data private --- title: "No cloud or vendor lock-in with Cerbos" description: "Maintain full control over your authorization processes. Deploy on any platform, ensuring independence and adaptability." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/no-cloud-vendor-lock-in" source: "https://www.cerbos.dev/features-benefits-and-use-cases/no-cloud-vendor-lock-in" --- # No cloud or vendor lock-in with Cerbos Maintain full control over your authorization processes. Deploy on any platform, ensuring independence and adaptability. ## Why avoiding lock-in matters Being tied to a specific cloud provider or vendor can limit flexibility, increase costs, and make migrations challenging. By avoiding lock-in, organizations can choose the best tools for their needs, negotiate better pricing, and ensure long-term adaptability. ### Freedom, flexibility and control - **Platform agnostic:** Deploy Cerbos on public/private/hybrid clouds, serverless platforms, or even your data center. - **Migration ease:** Transition between platforms or vendors without the challenges of proprietary systems. - **Future-proofing:** As technology landscapes evolve, ensure that your authorization system remains adaptable. - **Full control:** Maintain 100% control within your perimeter, ensuring security and compliance on your terms. ## Maximize flexibility with Cerbos - [Deployment models](https://www.cerbos.dev/features-benefits-and-use-cases/ecosystem) — Cerbos is stateless and runs anywhere a container or a binary can be launched, including common deployment models - [How Cerbos works](https://www.youtube.com/watch?v=_bF4JjUMJkY) — Find out more in the following video - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on avoiding cloud/vendor lock-in --- title: "Human-readable authorization with Cerbos" description: "Empower your teams with Cerbos' low-code, human-readable configuration. Implement and adapt policies with clarity and ease." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/human-readable-authorization" source: "https://www.cerbos.dev/features-benefits-and-use-cases/human-readable-authorization" --- # Human-readable authorization with Cerbos Empower your teams with Cerbos' low-code, human-readable configuration. Implement and adapt policies with clarity and ease. ## What is human-readable authorization In the complex world of authorization, understanding and managing policies can become a daunting task. Human-readable authorization simplifies this by representing policies in a format that is intuitive and easy to understand, eliminating the need for intricate coding or deep technical knowledge. ### Simplicity, transparency and collaboration - **Configuration over coding:** Implement and modify authorization policies without delving deep into the application code, ensuring a faster and error-free process. - **Clear and intuitive:** With simple YAML policies, understanding and crafting policies becomes a breeze, even for non-technical stakeholders. - **Enhanced collaboration:** The clarity of human-readable policies fosters better team collaboration, ensuring everyone is on the same page. - **Audit with ease:** The transparent nature of human-readable policies simplifies the audit process, making it easier for security teams to review and validate policies. - **Extensive documentation:** Benefit from clear documentation ensuring a smooth integration process. ### Sample human-readable policy ```yaml apiVersion: api.cerbos.dev/v1 resourcePolicy: resource: document version: default rules: - actions: - create effect: EFFECT_ALLOW roles: - admin - actions: - read effect: EFFECT_ALLOW roles: - user - admin ``` This YAML snippet showcases the simplicity and clarity of human-readable policies, making it easy to understand which actions are possible on a resource and under what conditions. ## Master authorization with Cerbos - [Human-readable policy documentation](https://docs.cerbos.dev/cerbos/latest/policies/) — Dive deep into crafting and managing policies with our comprehensive guide - [Documentation](https://docs.cerbos.dev/cerbos/latest/what-is-cerbos.html#_policy_as_code) — Policy as code - [Community insights](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share and learn best practices for human-readable authorization --- title: "Authorize anywhere with Cerbos Hub" description: "With the power of WebAssembly, empower your authorization with on-device and edge capabilities." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/embed-anywhere" source: "https://www.cerbos.dev/features-benefits-and-use-cases/embed-anywhere" --- # Authorize anywhere with Cerbos Hub With the power of WebAssembly, empower your authorization with on-device and edge capabilities. ## Flexibility and adaptability With today's variety of deployment models, the need for flexible and adaptable authorization mechanisms is paramount. Cerbos Hub enables running authorization not only as a service in your infrastructure, but also on device or at the edge. By generating a WASM module from your policy on every change, Cerbos Hub enables decisions to be made in any number of environments leading to faster response times, reduced server loads, and enhanced user experiences. ### Advantages of embedding Cerbos Hub - **WebAssembly integration:** By leveraging WebAssembly, Cerbos Hub ensures that your authorization policies are lightweight, fast, and universally compatible across various platforms and devices. - **On-device authorization:** Enhance security and reduce latency by processing authorization decisions directly on the user's device. - **At-edge authorization:** Distribute your authorization logic closer to the user by embedding it at the edge, ensuring rapid response times and reduced central server loads. - **Consistency:** As Cerbos Hub distributes policies for both the Policy Decision Points (PDPs) and the WebAssembly modules - any changes to policy is reflected everywhere with no extra work. ## Links to resources - [Learn more](https://www.cerbos.dev/product-cerbos-hub) — Discover all the features and capabilities of Cerbos Hub - [Documentation](https://docs.cerbos.dev/cerbos-hub) — Get started with Cerbos Hub - [Documentation](https://docs.cerbos.dev/cerbos-hub/decision-points-embedded) — Embedding Cerbos Hub - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on deployment models --- title: "Decoupled authorization with Cerbos" description: "Escape the chaos of intertwined authorization logic. Empower developers to focus on what truly matters: delivering exceptional products. Simplify, secure, and save with Cerbos." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/decoupled-authorization" source: "https://www.cerbos.dev/features-benefits-and-use-cases/decoupled-authorization" --- # Decoupled authorization with Cerbos Escape the chaos of intertwined authorization logic. Empower developers to focus on what truly matters: delivering exceptional products. Simplify, secure, and save with Cerbos. ## The perils of embedded authorization When authorization logic is deeply embedded within core application code, it becomes a ticking time bomb. As applications evolve, intertwined authorization doesn't just lead to technical challenges. It diverts valuable developer time and resources away from product innovation: - **Confusion:** Overlapping permissions and roles create a maze that's hard to navigate. - **Security risks:** Unintended access and data breaches due to overlooked or misconfigured permissions. - **Development delays:** Developers spend weeks, if not months, untangling and fixing authorization issues. - **Cost overruns:** Time spent fixing these issues translates to increased costs and delayed product releases. - **Lost innovation time:** Every hour spent untangling authorization is an hour not spent on feature development, user experience improvements, or innovation. - **Delayed releases:** Complex authorization issues can push back release dates, affecting product roadmaps and market positioning. - **Reduced developer morale:** Constantly firefighting tangled authorization issues can demotivate developers, reducing their job satisfaction and productivity. [#F9FAFB] ## Reclaim control, clarity, and cost-efficiency with Cerbos Cerbos simplifies authorization, restoring clarity and control to development teams. This streamlined approach cuts development delays and reduces security risks, saving costs. With Cerbos, you accelerate from ideation to market, gaining a competitive edge. - **Clear separation:** By decoupling authorization from your core application code, Cerbos ensures clarity and reduces complexity. - **Agile:** Easily adapt and scale your authorization logic without touching the core application, ensuring flexibility and robustness. - **Reduced security risks:** Minimize the chances of unintended access and data breaches with a dedicated authorization layer. - **Time & cost savings:** Reduce development delays and associated costs. Let your team focus on core functionalities while Cerbos handles authorization. - **Streamlined operations:** With Cerbos, product, security and development teams can easily collaborate, ensuring that authorization policies align with business needs without compromising security. - **Clear focus on product development:** By handling authorization outside the core code, developers can channel their energy and creativity into building standout features and improving user experience. - **Faster time-to-market:** With a dedicated authorization layer, product updates and new features can be rolled out more swiftly, keeping you ahead of the competition. [bg] ## Master decoupled authorization with Cerbos - [What is decoupled authorization](https://www.youtube.com/watch?v=ngr8VeO7AMk) — Learn more in our explainer video - [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) — A 10-step roadmap for adopting externalized AuthZ with practical frameworks and policy examples - [No to hard coding access controls](https://www.cerbos.dev/blog/badly-designed-authorization-is-technical-debt) — Learn why badly designed authorization is technical debt - [Scalable authorization](https://www.cerbos.dev/blog/designing-an-authorization-model-that-scales-with-your-business) — Why authorization rules have to evolve with the business needs - [Cerbos demo](https://www.cerbos.dev/blog/cloud-native-live-modernizing-authorization) — Modernizing authorization, from basic roles to decoupled ABAC - [Contributor podcast](https://www.cerbos.dev/blog/contributor-podcast-decoupling-authorization) — Decoupling authorization - [The technical complexities of decoupled authorization](https://www.cerbos.dev/blog/technical-complexities-of-decoupled-authorization) — Decoupled authorization can add new technical challenges that aren’t always apparent at the start of a project. Explore useful strategies for avoiding pitfalls - [Authentication vs authorization](https://www.cerbos.dev/blog/authentication-vs-authorization) — Discover the differences and the value of each solution - [AuthN vs Authz](https://youtu.be/v9aqaw5G_vo?feature=shared) — Find out more about authentication and authorization in the following video - [Where to implement authorization in your architecture](https://youtu.be/03XgWf_7dzI) — Find out more in the following video - [How do we distribute Cerbos](https://youtu.be/Rvw0DTTQmSw) — Find out more in the following video - [Community insights](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community, learning from real-world scenarios and solutions --- title: "Coordinated rollout and monitoring" description: "Seamlessly coordinate, rollout, and monitor your authorization policies with Cerbos Hub." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/coordinated-rollout-and-monitoring" source: "https://www.cerbos.dev/features-benefits-and-use-cases/coordinated-rollout-and-monitoring" --- # Coordinated rollout and monitoring Seamlessly coordinate, rollout, and monitor your authorization policies with Cerbos Hub. ## What is coordinated rollout and monitoring? In a dynamic environment, ensuring that all your policies are consistently applied and monitored in is crucial. Coordinated rollout and monitoring is all about pushing real-time policy changes proactively and keeping track of them. With Cerbos Hub, you can centralize your policy management, ensuring that all Policy Decision Points (PDPs) receive the latest policy updates in real-time. This not only streamlines the rollout process but also ensures that your policies are consistently applied across the board. ### Coordinated rollout and monitoring with Cerbos - **Centralized management:** Manage all your policies from a single point, ensuring consistency and reducing the chances of errors. - **Real-time policy push:** No more waiting or manual updates. Cerbos Hub pushes policy changes proactively to all PDPs, ensuring immediate application. - **Insightful monitoring:** Track active policies, their versions, and more. Know at a glance which policies are active and where. - **Synchronized PDPs:** Ensure all your PDPs are in sync and up-to-date, reducing the risk of policy mismatches or outdated rules. ### Demonstration ![coordinated rollout screenshot](/assets/coordinated-rollout-screenshot.jpeg) Empower your team with Cerbos Hub's coordinated rollout and monitoring, ensuring that your policies are always up-to-date and consistently applied. ## Links to resources - [Coordinated rollout documentation](https://docs.cerbos.dev/cerbos-hub/ci-cd) — Learn more - [Cerbos Hub features and capabilities](https://www.cerbos.dev/product-cerbos-hub) — Discover by clicking here - [Cerbos Hub documentation](https://docs.cerbos.dev/cerbos-hub) — Get started with Cerbos Hub now - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on coordinated rollout and monitoring --- title: "Centralized management" description: "Unify your authorization strategy in one central hub." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/centralized-management" source: "https://www.cerbos.dev/features-benefits-and-use-cases/centralized-management" --- # Centralized management Unify your authorization strategy in one central hub. ## What is centralized management in authorization? As applications grow and diversify, managing an authorization can become a complex challenge. Cerbos Hub's centralized management feature provides a unified platform where developers and product teams can collaboratively author, iterate, and manage authorization policies. This ensures that authorization logic remains consistent, transparent, and adaptable across all applications, regardless of their scale or complexity. ### Cerbos Hub's centralized management - **Collaborative platform:** A unified space where developers and product teams can seamlessly collaborate on authorization policies, ensuring alignment and clarity. - **Iterative development:** Easily make updates, test changes, and refine your policies in real-time, without disrupting the user experience. - **Consistent authorization:** By centralizing policy management, Cerbos Hub ensures that all applications adhere to the same authorization standards, minimizing discrepancies and potential errors. ### Demonstration ![centralized management screenshot](/assets/centralized-management-screenshot.webp) Harness the power of centralized management with Cerbos Hub and ensure a streamlined, consistent, and error-free authorization experience across all your applications. ## Links to resources - [Cerbos Hub](https://www.cerbos.dev/product-cerbos-hub) — Discover all the features and capabilities of Cerbos Hub - [Documentation](https://docs.cerbos.dev/cerbos-hub) — Get started with Cerbos Hub - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community to share experiences and insights on centralized management --- title: "Authorize anywhere with Cerbos Hub" description: "With the power of WebAssembly, empower your authorization with on-device and edge capabilities." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/authorize-anywhere" source: "https://www.cerbos.dev/features-benefits-and-use-cases/authorize-anywhere" --- # Authorize anywhere with Cerbos Hub With the power of WebAssembly, empower your authorization with on-device and edge capabilities. ## Flexibility and adaptability With today's variety of deployment models, the need for flexible and adaptable authorization mechanisms is paramount. Cerbos Hub enables running authorization not only as a service in your infrastructure, but also on client devices or at the edge. By generating a WASM module from your policy on every change, Cerbos Hub enables decisions to be made in any number of environments leading to faster response times, reduced server loads, and enhanced user experiences. ## Advantages of embedding Cerbos Hub * WebAssembly runtime: By leveraging WebAssembly, Cerbos Hub ensures that your authorization policies are lightweight, fast, and universally compatible across various platforms and devices. * On-device authorization: Enhance security and reduce latency by processing authorization decisions directly on the user's device. * At-edge authorization: Distribute your authorization logic closer to the user by embedding it at the edge, ensuring rapid response times and reduced central server loads. * Consistency: As Cerbos Hub distributes policies for both the Policy Decision Points (PDPs) and the WebAssembly modules - any changes to policy are reflected everywhere with no extra work. * Scalability: Effortlessly scale your authorization system as your application grows, without the need for running extra infrastrcutrue. * Performance: Local authorization decisions without having to roundtrip to the backend, enhancing the overall performance and responsiveness of your application. ## Master authorization with Cerbos - [Stateless authorization](https://www.cerbos.dev/features-benefits-and-use-cases/stateless-authorization) — Ensure real-time access decisions without the overhead of managing application states. - [How do we distribute Cerbos](https://youtu.be/Rvw0DTTQmSw) — Find out more in the following video. - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community for insights and tips on authorization. --- title: "Illuminate your authorization with advanced observability" description: "Gain unparalleled insights into your authorization processes with Cerbos, ensuring transparency, efficiency, and security at every step." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/advanced-observability" source: "https://www.cerbos.dev/features-benefits-and-use-cases/advanced-observability" --- # Illuminate your authorization with advanced observability Gain unparalleled insights into your authorization processes with Cerbos, ensuring transparency, efficiency, and security at every step. ## The power of observability in authorization Observability isn't just about monitoring; it's about understanding the "why" behind the data. In the context of authorization, observability provides insights into how decisions are made, where bottlenecks might exist, and how to optimize for performance and security. ### Shine a light on every aspect of your authorization - **Tracing & metrics:** Cerbos supports OpenTelemetry tracing and Prometheus for metrics to provide you with insight into every step of the authorization process. - **Detailed logging:** Dive deep into every decision with comprehensive logs which can be sent to SIEM tools such as DataDog, Elastic and others, helping you understand the "why" and "how" behind each authorization. - **Performance metrics:** Identify bottlenecks, optimize processes, and ensure your authorization system runs at peak efficiency. ## Master observability with Cerbos - [Audit logging](https://docs.cerbos.dev/cerbos/latest/configuration/audit) — Maximize the insights and security of your observability setup - [Metrics](https://docs.cerbos.dev/cerbos/latest/configuration/server#_metrics) — Obtain insights into how your Cerbos instances are running - [Demo](https://www.cerbos.dev/blog/cncf-webinar-cloud-native-application-authorization) — See how Cerbos works with a cloud native monitoring infrastructure - [How do we distribute Cerbos](https://youtu.be/Rvw0DTTQmSw) — Find out more in the following video - [Cerbos PDP dashboard on Grafana Cloud](https://www.cerbos.dev/blog/cerbos-pdp-dashboard-on-grafana-cloud) — Quickly answer operational questions: is the fleet up, is it keeping up with traffic, is it on the current policy - [Community discussions](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community for insights, tips, and real-world use cases on observability --- title: "Empower enterprise organizations with Cerbos" description: "Navigate the intricate maze of enterprise structures, from departments to global geographies, with Cerbos' powerful and intuitive policies." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/support-enterprise-organizations" source: "https://www.cerbos.dev/features-benefits-and-use-cases/support-enterprise-organizations" --- # Empower enterprise organizations with Cerbos Navigate the intricate maze of enterprise structures, from departments to global geographies, with Cerbos' powerful and intuitive policies. ## Understanding enterprise organizational complexity Enterprises are multifaceted entities, often spanning multiple geographies, departments, and hierarchies. Managing access controls in such a diverse environment requires a solution that's both flexible and robust. Cerbos provides the tools to craft policies that mirror the intricate realities of enterprise organizations, ensuring precise and secure access controls. ### Crafting tailored enterprise experiences - **Reflect organizational realities:** Design access controls that mirror the intricate structures of departments, offices, and global geographies. - **Empower internal teams:** Offer controlled access to support and product teams, ensuring they have the permissions they need across customers, departments, and regions. - **Auditable actions:** Maintain a comprehensive audit trail, capturing every policy decision, ensuring transparency and compliance. - **Dynamic role adaptability:** Derive roles based on context, ensuring flexibility beyond the confines of traditional identity providers. ### Designing enterprise policies with Cerbos Reflect the businesses' organizational hierarchy via Cerbos policy for fine-grained permissioning. ![scoped policies diagram](/assets/scoped-policies-diagram.svg) ## Master enterprise access with Cerbos - [Speak to a Cerbos engineer](https://meetings.hubspot.com/aandreasyan/cerbos-for-enterprise-organizations) — Book an intro call and learn more - [Scoped policies](https://docs.cerbos.dev/cerbos/latest/policies/scoped_policies.html) — Dive deep into the intricacies of enterprise access with Cerbos, ensuring you craft secure and tailored experiences - [Guide](https://www.cerbos.dev/blog/mapping-business-requirements-to-authorization-policy) — Mapping business requirements to authorization policy - [Community insights on enterprise access](https://community.cerbos.dev/?_gl=1*5ozo82*_ga*MTk1NjcwNzQ1MC4xNjY2Mjc5NjI2*_ga_8G3G3MS838*MTY5NDE5MTE5Ny41MjcuMS4xNjk0MTkyNzgyLjIwLjAuMA) — Engage with the Cerbos community, learning from real-world enterprise scenarios and solutions --- title: "Every decision, every action recorded" description: "Collect and collate records of every action, decision, and change across all your Policy Decision Point instances." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs" source: "https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs" --- # Every decision, every action recorded Collect and collate records of every action, decision, and change across all your Policy Decision Point instances. ## Easily manage and review all your logs Audit Logs enable enhanced security, easier compliance verification and faster debugging. Each Cerbos PDP instance records detailed audit logs for every decision made. When collected by Cerbos Hub, all the logs are centralized, making it easy to manage and analyze them from a single pane. Speed up your workflow with two types of logs: - **Decision logs** — track authorization checks, showing who tried to do what and whether they were allowed or denied. Decision logs include details about decision lineage, which are vital for compliance checks and security investigations. - **Access logs** — keep chronological records of API requests and their sources. They help debug PDPs, and ensure you meet security standards in your application. ## See Audit Logs in action with Cerbos PDP This sample log entry indicates that user "sally" was allowed to view "expense1" based on the expense resource policy (default version). It’s really that simple. ```json { "timestamp": "2023-01-05T15:51:13.150492178Z", "requestId": "01GP1A25FW6BVX9JWYM9M6T0Z0", "principal": { "id": "sally", "roles": ["USER"], "attr": { "region": "EMEA", "department": "SALES" } }, "resource": { "kind": "expense", "id": "expense1", "attr": { "status": "PENDING", "amount": "40", "region": "EMEA", "vendor": "Expense 1", "approvedBy": "frank", "createdAt": "2023-01-03T15:45:55.461Z", "ownerId": "sally" } }, "action": "view", "effect": "EFFECT_ALLOW", "policy": "resource.expense.vdefault", "effectiveDerivedRoles": ["OWNER"] } ``` ## Audit logs in Cerbos Hub Cerbos Hub brings all Logs together in one unified view, making it easier to troubleshoot and giving teams more control over managing authorization. So you retain control over all your permissions. ## Audit Logs for security engineers, PMs, developers - **Security engineers** — Track user activities, investigate potential breaches, and meet compliance requirements. - **Product managers** — Quickly diagnose access issues, understand user behavior, and make data-driven decisions. - **Developers** — Ensure the reliability of your authorization policies with built-in testing capabilities. --- title: "Dynamic policy management at scale" description: "Programmatic policy management with Cerbos Hub: create, update and deploy authorization policies through an API rather than by hand." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-policies" source: "https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-policies" --- # Dynamic policy management at scale Automate your policy lifecycle: create, update, and deploy policies programmatically to save engineering hours and accelerate releases. ## Automate your policy management with Cerbos Hub - **Policy-as-API** — Full programmatic CRUD operations on access control policies via a robust new API and updated SDKs. - **Validated builds** — Every change is compiled and tested against your policy test suite before deployment. - **Instant bundled deployment** — Updates are pushed to all PDPs immediately. - **No custom infrastructure** — Skip building and scaling your own policy database, reloads, or test pipelines. Cerbos Hub handles it all. - **Full traceability** — Track every API policy change, deployed bundle, and PDP decision with a complete audit log and version history. ## End-to-end programmatic policies 1. **Provision a Policy Store** — Set up a dedicated Policy Store in Cerbos Hub to manage policies programmatically via API. 2. **Integrate via API or SDKs** — Programmatically create, update, or delete policies in Policy Stores, triggered by any system or event. 3. **Auto-build, test, and deploy** — Each change is validated, tested, and deployed to all connected PDPs instantly. 4. **Audit everything** — Log every authorization action in versioned audit logs and track programmatic policy activity. ## The policy management platform for modern teams - **Faster policy rollout** — Deliver validated policy changes across all environments in seconds. - **Reduce operational overhead** — Offload policy storage, reloads, and testing to Cerbos Hub. - **Improve reliability** — Deploy policy updates atomically and synchronously across all PDPs. ## Integrate with your stack in minutes - SDKs - Deployment models - Integrations ## Master dynamic policy management Demo: build dynamic policies and integrate with your systems. [Watch the demo](https://www.youtube.com/watch?v=vvfHTUFcwPM) - **Webinar on managing permissions with code** — Programmatic policy management for complex systems. - [Policy Store key concepts and best practices](https://docs.cerbos.dev/cerbos-hub/policy-stores) — Policy store essentials for dynamic policies. - [Documentation](https://docs.cerbos.dev/cerbos/latest/cli/cerbosctl.html) — Docs on Cerbos CLI for programmatic policy management. ## Learn more - [Advanced multi-tenant SaaS authorization with Cerbos](https://www.cerbos.dev/blog/multi-tenant-saas-authorization-role-policies-and-scoped-resource-policies) — Guide - [Authorization in developer workflows: best practices and tools](https://www.cerbos.dev/blog/authorization-in-workflows) — Guide - [Best IAM solutions for enterprises](https://www.cerbos.dev/blog/best-iam-solutions-for-enterprises) — Article --- title: "Personalized access control for every SaaS tenant" description: "Per-tenant authorization policy in multi-tenant SaaS: define and deploy policies for each tenant, customer or organizational unit from Cerbos Hub." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies" source: "https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies" --- # Personalized access control for every SaaS tenant Define and manage tenant specific policies dynamically for every tenant, customer, or organizational unit. ## Fine-grained, tenant specific authorization ### Enterprise ready tenant policies Allow your customers to define their roles and permissions, unlocking enterprise contracts with complex access requirements. - Set up, manage, and deploy tenant policies, fast and reliably. - Integrate policies from any Git provider, CI/CD, CLI, API, or direct UI uploads. - Use distinct Policy Stores for each tenant & groups of tenants to keep clean separation. - Isolate tenant specific logic from core policies & other tenant policies for safer changes. - Automate compilation, validation, testing, and deployment pipelines. [Learn more](https://docs.cerbos.dev/cerbos-hub/policy-stores) ### Realtime, tenant driven policy workflows Deliver dynamic, tenant specific logic instantly, without complex custom code or infrastructure. - Enable unique tenant roles and overrides via API driven Policy Stores. - Allow internal tools or customer portals to push tenant policy updates securely via API. - Combine static base policies with dynamic tenant rules in a single, versioned deployment. - Managed distribution of policy bundles to all PDPs, automatically. - Eliminate custom infrastructure for tenant policy management, saving engineering time and cost. [Talk to an engineer](https://www.cerbos.dev/workshop) ### Audit logs with full traceability Complete visibility into tenant specific access decisions for confident debugging, compliance, and audits - View active policies and version history for both core and tenant specific polices directly in Cerbos Hub. - Trace every authorization decision back to the exact policy version that enforced it. - Maintain structured, centralized logs to simplify audits and meet enterprise compliance requirements. [Talk to an engineer](https://www.cerbos.dev/workshop) ## Per tenant authorization with Cerbos Hub 1. **Create Policy Stores** — Define Policy Stores in Cerbos Hub. Organize policies by tenant, customer group, or specific feature set. 2. **Fill in your tenant policies** — Add tenant-specific policies via API, programmatically through Git & CI/CD, or with direct upload or CLI. 3. **Build unified deployment** — Build a single versioned deployment that merges tenant specific and base policies, automatically validated and tested. 4. **Automated distribution and audit** — Deploy validated policies to all PDPs automatically, with every change versioned. ## Works with your existing tools, workflows, and infrastructure - **Flexible policy sources** — Add tenant policies from any Git provider, any CI/CD tool, Cerbos Hub API, cerbosctl CLI, direct UI upload; no lock-in. - **SDKs for every stack** — Use updated SDKs for JS, Go, Python, Java, .NET, Rust, PHP, Ruby for programmatic policy management. - **Deployment targets** — Deploy to Cerbos PDPs in containers, serverless, edge, or multi region clusters. - **Compliance ready audit logs** — Ensure audit readiness for SOC2, HIPAA, ISO 27001, PCI DSS, and GDPR. ## Learn how to build tenant-specific authorization Demo: policy creation, deployment, and audit for multi-tenant SaaS. [Watch the demo](https://www.youtube.com/watch?v=dpUpQiy9Pjw) - [Playground for this demo](https://play.cerbos.dev/p/XhkOi82fFKk3YW60e2c806Yvm0trKEje?utm_campaign=hub_update_25&utm_source=playground_multi_tenant&utm_medium=email&utm_content=&utm_term=) — Prototype and play with policies for multi-tenant SaaS in your browser. - **Webinar on tenant-specific authorization** — On-demand webinar on multi-tenant authorization best practices. - [Policy Store key concepts and best practices](https://docs.cerbos.dev/cerbos-hub/policy-stores) — Policy store essentials for multi-tenant authorization. ## Centralized permission management for SaaS - **Enterprise flexibility** — Support tenant roles and dynamic policies at scale. - **Streamlined policy operations** — Replace custom workflows with automated deployments. - **Faster engineering delivery** — Programmatic updates, fast testing, and simplified policy management. - **No infra overhead** — Deliver dynamic tenant policies at scale without building and maintaining complex infrastructure. ## Learn more about tenant authorization - [A guide to multitenant authorization](https://solutions.cerbos.dev/guide-to-multitenant-authorization) — Ebook - [How to implement scalable multitenant authorization](https://www.cerbos.dev/blog/how-to-implement-scalable-multitenant-authorization) — Article - **Scaling authorization logic in a multitenant application** — Webinar - [How to implement resource-based authorization](https://www.cerbos.dev/blog/how-to-implement-resource-based-authorization) — Article - [Advanced multi-tenant SaaS authorization](https://www.cerbos.dev/blog/multi-tenant-saas-authorization-role-policies-and-scoped-resource-policies) — Guide - [Who owns authorization in a large engineering organization?](https://www.cerbos.dev/blog/who-owns-authorization-in-large-engineering-organization) — Article - [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) — Ebook - [ePDP Rules: Fine-grained control for embedded policy bundles](https://www.cerbos.dev/blog/epdp-rules-fine-grained-control-for-embedded-policy-bundles) — Article --- title: "Scalable NHI permission management" description: "Authorization for non-human identities — workloads, microservices, AI agents and API clients — with policy-driven access control across the whole architecture." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/authorization-non-human-identities" source: "https://www.cerbos.dev/features-benefits-and-use-cases/authorization-non-human-identities" --- # Scalable NHI permission management Secure every workload, microservice, AI agent, and API client in your architecture with policy-driven authorization ## Non-human identities are your hidden security risk - **The fastest-growing attack surface** — NHIs are fragmented, overprivileged, and invisible. Every workload becomes a backdoor for attackers. - **Compliance startswith machines** — Compliance requires auditable and enforceable access controls for both humans and machines. - **Overprivileged NHIs break Zero Trust** — Zero Trust model requires every request to be checked in every service. Blindly trusting microservices breaks this paradigm. - **AI multipliesNHI risk** — AI agents with no authorization controls expand the attack surface and increase the risk of data leaks. ## NHI permission management with Cerbos A centralized, scalable solution to implement consistent authorization policies for every identity across the entire architecture - **Issue identity** — Leverage an IdP to issue every workload a unique identity - **Set policies** — Set your user and service-level access policies - **Request access** — Cerbos evaluates each service request against policy and allows or denies access - **Audit** — Every request is captured along with the access decision and the policy that enforced it ## Manage access for every identity, human or machine - Workforce - Partners - Customers - Microservices - Workloads - API clients - AI agents - AI workflows - MCP servers ## Our approach to future-proof authorization ### Build your Workload IAM strategy Define, manage, and enforce access policies for all identity types: - Powerful ABAC, RBAC, and PBAC for your NHIs. - Full control over NHIs in cloud, on-prem, or hybrid environments. - Support Zero Trust with least privilege and continuous verification for every machine identity. - Seamless scalability and flexible run-time authorization. [Let's discuss your NHIs strategy](https://www.cerbos.dev/workshop) ### Handle authorization at the API gateway, in the service mesh, and microservices Prevent over-permissioned services with policy-based authorization, one policy engine for both user and service identities. - Enforce least privilege access control among services. - Secure service-to-service communication using NHIs tied to each microservice. - Implement a principal identity-based delegated authorization strategy. - Apply consistent authorization across cloud-native, containerized, and distributed environments. - Predictable performance at scale driven by the stateless architecture. [Talk to an engineer](https://www.cerbos.dev/workshop) ### Safeguard AI agents, MCP servers, and RAG AI agents are non-human identities that access systems autonomously, govern their action,s and control data access to prevent leakage, injection, and overreach. - Secure agentic workflows with centralized policies. - Dynamic, policy-driven prompt filtering to add additional layers of control. - Control what context an LLM is provided with permission-aware data filtering for vector stores. - Enhance RAG architectures using data restricted to the user's permissions. [Talk to an engineer](https://www.cerbos.dev/workshop) ### Get full visibility into NHI actions Centralized audit trails for all non-human identity access decisions across all your applications. Stay compliant with SOC2, ISO27001, HIPAA, PCI/DSS, and GDPR. - Capture every authorization check—across services, agents, and APIs—with structured logs that enable full traceability, compliance readiness, and forensic investigations. - Track which AI agent, API client, or workload accessed what, when, on behalf of whom, and which policy granted access, ensuring no identity operates unchecked. - Remove NHI compliance risks with full visibility into your workload’s actions [Talk to an engineer](https://www.cerbos.dev/workshop) ## Seamlessly fit into your tech stack - Machine identity providers - SDKs - Deployment models ## Why enterprises choose Cerbos - **Centralized policy management** — Unify your authorization strategy for all identity types in a central hub. - **Authorize anywhere** — Run your authorization logic anywhere, in your infrastructure or at the edge. - **Grows with your architecture** — Support evolving org structures, NHI growth, and complex access models. - **Full auditability** — Capture every request and decision in standardized audit logs. ## Learn more about NHIs - [Securing AI agents and non-human identities in enterprises](https://solutions.cerbos.dev/securing-ai-agents-non-human-identities-in-enterprises) — Ebook - **Fine-grained authorization for non-human identities** — Webinar - [Cerbos named a Sample Vendor for AuthZEN in the Gartner Hype Cycle for Digital Identity](https://www.cerbos.dev/blog/cerbos-named-sample-vendor-authzen-gartner-hype-cycle-for-digital-identity) — Announcement - [The ROI of NHI security](https://www.cerbos.dev/blog/roi-of-nhi-security-investing-in-machine-identity-protection-pays-off) — Article - [A CISO’s benchmark for authorization maturity](https://solutions.cerbos.dev/authorization-maturity-model-a-cisos-benchmark) — Ebook - [Dimmer switch: AI agent governance](https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance) — Article - [SPIFFE identity parsing added to Cerbos PDP](https://www.cerbos.dev/blog/spiffe-identity-parsing-cerbos-pdp) — Guide - [How to implement Cerbos for authorization of NHIs](https://www.cerbos.dev/blog/cerbos-for-non-human-identities) — Article - [How Utility Warehouse secured millions of NHIs with Cerbos](https://www.cerbos.dev/customers/utility-warehouse/non-human-identities) — Success story - [Understanding and addressing the OWASP top 10 threats](https://www.cerbos.dev/blog/safeguarding-non-human-identities-understanding-and-addressing-owasp-top-10-threats) — Article - [Securing cloud architectures in the age of NHIs and ephemeral services](https://www.cerbos.dev/news/securing-cloud-architectures-non-human-identities-ephemeral-services) — Article - [NHI security: How to manage non-human identities and AI agents](https://www.cerbos.dev/blog/nhi-security-how-to-manage-non-human-identities-and-ai-agents) — Article - **Securing agentic AI in production** — Webinar - [NHI management still has a blind spot](https://www.cerbos.dev/blog/non-human-identity-management-has-a-blind-spot) — Article - [Multi-hop delegation for AI agents, explained](https://www.cerbos.dev/blog/multi-hop-delegation-ai-agents) — Article - [Best AI agent security and governance tools](https://www.cerbos.dev/blog/best-ai-agent-security-and-governance-tools) — Guide - [What is AIAM?](https://www.cerbos.dev/blog/aiam-ai-identity-and-access-management) — Article --- title: "Enterprise-grade authorization for MCP servers" description: "Fine-grained authorization for Model Context Protocol servers: control which tools an agent can reach, dynamically and with a full audit trail." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers" source: "https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers" --- # Enterprise-grade authorization for MCP servers Safely expose tools to agents without compromising control, reliability, or auditability, using fine-grained permissions. ## MCP servers are a hidden security risk Real breaches. Real companies. Real consequences. - **Every MCP server is a new backdoor** — MCP servers are being created in a way that allows them to bypass traditional API gateways, authentication layers, and access controls. - **Rogue agents wreak havoc** — AI agents operate "on behalf of users," but blur the lines of identity. They act without oversight, impersonating users and making destructive decisions. - **AI agents break trust perimeters** — To perform their tasks, AI agents need access to many services, forcing organizations to grant broad permissions that attackers can exploit. ## Fine-grained authorization for MCP servers with Cerbos A centralized, scalable solution for dynamically controlling tool availability. 1. **Define access rules** — Write simple, declarative rules that define under which conditions users or workloads can access specific MCP tools, and authorize downstream service to service requests. 2. **Deploy Cerbos PDP** — Run Cerbos PDP with your policies managed by Cerbos Hub. The stateless service provides an API for MCP servers to query for authorization checks. 3. **Integrate authorization checks** — When clients connect, your MCP server calls Cerbos to check which tools are permitted for that user and context, then enables/disables tools accordingly. 4. **Test and iterate** — Verify policies work across different roles. Update permissions by modifying policies without touching the MCP server code - Cerbos supports live policy reloading. ## Manage access for every identity, human or machine - Workforce - Partners - Customers - Microservices - Workloads - API clients - AI agents - AI workflows - MCP servers ## The Cerbos approach to future-proof authorization ### Build your MCP server IAM strategy Define, manage, and enforce access policies for all identity types: - Powerful ABAC, RBAC, and PBAC for your MCP servers and AI agents. - Full control over AI agents in cloud, on-prem, or hybrid environments. - Support Zero Trust with least privilege and continuous verification for every machine identity. - Seamless scalability and flexible run-time authorization. [Let's discuss your MCP strategy](https://www.cerbos.dev/secure-your-mcp-server-workshop) ### Handle authorization at the API gateway, in the service mesh, and microservices - Prevent over-permissioned services with policy-based authorization, one policy engine for both user and service identities. - Enforce least privilege access control among services. - Secure MCP server communication using policy-based access control for delegated service calls. - Implement a principal identity-based delegated authorization strategy. - Apply consistent authorization across cloud-native, containerized, and distributed environments. - Predictable performance at scale driven by the stateless architecture. [Talk to an engineer](https://www.cerbos.dev/secure-your-mcp-server-workshop) ### Safeguard AI agents, MCP servers, and RAG pipelines AI agents are non-human identities that access systems autonomously. Govern their actions and control data access to prevent leakage, injection, and overreach. - Secure agentic workflows with centralized policies. - Dynamic, policy-driven prompt filtering to add additional layers of control. - Control what context an LLM is provided with permission-aware data filtering for vector stores. - Enhance RAG architectures using data restricted to the user's permissions. [Let's discuss your MCP strategy](https://www.cerbos.dev/secure-your-mcp-server-workshop) ### Get full visibility into MCP server and AI agent actions Centralized audit trails for all non-human identity access decisions across all your applications. Stay compliant with SOC2, ISO27001, HIPAA, PCI DSS, and GDPR. - Capture every authorization check, across services, agents, and APIs, with structured logs that enable full traceability, compliance readiness, and forensic investigations. - Track which AI agent, API client, or workload accessed what, when, on behalf of whom, and which policy granted access, ensuring no identity operates unchecked. - Remove MCP compliance risks with full visibility into your agents actions. [Talk to an engineer](https://www.cerbos.dev/secure-your-mcp-server-workshop) ## Perfectly fits into your tech stack - Integrations - SDKs - Deployment models ## Why enterprises choose Cerbos - **Centralized policy management** — Manage and enforce authorization consistently across all identity types through one central hub. - **Authorize anywhere** — Run your authorization logic anywhere - in the cloud, on the edge, or directly on user's devices. - **Grows with your architecture** — Support evolving org structures, MCP server and AI agent growth, and complex access models - without rewriting access logic. - **Full auditability** — Capture every request and decision in standardized audit logs. Stream to existing log management. ## Learn more about MCP server guardrails - [Zero Trust for AI: Securing MCP Servers](https://solutions.cerbos.dev/zero-trust-for-ai-securing-mcp-servers) — Ebook - **Adding fine-grained authorization to MCP servers** — Webinar - [Cerbos named a Sample Vendor for AuthZEN in the Gartner Hype Cycle for Digital Identity](https://www.cerbos.dev/blog/cerbos-named-sample-vendor-authzen-gartner-hype-cycle-for-digital-identity) — Announcement - [How to secure your FastMCP server with permission management](https://www.cerbos.dev/blog/how-to-secure-your-fast-mcp-server-with-permission-management) — Article - [Authorizing MCP tool calls at the gateway or inside the proxy](https://www.cerbos.dev/blog/authorizing-mcp-tool-calls-at-the-gateway-or-inside-the-proxy) — Guide - [Dimmer switch: AI agent governance](https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance) — Article - [MCP permissions. Securing AI agent access to tools](https://www.cerbos.dev/blog/mcp-permissions-securing-ai-agent-access-to-tools) — Article - [Dynamic authorization for AI agents. A guide to fine-grained permissions in MCP servers](https://www.cerbos.dev/blog/dynamic-authorization-for-ai-agents-guide-to-fine-grained-permissions-mcp-servers) — Guide - [AI agents, the Model Context Protocol, and the future of authorization guardrails](https://www.cerbos.dev/news/securing-ai-agents-model-context-protocol ) — Article - [MCP authorization: Securing Model Context Protocol servers with fine-grained access control](https://www.cerbos.dev/blog/mcp-authorization) — Article - [MCP security & AI agent authorization. A CISO and architect’s guide to securing the new AI perimeter](https://www.cerbos.dev/blog/mcp-security-ai-agent-authorization-a-ciso-and-architects-guide) — Article - **Securing agentic AI in production** — Webinar - [Making AI agents a trustworthy part of your architecture](https://www.cerbos.dev/blog/mcp-and-zero-trust-securing-ai-agents-with-identity-and-policy) — Article - [Policy-driven MCP routing](https://www.cerbos.dev/blog/policy-driven-mcp-routing-tool-gating) — Article - [MCP server vetting checklist](https://www.cerbos.dev/blog/mcp-server-vetting-checklist) — Guide - [What an MCP gateway is](https://www.cerbos.dev/blog/what-is-an-mcp-gateway) — Article - [MCP authorization standards](https://www.cerbos.dev/blog/mcp-authorization-standards) — Guide - [Multi-hop delegation for AI agents, explained](https://www.cerbos.dev/blog/multi-hop-delegation-ai-agents) — Article - [Best AI agent security and governance tools](https://www.cerbos.dev/blog/best-ai-agent-security-and-governance-tools) — Guide - [Best IAM solutions for enterprises](https://www.cerbos.dev/blog/best-iam-solutions-for-enterprises) — Article - [What is AIAM?](https://www.cerbos.dev/blog/aiam-ai-identity-and-access-management) — Article --- title: "Policy-based guardrails for AI agents" description: "Policy-based guardrails for AI agents: secure agentic workflows, RAG pipelines and MCP servers with policy-driven access control and full decision logging." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/ai-security" source: "https://www.cerbos.dev/features-benefits-and-use-cases/ai-security" --- # Policy-based guardrails for AI agents Secure agentic workflows, RAG pipelines, and MCP servers with policy-driven access control and full decision logging. *Build your AI security strategy* ## Control access for every identity, at any scale - **Consistent access control everywhere** — Enforce fine-grained, contextual authorization across apps, APIs, services, and AI systems from a centralized control layer. - **Powerful policy lifecycle management** — Define, test, and validate access policies before deployment. Manage through Git and CI/CD. Roll out policy updates instantly across all enforcement points. - **Zero Trust security at runtime** — Authorize every AI and service request at runtime. Prevent over-permissioned actions with contextual, least-privilege enforcement. - **Compliance ready visibility** — Record every allow or deny decision with full request context and policy version so authorization behavior is fully traceable across all identities. ## Launch production-ready AI systems with Cerbos 1. **Every action is checked** — When a user clicks a button, a service calls an API, or an AI agent uses a tool, the request is sent to Cerbos. 2. **The request is evaluated** — Cerbos reviews who is making the request, what they want to do, what they want to access, and the surrounding context. 3. **The decision is enforced** — Cerbos returns ALLOW or DENY. The application follows that decision before the action runs. ## Access control for AI agents and every other use case Cerbos is an authorization management platform that scales with your business. - [AI agent guardrails](https://www.cerbos.dev/features-benefits-and-use-cases/agentic-authorization) - [MCP server security](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers) - [RAG authorization](https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag) - [AI gateway governance](https://www.cerbos.dev/features-benefits-and-use-cases/ai-gateway-authorization) - [Application permissions](https://www.cerbos.dev/features-benefits-and-use-cases/application-permissions) - [Multi-tenant SaaS access control](https://www.cerbos.dev/features-benefits-and-use-cases/per-tenant-custom-policies) - [Programmatic permission management](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-policies) - [Legacy application authorization](https://www.cerbos.dev/features-benefits-and-use-cases/legacy-app-authorization) ## Weak authorization is how breaches start. AI scales the mistake. - **Over-permissioned access** — AI agents and services can do more than they should. One mistake can expose sensitive data or trigger unauthorized actions. - **Gaps between systems** — When access rules live in different services, decisions become inconsistent. Attackers exploit those gaps. - **Access that never expires** — Long-lived tokens and shared credentials stay valid long after they are needed, increasing the chance of compromise. - **No way to stop it instantly** — If an agent goes beyond its scope, access continues until someone rotates credentials or restarts systems. ## Become compliance-ready with every access decision, AI or human - SOC 2 - SOC 3 - HIPAA - ISO 27001 - GDPR - FedRAMP - PCI DSS - NIS2 - DORA *Plug into your existing stack* ## Go live with authorization in one sprint - **Capture every decision for all identities** — Log requests, actions, resources, access outcomes, and service-to-service authorization calls for both humans and machines. - **Trace policy lineage** — See the exact policy, version, and release behind each decision for complete traceability. - **Monitor with context** — Review detailed logs, policy versions, and real-time metrics across all PDPs and environments. - **Simplify audits and compliance** — Maintain centralized, structured logs on-premise to support audits and demonstrate readiness for FedRAMP, SOC 2&3, ISO 27001, HIPAA, PCI DSS, and GDPR. - **MCPs** — Integrate Cerbos authorization with Fasten MCP and Anthropic MCP to control agent workflows at the orchestration layer. - **Vector stores** — Enforce policy-based access for embeddings and retrievals across FAISS, Pinecone, Weaviate, Chroma, and Qdrant. - **AI infrastructure** — Deploy Cerbos policies alongside your AI model APIs. Works with OpenAI, Anthropic, Groq, and other inference providers. - **SDKs** — Use Cerbos SDKs for languages like JS, Python, Go, Rust, Java, and .NET to authorize requests from your application code. ## Purpose-built authorization, not a generic policy engine | | Generic policy engines | Cerbos | | --- | --- | --- | | **Policy language** | General-purpose policy languages designed for broader use cases. | YAML policies purpose-built for authorization, readable by security teams. | | **Authorization model** | Authorization patterns must be assembled from generic primitives. | First-class RBAC, ABAC, and PBAC with principal/resource/action semantics. | | **Evaluation latency** | Varies by policy complexity and engine architecture. | Sub-millisecond, optimized for per-request evaluation at machine speed. | | **Policy lifecycle** | Custom sync, manual distribution, separate CI/CD tooling. | Cerbos Hub: managed policy lifecycle with CI/CD, testing, and real-time distribution. | | **Audit and compliance** | Decision logs require additional infrastructure to capture and correlate. | Structured decision logs with policy version lineage, built in. | *Implementing Zero Trust with Cerbos* ## Why engineering teams love Cerbos > When I did an audit, I found that the cost of managing authorization and authentication in-house over the entire lifespan of the company was in the 7 figures. Cerbos saved that. Deploying Cerbos has allowed our engineers to spend their time on what really matters for our success. > > — Chuck Hardy, Head of Engineering @Salesroom > Having to modify authorization is a five-minute job now. Having to troubleshoot authorization is a five-minute job. So that has actually allowed the team to spend more time where it really matters on the platform. > > — Karen Kim, CEO @Human Managed > We rely on Cerbos to make authorization decisions across the whole mesh - millions of times a day. And it’s fast. We don’t even think about it anymore. It just works. > > — Rob Crowe, Principal Engineer @Utility Warehouse > We went from one user - every role, to a world where there are many users - many roles. And the product, it relies on Cerbos to actually bring the value that we want to bring to customers. All of our customers are relying on Cerbos, by relying on the product, which is of course relying on Cerbos. > > — Joe Lines, CEO & Co-Founder @Nook > One of our big considerations was speed. We have strict latency tolerances. When it comes to Cerbos - you can call it a hundred times during a request and it doesn't matter. It's incredibly fast. > > — Steve High, Staff Engineer @Complex > The main reason we switched to Cerbos was to have a sophisticated authorization software to help organize and handle our authorization. We wanted to focus on domain related features and spend less time backtracking and fixing issues with our authorization. > > — Lead Software Developer at @BarrierSystems > Cerbos enables us to go to market very quickly, compared to an in-house solution. It allows us to offer new products faster, because creating or editing policies is so easy. > > — Engin Attar, Head of Product and Growth, Co-Founder @Debite > We got the foundation set. Now we can scale and include more complex policies. And we can grow in the right direction and with the right security thanks to Cerbos authorization management. > > — Edgar Rivera, CTO @4gcapital > Having the separation of the permissions from the code base just makes the code base more elegant. It makes the permissioning more elegant. It means they're centralized, so they're not tied to specific endpoints. And ultimately it means that different business owners have the ability to actually make updates. > > — Henry Arnold, CTO & Co-Founder @Nook > We're not worried about scaling because we can easily increase our load on Cerbos. It will also be easy for us to change how we're distributing policies as we reach different points of scale. > > — David Workman, Senior Software Engineer @ Salesroom > Offering dynamic roles and permissions makes us more competitive in the market. We’re providing companies with a software that can be adapted to their workflows. > > — Ibrahim Bou Ncoula, CTO @Supy > We can create unlimited conditions, attributes, and parameters at any level of granularity without writing any code. It allows us to deliver truly personalized services quickly, securely, and at scale. > > — Karen Kim, CEO @Human Managed ## Learn more about AI security - [Governing AI coding agents with Cerbos Synapse](https://www.cerbos.dev/blog/governing-ai-coding-agents-with-cerbos-synapse) — Article - [Securing AI agents and non-human identities in enterprises](https://solutions.cerbos.dev/securing-ai-agents-non-human-identities-in-enterprises) — Ebook - [Cerbos named a Sample Vendor for AuthZEN in the Gartner Hype Cycle for Digital Identity](https://www.cerbos.dev/blog/cerbos-named-sample-vendor-authzen-gartner-hype-cycle-for-digital-identity) — Announcement - [A CISO’s benchmark for authorization maturity](https://solutions.cerbos.dev/authorization-maturity-model-a-cisos-benchmark) — Ebook - [Dimmer switch: AI agent governance](https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance) — Article - [Who owns authorization in a large engineering organization?](https://www.cerbos.dev/blog/who-owns-authorization-in-large-engineering-organization) — Article - [Zero Trust for AI: Securing MCP Servers](https://solutions.cerbos.dev/zero-trust-for-ai-securing-mcp-servers) — Ebook - [Implementing authorization in RAG-based AI systems with Cerbos](https://www.cerbos.dev/blog/access-control-for-rag-llms) — Article - [Multi-hop delegation for AI agents, explained](https://www.cerbos.dev/blog/multi-hop-delegation-ai-agents) — Article - [Best AI agent security and governance tools](https://www.cerbos.dev/blog/best-ai-agent-security-and-governance-tools) — Guide - [What is AIAM?](https://www.cerbos.dev/blog/aiam-ai-identity-and-access-management) — Article --- title: "Permissions-aware authorization for RAG pipelines" description: "Permissions-aware authorization for retrieval-augmented generation: Cerbos filters at the retrieval layer so only data a user may see reaches the LLM." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag" source: "https://www.cerbos.dev/features-benefits-and-use-cases/access-control-for-rag" --- # Permissions-aware authorization for RAG pipelines Control what data enters your AI prompts. Cerbos enforces user-level permissions at the retrieval layer, so your RAG systems only surface information each user is authorized to see. ## RAG pipelines expose data your users shouldn't see - **Over-retrieval from vector stores** — Embedding-based retrieval ignores authorization. A similarity search returns the most relevant chunks regardless of whether the requesting user has permission to see them. - **Context injection into prompts** — Unauthorized data retrieved from the vector store is injected directly into the LLM prompt. The model treats it as ground truth and surfaces it in its response. - **Post-hoc filtering is brittle** — Filtering results after retrieval means sensitive data has already been fetched, loaded into memory, and potentially cached. The security boundary was already crossed. - **No audit trail for data access** — Without authorization checks at the retrieval layer, there is no record of which data was accessed, by whom, or under what policy. Compliance teams have no visibility. ## Permission-aware data filtering with Cerbos Cerbos integrates at the retrieval layer to ensure only authorized data reaches the LLM. The query plan API translates your authorization policies into database-native filters — applied before any data is fetched. 1. **Define data access policies** — Write YAML policies that define which principals can access which data based on role, department, region, classification level, or any attribute. Policies are version-controlled and testable. 2. **Generate authorization-aware query plans** — When a user triggers a RAG query, Cerbos evaluates their permissions and returns a query plan — a set of conditions that can be translated into native database or vector store filters. 3. **Apply filters at the retrieval layer** — The query plan is applied as a pre-filter on your vector store or database. Only data the user is permitted to access is retrieved. 4. **Log every data access decision** — Every authorization check is logged with the principal, resource, action, policy version, and outcome. Stream structured logs to your SIEM for compliance and forensic analysis. ## How Cerbos secures your RAG pipeline Filter before retrieval, not after. Cerbos translates authorization policies into native query filters so sensitive data never enters the pipeline. - **Native vector store integration** — Cerbos query plans translate into native filter syntax for Pinecone, Weaviate, Chroma, Qdrant, and FAISS. No custom middleware required. - **Pre-retrieval enforcement** — Authorization is enforced before data is fetched, not after. Sensitive data never enters the RAG pipeline or the LLM context window. - **Sub-millisecond query plan generation** — Query plans are generated in under a millisecond. Authorization adds negligible latency to the retrieval pipeline. - **Same policies across all layers** — The same YAML policies govern data access, API authorization, application permissions, and AI agent behavior. One policy engine, consistent enforcement. ## Full audit trail for every data access decision - **Trace every data access decision** — Log which data was surfaced to which user through which RAG pipeline, with the exact policy version and conditions applied. - **Policy lineage for every retrieval** — See the exact policy, version, and release behind each data access decision for complete traceability. - **Compliance-ready audit trails** — Structured logs compatible with SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR audit requirements. Stream to your SIEM or log management platform. ## RAG authorization in practice - **HR knowledge base** — An employee asks the company chatbot about parental leave policy. Cerbos ensures the RAG pipeline retrieves only policies applicable to the employee’s region, employment type, and seniority level — not compensation data, termination procedures, or policies for other jurisdictions. - **Multi-tenant SaaS documentation** — A customer queries the support AI. Cerbos filters retrieval to only surface documentation, configuration guides, and known issues for that customer’s specific plan tier and product modules — not internal engineering docs or other tenants’ data. - **Financial services research** — An analyst asks an AI assistant about market positions. Cerbos enforces information barriers: the retrieval layer only returns research and positions the analyst’s desk is authorized to access, maintaining regulatory compliance with Chinese wall requirements. ## Integrate with your AI and data stack - **Vector stores** — Enforce policy-based access for embeddings and retrievals across FAISS, Pinecone, Weaviate, Chroma, and Qdrant. - **AI infrastructure** — Deploy Cerbos policies alongside your AI model APIs. Works with OpenAI, Anthropic, Groq, and other inference providers. - **SDKs** — Use Cerbos SDKs to integrate authorization into your RAG pipeline with a few lines of code. ## Why enterprises choose Cerbos - **Pre-retrieval filtering** — Authorization is enforced before data is fetched, not after. Sensitive data never enters the RAG pipeline. - **Sub-millisecond decisions** — Query plan generation adds negligible latency to the retrieval pipeline. Authorization at machine speed. - **Policy as code** — YAML policies version-controlled in Git. Security teams can read and audit data access rules without specialized training. - **Audit-ready logs** — Every data access decision logged with full context. Meet SOC 2, HIPAA, ISO 27001 requirements out of the box. ## Learn more about RAG authorization - [Implementing authorization in RAG-based AI systems with Cerbos](https://www.cerbos.dev/blog/access-control-for-rag-llms) — Article - **Securing agentic AI in production** — Webinar - [Cerbos named a Sample Vendor for AuthZEN in the Gartner Hype Cycle for Digital Identity](https://www.cerbos.dev/blog/cerbos-named-sample-vendor-authzen-gartner-hype-cycle-for-digital-identity) — Announcement - [Dimmer switch: AI agent governance](https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance) — Article - [Zero Trust for AI: Securing MCP Servers](https://solutions.cerbos.dev/zero-trust-for-ai-securing-mcp-servers) — Ebook - [Securing AI agents and non-human identities in enterprises](https://solutions.cerbos.dev/securing-ai-agents-non-human-identities-in-enterprises) — Ebook - [MCP security & AI agent authorization](https://www.cerbos.dev/blog/mcp-security-ai-agent-authorization-a-ciso-and-architects-guide) — Article - [MCP permissions. Securing AI agent access to tools](https://www.cerbos.dev/blog/mcp-permissions-securing-ai-agent-access-to-tools) — Article - [Multi-hop delegation for AI agents, explained](https://www.cerbos.dev/blog/multi-hop-delegation-ai-agents) — Article - [Best AI agent security and governance tools](https://www.cerbos.dev/blog/best-ai-agent-security-and-governance-tools) — Guide - [Best IAM solutions for enterprises](https://www.cerbos.dev/blog/best-iam-solutions-for-enterprises) — Article - [What is AIAM?](https://www.cerbos.dev/blog/aiam-ai-identity-and-access-management) — Article --- title: "Fine-grained application permissions without the complexity" description: "Fine-grained, context-aware application permissions with Cerbos: model resources and actions, write policies, and replace scattered permission checks with a single API call." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/application-permissions" source: "https://www.cerbos.dev/features-benefits-and-use-cases/application-permissions" --- # Fine-grained application permissions without the complexity Context-aware, policy-based access control for every resource in your application. No more tangling authorization logic into your core code. ## Authorization that gets out of your way ### Fine-grained access control without code complexity Define precise permissions for every resource and action in your application using readable YAML policies, not tangled if-else logic. - Model any permission structure: RBAC, ABAC, or both combined. - Sub-millisecond decisions evaluated locally, with no external dependencies. - Separate authorization logic from application code for cleaner architecture. - Use real-time context (user attributes, resource properties, time) in every decision. [Read the docs](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html) ### Ship permissions changes without redeploying Update access rules by changing policy files, not application code. Test in CI, validate in playground, deploy with confidence. - Policies are YAML files in Git. Review, approve, and deploy like any other config. - Use the Cerbos Playground to prototype and test policies before deploying. - Hot-reload policies in development. No restart, no redeploy needed. - Built-in test framework validates policies in CI before they reach production. [Try the playground](https://play.cerbos.dev/) ### Full audit trail for every access decision Capture what was allowed or denied, which policy applied, and the exact context behind every authorization decision. - Every decision is logged with principal, resource, action, and result. - Trace decisions back to the exact policy version that enforced them. - Support SOC 2, ISO 27001, HIPAA, and GDPR audit requirements with structured logs. [Learn about audit logs](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) ## Implement application permissions in four steps 1. **Define your resources and actions** — Model your application's resources (documents, orders, projects) and the actions users can perform on them. 2. **Write context-aware policies** — Create policies that combine roles, attributes, and runtime context to make fine-grained access decisions. 3. **Integrate with a single API call** — Replace scattered permission checks with a single call to Cerbos. Get an allow/deny decision in sub-milliseconds. 4. **Deploy and iterate without code changes** — Update permissions by changing policy files, not application code. Test in CI, deploy via GitOps. [Get started](https://docs.cerbos.dev/cerbos/latest/quickstart.html) ## Works with your existing tools, workflows, and infrastructure - **Flexible policy sources** — Manage policies from any Git provider, CI/CD tool, Cerbos Hub API, CLI, or direct UI upload. - **SDKs for every stack** — First-class SDKs for JS, Go, Python, Java, .NET, Rust, PHP, and Ruby with idiomatic APIs. - **Deployment targets** — Deploy Cerbos PDPs in containers, serverless, edge, or multi-region clusters. - **Compliance ready audit logs** — Ensure audit readiness for SOC 2, HIPAA, ISO 27001, PCI DSS, and GDPR. ## Why developers choose Cerbos for application permissions - **Faster development** — Replace months of custom authorization code with a single API integration. - **Cleaner architecture** — Separate authorization from business logic for maintainable, testable code. - **Stronger security** — Enforce least privilege with context-aware policies across every resource. - **No vendor lock-in** — Open source PDP with Apache 2.0 license. Run anywhere, own your enforcement layer. ## Learn more about application permissions - [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) — Ebook - [How to implement resource-based authorization](https://www.cerbos.dev/blog/how-to-implement-resource-based-authorization) — Article - [Mapping business requirements to authorization policy](https://www.cerbos.dev/blog/mapping-business-requirements-to-authorization-policy) — Guide - [ePDP Rules: Fine-grained control for embedded policy bundles](https://www.cerbos.dev/blog/epdp-rules-fine-grained-control-for-embedded-policy-bundles) — Article - [Who owns authorization in a large engineering organization?](https://www.cerbos.dev/blog/who-owns-authorization-in-large-engineering-organization) — Article --- title: "Multi-tenant SaaS authorization that scales with your customers" description: "Multi-tenant SaaS authorization with Cerbos: tenant isolation, per-customer roles, and an audit trail for every access decision." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/multi-tenant-saas" source: "https://www.cerbos.dev/features-benefits-and-use-cases/multi-tenant-saas" --- # Multi-tenant SaaS authorization that scales with your customers Enforce tenant isolation, support custom roles per customer, and audit every access decision across your entire SaaS platform. ## Tenant-aware authorization for every customer ### Tenant isolation without code complexity Enforce strict tenant boundaries at the authorization layer, not in application code. Each tenant operates in their own secure environment. - Scope policies by tenant ID to guarantee data isolation across your platform. - Separate tenant-specific logic from core policies for safer, independent changes. - Support hierarchical organizations with teams, departments, and custom role structures. - Scale to thousands of tenants without degrading authorization performance. [Read the docs](https://docs.cerbos.dev/cerbos/latest/policies/scoped_policies.html) ### Self-service permissions for enterprise customers Unlock enterprise contracts by allowing customers to define their own roles and permissions without engineering involvement. - Let tenants configure custom roles and access rules via API-driven Policy Stores. - Build internal tools or customer portals that push tenant policy updates securely. - Combine static base policies with dynamic tenant rules in a single versioned deployment. - Deploy policy changes instantly without restarting services or redeploying application code. [Talk to an engineer](https://www.cerbos.dev/workshop) ### Audit trails with full tenant traceability Complete visibility into tenant-specific access decisions for compliance, debugging, and customer accountability. - View active policies and version history for each tenant directly in Cerbos Hub. - Trace every authorization decision back to the exact policy version that enforced it. - Maintain structured, centralized logs to simplify audits and meet enterprise compliance requirements. [Learn about audit logs](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) ## Implement tenant authorization in four steps 1. **Define tenant boundaries in policy** — Use scoped policies to isolate tenant data and enforce that users can only access resources within their own tenant. 2. **Enable self-service roles per tenant** — Let tenants define their own roles and permissions through Policy Stores, without touching your core codebase. 3. **Deploy tenant policies dynamically** — Push tenant-specific policy updates via API, Git, or CLI. Cerbos Hub validates, builds, and distributes automatically. 4. **Audit every tenant decision** — Trace every authorization decision back to the exact policy version and tenant context that enforced it. [Talk to an engineer](https://www.cerbos.dev/workshop) ## Works with your existing tools, workflows, and infrastructure - **Flexible policy sources** — Add tenant policies from any Git provider, CI/CD tool, Cerbos Hub API, CLI, or direct UI upload. - **SDKs for every stack** — First-class SDKs for JS, Go, Python, Java, .NET, Rust, PHP, and Ruby. - **Deployment targets** — Deploy Cerbos PDPs in containers, serverless, edge, or multi-region clusters. - **Compliance ready audit logs** — Ensure audit readiness for SOC 2, HIPAA, ISO 27001, PCI DSS, and GDPR. ## Why SaaS teams choose Cerbos for multi-tenancy - **Enterprise flexibility** — Support custom tenant roles and dynamic policies at any scale. - **Streamlined operations** — Replace custom tenant workflows with automated policy deployments. - **Faster delivery** — Programmatic updates, fast testing, and simplified policy management. - **No infra overhead** — Deliver dynamic tenant policies at scale without building custom infrastructure. ## Learn more about multi-tenant authorization - [A guide to multitenant authorization](https://solutions.cerbos.dev/guide-to-multitenant-authorization) — Ebook - [How to implement scalable multitenant authorization](https://www.cerbos.dev/blog/how-to-implement-scalable-multitenant-authorization) — Article - **Scaling authorization logic in a multitenant application** — Webinar - [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) — Ebook - [ePDP Rules: Fine-grained control for embedded policy bundles](https://www.cerbos.dev/blog/epdp-rules-fine-grained-control-for-embedded-policy-bundles) — Article - [Best IAM solutions for enterprises](https://www.cerbos.dev/blog/best-iam-solutions-for-enterprises) — Article --- title: "Product packaging and feature gating with policy" description: "Feature gating and entitlements driven by authorization policy: trials, tiers, custom bundles and enterprise contracts without hardcoding." canonical: "https://www.cerbos.dev/features-benefits-and-use-cases/product-packaging" source: "https://www.cerbos.dev/features-benefits-and-use-cases/product-packaging" --- # Product packaging and feature gating with policy Control which features are available to which customers using authorization policy. Trials, tiers, custom bundles, and enterprise contracts, all without hardcoding. ## Authorization-driven product packaging ### Feature gating without hardcoded flags Control which features are available to which customers using policy, not feature flags buried in code. - Map product packages to Cerbos roles for clean, declarative entitlements. - Sub-millisecond entitlement checks with no external runtime dependency. - Define complex package hierarchies where premium includes standard includes free. - Support custom contracts and one-off feature bundles for enterprise customers. [Read the docs](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html) ### Time-limited trials and dynamic upgrades Offer trial access to premium features with time-based conditions, and upgrade packages instantly via policy changes. - Use time-based conditions in policies to automatically expire trial access. - Upgrade or downgrade customer packages instantly by updating policy, not code. - Build self-service upgrade flows that trigger policy changes via the Cerbos API. - Test package configurations in the Cerbos Playground before deploying to production. [Try the playground](https://play.cerbos.dev/) ### Full visibility into entitlement decisions Understand exactly which features are accessible to which customers, and prove it for billing, compliance, and support. - Log every entitlement check with package, feature, and decision result. - Trace feature access back to the exact policy version for billing accuracy. - Support customer success teams with clear visibility into what each customer can access. [Learn about audit logs](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) ## Implement product packaging in four steps 1. **Define your packages as policies** — Map product tiers (free, standard, premium) to authorization policies that control which features each package can access. 2. **Gate features with a single API call** — Check entitlements at runtime by calling Cerbos. Get an instant allow/deny decision based on the user's package. 3. **Update packages without code deploys** — Add features to a tier or create a new package by updating policy files. No application redeployment needed. 4. **Audit every entitlement decision** — Track which features were accessed, by whom, under which package, with full decision-level evidence. [Get started](https://docs.cerbos.dev/cerbos/latest/quickstart.html) ## Works with your existing tools, workflows, and infrastructure - **Flexible policy sources** — Manage packaging policies from any Git provider, CI/CD tool, Cerbos Hub API, CLI, or direct UI upload. - **SDKs for every stack** — First-class SDKs for JS, Go, Python, Java, .NET, Rust, PHP, and Ruby. - **Deployment targets** — Deploy Cerbos PDPs in containers, serverless, edge, or multi-region clusters. - **Compliance ready audit logs** — Ensure audit readiness for SOC 2, HIPAA, ISO 27001, PCI DSS, and GDPR. ## Why teams choose Cerbos for product packaging - **Flexible packaging** — Define unlimited package tiers, custom bundles, and trial configurations with policy. - **Instant updates** — Change what features are in a package without code changes or redeployments. - **Billing accuracy** — Audit every entitlement decision for accurate billing reconciliation. - **No custom infrastructure** — Replace homegrown feature-flag systems with a dedicated authorization layer. ## Learn more about product packaging with Cerbos - [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) — Ebook - [Designing an authorization model that scales with your business](https://www.cerbos.dev/blog/designing-an-authorization-model-that-scales-with-your-business) — Article - [ePDP Rules: Fine-grained control for embedded policy bundles](https://www.cerbos.dev/blog/epdp-rules-fine-grained-control-for-embedded-policy-bundles) — Article - [Best IAM solutions for enterprises](https://www.cerbos.dev/blog/best-iam-solutions-for-enterprises) — Article --- title: "How Cerbos compares" description: "Technical comparisons of Cerbos with PlainID, Axiomatics, PingAuthorize, EmpowerID, OPA, Cedar, Permit.io, OpenFGA, Zanzibar." canonical: "https://www.cerbos.dev/comparisons" source: "https://www.cerbos.dev/comparisons" comparisons: 9 --- # How Cerbos compares > Verdict summaries for all 9 competitor comparisons. Each has a full document with a requirement matrix, concept mapping and limitations, linked below and available as markdown. ## PlainID Both products answer the same runtime question: may this principal perform this action on this resource? They emphasize different policy lifecycles, governance models, deployment topologies, enforcement patterns, and portability boundaries. **Choose Cerbos when** - Application authorization needs repository-native policy review, tests, and deployment without making a central commercial platform part of each decision path. - The required enforcement model is an application-side authorization check or a query plan applied by the application data layer. - An Apache 2.0 PDP and a documented exit path are material procurement requirements. **Consider PlainID when** - Inline SQL rewriting, row filtering, and column or cell masking are hard requirements. - Nondeveloper visual authoring and packaged Authorizers outweigh repository-native ownership and PDP portability. **Already on PlainID? Switching probably is not worth it when** - Inline SQL rewriting, row filtering, or column masking runs in production and the adapter and masking work has not been budgeted. - Packaged Authorizers cover enforcement points that have no Cerbos integration pattern yet. Facts last checked on 24 July 2026. Full comparison: [Repository-native policy and centrally governed policy workflows](https://www.cerbos.dev/cerbos-vs-plainid) · markdown at https://www.cerbos.dev/cerbos-vs-plainid.md ## Axiomatics Axiomatics, a Leonardo company since December 2025, provides a commercial XACML and ALFA authorization suite. Cerbos combines an Apache 2.0 YAML and CEL policy engine with optional Cerbos Hub and Cerbos Synapse components. Teams with an existing XACML estate should compare policy semantics and operating requirements case by case. **Choose Cerbos when** - New application-authorization work needs authorization-specific YAML or JSON policies with CEL conditions and a self-service development loop. - A stateless Apache 2.0 PDP must run close to workloads in sidecar, shared-service, Kubernetes, serverless, or edge topologies. - The program can migrate XACML semantics incrementally and validate them with dual evaluation. **Consider Axiomatics when** - The existing XACML and ALFA estate is stable, governed, and more expensive to translate than to operate. - XACML semantic continuity, CAQ entitlement analysis, or specialist XACML services are primary requirements. **Already on Axiomatics? Switching probably is not worth it when** - The XACML or ALFA estate is stable, and translating it would cost more than operating it. - Obligations, combining behavior, or CAQ entitlement analysis carry real controls and nothing is planned to replace them. Facts last checked on 24 July 2026. Full comparison: [Two approaches to enterprise ABAC](https://www.cerbos.dev/cerbos-vs-axiomatics) · markdown at https://www.cerbos.dev/cerbos-vs-axiomatics.md ## PingAuthorize PingAuthorize is a commercial, self-managed ABAC platform with visual authoring and several runtime integration patterns. Cerbos combines an Apache 2.0 stateless Cerbos PDP with optional Cerbos Hub and Cerbos Synapse components for lifecycle management, distribution, audit aggregation, enrichment, and protocol integrations. **Choose Cerbos when** - Services need local authorization decisions through sidecar or DaemonSet PDPs, with shared-service deployment retained where appropriate. - The authorization layer must remain independent of the identity provider and accept identity context from Ping or another IdP. - Teams want Git or source-agnostic policy workflows around an Apache 2.0 PDP with published platform tiers. **Consider PingAuthorize when** - Ping-native identity and gateway integration removes material implementation work. - Its visual authoring, packaged gateway topology, and ordered attribute resolvers are firm requirements. **Already on PingAuthorize? Switching probably is not worth it when** - Ping-native identity and gateway integrations carry the implementation, and replacing them would add more custom work than the switch saves. - Policy authors rely on the Visual Policy Editor and ordered attribute resolvers, and nobody has mapped those to code-first policy and Cerbos Synapse. Facts last checked on 24 July 2026. Full comparison: [Different authoring and operating models](https://www.cerbos.dev/cerbos-vs-ping-authorize) · markdown at https://www.cerbos.dev/cerbos-vs-ping-authorize.md ## EmpowerID 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. Omada, an identity governance vendor, acquired EmpowerID in September 2026. **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 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 gateway, per-call delegation checks, and escalation to human approval, is wanted from a single vendor rather than assembled. **Already on EmpowerID? Switching probably is not worth it when** - EmpowerID mainly runs identity governance, PAM, or SAP identity work. Cerbos does not replace those, so run it alongside rather than switching. - Credential custody or signed, hash-chained decision evidence from the authorization vendor is an audit requirement today. Facts last checked on 3 August 2026. Full comparison: [A decision point behind your stack, or an execution plane in front of it](https://www.cerbos.dev/cerbos-vs-empowerid) · markdown at https://www.cerbos.dev/cerbos-vs-empowerid.md ## OPA OPA is a general-purpose policy engine that evaluates Rego policies over structured data. Cerbos is purpose-built for fine-grained authorization across applications, APIs, agents, services, and workloads. The comparison covers both engines and the lifecycle tooling around them. **Choose Cerbos when** - The scope is application authorization and teams want principals, resources, actions, roles, conditions, tests, audit, and query planning as product primitives. - Operating Rego conventions, bundle infrastructure, decision-log collection, or application-specific query adapters creates material maintenance work. - Policy reviewers prefer an authorization-specific YAML or JSON schema with CEL conditions over a general-purpose language. **Consider OPA when** - One engine must cover Kubernetes admission, infrastructure, CI/CD, and policy shapes outside application authorization. - An existing platform is stable and its Rego expressiveness or ecosystem is a verified requirement. **Already on OPA? Switching probably is not worth it when** - The OPA deployment already serves application authorization reliably, and its Rego conventions, bundles, and query adapters cost little to maintain. - Most of the Rego estate is admission, infrastructure, or CI/CD policy. Move only the application authorization subset, or nothing. Facts last checked on 24 July 2026. Full comparison: [Authorization-specific platform or general-purpose policy engine](https://www.cerbos.dev/cerbos-vs-opa) · markdown at https://www.cerbos.dev/cerbos-vs-opa.md ## Cedar Cedar is an Apache 2.0 authorization language and engine ecosystem with strong schema validation and formal analysis. Cerbos combines an Apache 2.0 Cerbos service PDP with an optional Cerbos Hub-managed, in-process WebAssembly ePDP and Cerbos Synapse decision-time data. The right choice starts with the product boundary, not policy syntax alone. **Choose Cerbos when** - Multiple services or languages need one independently deployable authorization API rather than an evaluator embedded into each application. - Policy build, test, signed distribution, audit collection, list-query planning, or decision-time data would otherwise become internal platform work. - Deployment control matters across the stack: the Cerbos service PDP and Cerbos Synapse are self-hosted, Cerbos Hub ePDP evaluates in-process, and Cerbos Hub Enterprise is available on-premise for restricted and air-gapped environments. **Consider Cedar when** - Symbolic equivalence and permissiveness analysis are firm requirements, or its typed model is the platform standard. - A native in-process Rust or Go implementation, a Java binding, or an embedded engine without a Cerbos Hub dependency is required. An existing Cedar-based AWS workflow can also be decisive. **Already on Cedar? Switching probably is not worth it when** - A well-operated Cedar platform already meets the requirement, particularly one built around Cedar-based AWS workflows. - Formal policy analysis is part of the assurance case. Cerbos schemas, compile checks, and policy tests do not replace a symbolic prover. Facts last checked on 27 July 2026. Full comparison: [An authorization platform with service and embedded runtimes, or an engine toolkit](https://www.cerbos.dev/cerbos-vs-cedar) · markdown at https://www.cerbos.dev/cerbos-vs-cedar.md ## Permit.io Both products target application teams. In its standard hosted model, Permit.io pairs a managed control plane with an open source PDP. Cerbos can run a self-hosted Cerbos PDP from hand-authored policy files with no control plane required for decisions, while Cerbos Hub and Cerbos Synapse add commercial management and enrichment capabilities. **Choose Cerbos when** - The default should be a modular authorization platform: an independently deployable open source PDP, optional Cerbos Hub policy lifecycle, and commercial Cerbos Synapse enrichment. - The application team wants YAML or JSON policy with CEL rather than generated Rego or Cedar. - Policy lifecycle management and decision-time data enrichment should remain separate, optional platform concerns. **Consider Permit.io when** - A low code policy editor is the preferred authoring surface for developers and nondeveloper stakeholders. - Embeddable access request, approval, and user management components are product requirements. - OPAL-based policy and data distribution matches the operating model the team wants. **Already on Permit.io? Switching probably is not worth it when** - Product features depend on Permit Elements for access requests, approvals, or user management, and nobody is budgeted to rebuild them. - Nondevelopers author policy in the low code editor today and would not move to YAML or JSON with CEL. Facts last checked on 24 July 2026. Full comparison: [Two developer-focused products, two default operating models](https://www.cerbos.dev/cerbos-vs-permit) · markdown at https://www.cerbos.dev/cerbos-vs-permit.md ## OpenFGA OpenFGA primarily evaluates whether relationships exist using a model and stored or contextual tuples. Cerbos PDP evaluates whether an action is allowed using policy and request-supplied attributes. The right choice depends on the shape of the authorization problem. **Choose Cerbos when** - The default should combine an independently deployable open source service PDP, an optional commercial Cerbos Hub-managed WebAssembly ePDP, and commercial Cerbos Synapse enrichment around attribute-led authorization. - Application relationship data should remain in existing systems rather than a second materialized tuple store. - The decision service must run locally and independently from a managed authorization API. **Consider OpenFGA when** - Permissions form a deep relationship graph with nested groups, folders, sharing, or delegation. - Native ListObjects and ListUsers operations are central to the application. - A Zanzibar-style model is the intended source of truth for authorization relationships. **Already on OpenFGA? Switching probably is not worth it when** - The tuple store is the system of record for relationships, and ListObjects or ListUsers back core product features. - Recursive sharing or nested group traversal dominates the authorization logic. Run both with a defined boundary instead of migrating. Facts last checked on 24 July 2026. Full comparison: [A relationship graph or a policy engine](https://www.cerbos.dev/cerbos-vs-openfga) · markdown at https://www.cerbos.dev/cerbos-vs-openfga.md ## Zanzibar Zanzibar is Google's internal authorization system, documented in a 2019 USENIX paper, which inspired open source systems including OpenFGA and SpiceDB. Cerbos PDP is a policy engine; the broader Cerbos platform also includes Cerbos Hub, Cerbos Synapse, and enforcement integrations. **Choose Cerbos when** - The default should combine an independently deployable open source PDP, optional Cerbos Hub policy lifecycle, and commercial Cerbos Synapse enrichment around contextual policy. - Relationship facts already live in application systems and can be supplied for each decision. - A stateless, locally deployed PDP is preferable to operating a separate relationship database. **Consider Zanzibar when** - The authorization domain is a large, dynamic graph with recursive inheritance or delegated sharing. - Both principal-to-resource and resource-to-principal queries must be native operations. - The system needs Zanzibar-style consistency controls across stored authorization relationships. **Already on Zanzibar? Switching probably is not worth it when** - A Zanzibar-style relationship store is already the system of record, and both lookup directions are native operations the product depends on. - Graph consistency semantics such as snapshot tokens are part of the correctness model. Facts last checked on 24 July 2026. Full comparison: [Policy-first or relationship-graph-first authorization](https://www.cerbos.dev/cerbos-vs-zanzibar) · markdown at https://www.cerbos.dev/cerbos-vs-zanzibar.md --- title: "Repository-native policy and centrally governed policy workflows" description: "Both products answer the same runtime question: may this principal perform this action on this resource? They emphasize different policy lifecycles, governance models, deployment topologies, enforcement patterns, and portability boundaries." competitor: "PlainID" reviewed: "2026-07-24" prepared_by: "Cerbos" canonical: "https://www.cerbos.dev/cerbos-vs-plainid" source: "https://www.cerbos.dev/cerbos-vs-plainid" --- # Repository-native policy and centrally governed policy workflows Both products answer the same runtime question: may this principal perform this action on this resource? They emphasize different policy lifecycles, governance models, deployment topologies, enforcement patterns, and portability boundaries. Prepared by the Cerbos team. Facts last checked on 24 July 2026. ## Verdict **Choose Cerbos when** - Application authorization needs repository-native policy review, tests, and deployment without making a central commercial platform part of each decision path. - The required enforcement model is an application-side authorization check or a query plan applied by the application data layer. - An Apache 2.0 PDP and a documented exit path are material procurement requirements. **Consider PlainID when** - Inline SQL rewriting, row filtering, and column or cell masking are hard requirements. - Nondeveloper visual authoring and packaged Authorizers outweigh repository-native ownership and PDP portability. **Already on PlainID? Switching probably is not worth it when** - Inline SQL rewriting, row filtering, or column masking runs in production and the adapter and masking work has not been budgeted. - Packaged Authorizers cover enforcement points that have no Cerbos integration pattern yet. ## Two operating models for the same decision PlainID and Cerbos both provide fine-grained runtime authorization. PlainID centralizes policy governance in a commercial platform, supports visual, Structured Rego, and selected native authoring, offers managed and self-managed PDP deployment, and provides Authorizers for distributed enforcement and data-layer controls. Cerbos combines an Apache 2.0 stateless Cerbos PDP with commercial Cerbos Hub and Cerbos Synapse components. The Cerbos PDP uses YAML or JSON policies with CEL conditions and supports shared-service, sidecar, DaemonSet, and selected serverless deployment. Cerbos Hub provides source-agnostic policy lifecycle, build, test, distribution, and audit aggregation. Cerbos Synapse provides decision-time enrichment, transformation, caching, and integration extensions. **PlainID** — Particularly fits organizations that want centralized policy governance across a large application estate. PlainID supports nondeveloper visual authoring, Structured Rego and selected native formats, and documents Authorizers for API, service-mesh, data, IdP, and SaaS integrations. Its SQL Authorizers provide row filtering plus column- and cell-level filtering or masking across documented data platforms. **Cerbos** — Fits engineering-owned, repository-based workflows while retaining centralized governance through Cerbos Hub. Policies are YAML or JSON with CEL conditions and can be 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 downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, also without a per-decision service call. Cerbos Hub is available as an enterprise on-premise deployment, including restricted and air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure. - **Policy review and history** — Cerbos supports repository diffs, pull requests, compile checks, and CI tests, while Cerbos Hub also supports source-agnostic policy stores and a managed validation and distribution pipeline. PlainID provides platform-native audit and history, and teams can also manage Structured Rego through APIs and source control. - **Integration scope** — Cerbos provides a local container and binary quick start. PlainID integration patterns can involve workspaces, templates, mappers, or Authorizers, while direct REST and SDK paths also exist. Test onboarding effort against one representative service. - **Who operates it** — Cerbos is designed to fit engineering-owned workflows and can add central governance through Cerbos Hub. PlainID emphasizes centralized governance commonly led by IAM, security, or platform teams. Operating ownership remains an organizational choice for either product. ## What enterprise buyers ask for Checked against public documentation from both vendors. Evidence links under each row point to the sources for each column. | Requirement | Cerbos | PlainID | | --- | --- | --- | | Distributed enforcement with a sidecar PDP | NATIVE — Ships as a standalone binary or container and supports shared-service, sidecar, DaemonSet, and selected serverless patterns. A standalone or Cerbos Hub-connected service PDP evaluates locally without a per-decision Cerbos Hub round trip. | DISTRIBUTED OPTIONS — Offers managed Cloud PDP and self-managed PAA PDP deployments; the documentation does not describe a sidecar PDP. PlainID centralizes policy governance while distributing PEP and Authorizer enforcement; topology depends on deployment. | | Policy authoring and source of truth | GIT NATIVE — Uses YAML or JSON 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 — Supports visual, Structured Rego, and selected native authoring. Structured Rego is API-importable and exportable and can be versioned in Git, but depends on PlainID metadata and platform objects. | | SDK language coverage | 8 LANGUAGES + LARAVEL — Provides gRPC and REST APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel. | MULTIPLE LIBRARIES — Documents REST APIs plus Java, .NET, and Python libraries for its SQL Authorizer. A Node.js PDP SDK is published on npm but not covered in the documentation. Compare maturity and use-case coverage for the required language. | | Decision time data and connectors | VIA SYNAPSE — The Cerbos PDP evaluates request-supplied context. Commercial Cerbos Synapse can enrich decisions from SQL, identity provider, graph, and API sources through built-in or custom extensions, with in-memory or Redis caching. | BUILT IN — Can retrieve external attributes at decision time and offers configurable identity, source, and decision caching, including Redis-backed options, plus a broad Authorizer library. | | Inline data filtering and masking | PARTIAL — PlanResources returns a query plan that reference adapters translate for the data layer. Cerbos Synapse proxy extensions can redact Cerbos API response fields. Cerbos does not provide an equivalent inline SQL interceptor. | BUILT IN — Rewrites queries to enforce row filtering and column or cell filtering and masking across documented databases and data platforms. This is a material PlainID strength. | | Decision logging and audit | BUILT IN — When enabled, 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. | VERIFY — Provides Authorization and Administration Audit reports. Cloud and self-hosted configurations differ; verify retention, format, and export against compliance requirements. | | AuthZEN compatibility | INTEROP READY — The current Cerbos PDP partially implements documented AuthZEN endpoints and has participated in published interoperability testing. Alex Olivier is one of the current AuthZEN Working Group cochairs. | INTEROP PARTICIPANT — PlainID and Cerbos both appear in published AuthZEN interoperability results. Compare the exact endpoints, specification version, and production support each vendor ships. | | Open source and pricing transparency | APACHE 2.0 — The Cerbos PDP is Apache 2.0. Cerbos publishes Cerbos Hub pricing, including a $0 proof of concept tier; Cerbos Hub and licensed Cerbos Synapse capabilities are commercial. | COMMERCIAL — Uses a contact-led sales motion. No public self-serve pricing or documented ongoing free tier was found as of 24 July 2026. Evaluation runs through a demo request. | ### Sources - [Cerbos deployment patterns](https://docs.cerbos.dev/cerbos/latest/deployment/) - [Cerbos Hub decision points](https://docs.cerbos.dev/cerbos-hub/decision-points.html) - [PlainID PDP](https://docs.plainid.io/docs/pdp-1) - [PlainID Policy Authorization Agents](https://docs.plainid.io/docs/about-paas-and-pips) - [Cerbos policy authoring](https://docs.cerbos.dev/cerbos/latest/policies/) - [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/policy-stores.html) - [PlainID Structured Rego](https://docs.plainid.io/apidocs/structured-rego) - [PlainID Policy Canvas](https://docs.plainid.io/docs/policy-canvas) - [PlainID Snowflake native policy support](https://docs.plainid.io/docs/sf-native-policy-support) - [Cerbos APIs and SDKs](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [PlainID integration patterns](https://docs.plainid.io/docs/integration-patterns) - [PlainID PDP SDK for Node.js](https://www.npmjs.com/package/plainid-pdp-sdk) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [Cerbos Synapse data sources](https://docs.cerbos.dev/synapse/latest/extensions/data-sources.html) - [PlainID PDP caching options](https://docs.plainid.io/docs/pdp-caching-options) - [PlainID PIP caching views](https://docs.plainid.io/docs/caching-views) - [PlainID Authorizers overview](https://docs.plainid.io/docs/authorizers) - [Cerbos query-plan adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html) - [Cerbos Synapse extensions](https://docs.cerbos.dev/synapse/latest/extensions/index.html) - [PlainID SQL Database Authorizer](https://docs.plainid.io/docs/sql-database-authorizer) - [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) - [PlainID Authorization Audit Report](https://docs.plainid.io/docs/authorization-audit-report) - [PlainID Administration Audit Report](https://docs.plainid.io/docs/about-audit-reports) - [PlainID Authorization Audit configuration](https://docs.plainid.io/docs/authorization-audit-configuration) - [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/) - [PlainID AuthZEN standard page](https://lp.plainid.com/standards/authzen) - [AuthZEN interop results: PlainID](https://www.authzen-interop.net/docs/scenarios/todo-1.1/results/plainid) - [Cerbos licence](https://github.com/cerbos/cerbos/blob/main/LICENSE) - [Cerbos pricing](https://www.cerbos.dev/pricing) - [PlainID demo request](https://www.plainid.com/demo/) Details change, so verify current capabilities with both vendors before you decide. ## The policy lifecycle starts in different places PlainID centers policy governance in its platform. Cerbos can start in Git and add centralized controls through Cerbos Hub. PlainID supports visual authoring, Structured Rego, selected native formats, policy history, and platform workflows. This model is a strong fit when IAM or security owns policy authoring across many applications. Cerbos resource and principal policies are YAML or JSON with CEL conditions. Teams can review changes in pull requests and run compile checks and policy tests in CI. Cerbos Hub adds source-agnostic policy stores, managed validation, signed bundle distribution, and audit aggregation. Cerbos Hub is not required for the Apache 2.0 Cerbos PDP to evaluate decisions. When Cerbos Hub is used, connected PDPs evaluate downloaded bundles locally rather than calling Cerbos Hub for each decision. Cerbos Hub Enterprise can run on-premise in restricted and air-gapped environments. ## Data enforcement is not a feature-for-feature match PlainID can enforce within documented data platforms. Cerbos returns authorization results that the application or adapter applies. PlainID SQL Authorizers document inline query rewriting for row filtering and column or cell filtering and masking. That is a material advantage when enforcement must sit inside the database access path. Cerbos PlanResources returns a datastore-agnostic query plan. The application translates that plan through an adapter and includes the resulting predicate in its own query. This keeps query execution and transaction ownership in application code, but it requires an adapter for the selected data layer. Cerbos Synapse proxy extensions can redact fields in Cerbos API responses. They are not an inline SQL interceptor and should not be presented as a replacement for PlainID's database enforcement. ## Decision-time data has separate runtime boundaries Both products can use external attributes, but Cerbos separates evaluation in the Cerbos PDP from optional enrichment in Cerbos Synapse. The standalone open source Cerbos PDP evaluates the principal, resource, and auxiliary data supplied with a request. It remains stateless and can run as a shared service, sidecar, or DaemonSet. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, with no per-decision service call. Cerbos Synapse can retrieve and transform decision context from SQL, identity provider, graph, API, and custom sources, with configured caching. Cerbos Synapse runs in customer-controlled infrastructure and sits in the request path only where enrichment or protocol transformation is required. PlainID documents external attribute retrieval, configurable caching, and Authorizers for multiple enforcement environments. Compare connector coverage, stale-data behavior, and failure handling against one representative attribute-heavy policy. ## Migrate one enforcement path before migrating the catalog Treat policy translation and enforcement replacement as separate workstreams. Start with one service whose authorization outcomes and data access can be observed. | PlainID concept | Cerbos | Notes | | --- | --- | --- | | Workspace, policy, and policy metadata | Policy repository or Cerbos Hub policy store | Map ownership, review, promotion, rollback, and export workflows before translating rules. | | Subject, asset, action, and context | Principal, resource, action, and request auxiliary data | Preserve identifiers and attribute provenance so both engines receive equivalent inputs. | | PDP or Authorizer decision | Cerbos PDP CheckResources request | Run shadow checks and compare normalized allow or deny results before changing enforcement. | | SQL Authorizer filtering or masking | PlanResources plus a data-layer adapter | This changes the enforcement boundary. Validate query semantics, masking requirements, and transaction behavior separately. | ### A controlled data-enforcement transition 1. **Capture** — Build a corpus of representative principals, resources, actions, context, and expected data results. 2. **Translate** — Express one authorization domain as Cerbos policies and encode expected decisions as policy tests. 3. **Shadow** — Call the Cerbos PDP without enforcing its result, then compare normalized decisions and decision logs. 4. **Adapt** — For list filtering, translate PlanResources output into the selected ORM or query builder and compare returned records. 5. **Cut over** — Move enforcement only after decision parity, query semantics, latency, and failure behavior meet the acceptance criteria. Inline SQL masking does not map directly. Keep PlainID on that path or implement and validate an explicit application-layer masking control. ## Where Cerbos is not a direct replacement The products overlap at runtime authorization but differ in authoring, integration packaging, and data enforcement. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | Visual policy authoring | Cerbos policies are YAML or JSON with CEL conditions. Cerbos Hub governs policy lifecycle but does not reproduce PlainID's visual authoring model. | If nondevelopers must construct policies visually, validate author workflows before selecting Cerbos. | | Inline database filtering and masking | PlanResources returns a query plan for an application adapter. Cerbos does not provide an equivalent inline SQL interceptor. | Retain PlainID for the data path or budget explicit adapter and masking work. | | Packaged Authorizer breadth | Cerbos exposes REST, gRPC, SDK, proxy, and adapter integration patterns. Coverage differs by target technology. | Inventory every enforcement point and prototype the least common integration before committing to migration. | ## Openness 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. PlainID Structured Rego uses Rego v1 plus required PlainID metadata and platform-object conventions. It can be edited in the UI or managed through import and export APIs and source control. PlainID's native APIs and platform metadata may create migration work, so request contract terms, policy export samples, AuthZEN production support, and an exit test before purchase. Both vendors have participated in published AuthZEN interoperability testing. The Cerbos PDP partially implements documented AuthZEN endpoints, and Alex Olivier of Cerbos is one of the current AuthZEN Working Group cochairs. Compare supported endpoint sets and specification versions in a representative integration. ## Use Cerbos as the default application-authorization path Cerbos is the stronger overall choice when application teams need an open PDP, policy as code, local decisions, managed distribution, and application-controlled query filtering. Prove that model with one policy change containing an attribute condition and a filtered list. Implement it as Cerbos policy and tests, distribute it through Git or Cerbos Hub, run shadow decisions, and apply a PlanResources result to the real data layer. Keep PlainID only where its inline data enforcement or visual authoring is a verified requirement. ## Questions you are probably asking ### PlainID supports policy as code too. Is that not the same thing? PlainID supports code and visual workflows around a centrally governed policy catalog. Its Structured Rego uses PlainID metadata and platform objects, while Cerbos is repository-native and Cerbos Hub also supports centrally governed, source-agnostic stores. Ask each vendor to demonstrate a policy change, review, failing test, promotion, export, and rollback. ### We need row and column level data filtering. Does Cerbos match PlainID there? PlainID documents inline SQL rewriting, row filtering, and column or cell filtering and masking across several data platforms; verify database-specific limitations. Cerbos PlanResources returns a query plan that the application applies through an adapter, while Cerbos Synapse extensions can redact Cerbos API response fields. If inline database masking is required, PlainID has the stronger documented mechanism. If filtering should remain in the application data path, Cerbos provides that model. ### PlainID is recognized by analysts. Is Cerbos enterprise ready? PlainID is listed in current Gartner and KuppingerCole research across authorization and adjacent identity, data, and API categories. Cerbos documents self-hosted production patterns, while Cerbos Hub adds managed policy build, test, distribution, and audit aggregation across Git, API, SDK, CLI, CI/CD, and browser-upload workflows. The open source Cerbos PDP and published Cerbos Hub tiers can be evaluated self-serve; scope a proof of concept around one real service. ### Our business users need to author policy without engineers. Does that rule out Cerbos? If nondevelopers author policy in a central console, PlainID may be a strong fit. Cerbos policies use human-readable YAML or JSON with CEL conditions, but the default workflow is code-first and should be tested with the intended authors. Cerbos Hub adds centralized governance without requiring Git as the only source. ### Can we integrate Cerbos with our identity stack the way PlainID integrates with IdPs? With JWKS or keysets configured, the Cerbos PDP can verify and consume JWT claims from an IdP; applications and gateways should still perform authoritative token validation. Cerbos Synapse can query identity provider or directory APIs through configured or custom extensions and cache results. Validate the exact provider, connector implementation, and failure behavior. ## The short version **Cerbos strengths** - Combines an Apache 2.0 Cerbos PDP with Cerbos Hub policy lifecycle management and Cerbos Synapse enrichment and integration capabilities - Uses YAML or JSON policies with CEL conditions across repository-native and source-agnostic Cerbos Hub workflows - Supports standalone, shared-service, sidecar, DaemonSet, and selected serverless PDP deployment patterns - Provides gRPC and REST APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel - Can record allow or deny decisions and matched-policy metadata when logging is enabled - Partially implements documented AuthZEN endpoints and has participated in published interoperability testing **Weigh with PlainID** - Inline SQL rewriting with row filtering and column or cell filtering and masking is a material PlainID strength - A broad library of prebuilt Authorizers may reduce integration work; validate the required technology and version - The visual wizard suits organizations where nondevelopers author policy - Current analyst recognition across authorization and adjacent identity, data, and API categories - Deployments can involve workspaces, templates, mappers, and Authorizers depending on the integration pattern - Portability requires validation because Structured Rego depends on PlainID metadata and platform objects, although APIs and source-control workflows are supported Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- title: "Two approaches to enterprise ABAC" description: "Axiomatics, a Leonardo company since December 2025, provides a commercial XACML and ALFA authorization suite. Cerbos combines an Apache 2.0 YAML and CEL policy engine with optional Cerbos Hub and Cerbos Synapse components. Teams with an existing XACML estate should compare policy semantics and operating requirements case by case." competitor: "Axiomatics" reviewed: "2026-07-24" prepared_by: "Cerbos" canonical: "https://www.cerbos.dev/cerbos-vs-axiomatics" source: "https://www.cerbos.dev/cerbos-vs-axiomatics" --- # Two approaches to enterprise ABAC Axiomatics, a Leonardo company since December 2025, provides a commercial XACML and ALFA authorization suite. Cerbos combines an Apache 2.0 YAML and CEL policy engine with optional Cerbos Hub and Cerbos Synapse components. Teams with an existing XACML estate should compare policy semantics and operating requirements case by case. Prepared by the Cerbos team. Facts last checked on 24 July 2026. ## Verdict **Choose Cerbos when** - New application-authorization work needs authorization-specific YAML or JSON policies with CEL conditions and a self-service development loop. - A stateless Apache 2.0 PDP must run close to workloads in sidecar, shared-service, Kubernetes, serverless, or edge topologies. - The program can migrate XACML semantics incrementally and validate them with dual evaluation. **Consider Axiomatics when** - The existing XACML and ALFA estate is stable, governed, and more expensive to translate than to operate. - XACML semantic continuity, CAQ entitlement analysis, or specialist XACML services are primary requirements. **Already on Axiomatics? Switching probably is not worth it when** - The XACML or ALFA estate is stable, and translating it would cost more than operating it. - Obligations, combining behavior, or CAQ entitlement analysis carry real controls and nothing is planned to replace them. ## Commercial XACML suite, open source YAML and CEL PDP Axiomatics is a long-established commercial authorization vendor. Its personnel contributed to XACML, and its platform provides PAP, PDP, PEP, and PIP components around XACML and ALFA. Cerbos provides fine-grained ABAC through an Apache 2.0 Go Cerbos PDP using YAML or JSON policies with CEL conditions, plus commercial Cerbos Hub and Cerbos Synapse components for lifecycle management, distribution, audit aggregation, enrichment, and integrations. The material differences are policy language and semantics, product packaging, governance workflow, licensing, and commercial model. XACML remains an OASIS policy standard. AuthZEN standardizes the interface between enforcement points and decision points independently of the policy language behind the PDP. **Axiomatics** — Fits enterprise and regulated-sector programs that value XACML and ALFA, centralized policy management, professional services, audit data, and CAQ-based entitlement analysis. Axiomatics has offered patented reverse-query technology since 2011 and remains active in AuthZEN. It is a mature continuity option for an existing XACML estate. **Cerbos** — Fits teams that want a self-service path to fine-grained authorization. The self-hosted Apache 2.0 Go Cerbos PDP is available as a binary or container and is documented for Kubernetes, sidecar, serverless, and edge deployment. For supported JavaScript environments where embedded evaluation is appropriate, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, without a service call for each decision. Cerbos Hub Enterprise can run on-premise, including in restricted and air-gapped environments, while Cerbos Synapse runs in customer-controlled infrastructure. Policies are YAML or JSON with CEL conditions and can be versioned in Git with validation and tests. - **Policy language** — Cerbos stores YAML or JSON policies with CEL conditions. Axiomatics supports ALFA as policy as code, compiles it to XACML, and documents Git and CI/CD workflows. OASIS published an ALFA working draft in 2015, but it is not an approved OASIS Standard. - **Runtime footprint** — Cerbos deploys as a Go binary or container without a separate language VM. Axiomatics documents JAR, Kubernetes, REST and JSON microservice, sidecar, service-mesh, node, and cluster patterns. Benchmark startup, footprint, and throughput in the target topology for both products. - **Evaluation workflow** — Cerbos provides public tooling to author, test, and run a policy without a mandatory services engagement. Axiomatics routes public evaluation through demo and contact paths and also documents policy as code, DevOps tooling, professional services, and a deployment methodology. ## Selected product dimensions Checked against Cerbos documentation, neutral standards, and Axiomatics' own documentation. Evidence links under each row point to the sources for each column. | Requirement | Cerbos | Axiomatics | | --- | --- | --- | | Distributed sidecar enforcement | NATIVE — Runs as a self-hosted binary or container and supports sidecar, Kubernetes, serverless, and edge deployment patterns. | SUPPORTED — Documents JAR and Kubernetes deployment, a REST API, and shared-service, sidecar, and Istio or Envoy service-mesh integration patterns. Benchmark both products in the target topology. | | Policy language and authoring | GIT NATIVE — Uses YAML or JSON policies with CEL conditions. Policies can be versioned in Git with compile checks, test suites, and pull request review. | ALFA / XACML — Supports ALFA policy as code or a web editor, with compilation, Git, CI/CD, and automated testing. ALFA has an OASIS working draft but is not a ratified OASIS Standard. | | Decision time attribute retrieval | VIA SYNAPSE — Keeps the open source Cerbos PDP stateless, with callers passing context. Cerbos Synapse is a commercial platform component, also included within the $0 PoC tier, that supports decision-time enrichment and caching. | BUILT IN — Pulls attributes from LDAP, SQL, and REST sources through mature PIP connectors at decision time. | | Data filtering and reverse query | BUILT IN — PlanResources returns a datastore-agnostic query plan, with reference adapters for Prisma, Drizzle, Mongoose, Convex, LangChain/ChromaDB, and SQLAlchemy. | BUILT IN — Released reverse-query technology in 2011, since patented. CAQ, available in Access Decision Service, supports entitlement analysis and application data filtering. | | Decision logging and obligations | BUILT IN — Emits configurable structured decision logs. Rule outputs provide advisory data for the enforcement point on allow and deny paths. | BUILT IN — Provides XACML obligations and advice, which the XACML 3.0 standard requires the enforcement point to fulfill, plus audit logging in Access Decision Service that is off by default. | | Compliance and access review tooling | PARTIAL — Provides decision logs, policy tests, and Git history as technical evidence sources. Auditor acceptance and compliance depend on the wider control environment. | ANALYTICAL — CAQ supports contextual entitlement analysis that can inform access reviews. Verify campaign workflow, attestation, remediation, certification, and IGA integration requirements. | | AuthZEN compatibility | INTEROP READY — The Cerbos PDP partially implements the AuthZEN Authorization API. Alex Olivier is one of the current AuthZEN Working Group cochairs. | ACTIVE — David Brossard is one of the current Working Group cochairs. Axiomatics and Cerbos have both participated in AuthZEN interoperability demonstrations. | | Open source and pricing transparency | APACHE 2.0 — The Cerbos PDP is Apache 2.0. Cerbos publishes $0, development, production, and enterprise platform tiers; the $0 PoC tier includes limited Cerbos Hub and Cerbos Synapse usage. | COMMERCIAL — No public list pricing or public self-service free tier was found in the official sources reviewed. Contact Axiomatics for demo, evaluation licensing, services, and pricing. | ### Sources - [Cerbos deployment](https://docs.cerbos.dev/cerbos/latest/deployment/index.html) - [Axiomatics Access Decision Service deployment](https://docs.axiomatics.com/access-decision-service/installation/deployment/) - [Axiomatics blog: authorization deployment Q&A](https://axiomatics.com/blog/feeling-anxious-about-your-authorization-deployment-we-have-a-qa-for-that) - [Cerbos policies](https://docs.cerbos.dev/cerbos/latest/policies/index.html) - [OASIS ALFA draft](https://www.oasis-open.org/committees/document.php?document_id=55228&wg_abbrev=xacml) - [Axiomatics Policy DevOps CI/CD integrations](https://docs.axiomatics.com/axiomatics-policy-devops/integrations-cicd/) - [Axiomatics blog: Is ALFA part of the OASIS XACML standards?](https://axiomatics.com/blog/is-alfa-a-part-of-the-oasis-xacml-technical-committee-series-of-standards) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [Axiomatics ADS docs: Attribute connectors](https://docs.axiomatics.com/access-decision-service/attribute-connectors/) - [Axiomatics docs: LDAP attribute connector](https://docs.axiomatics.com/attribute-connectors/ldap-ac) - [Cerbos PlanResources adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html) - [Axiomatics press release: Reverse Query](https://axiomatics.com/news/press-releases/axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services) - [Axiomatics blog: Contextual Authorization Query](https://axiomatics.com/blog/contextual-authorization-query-simplifying-entitlement-reviews-and-data-filtering) - [Cerbos audit logs](https://docs.cerbos.dev/cerbos/latest/configuration/audit.html) - [Cerbos rule outputs](https://docs.cerbos.dev/cerbos/latest/policies/outputs.html) - [Axiomatics ALFA docs: Obligations and advice](https://docs.axiomatics.com/alfa/policy-authoring/obligations-and-advice/) - [Axiomatics ADS docs: Audit logging](https://docs.axiomatics.com/access-decision-service/metrics-tracing-logging/audit-logging/) - [Cerbos policy testing](https://docs.cerbos.dev/cerbos/latest/tutorial/04_testing-policies.html) - [Cerbos AuthZEN API](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [AuthZEN Working Group](https://openid.net/wg/authzen/) - [AuthZEN interoperability](https://authzen-interop.net/docs/intro/) - [OpenID Foundation: AuthZEN interop results](https://openid.net/authorization-interop-results/) - [Cerbos licence](https://github.com/cerbos/cerbos/blob/main/LICENSE) - [Cerbos pricing](https://www.cerbos.dev/pricing) - [Axiomatics: Request a demo](https://axiomatics.com/demo/) Details change, so verify current capabilities with both vendors before you decide. ## Syntax translation is the smallest part of migration Subject, resource, action, and environment attributes map cleanly in many cases. XACML evaluation semantics require explicit analysis. Many ALFA or XACML target and condition expressions can be expressed through Cerbos principals, resources, actions, derived roles, and CEL conditions. Policy sets, rule and policy combining algorithms, Indeterminate results, missing-attribute behavior, obligations, advice, and custom functions do not have a mechanical one-to-one mapping. A translator that only rewrites syntax can preserve the apparent rule while changing the decision. Build a semantic inventory before translation. Classify each construct as direct, equivalent with restructuring, application-enforced, or unsupported. Use production-derived scenarios and edge cases to compare normalized outcomes from both engines. ## PIP and PDP responsibilities move independently Cerbos keeps the open source Cerbos PDP stateless. Decision-time retrieval belongs in the caller or in customer-controlled Cerbos Synapse. Axiomatics packages PAP, PDP, PEP, and PIP concepts around XACML and ALFA. Existing policies may assume that attributes are resolved through configured PIPs during evaluation. The Cerbos PDP evaluates attributes supplied in the authorization request. Cerbos Synapse can retrieve, transform, and cache context from SQL, identity provider, graph, API, or custom sources before forwarding the decision to the Cerbos PDP. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, with no per-decision service call. It remains distinct from the standalone open source Cerbos PDP. Cerbos Synapse is commercial and runs in customer-controlled infrastructure. Cerbos Hub provides policy lifecycle, test, signed distribution, and audit aggregation; it does not perform decision-time attribute enrichment. ## XACML continuity remains a valid reason to stay A mature XACML program contains policy semantics, operating practices, audit evidence, and specialist knowledge. Axiomatics supports ALFA policy as code, compilation to XACML, Git and CI/CD workflows, centralized management, and professional services. A move to Cerbos should not be justified by assuming that XACML cannot support modern engineering workflows. Cerbos provides a smaller authorization-specific model and a public self-service development path. Cerbos Hub can govern source-agnostic policy stores and run as an enterprise on-premise deployment, including restricted and air-gapped environments. Migration is justified only when the target operating model reduces enough policy, runtime, or integration cost to repay semantic translation and revalidation. ## Build a semantic map before changing enforcement Inventory policy constructs and observable outcomes first. Translate one bounded authorization domain and keep the existing PDP authoritative during comparison. | XACML or ALFA concept | Cerbos | Notes | | --- | --- | --- | | Subject, resource, action, environment | Principal, resource, action, auxiliary data | Record attribute identifiers, types, issuers, defaults, and source systems. | | Target and condition | Rule scope plus CEL condition | Test absent, null, malformed, and multivalued attributes, not only the expected path. | | Policy set and combining algorithm | Policy scope, rule ordering, and explicit effect design | No universal mapping exists. Derive the intended decision table and model it explicitly. | | Obligation or advice | Structured rule output enforced by the application or PEP | Cerbos output is not a XACML must-fulfill contract. The enforcement point must implement and test the behavior. | | PIP attribute retrieval | Caller-supplied context or Cerbos Synapse enrichment | Map source, cache, timeout, stale-data, and fail-open or fail-closed behavior for each attribute. | ### Dual evaluation for one policy domain 1. **Inventory** — Extract policies, combining algorithms, functions, obligations, attribute sources, and error behavior. 2. **Normalize** — Define a shared request fixture and normalize each engine's response into allow, deny, or evaluation error plus outputs. 3. **Translate** — Model the intended decision table in Cerbos policies and encode representative cases as policy tests. 4. **Replay** — Send production-derived and boundary cases to both PDPs without changing the authoritative enforcement result. 5. **Resolve** — Classify every mismatch as input, semantic, output-enforcement, or engine-error behavior before cutover. Passing a replay corpus increases confidence but does not prove full semantic equivalence. High-impact rules still require policy-owner review. ## Where Cerbos does not reproduce the XACML suite Cerbos covers fine-grained application authorization through a different policy and runtime model. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | XACML semantic compatibility | Cerbos uses authorization-specific YAML or JSON policies with CEL conditions rather than XACML or ALFA. | Treat migration as semantic remodeling and dual evaluation, not file conversion. | | Obligations and advice | Rules can return structured output, but the application or enforcement point must interpret and enforce it. | Map each obligation separately and test failure behavior where fulfillment is mandatory. | | CAQ entitlement analysis | Cerbos evaluates requests, tests policies, and records decisions when logging is enabled. It does not reproduce CAQ or packaged recertification workflows. | Keep the existing analysis capability or integrate an IGA and reporting workflow where entitlement review is required. | ## The migration path from XACML Moving off a XACML estate is a project. The products share core ABAC concepts, but migration requires a semantic gap analysis. Many subject, action, resource, and environment conditions can be expressed in Cerbos policies and CEL. Policy hierarchy, combining behavior, obligations and advice, error semantics, and custom functions require separate validation. One practical approach is an incremental, service-by-service migration. A customer-built harness can send representative requests to both engines and compare normalized results. Build a test corpus from production scenarios and policy edge cases. Passing it increases confidence but does not prove exhaustive equivalence. Cerbos supports Git-based policy review and testing, stateless PDP deployment, structured decision logs that can support audit evidence, and AuthZEN endpoints. Operational responsibility depends on the selected Cerbos PDP, Cerbos Hub, and Cerbos Synapse deployment model. Contact Cerbos to discuss an assisted policy-mapping and dual-evaluation exercise, subject to scope and data-handling terms. ## Use Cerbos for the next application-authorization boundary Cerbos is the stronger overall choice for a new or incrementally modernized authorization domain because the Apache 2.0 Cerbos PDP, authorization-specific policies, tests, and cloud-native deployment remove the need to extend the XACML estate. Prove the recommendation with a bounded policy set containing attribute retrieval, a combining rule, and an obligation. Run both PDPs in parallel and review every mismatch before moving enforcement. Keep Axiomatics authoritative only where XACML continuity or CAQ remains a verified requirement. ## Questions you are probably asking ### Axiomatics personnel helped author and edit XACML. Why move off it? Some teams prefer YAML or JSON with CEL and a smaller self-service PDP footprint. Others value Axiomatics' XACML continuity and broader management suite. AuthZEN defines a PEP-to-PDP API independently of either policy language. Benchmark both products in the target topology, and migrate only when the operating benefit exceeds the migration cost. ### We rely on PIP attribute lookups. Does Cerbos force us to rebuild that? The model differs. The open source Cerbos PDP is stateless and evaluates context supplied with the request. Cerbos Synapse supports comparable categories of decision-time enrichment, including SQL databases, identity provider APIs, graph stores, other services, and configurable caching. Validate each required connector, transformation, cache, and failure mode. ### Does Cerbos have obligations and advice like XACML? Cerbos outputs can carry structured rule data for similar application use cases, including field masking, audit logging, and notifications when implemented by the application or enforcement point. They are not XACML obligations or advice and do not provide the same must-fulfill protocol contract. Map and test each obligation use case separately. ### Our program needs access recertification. Can Cerbos do it? Packaged recertification campaigns are an identity governance function, and neither PDP replaces an IGA tool. Cerbos evaluates each request against the active policy, logs authorization decisions when configured, and runs policy tests against specified scenarios. Axiomatics CAQ can support entitlement analysis. Verify the campaign workflow and evidence requirements with the IGA and audit teams. ## The short version **Cerbos strengths** - Delivers fine-grained ABAC through an Apache 2.0 Go Cerbos PDP with documented cloud-native deployment patterns - Uses YAML or JSON policies with CEL conditions, with Git-based review and testing options - Supports sidecar, serverless, Kubernetes, and edge deployment patterns - Offers public self-service tooling for a first working decision without a mandatory services engagement - Provides decision logs, structured outputs, and test suites that can serve as audit evidence - Publishes pricing with a free tier **Weigh with Axiomatics** - Operating since 2006, with personnel who contributed to XACML - Documented LDAP, SQL, and HTTP attribute connectors, plus patented reverse-query technology offered since 2011 - CAQ-based entitlement analysis that can support access-review and recertification processes; verify campaign workflow requirements separately - Professional services and a documented deployment methodology alongside self-managed policy as code and DevOps tooling - A wholly owned Leonardo subsidiary since 22 December 2025; buyers with ownership or supply-chain requirements should assess the implications - No public list pricing or public self-service free tier was found; the official site routes evaluation through demo and contact Contact Cerbos to discuss an assisted policy-mapping and dual-evaluation exercise, subject to scope and data-handling terms. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- title: "Different authoring and operating models" description: "PingAuthorize is a commercial, self-managed ABAC platform with visual authoring and several runtime integration patterns. Cerbos combines an Apache 2.0 stateless Cerbos PDP with optional Cerbos Hub and Cerbos Synapse components for lifecycle management, distribution, audit aggregation, enrichment, and protocol integrations." competitor: "PingAuthorize" reviewed: "2026-07-24" prepared_by: "Cerbos" canonical: "https://www.cerbos.dev/cerbos-vs-ping-authorize" source: "https://www.cerbos.dev/cerbos-vs-ping-authorize" --- # Different authoring and operating models PingAuthorize is a commercial, self-managed ABAC platform with visual authoring and several runtime integration patterns. Cerbos combines an Apache 2.0 stateless Cerbos PDP with optional Cerbos Hub and Cerbos Synapse components for lifecycle management, distribution, audit aggregation, enrichment, and protocol integrations. Prepared by the Cerbos team. Facts last checked on 24 July 2026. ## Verdict **Choose Cerbos when** - Services need local authorization decisions through sidecar or DaemonSet PDPs, with shared-service deployment retained where appropriate. - The authorization layer must remain independent of the identity provider and accept identity context from Ping or another IdP. - Teams want Git or source-agnostic policy workflows around an Apache 2.0 PDP with published platform tiers. **Consider PingAuthorize when** - Ping-native identity and gateway integration removes material implementation work. - Its visual authoring, packaged gateway topology, and ordered attribute resolvers are firm requirements. **Already on PingAuthorize? Switching probably is not worth it when** - Ping-native identity and gateway integrations carry the implementation, and replacing them would add more custom work than the switch saves. - Policy authors rely on the Visual Policy Editor and ordered attribute resolvers, and nobody has mapped those to code-first policy and Cerbos Synapse. ## Compare the proposed topology, not a centralized-distributed binary PingAuthorize uses a visual Policy Editor and self-managed PingAuthorize Servers. Each Server embeds its PDP and can be deployed in reverse-proxy, sideband, SCIM, or PDP API architectures. Stateless Server instances can scale behind a load balancer, so PingAuthorize is not limited to one centralized runtime instance. Cerbos provides an Apache 2.0 stateless Cerbos PDP that can run as a shared service, sidecar, DaemonSet, or selected serverless deployment. Cerbos Hub manages policy build, testing, signing, distribution, and audit aggregation across Git and source-agnostic policy stores. Cerbos Synapse adds decision-time context, transformations, caching, and integration protocols. Compare PEP placement, runtime hops, policy promotion, attribute retrieval, and licence packaging in the proposed topology. **PingAuthorize** — Fits organizations that want a commercial, self-managed authorization platform with a visual Policy Editor, branches, commits, snapshots, deployment packages, approvals, and rollback. Ping-native integrations are a strength, while JWT, third-party SDK-based identity, external-gateway validators, PDP APIs, sideband, SCIM, and gateway patterns broaden the supported estate. **Cerbos** — Fits engineering teams that want to select deployment topology per workload while keeping the policy engine independent of the identity provider. The Cerbos PDP is self-hosted and consumes request context from any provider. Cerbos Hub supports Git, API, SDK, CLI, CI/CD, and browser-upload policy workflows, with an enterprise on-premise option for restricted and air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure. - **Latency and availability** — Cerbos sidecar or DaemonSet deployments support local decisions, while shared-service deployment remains available. For supported JavaScript environments where embedded evaluation is appropriate, Cerbos Hub's commercial ePDP evaluates downloaded Cerbos Hub-managed bundles in-process through WebAssembly, with no per-decision service call. PingAuthorize supports multiple stateless Servers across gateway, sideband, SCIM, and PDP API patterns. Measure hops, throughput, failover, and policy-update behavior in each proposed topology. - **Identity coupling** — Cerbos consumes claims and attributes independently of the identity provider. PingAuthorize supports Ping-native integration plus JWT, third-party, and external-gateway identity validators. Identify which proposed capabilities require other Ping products and which accept third-party identity context. - **Agent and service traffic** — An architecture that authorizes each agent tool call and service hop creates more checks than perimeter-only authorization. Cerbos supports local or shared checks, and PingAuthorize exposes PDP APIs for application and service authorization in addition to gateway integration. ## Selected product dimensions Checked against public documentation from both vendors. Evidence links under each row point to the sources for each column. | Requirement | Cerbos | PingAuthorize | | --- | --- | --- | | Distributed enforcement with a sidecar PDP | NATIVE — Supports shared-service, sidecar, DaemonSet, and selected serverless deployments. In sidecar or DaemonSet topologies, the service PDP evaluates locally without a per-decision Cerbos Hub round trip. | MULTIPLE TOPOLOGIES — Each self-managed Server embeds a PDP. PingAuthorize documents reverse-proxy, sideband, SCIM, and PDP API architectures, with stateless instances scaled behind a load balancer. | | Works with any identity provider | VENDOR NEUTRAL — Consumes identity context from any provider, including Ping-issued JWTs or mapped principal data. Cerbos Synapse can query identity provider APIs through configured or custom extensions. | PING-NATIVE + THIRD-PARTY — Supports PingFederate, JWT, third-party SDK-based, and external-gateway identity validators. Confirm which proposed features require other Ping products. | | SDK language coverage | 8 LANGUAGES + LARAVEL — Provides REST and gRPC APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel. | API-LED — Provides JSON PDP APIs, a subset XACML-JSON PDP API, gateway, sideband, and SCIM integrations, Policy Editor APIs, and a Java Server SDK for extensions. Verify licence requirements and application client coverage. | | Multi team policy management | HUB + GIT WORKFLOWS — Cerbos Hub supports Git and source-agnostic policy stores, then compiles, tests, signs, and distributes policy bundles. Repository pull-request review is one supported workflow. | UI FIRST — Uses a Policy Editor for technical and business users, with branches, commits, snapshots, deployment packages, approvals, workflows, and revert capabilities. | | Decision time data and connectors | VIA SYNAPSE — The stateless Cerbos PDP evaluates request-supplied context. Licensed Cerbos Synapse supports SQL, external APIs, IdPs, graph stores, custom sources, and in-memory or Redis caching. | BUILT IN — Retrieves and combines request, constant, service, attribute, system, and configuration-key sources with ordered and conditional processing. This is a documented PingAuthorize strength. | | Decision logging and audit | BUILT IN — When enabled, emits structured decision logs to file, Kafka, local storage, or Cerbos Hub. Cerbos Hub adds managed collection and search. | BUILT IN — Provides a policy-decision log and Decision Visualizer for recent or pasted responses. Verify retention, forwarding, and licensed operational requirements. | | AuthZEN compatibility | INTEROP READY — The Cerbos PDP partially implements AuthZEN Authorization API 1.0. Alex Olivier is one of the current AuthZEN Working Group cochairs. | VERIFY — Documents XACML 3.0 JSON Profile, SCIM 2.0, and OAuth-based integrations. No first-party PingAuthorize AuthZEN support was found as of 15 October 2026. The AuthZEN interop results list PingAuthorize through a third-party ID Partners adapter; confirm the support model with Ping. | | Open source and pricing transparency | APACHE 2.0 — The Cerbos PDP is Apache 2.0. Cerbos publishes pricing for the combined Cerbos Hub and Cerbos Synapse platform, including a $0 proof of concept tier. | COMMERCIAL — Requires a commercial licence key, and some features are licence-tier dependent. No public PingAuthorize unit price was found; Ping routes prospects through sales. | ### Sources - [Cerbos deployment](https://docs.cerbos.dev/cerbos/latest/deployment/) - [Cerbos Hub decision points](https://docs.cerbos.dev/cerbos-hub/decision-points.html) - [PingAuthorize architecture overview](https://docs.pingidentity.com/pingauthorize/11.1/paz_architecture_overview.html) - [PingAuthorize clustering and scaling](https://docs.pingidentity.com/pingauthorize/11.1/installing_and_uninstalling_pingauthorize/paz_clustering_scaling.html) - [Cerbos JWT claims](https://docs.cerbos.dev/cerbos/latest/recipes/jwt-claims.html) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [PingAuthorize access token validator types](https://docs.pingidentity.com/pingauthorize/11.1/pingauthorize_server_administration_guide/paz_access_token_val_types.html) - [Cerbos APIs and SDKs](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [PingAuthorize Authorization Policy Decision APIs](https://docs.pingidentity.com/pingauthorize/11.1/pingauthorize_server_administration_guide/paz_authr_policy_decision.html) - [PingAuthorize Server SDK extensions](https://docs.pingidentity.com/pingauthorize/11.1/pingauthorize_server_administration_guide/paz_managing_sdk_extensions.html) - [Cerbos Hub](https://docs.cerbos.dev/cerbos-hub/index.html) - [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/policy-stores.html) - [PingAuthorize Policy Editor version control](https://docs.pingidentity.com/pingauthorize/11.1/pingauthorize_policy_administration_guide/paz_version_control.html) - [PingAuthorize introduction](https://docs.pingidentity.com/pingauthorize/11.1/paz_introduction.html) - [Cerbos Synapse data sources](https://docs.cerbos.dev/synapse/latest/extensions/data-sources.html) - [PingAuthorize attribute resolvers](https://docs.pingidentity.com/pingauthorize/11.1/pingauthorize_policy_administration_guide/paz_resolvers.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) - [PingAuthorize Decision Visualizer](https://docs.pingidentity.com/pingauthorize/11.1/pingauthorize_policy_administration_guide/paz_visualize_pol_resp.html) - [Cerbos AuthZEN API](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [AuthZEN Working Group](https://openid.net/wg/authzen/) - [Cerbos licence](https://github.com/cerbos/cerbos/blob/main/LICENSE) - [Cerbos pricing](https://www.cerbos.dev/pricing) - [PingAuthorize license keys](https://docs.pingidentity.com/pingauthorize/11.1/installing_and_uninstalling_pingauthorize/paz_license_keys.html) - [PingAuthorize Premier requirement for PDP APIs](https://docs.pingidentity.com/pingauthorize/11.1/pingauthorize_server_administration_guide/paz_authr_policy_decision.html) - [Ping Identity pricing page](https://www.pingidentity.com/en/platform/pricing.html) Details change, so verify current capabilities with both vendors before you decide. ## The request path determines the comparison Compare the exact enforcement and decision topology, not generic claims about centralized or distributed authorization. PingAuthorize documents gateway, sideband, SCIM, application, and service PDP API patterns. A gateway deployment concentrates enforcement at the gateway, while application and service integrations can place checks deeper in the request path. Cerbos PDPs can run as a shared service, sidecar, or DaemonSet. Sidecar evaluation shares a workload failure boundary and can avoid a remote service hop. A shared service reduces instance count but adds a network dependency to each check. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, without a per-decision service call. Cerbos Hub distributes signed policy bundles and aggregates audit data; it is not called for each decision. Cerbos Hub Enterprise can run on-premise in restricted and air-gapped environments. Cerbos Synapse joins the request path only where enrichment or protocol transformation is required and runs in customer-controlled infrastructure. ## Identity integration does not require identity lock-in Ping identity can remain authoritative while Cerbos evaluates application authorization. Applications or gateways authenticate the principal and pass verified identity claims and application context into the authorization request. The Cerbos PDP can verify configured JWTs, but authoritative authentication remains an identity or application concern. This permits a split in which Ping handles authentication and identity lifecycle while Cerbos handles application and service authorization. It also permits multiple identity providers to feed the same authorization model. PingAuthorize remains a reasonable choice when its native Ping integrations, Policy Editor, attribute resolvers, and gateway deployment reduce more work than a vendor-neutral authorization layer would. ## Attribute retrieval changes latency and failure behavior Resolver breadth matters, but so do cache policy, timeouts, and the location of each lookup. PingAuthorize documents ordered and conditional attribute resolvers. This can centralize decision-time retrieval inside the authorization system. The Cerbos PDP is stateless and evaluates supplied context. Licensed Cerbos Synapse retrieves, transforms, and caches context from configured or custom sources before a Cerbos PDP decision. For either product, test fresh and stale cache entries, partial source failure, timeout behavior, and the handling of absent attributes. A connector list does not establish production behavior. ## Map topology before translating policy Start with the current request path. Identify where identity is verified, where authorization is enforced, where attributes are retrieved, and which component remains available during each failure. | PingAuthorize concept | Cerbos | Notes | | --- | --- | --- | | Policy Editor and deployment package | Policy repository or Cerbos Hub policy store and signed bundle | Map review, approval, promotion, rollback, and emergency-change controls. | | Gateway or sideband enforcement | Gateway integration, application call, sidecar, or shared Cerbos PDP | Select the topology per workload instead of forcing one network path across the estate. | | Application or service PDP API | CheckResources over gRPC, REST, or an SDK | Normalize principal, resource, action, and contextual attributes at the enforcement boundary. | | Attribute resolver | Caller-supplied context or Cerbos Synapse data source | Preserve ordering, cache, timeout, and missing-attribute semantics where they affect decisions. | ### A local decision path behind Ping identity 1. **Authenticate** — The gateway or application validates the Ping-issued token and derives the application principal. 2. **Assemble context** — The application supplies resource attributes directly or calls customer-controlled Cerbos Synapse where external enrichment is required. 3. **Evaluate locally** — The service calls its sidecar or node-local Cerbos PDP with principal, resource, action, and context. 4. **Enforce** — The service applies the allow or deny result and any structured policy output at the operation boundary. 5. **Operate** — Cerbos Hub distributes signed policies and aggregates configured audit records without joining the per-decision request path. A shared-service Cerbos PDP is also valid. Benchmark both topologies with the required check volume and dependency failures. ## Where Cerbos requires a different integration Cerbos can coexist with Ping identity, but it does not reproduce every PingAuthorize integration or authoring surface. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | Ping-native platform integration | Cerbos consumes verified identity context through standard application, gateway, API, and SDK boundaries. | If a native Ping integration removes material custom work, include that work explicitly in the Cerbos proof of concept. | | Visual Policy Editor | Cerbos policies use YAML or JSON with CEL conditions and repository or Cerbos Hub lifecycle workflows. | Test the intended policy authors and approval process rather than assuming a code-first workflow will fit. | | Ordered built-in attribute resolvers | The Cerbos PDP evaluates supplied attributes. Cerbos Synapse provides commercial enrichment and transformation from customer-controlled infrastructure. | Map each resolver to the caller or Cerbos Synapse and verify ordering, caching, timeout, and licence requirements. | ## The pattern analysts recommend Gartner's October 2025 Runtime Authorization reference-architecture abstract recommends centralized runtime-authorization management with decentralized enforcement and a multitiered architecture. Decentralized enforcement does not require a sidecar for every workload, but a local decision component can avoid a remote PDP hop. Cerbos Hub centralizes policy administration and distributes signed bundles. Sidecar or DaemonSet PDPs evaluate locally, while a shared-service topology remains available. Cerbos Synapse sits in the request path when context enrichment or protocol transformation is required. This range lets teams choose the failure boundary and network path per workload. A gateway concentrates enforcement at that gateway; a shared PDP cluster centralizes decision-service calls. PingAuthorize also supports application and service PDP APIs and multiple stateless Servers. Ask both vendors to diagram the exact request path and test latency, availability, capacity, and policy rollout under failure. ## Keep Ping identity and use Cerbos for application authorization Cerbos is the stronger overall choice when the authorization layer must stay identity provider neutral, evaluate close to services, and use an open PDP with testable policy workflows. Prove that topology with one request that passes through Ping authentication, needs an external attribute, and triggers multiple downstream checks. Compare shared-service and local PDP variants, using Cerbos Synapse only for required enrichment. Select PingAuthorize instead only if its native gateway or resolver integration removes enough verified work to justify coupling authorization to that platform. ## Questions you are probably asking ### We already run Ping for identity. Is PingAuthorize not the obvious choice? It is a reasonable product to evaluate, and Ping documents native platform and gateway integrations. Ask which proposed features require Ping products, which accept JWT or gateway-provided identity, and whether the proposed gateway, sideband, SCIM, or PDP API topology meets latency and availability requirements. Cerbos consumes Ping-issued JWTs or mapped identity context and offers a public $0 proof of concept tier; implementation effort still depends on scope. ### Is a distributed PDP not more infrastructure to run? A sidecar topology runs more PDP instances. Each Cerbos PDP is stateless; in sidecar mode it scales and shares a failure boundary with the application pod. It can consume prebuilt or local bundles without a runtime database. Cerbos also supports shared-service and database-backed policy-store configurations. Compare capacity, failover, rollout, and incident runbooks for the selected topology. ### Can Cerbos match the attribute retrieval PingAuthorize does? Both products can retrieve and transform decision-time attributes, but the mechanisms differ. The open source Cerbos PDP evaluates request-supplied context. Licensed Cerbos Synapse enriches from SQL, APIs, IdPs, graph stores, and custom sources with in-memory or Redis caching. PingAuthorize documents ordered conditional resolvers. Test connectors, orchestration, failure handling, caching, and licensing against one attribute-heavy policy. ### How does each handle AI agent traffic? An architecture that authorizes each tool call and downstream hop creates more checks than perimeter-only authorization. Cerbos supports sidecar or DaemonSet checks, where a Unix socket can avoid a network hop, and also supports shared service deployment. PingAuthorize exposes PDP APIs for application and service checks in addition to gateway patterns. Test a concrete multihop agent flow in both proposed topologies. ## The short version **Cerbos strengths** - Supports local sidecar and DaemonSet decisions as well as shared-service deployment - Stays vendor neutral across identity providers, including Ping - Combines Git and source-agnostic Cerbos Hub workflows with compile checks, tests, signed distribution, and audit aggregation - Provides REST and gRPC APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel - Publishes the Apache 2.0 Cerbos PDP and platform pricing, including a $0 proof of concept tier - Partially implements AuthZEN Authorization API 1.0; Alex Olivier is a current Working Group cochair **Weigh with PingAuthorize** - Ping-native integration plus documented third-party identity-validator options - A Policy Editor for technical and nontechnical authors with built-in lifecycle controls - Decision-time attribute resolution with ordered and conditional processing - Gateway, sideband, SCIM, and PDP API integration patterns - Central policy management with branches, commits, snapshots, deployment packages, approvals, and rollback - Commercial licensing with feature-tier dependencies and a sales-led public evaluation path Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- 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. Omada, an identity governance vendor, acquired EmpowerID in September 2026." competitor: "EmpowerID" reviewed: "2026-08-03" prepared_by: "Cerbos" 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. Omada, an identity governance vendor, acquired EmpowerID in September 2026. Prepared by the Cerbos team. Facts last checked on 3 August 2026. ## 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 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 gateway, per-call delegation checks, and escalation to human approval, is wanted from a single vendor rather than assembled. **Already on EmpowerID? Switching probably is not worth it when** - EmpowerID mainly runs identity governance, PAM, or SAP identity work. Cerbos does not replace those, so run it alongside rather than switching. - Credential custody or signed, hash-chained decision evidence from the authorization vendor is an audit requirement today. ## 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. EmpowerID by Omada sells its agent controls as Agent Governance & Execution, an MCP Gateway, an LLM Gateway, Credentials Without Custody, and Trust & Proof on a shared Identity Fabric, with Governed Authorization as the ABAC decision authority. Earlier documentation called the platform EmpowerNow and the agent layer ARIA. The MCP Gateway enforces each agent tool call against pinned tool schemas, active delegation, and an AuthZEN policy decision. A vault keeps OAuth tokens inside the server trust boundary so agents receive results rather than credentials, risky actions can escalate to human approval, and every governed action produces a signed, hash-chained receipt. 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. EmpowerID's agent controls are recent, native to AuthZEN, and shipped rather than announced. The question is whether you want to adopt an execution plane that sits in your call path and mediates 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. Its agent products add credential non-custody, tool-schema pinning, per-call delegation checks, an identity chain from human through agent to tool, escalation to human approval, an MCP gateway, and budget controls in an LLM gateway. EmpowerID's trust center lists SOC 2 Type II and ISO 27001:2022. **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 EmpowerID's agent controls means placing its MCP 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. EmpowerID's PDP documents YAML policy files with a five-level inheritance hierarchy, plus lint and pre-commit tooling, but no test runner or promotion pipeline. 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 Checked against public documentation from both vendors. Evidence links under each row point to the sources for each column. EmpowerID 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. Its agent products, sold by EmpowerID by Omada as the MCP Gateway and related agent controls and documented earlier as EmpowerNow and ARIA, form 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. The newer PDP documents YAML policy files stored under config/policies, with a five-level inheritance hierarchy from application to global. | | 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 — The PDP documentation includes a policy lint script, a Git pre-commit hook example, a hot-reload watch script, and an app scaffold. No policy test-suite runner or CI promotion pipeline was documented as of 15 October 2026. This is an absence of public evidence rather than a proven absence, so ask how a policy change is 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 — Documents an MCP Gateway that pins approved tool schemas and fails closed on a mismatch, verifies delegation on every governed call, asks the PDP for an AuthZEN decision, scopes the tool catalog, and supports token exchange with optional sender-constrained tokens. Risky actions can escalate to human approval, and budget controls sit in a separate LLM Gateway. 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 — Documents a three-zone trust model in which the policy decision comes before credential retrieval, a mediator injects the credential at the execution boundary, and the agent receives only the result. 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 — Documents a signed receipt for every governed action, binding request, authorization decision, execution, and outcome, hash-chained for tamper detection, with four-layer evidence packs on permit and deny paths. 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. | | 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 both documented. | | 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. Pricing is contact-sales, with licensing based on governed Person populations, and perpetual on-premise licenses are offered alongside subscription and SaaS. Integration is documented around REST APIs, OAuth-registered applications, and mTLS with sender binding. | ### Sources - [Cerbos deployment patterns](https://docs.cerbos.dev/cerbos/latest/deployment/) - [Cerbos Hub decision points](https://docs.cerbos.dev/cerbos-hub/decision-points.html) - [EmpowerID hybrid access control](https://docs.empowerid.com/docs/admin-guide/authorization/key-concepts/empowerid-hybrid-access-control-rbac-abac-and-pbac) - [EmpowerNow ARIA intro and architecture](https://docs.empowernow.ai/docs/services/aria-shield/intro-architecture) - [EmpowerID MCP Gateway](https://www.empowerid.com/platform/mcp-gateway/) - [Cerbos policy authoring](https://docs.cerbos.dev/cerbos/latest/policies/) - [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/policy-stores.html) - [EmpowerID access levels](https://docs.empowerid.com/docs/admin-guide/authorization/access-levels/what-are-access-levels) - [EmpowerNow PDP policy author guide](https://docs.empowernow.ai/docs/services/pdp/explanation/policy_author_guide) - [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) - [EmpowerNow PDP developer tools](https://docs.empowernow.ai/docs/services/pdp/explanation/developer_tools) - [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) - [EmpowerID credentials without custody](https://www.empowerid.com/solutions/credentials-without-custody/) - [EmpowerNow secrets security model](https://docs.empowernow.ai/docs/services/crud-service/secrets/security-model) - [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) - [EmpowerID cryptographic proof, not logs](https://www.empowerid.com/resources/blog/cryptographic-proof-not-logs/) - [EmpowerID platform: how it works](https://www.empowerid.com/platform/how-it-works/) - [EmpowerNow ARIA receipt chains](https://docs.empowernow.ai/docs/services/aria-shield/receipt-chains) - [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/) - [AuthZEN interop results: EmpowerID](https://www.authzen-interop.net/docs/scenarios/todo-1.1/results/empowerid) - [AuthZEN interop results: EmpowerID](https://www.authzen-interop.net/docs/scenarios/search/results/empowerid) - [EmpowerID Governed Authorization](https://www.empowerid.com/products/governed-authorization/) - [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) - [EmpowerID competitive comparison](https://www.empowerid.com/competitive-comparison/) - [EmpowerID Identity Governance](https://www.empowerid.com/products/identity-governance/) - [EmpowerID SAP integrations](https://www.empowerid.com/integrations/sap/) - [Cerbos licence](https://github.com/cerbos/cerbos/blob/main/LICENSE) - [Cerbos pricing](https://www.cerbos.dev/pricing) - [EmpowerID FAQs](https://www.empowerid.com/faqs/) - [EmpowerID Web API](https://docs.empowerid.com/docs/developer-guide/web-api) - [EmpowerNow mTLS for CRUD Service APIs](https://docs.empowernow.ai/docs/services/crud-service/reference/mtls) EmpowerID's earlier documentation used EmpowerNow for its next-generation platform and ARIA for its agent runtime layer, and some evidence links still point to that documentation. EmpowerID by Omada now sells those capabilities under product names such as MCP Gateway, Credentials Without Custody, Trust & Proof, and Governed Authorization. Details change, so verify current capabilities with both vendors before you decide. ## The difference is the integration surface, not the vintage EmpowerID's agent products are designed to sit in the execution path and mediate credentials. Cerbos is designed to be called from a path you already own. EmpowerID by Omada sells its agent controls as Agent Governance & Execution, an MCP Gateway, an LLM Gateway, and Credentials Without Custody on its Identity Fabric, documented earlier under the EmpowerNow and ARIA names. The MCP Gateway is the enforcement point for agent tool calls. It binds the caller, verifies tool integrity against pinned schemas, verifies delegation, asks the PDP for a decision over AuthZEN, enforces it, dispatches without handing over credentials, and records the result. Risky actions can escalate to human approval. It is a coherent architecture and it is shipped. The cost of that coherence is adoption surface. The gateway has to be in the call path, the vault has to hold the tokens, and the tool catalog 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 like EmpowerID'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, EmpowerID answers more of the problem in one purchase. This is not a legacy-versus-modern comparison and should not be argued as one. EmpowerID has shipped a converged identity platform since 2005, its agent controls are recent and native to AuthZEN, and Omada, which acquired it in September 2026, plans to integrate that agent technology into its own identity governance platform. ## Both have a real policy model; the difference is the toolchain EmpowerID's PDP documents YAML policies with five levels of inheritance. The public difference is the testing and promotion toolchain around them. EmpowerID's PDP documentation describes YAML policy files under config/policies, organized in a five-level inheritance hierarchy from application up to global. Governed Authorization describes one ABAC decision authority in which roles and relationships supply facts, and application owners declare capabilities that are projected into policy, grants, and tests. 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. The PDP documentation includes a policy lint script, a Git pre-commit hook example, a hot-reload watch script, and an app scaffold. No policy test-suite runner or CI promotion pipeline was found in EmpowerID's public sources as of 15 October 2026. That is an absence of public evidence, not proof of absence, so put it to the vendor as a question. 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 EmpowerID capabilities with no Cerbos equivalent today. Credentials Without Custody uses a three-zone trust model of untrusted agent runtime, authenticated backend, and high-security vault. The policy decision comes before credential retrieval, a mediator injects the credential at the execution boundary, and the agent receives only the result. 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 EmpowerID's answer and not ours. EmpowerID's Trust & Proof capability produces a signed receipt for every governed action, binding the request, authorization decision, execution, and outcome, hash-chained for tamper detection, with four-layer evidence packs on both permit and deny paths. 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 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. | | YAML policy with five-level 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. | | Application capability or operation identifier | 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. | | MCP Gateway check on an agent tool call | PDP check from your MCP server or agent framework | Cerbos covers the policy decision 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 EmpowerID's credential vault. | Keep credential custody with your secrets manager and execution boundary, or keep EmpowerID 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 controls, approval escalation, and tool discovery are not Cerbos features. | Inventory which controls you already have. If none exist and nobody owns them, a packaged runtime is a legitimate reason to prefer EmpowerID. | | 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. EmpowerID's published interop results additionally cover 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. EmpowerID is closed source. Its PDP documents YAML policy files with a five-level inheritance hierarchy, and no public test runner, promotion pipeline, or policy export tooling was found as of 15 October 2026. Request policy export samples, a documented review and promotion workflow, and an exit test before purchase. Omada's plan to integrate EmpowerID's agent technology into its own platform is a second reason to confirm roadmap and support terms. Adoption cost matters as much as exit cost here. EmpowerID's MCP Gateway and credential vault are 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 like EmpowerID'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 EmpowerID where its credential vault, signed evidence packs, packaged agent controls, 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. 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 EmpowerID'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. EmpowerID documents Governed Authorization as SaaS or a dedicated single-tenant environment, with multiple PDP instances running near enforcement points under one logical authority. Rather than trading benchmark numbers, ask what happens when an instance loses contact with that authority, and how quickly a revoked entitlement reaches every instance, 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 with tool-schema pinning, per-call delegation checks, escalation to human approval, an MCP gateway, and LLM gateway budget controls - Documented credential non-custody for agents, which Cerbos does not provide - Signed, hash-chained receipts and evidence packs for each governed action, 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 II and ISO 27001:2022 listed in its trust center - Acquired by Omada in September 2026, which plans to integrate EmpowerID's agent governance technology into its own platform; confirm the roadmap and support for the EmpowerID products you would rely on 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. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- title: "Authorization-specific platform or general-purpose policy engine" description: "OPA is a general-purpose policy engine that evaluates Rego policies over structured data. Cerbos is purpose-built for fine-grained authorization across applications, APIs, agents, services, and workloads. The comparison covers both engines and the lifecycle tooling around them." competitor: "OPA" reviewed: "2026-07-24" prepared_by: "Cerbos" canonical: "https://www.cerbos.dev/cerbos-vs-opa" source: "https://www.cerbos.dev/cerbos-vs-opa" --- # Authorization-specific platform or general-purpose policy engine OPA is a general-purpose policy engine that evaluates Rego policies over structured data. Cerbos is purpose-built for fine-grained authorization across applications, APIs, agents, services, and workloads. The comparison covers both engines and the lifecycle tooling around them. Prepared by the Cerbos team. Facts last checked on 24 July 2026. ## Verdict **Choose Cerbos when** - The scope is application authorization and teams want principals, resources, actions, roles, conditions, tests, audit, and query planning as product primitives. - Operating Rego conventions, bundle infrastructure, decision-log collection, or application-specific query adapters creates material maintenance work. - Policy reviewers prefer an authorization-specific YAML or JSON schema with CEL conditions over a general-purpose language. **Consider OPA when** - One engine must cover Kubernetes admission, infrastructure, CI/CD, and policy shapes outside application authorization. - An existing platform is stable and its Rego expressiveness or ecosystem is a verified requirement. **Already on OPA? Switching probably is not worth it when** - The OPA deployment already serves application authorization reliably, and its Rego conventions, bundles, and query adapters cost little to maintain. - Most of the Rego estate is admission, infrastructure, or CI/CD policy. Move only the application authorization subset, or nothing. ## General engine, specific product OPA is a CNCF-graduated, general-purpose policy engine. It evaluates Rego over structured data and has documented use cases across Kubernetes admission control, Terraform, CI/CD, gateways, and application or API authorization. Cerbos provides authorization-specific primitives through its Apache 2.0 PDP, managed lifecycle options through Cerbos Hub, and context and integration capabilities through Cerbos Synapse. Cerbos reports that its first prototype used OPA and that its replacement engine was up to 17 times faster on the application-authorization workloads Cerbos tested. Treat that as a scoped internal comparison and benchmark representative policies in the intended deployment. In August 2025, OPA's creators and many Styra team members joined Apple. The OPA project said its CNCF governance and Apache 2.0 licensing were unchanged. OPA remains community governed with active releases and documented production adopters; verify the support provider and lifecycle product your deployment will rely on. **OPA** — Fits teams that need a programmable, general-purpose policy engine across infrastructure and application domains. OPA has mature use cases for Kubernetes admission control, Terraform, CI/CD, gateways, and application or API authorization. Rego supports a broader range of policy shapes than Cerbos' authorization-specific model. **Cerbos** — Fits teams that want authorization-specific principals, resources, actions, roles, conditions, tests, audit, and query planning. The open source Cerbos PDP is self-hosted as a service. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, without a per-decision service call. Cerbos Hub also adds managed lifecycle workflows and is available as an enterprise on-premise deployment for restricted and air-gapped environments. Cerbos Synapse adds decision-time data and integrations from customer-controlled infrastructure. - **What your team maintains** — Choose an authorization-specific product with managed lifecycle options, or assemble and operate OPA's general-purpose components, including the self-hosted OPA Control Plane, around the application model. Both are valid; operational ownership and product roadmaps differ. - **Policy authoring** — Rego is broader and more programmable. Cerbos' authorization-specific YAML or JSON schema with CEL conditions may be easier for some application teams to review. Test both languages with representative policies and the intended reviewers. - **List filtering** — Cerbos PlanResources returns a query plan, with reference adapters for six data layers. OPA's Compile API can return data filters directly as SQL for PostgreSQL, MySQL, SQL Server, and SQLite, or as UCAST conditions. Compare the generated filters for your own policies and data layer. ## What application teams ask for Checked against public documentation from both projects. Evidence links under each row point to the sources for each column. | Requirement | Cerbos | OPA | | --- | --- | --- | | Application authorization primitives | NATIVE — Models principals, resources, actions, roles, and derived roles directly in policy. | GENERAL PURPOSE — Models anything expressible in Rego, with authorization conventions left to your team. | | Policy testing and CI | BUILT IN — Ships a first class test format and compile checks designed for authorization policies. | BUILT IN — Provides mature testing through opa test and surrounding tooling. Genuine parity on this row. | | Decision logging and audit | BUILT IN + HUB — Provides configurable decision logging to file, Kafka, local storage, or Cerbos Hub. Cerbos Hub adds managed collection and search. | BUILT IN + CONFIGURABLE — Provides configurable decision logging. OPA core requires a collector or control plane for durable storage and search. | | List filtering and query planning | BUILT IN — PlanResources returns a query plan, with reference adapters for Prisma, Drizzle, Mongoose, Convex, LangChain/ChromaDB, and SQLAlchemy. | BUILT IN — The Compile API can return data filters as SQL for PostgreSQL, MySQL, SQL Server, and SQLite, or as UCAST conditions, including LINQ and Prisma variants. Other targets still need translation from UCAST or the older JSON AST output. | | Managed policy distribution | VIA HUB — Cerbos Hub builds, tests, signs, and distributes policies from Git and other policy-store workflows. The open source Cerbos PDP also supports disk, Git, object storage, database, and Cerbos Hub stores. | CORE + SELF-HOSTED OCP — OPA core supports bundle distribution. The Apache 2.0 OPA Control Plane adds self-hosted Git-based policy management, bundle building, external data sources, and object-storage distribution. | | SDK language coverage | 8 LANGUAGES + LARAVEL — Provides REST and gRPC APIs with official clients for Go, Java, JavaScript, Python, Ruby, Rust, .NET, and PHP, plus Laravel. | BROAD ECOSYSTEM — Exposes REST, a Go API, WebAssembly, and a broad ecosystem of language SDKs and integrations. Maturity varies, so verify the specific package. | | AuthZEN compatibility | INTEROP READY — The Cerbos PDP partially implements AuthZEN Authorization API 1.0. Alex Olivier is one of the current AuthZEN Working Group cochairs. | VERIFY — OPA core does not document native AuthZEN endpoints. OPA took part in the AuthZEN Todo interop rounds from 2024 to early 2025 through a proxy; verify the adapter, gateway, and specification version required. | | Infrastructure and platform policy | AUTHORIZATION FOCUS — Focuses on authorization decisions and can integrate with infrastructure systems through Cerbos Synapse. It is not a general-purpose admission-policy engine. | NATIVE — Has mature ecosystem projects for infrastructure policy. Gatekeeper is the OPA project's recommended Kubernetes admission-control integration. | ### Sources - [Cerbos resource policies](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html) - [Cerbos derived roles](https://docs.cerbos.dev/cerbos/latest/tutorial/06_derived-roles.html) - [OPA introduction](https://www.openpolicyagent.org/docs) - [OPA Rego policy language](https://www.openpolicyagent.org/docs/policy-language) - [Cerbos policy testing](https://docs.cerbos.dev/cerbos/latest/tutorial/04_testing-policies.html) - [Cerbos compile](https://docs.cerbos.dev/cerbos/latest/cli/cerbos.html) - [OPA policy testing](https://www.openpolicyagent.org/docs/policy-testing) - [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) - [OPA decision logs](https://www.openpolicyagent.org/docs/management-decision-logs) - [Cerbos query-plan adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html) - [OPA Compile API](https://www.openpolicyagent.org/docs/rest-api#compiling-a-rego-policy-and-query-into-data-filters) - [OPA data filtering](https://www.openpolicyagent.org/docs/filtering) - [Cerbos Hub](https://docs.cerbos.dev/cerbos-hub/index.html) - [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/policy-stores.html) - [Cerbos PDP storage](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html) - [OPA bundles](https://www.openpolicyagent.org/docs/management-bundles) - [OPA Control Plane](https://github.com/open-policy-agent/opa-control-plane) - [Cerbos APIs and SDKs](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [OPA integration](https://www.openpolicyagent.org/docs/integration) - [OPA ecosystem](https://www.openpolicyagent.org/ecosystem) - [Cerbos AuthZEN API](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [AuthZEN Working Group](https://openid.net/wg/authzen/) - [OpenID AuthZEN interoperability datasheet](https://openid.net/wp-content/uploads/2025/04/OpenID-AuthZEN-Datasheet-Gartner-London.pdf) - [AuthZEN interop results](https://authzen-interop.net/docs/intro) - [AuthZEN interop: OPA Todo 1.1 results](https://authzen-interop.net/docs/scenarios/todo-1.1/results/opa) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [OPA CNCF project](https://www.cncf.io/projects/open-policy-agent-opa/) - [OPA Kubernetes](https://www.openpolicyagent.org/docs/kubernetes) - [OPA Gatekeeper docs](https://open-policy-agent.github.io/gatekeeper/website/docs/) Details change, so verify current capabilities before you decide. ## The policy model trades breadth for application structure OPA evaluates arbitrary Rego over structured data. Cerbos fixes the outer model around application authorization and uses CEL for conditions. OPA can express application, infrastructure, admission, configuration, and pipeline policy. The team defines its own input schema, package conventions, decision shape, and reusable libraries. Cerbos models principals, resources, actions, roles, derived roles, scopes, conditions, and structured outputs directly. This is less general than Rego and makes more authorization conventions common across services. Migration should start by identifying the application-authorization subset of the Rego estate. Infrastructure and admission policies can remain on OPA while application decisions move to Cerbos. ## Both engines are open source; the surrounding ownership differs OPA core provides engine primitives and bundle support. Cerbos packages authorization-specific runtime and lifecycle mechanisms across Cerbos PDP, Cerbos Hub, and Cerbos Synapse. OPA provides policy evaluation, testing, bundles, decision logging, partial evaluation, REST, Go, and WebAssembly integration. The self-hosted OPA Control Plane adds Git-based management, bundle building, external data, and object-storage distribution. The Apache 2.0 Cerbos PDP provides authorization APIs, policy tests, decision logging, and query planning. Cerbos Hub adds managed build, test, signed distribution, and audit aggregation. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, without a per-decision service call. Cerbos Hub Enterprise can run on-premise in restricted and air-gapped environments. Cerbos Synapse is a separate commercial component for decision-time data and protocol or integration extensions. It runs in customer-controlled infrastructure. Neither Cerbos Hub nor Cerbos Synapse changes the open source licence of the Cerbos PDP. ## List filtering differs in what each engine emits OPA's Compile API can emit SQL or UCAST filters directly. Cerbos returns an authorization-specific query plan with reference data-layer adapters. OPA's Compile API can return data filters as SQL for PostgreSQL, MySQL, SQL Server, and SQLite, or as UCAST conditions, including LINQ and Prisma variants. Targets outside those formats, such as other ORMs, document stores, or search systems, still need a translation layer. Cerbos PlanResources returns a datastore-agnostic query plan for the requested principal, action, and resource kind. Reference adapters translate supported plan shapes for selected data layers. Neither approach removes the need to validate query semantics and unsupported expressions. Compare the real adapter code, generated predicate, and returned records for representative policies. ## Separate reusable authorization intent from Rego implementation Translate the input contract and decision table before translating expressions. Keep OPA for policy domains that require its general-purpose model. | OPA or Rego concept | Cerbos | Notes | | --- | --- | --- | | input.subject or input.user | request.principal | Normalize the principal ID, roles, and attributes at the enforcement point. | | input.resource | request.resource | Assign a resource kind and ID, then pass domain attributes under resource.attr. | | input.action and allow rule | Rule actions and EFFECT_ALLOW or EFFECT_DENY | Derive an explicit action-by-scenario decision table before modeling rules. | | Rego helper rule | Derived role, scoped policy, or CEL condition | Choose the construct by domain meaning. Do not mechanically inline every helper into CEL. | | Partial evaluation or Compile API | PlanResources query plan | Replace and test the data-layer translation separately from single-resource checks. | ### An owner-or-editor document policy `document.yaml` ```yaml apiVersion: api.cerbos.dev/v1 resourcePolicy: version: default resource: document rules: - actions: ["view", "edit"] effect: EFFECT_ALLOW condition: match: expr: request.resource.attr.ownerId == request.principal.id - actions: ["view", "edit"] effect: EFFECT_ALLOW roles: ["editor"] ``` The enforcement point sends the principal, document resource, and requested action to CheckResources. Add deny cases, missing-attribute cases, and scope variants to the Cerbos policy test suite before comparing with the Rego result. ## Where OPA remains the stronger fit Cerbos is purpose-built for authorization. It is not a replacement for every Rego policy domain. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | General-purpose policy evaluation | Cerbos models application and service authorization through fixed principal, resource, action, and policy concepts. | Keep OPA for admission control, infrastructure, CI/CD, and policy shapes outside the Cerbos model. | | Rego expressiveness and ecosystem | Cerbos uses YAML or JSON policy schemas with CEL conditions and authorization-specific APIs. | Inventory custom functions, recursive logic, ecosystem integrations, and packages outside authorization before considering migration. | | Existing stable OPA platform | Cerbos can reduce authorization-specific platform work, but migration still requires policy, integration, and operational changes. | Do not migrate solely to change engines. Quantify current maintenance cost and test coexistence first. | ## Coexistence, and where the standards are going OPA and Cerbos can coexist, for example with OPA handling infrastructure policy and Cerbos handling application authorization. Admission control often benefits from a general policy engine. Application teams may prefer authorization-specific primitives, query adapters, and managed lifecycle tooling, although OPA also supports application authorization and lifecycle components. AuthZEN Authorization API 1.0 defines an interoperable PEP-to-PDP interface. Services can use the same API against PDPs that implement the relevant endpoints and capabilities. The Cerbos PDP partially implements documented AuthZEN endpoints. An OPA deployment currently requires a compatible adapter or gateway. Alex Olivier of Cerbos is one of the current AuthZEN Working Group cochairs. For an existing OPA application-authorization stack, compare the cost of OCP or other control-plane components and application-specific data or query adapters with Cerbos PDP, Cerbos Hub, and Cerbos Synapse. The Cerbos platform packages authorization-specific policy, tests, audit, distribution, enrichment, and query-planning mechanisms while retaining an Apache 2.0 Cerbos PDP. ## Use Cerbos for application authorization and keep OPA where it fits Cerbos is the stronger overall choice for application authorization because its PDP, policy model, tests, audit, query planning, Cerbos Hub distribution, and optional Cerbos Synapse enrichment are designed around that problem. Prove the boundary with one Rego package that performs single-resource checks and list filtering. Run both engines in parallel and compare decisions, data predicates, latency, memory, rollout, and operational work. Keep OPA for admission, infrastructure, and other general-purpose policy domains. ## Questions you are probably asking ### Is Rego not more expressive than YAML and CEL? Rego offers broader policy expressiveness. Cerbos' constrained authorization model may be easier for some application teams to review. Test both against representative policies and reviewers, including someone outside the authoring team. ### OPA is CNCF graduated and everywhere. Why bet on Cerbos? OPA remains CNCF graduated and community governed. Its creators and many Styra team members joined Apple in 2025; OPA said governance and licensing were unchanged, and several tools moved toward the OPA organization. Both OPA and the Cerbos PDP are Apache 2.0. Cerbos' commercial roadmap is focused on authorization management across Cerbos PDP, Cerbos Hub, and Cerbos Synapse. Verify the support provider and lifecycle tooling each deployment depends on. ### We already built application authorization on OPA. Is migration worth it? Sometimes no. If the OPA deployment is stable and inexpensive to maintain, keep it. A migration case appears when application-specific policy conventions, query adapters, data integration, or lifecycle operations carry material engineering cost. Cerbos reports up to 17 times faster evaluation than its own earlier OPA-based prototype on the workloads it tested; benchmark your policies and topology in a parallel run. ### Can OPA and Cerbos coexist? Yes. One possible split is OPA for infrastructure or admission policy and Cerbos for application authorization, but both products have broader integration surfaces. AuthZEN defines a standard interface for compatible PDPs. Cerbos partially implements it; an OPA deployment currently needs a compatible adapter or gateway. ## The short version **Cerbos strengths** - Packages authorization-specific primitives, tests, audit, query planning, distribution, and enrichment across Cerbos PDP, Cerbos Hub, and Cerbos Synapse - Uses an authorization-specific YAML or JSON schema with CEL conditions, which some teams may find easier to review - Returns datastore-agnostic query plans with six reference adapters - Distributes signed policies through Cerbos Hub from Git and source-agnostic policy stores - Partially implements AuthZEN Authorization API 1.0; Alex Olivier is a current Working Group cochair - Provides an Apache 2.0 Cerbos PDP that is free to self-host, with published Cerbos Hub pricing **Weigh with OPA** - Rego expresses logic that purpose built policy languages cannot - Infrastructure policy, Kubernetes admission control, and CI gates are OPA's home ground - The engine is CNCF graduated, community governed, and healthy - Mature testing tooling and a broad documented ecosystem - An existing, stable OPA deployment may not justify a migration - OPA's creators and many Styra team members joined Apple in 2025; verify the current support provider and product lifecycle Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- title: "An authorization platform with service and embedded runtimes, or an engine toolkit" description: "Cedar is an Apache 2.0 authorization language and engine ecosystem with strong schema validation and formal analysis. Cerbos combines an Apache 2.0 Cerbos service PDP with an optional Cerbos Hub-managed, in-process WebAssembly ePDP and Cerbos Synapse decision-time data. The right choice starts with the product boundary, not policy syntax alone." competitor: "Cedar" reviewed: "2026-07-27" prepared_by: "Cerbos" canonical: "https://www.cerbos.dev/cerbos-vs-cedar" source: "https://www.cerbos.dev/cerbos-vs-cedar" --- # An authorization platform with service and embedded runtimes, or an engine toolkit Cedar is an Apache 2.0 authorization language and engine ecosystem with strong schema validation and formal analysis. Cerbos combines an Apache 2.0 Cerbos service PDP with an optional Cerbos Hub-managed, in-process WebAssembly ePDP and Cerbos Synapse decision-time data. The right choice starts with the product boundary, not policy syntax alone. Prepared by the Cerbos team. Facts last checked on 27 July 2026. ## Verdict **Choose Cerbos when** - Multiple services or languages need one independently deployable authorization API rather than an evaluator embedded into each application. - Policy build, test, signed distribution, audit collection, list-query planning, or decision-time data would otherwise become internal platform work. - Deployment control matters across the stack: the Cerbos service PDP and Cerbos Synapse are self-hosted, Cerbos Hub ePDP evaluates in-process, and Cerbos Hub Enterprise is available on-premise for restricted and air-gapped environments. **Consider Cedar when** - Symbolic equivalence and permissiveness analysis are firm requirements, or its typed model is the platform standard. - A native in-process Rust or Go implementation, a Java binding, or an embedded engine without a Cerbos Hub dependency is required. An existing Cedar-based AWS workflow can also be decisive. **Already on Cedar? Switching probably is not worth it when** - A well-operated Cedar platform already meets the requirement, particularly one built around Cedar-based AWS workflows. - Formal policy analysis is part of the assurance case. Cerbos schemas, compile checks, and policy tests do not replace a symbolic prover. ## Engine toolkit, production platform Cedar provides a purpose-built authorization language, embeddable evaluators, schema validation, and unusually strong formal analysis. Its ecosystem includes Rust and Go implementations, Java bindings, WebAssembly, and experimental local-agent foundations. Teams or downstream products still define the production service topology, policy distribution, data providers, and operational workflow. Cerbos provides those production boundaries directly. The Apache 2.0 Cerbos service PDP exposes REST and gRPC authorization APIs, policy tests, configurable audit logs, and query planning. Optional commercial Cerbos Hub adds policy build, test, distribution, audit workflows, and a Cerbos ePDP that evaluates Cerbos Hub-managed bundles in-process through WebAssembly in JavaScript environments. Cerbos Synapse retrieves, transforms, and caches decision-time data from customer-controlled infrastructure. Both open source engines use Apache 2.0, and both can express role-, attribute-, and relationship-informed authorization. Cedar is a CNCF Sandbox project and has the stronger formal-analysis story. Cedar provides broader embedded runtime coverage; Cerbos provides both an independently deployable Cerbos service PDP and a Cerbos Hub-managed JavaScript/WebAssembly ePDP within a wider authorization platform. **Cedar** — Fits teams that want to embed a typed authorization engine, value symbolic analysis of policy sets, or are building around Cedar-compatible and AWS-native authorization workflows. It is especially credible where a native Rust or Go implementation, a Java binding, formal assurance, or operation without a Cerbos Hub dependency outweighs the cost of assembling the surrounding platform. **Cerbos** — Fits teams that want a language-neutral authorization service with built-in policy tests, audit, list-query planning, and optional lifecycle and data infrastructure. Cerbos Hub can also deliver an in-process WebAssembly Cerbos ePDP for JavaScript environments. The Cerbos service PDP is open source; commercial Cerbos Synapse and enterprise on-premise Cerbos Hub can run in customer-controlled or air-gapped environments. - **Choose the runtime boundary first** — Cedar embeds through native implementations, bindings, or WebAssembly. Cerbos supports a service, sidecar, or DaemonSet through REST and gRPC, plus a Cerbos Hub-managed ePDP that evaluates in-process through WebAssembly in JavaScript environments. - **Separate assurance from operations** — Cedar's symbolic analysis can compare policy sets and identify unreachable or overridden policy behavior. Cerbos instead emphasizes executable policy tests, schema checks, audit, rollout, and production operations. These solve different assurance problems. - **Prototype list filtering early** — Cedar's Rust library offers experimental partial evaluation, and Cedar supports entity slicing concepts. Cerbos PlanResources returns an authorization-specific query plan with reference adapters. In either case, verify the final datastore predicate against real policies and records. ## What application teams actually need Checked against public documentation from both projects. Evidence links under each row point to the sources for each column. | Requirement | Cerbos | Cedar | | --- | --- | --- | | Open source authorization engine | APACHE 2.0 — The Cerbos PDP is an Apache 2.0 authorization service with source available for independent operation. | APACHE 2.0 — Cedar's language, core implementations, and principal tooling are Apache 2.0. Genuine parity on licensing. | | Network-addressable PDP | BUILT IN — Ships a deployable Cerbos PDP with REST and gRPC APIs, health endpoints, SDKs, and documented service, sidecar, and DaemonSet patterns. | IMPLEMENTATION OWNED — Provides embeddable implementations, bindings, and experimental local-agent foundations. The production service contract and topology remain an integration decision. | | In-process policy evaluation | VIA HUB EPDP — Cerbos Hub ePDP downloads filtered policy bundles and evaluates them in-process through WebAssembly in browsers, Node.js, edge runtimes, and React Native. | NATIVE + WASM — Provides Rust and Go implementations, Java bindings, and WebAssembly. Cedar has broader native embedding; both support in-process WebAssembly. | | Schemas and policy validation | BUILT IN — Validates policy structure and can enforce JSON schemas for principal and resource attributes. | BUILT IN — Provides typed schemas and validation designed to catch policy and entity-model errors before evaluation. A Cedar strength. | | Formal policy analysis | TESTS + SCHEMAS — Provides compile checks, schemas, and scenario-based policy tests, but not a symbolic equivalence or permissiveness prover. | SYMBOLIC ANALYSIS — Can compare policy sets for equivalence or permissiveness and find behaviors such as shadowed permits and impossible conditions. Cedar is stronger here. | | Policy lifecycle and distribution | VIA HUB — Cerbos Hub builds, tests, signs, and distributes policies through managed or enterprise on-premise workflows, including restricted and air-gapped deployments. | ASSEMBLE OR ADOPT — The open source engine evaluates supplied policies. Distribution, approvals, rollout, and fleet management come from the adopter or a downstream Cedar-based product. | | Decision logging and audit | BUILT IN + HUB — The Cerbos PDP can log decisions to file, local storage, Kafka, or Cerbos Hub. Cerbos Hub adds centralized collection and search. | INTEGRATION OWNED — The engine returns a decision and diagnostics. Experimental local-agent components can emit tracing and OCSF events; durable collection and search depend on the deployment. | | List filtering and query planning | PLAN + ADAPTERS — PlanResources returns a datastore-agnostic query plan, with reference adapters for six data layers. | ENGINE PRIMITIVES — Experimental partial evaluation in the Rust library and level validation can reduce or bound authorization work. Applications still own safe translation into their datastore query layer. | | Decision-time data | CALLER OR SYNAPSE — The Cerbos PDP evaluates supplied attributes. Optional Cerbos Synapse retrieves, transforms, and caches context from customer-controlled data sources. | PROVIDER OWNED — The evaluator consumes the request, policies, and relevant entities. The application, agent, or downstream service supplies and refreshes that data. | | Runtime and language interoperability | APIS + WASM — The Cerbos service PDP serves polyglot applications through stable APIs and official SDKs. Cerbos Hub ePDP adds in-process WebAssembly for JavaScript environments. The Cerbos service PDP partially implements AuthZEN. | EMBEDDABLE — Offers Rust and Go implementations, Java bindings, and WebAssembly. Strong when in-process evaluation is the intended architecture. | ### Sources - [Cerbos PDP documentation](https://docs.cerbos.dev/cerbos/latest/index.html) - [Cerbos PDP repository](https://github.com/cerbos/cerbos) - [Cedar](https://github.com/cedar-policy/cedar) - [cedar-go](https://github.com/cedar-policy/cedar-go) - [Cerbos APIs and SDKs](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [Cerbos deployment modes](https://docs.cerbos.dev/cerbos/latest/deployment/index.html) - [Cedar local agent](https://github.com/cedar-policy/cedar-local-agent) - [Cedar docs overview](https://docs.cedarpolicy.com/) - [Cerbos Hub embedded PDP](https://docs.cerbos.dev/cerbos-hub/deployments-epdp-rules.html) - [Cedar Java](https://github.com/cedar-policy/cedar-java) - [Cerbos schemas](https://docs.cerbos.dev/cerbos/latest/policies/schemas.html) - [Cerbos policy testing](https://docs.cerbos.dev/cerbos/latest/policies/compile.html) - [Cedar policy validation](https://docs.cedarpolicy.com/policies/validation.html) - [Cedar schema](https://docs.cedarpolicy.com/schema/schema.html) - [Introducing Cedar Analysis](https://aws.amazon.com/blogs/opensource/introducing-cedar-analysis-open-source-tools-for-verifying-authorization-policies/) - [Cerbos Hub](https://docs.cerbos.dev/cerbos-hub/index.html) - [On-premise Cerbos Hub](https://docs.cerbos.dev/cerbos-hub/on-premises.html) - [Amazon Verified Permissions](https://aws.amazon.com/verified-permissions/) - [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 query-plan adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html) - [Cerbos PlanResources API](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [Cedar partial evaluation](https://docs.rs/cedar-policy/latest/cedar_policy/struct.Authorizer.html) - [Cedar level validation](https://docs.cedarpolicy.com/policies/level-validation.html) - [Cerbos request model](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [Cedar authorization requests](https://docs.cedarpolicy.com/auth/authorization.html) - [AuthZEN Working Group](https://openid.net/wg/authzen/) - [Cedar Wasm](https://github.com/cedar-policy/cedar/tree/main/cedar-wasm) Cedar refers here to the open source language and engine ecosystem, not Amazon Verified Permissions or another downstream Cedar-based service. Verify current capabilities before deciding. ## The decisive difference is the product boundary Cedar supplies embeddable authorization engines and tooling. Cerbos supplies a deployable PDP plus optional lifecycle and data infrastructure. A Cedar evaluator receives a request, a policy set, and relevant entity data. Native implementations, bindings, WebAssembly, and experimental local-agent foundations give platform teams several ways to embed or productize that evaluator. The open source Cerbos PDP is a network-addressable service with REST and gRPC APIs, health endpoints, official SDKs, policy tests, configurable audit, and query planning. Services can share one authorization contract without embedding a language runtime. Commercial Cerbos Hub also supports an embedded PDP. Its JavaScript client downloads filtered policy bundles from Cerbos Hub and evaluates them in-process through WebAssembly without a per-decision call to a Cerbos service. Cerbos Hub adds managed build, test, signed distribution, and audit workflows, while commercial Cerbos Synapse adds decision-time data and integration extensions. The open source Cerbos service PDP remains independently operable without either product. ## Cedar leads on formal policy analysis Cedar can reason symbolically about whole policy sets. Cerbos focuses on executable tests, validation, audit, and rollout evidence. Cedar's analysis tooling can compare two policy sets for equivalence or relative permissiveness and detect cases such as shadowed permits, impossible conditions, or forbids that override expected access. Its symbolic compiler and mechanically checked foundations are meaningful advantages for high-assurance policy work. Cerbos validates policy structure and attribute schemas, compiles policies before deployment, and runs scenario-based test suites. In production, configurable decision logs and Cerbos Hub audit collection make observed behavior inspectable. These are complementary assurance layers, not interchangeable features. Choose Cedar when proofs about policy-space behavior are mandatory. Choose Cerbos when consistent deployment, regression tests, decision evidence, and application integration are the larger operational risk. ## Data and list filtering reveal the integration work Both evaluators need relevant authorization facts. Cerbos packages a query-plan API and offers Cerbos Synapse for decision-time data. Open source Cedar evaluates the entities and context supplied to it. Level validation and experimental partial evaluation can help bound or defer work, but the adopter still designs entity retrieval, refresh, and datastore-query translation. The open source Cerbos PDP likewise evaluates attributes supplied in the request. PlanResources returns an authorization-specific, datastore-agnostic query plan, and reference adapters translate supported plans for six data layers. Optional Cerbos Synapse runs in customer-controlled infrastructure and retrieves, transforms, and caches decision-time data. It changes the platform boundary, not the Cerbos PDP licence: teams that already have reliable context assembly can use the Cerbos PDP alone. ## Map authorization intent before translating syntax Cedar and Cerbos structure authorization differently. Start from the request contract, entity model, and expected decisions instead of converting policies line by line. | Cedar concept | Cerbos | Notes | | --- | --- | --- | | principal, action, resource, context | principal, actions, and resource; map context to attributes or JWT auxData by meaning | Normalize IDs and attributes at the enforcement point before comparing decisions. Use auxData only for supported JWT-backed facts. | | permit and forbid policies | EFFECT_ALLOW and EFFECT_DENY rules | Rebuild the decision table explicitly; the combining semantics are not a mechanical text substitution. | | entity types, attributes, and hierarchy | roles, derived roles, resource attributes, and request context | Choose the Cerbos construct by domain meaning. Keep relationships in supplied data where that is clearer. | | Cedar schema and validation | principal and resource schemas plus compile checks | Carry required attributes and failure cases into both schema validation and policy tests. | | partial evaluation and entity slicing | PlanResources query plan | Test generated datastore predicates separately from single-resource checks. | | application-managed policy set | Cerbos PDP policy store or optional Cerbos Hub workspace | Choose direct self-hosted storage or Cerbos Hub-managed build and distribution based on lifecycle requirements. | ### An owner-or-editor document policy `document.yaml` ```yaml apiVersion: api.cerbos.dev/v1 resourcePolicy: version: default resource: document rules: - actions: ["view", "edit"] effect: EFFECT_ALLOW condition: match: expr: request.resource.attr.ownerId == request.principal.id - actions: ["view", "edit"] effect: EFFECT_ALLOW roles: ["editor"] ``` Add explicit deny, missing-attribute, hierarchy, and list-filtering cases to the Cerbos test suite. Compare the resulting decisions with the Cedar evaluator before changing the enforcement path. ## Where Cedar remains the stronger fit Cerbos is the more complete application-authorization platform for many teams. Cedar retains real advantages that should influence the decision. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | Formal policy analysis | Cerbos uses schemas, compile checks, executable policy tests, and production audit rather than a symbolic policy-set prover. | Use Cedar when equivalence, permissiveness, or unreachable-policy analysis is a required assurance control. | | Native in-process runtimes | Cerbos Hub ePDP evaluates policies in-process through WebAssembly in browsers, Node.js, edge runtimes, and React Native. Current Cerbos guidance recommends the Cerbos service PDP for authoritative server-side routes and middleware. | Prefer Cedar where a native Rust or Go implementation, a Java binding, or an embedded engine without a Cerbos Hub dependency is required. For JavaScript and WebAssembly environments, compare Cedar directly with the Cerbos Hub ePDP. | | Cedar and AWS ecosystem alignment | Cerbos is cloud and identity provider neutral and exposes its own PDP APIs plus partial AuthZEN compatibility. | Prefer Cedar where compatibility with an existing Cedar policy estate or Cedar-based AWS workflow removes more integration work than Cerbos would. | ## Do not confuse an engine choice with a platform choice Cedar and the Cerbos service PDP are both purpose-built authorization engines under Apache 2.0. Cedar supplies native embeddable engines, bindings, and analysis primitives. Cerbos supplies an independently deployable Cerbos service PDP and, through commercial Cerbos Hub, a Cerbos ePDP that evaluates filtered policy bundles in-process through WebAssembly in JavaScript environments. Commercial Cerbos Hub and Cerbos Synapse extend the open source Cerbos service PDP without becoming prerequisites for it. Cerbos Hub adds policy build, test, signed distribution, audit workflows, and Cerbos ePDP bundle delivery. It is hosted by default and available to enterprise customers on-premise for restricted and air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure to retrieve, transform, and cache decision-time data. AuthZEN Authorization API 1.0 provides an emerging standard PEP-to-PDP contract. The Cerbos PDP partially implements documented AuthZEN endpoints, and Alex Olivier, Cerbos cofounder and CPO, is one of the current Working Group cochairs. A Cedar deployment can expose AuthZEN, but that service layer is not the open source engine's default product boundary. ## Compare the platform you need to operate, not just the evaluator Cerbos is the stronger overall default for application authorization because the open source Cerbos service PDP, Cerbos Hub ePDP, query planning, audit, optional Cerbos Hub lifecycle, and optional Cerbos Synapse data layer form a coherent production boundary. Cedar is the stronger choice when formal policy analysis, a native Rust or Go implementation, a Java binding, operation without a Cerbos Hub dependency, or Cedar ecosystem compatibility is decisive. Prove the difference with one policy set that includes single-resource checks, list filtering, policy rollout, audit retrieval, and a decision that needs external context. ## Questions you are probably asking ### Is Cedar only a policy language? No. Cedar is a language and an engine ecosystem with native implementations, bindings, validation, analysis, tooling, and experimental local-agent foundations. Cerbos takes a different packaging approach: an open source network-addressable Cerbos service PDP plus a commercial Cerbos Hub-managed WebAssembly ePDP for JavaScript environments. ### Does Cerbos offer Cedar's formal verification? Not today. Cerbos provides schema checks, compile validation, scenario-based policy tests, and production audit. Cedar's symbolic analysis can answer a different class of question about equivalence, permissiveness, and unreachable behavior. If those proofs are mandatory, Cedar has a real advantage. ### Does Cedar support relationship-based authorization? Yes. Cedar's entity model and hierarchy can express relationship-informed decisions alongside roles and attributes. Cerbos can also use roles, derived roles, resource attributes, and request context. For graph-heavy global authorization, benchmark the data model and lookup path rather than relying on category labels. ### Is Amazon Verified Permissions the same thing as Cedar? No. Cedar is the open source language and engine ecosystem. Amazon Verified Permissions is a managed AWS service built on Cedar and adds its own APIs, stores, integrations, logging model, limits, and operating boundary. Compare that service separately if it is the actual alternative. ### Can Cerbos run fully inside our environment? Yes. The open source Cerbos PDP is self-hosted. Cerbos Synapse runs in customer-controlled infrastructure. Cerbos Hub Enterprise is also available on-premise for restricted and air-gapped environments. The components can be adopted independently. ## The short version **Cerbos strengths** - Provides an Apache 2.0 Cerbos service PDP for shared, sidecar, and node-local deployment - Adds a Cerbos Hub-managed ePDP for in-process WebAssembly evaluation in JavaScript environments - Packages policy tests, configurable audit, and authorization-specific query planning into the runtime - Adds policy build, signed distribution, and audit workflows through optional Cerbos Hub - Adds decision-time retrieval, transformation, and caching through self-hosted Cerbos Synapse - Supports customer-controlled deployment across Cerbos PDP, Cerbos Synapse, and enterprise on-premise or air-gapped Cerbos Hub - Partially implements AuthZEN Authorization API 1.0; Alex Olivier is a current Working Group cochair **Weigh with Cedar** - Cedar has materially stronger symbolic policy analysis and formal-assurance tooling - A native in-process Rust or Go implementation, or a Java binding, may be the right packaging choice where a Cerbos Hub dependency is not acceptable - Cedar is a CNCF Sandbox project with substantial AWS and academic investment - Cedar schemas and validation are a first-class part of its model - AWS-native or Cedar-compatible ecosystems may make Cedar the lower-friction choice - An existing, well-operated Cedar platform may not justify migration Bring one real policy set, one list-filtering path, and your deployment constraints. We will model the same boundary in Cerbos and help you compare decisions, integration code, and operating work. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- title: "Two developer-focused products, two default operating models" description: "Both products target application teams. In its standard hosted model, Permit.io pairs a managed control plane with an open source PDP. Cerbos can run a self-hosted Cerbos PDP from hand-authored policy files with no control plane required for decisions, while Cerbos Hub and Cerbos Synapse add commercial management and enrichment capabilities." competitor: "Permit.io" reviewed: "2026-07-24" prepared_by: "Cerbos" canonical: "https://www.cerbos.dev/cerbos-vs-permit" source: "https://www.cerbos.dev/cerbos-vs-permit" --- # Two developer-focused products, two default operating models Both products target application teams. In its standard hosted model, Permit.io pairs a managed control plane with an open source PDP. Cerbos can run a self-hosted Cerbos PDP from hand-authored policy files with no control plane required for decisions, while Cerbos Hub and Cerbos Synapse add commercial management and enrichment capabilities. Prepared by the Cerbos team. Facts last checked on 24 July 2026. ## Verdict **Choose Cerbos when** - The default should be a modular authorization platform: an independently deployable open source PDP, optional Cerbos Hub policy lifecycle, and commercial Cerbos Synapse enrichment. - The application team wants YAML or JSON policy with CEL rather than generated Rego or Cedar. - Policy lifecycle management and decision-time data enrichment should remain separate, optional platform concerns. **Consider Permit.io when** - A low code policy editor is the preferred authoring surface for developers and nondeveloper stakeholders. - Embeddable access request, approval, and user management components are product requirements. - OPAL-based policy and data distribution matches the operating model the team wants. **Already on Permit.io? Switching probably is not worth it when** - Product features depend on Permit Elements for access requests, approvals, or user management, and nobody is budgeted to rebuild them. - Nondevelopers author policy in the low code editor today and would not move to YAML or JSON with CEL. ## Where authorization lives Both products provide developer tooling and SDKs, publish open source PDPs under Apache 2.0, support RBAC and ABAC, participated successfully in the OpenID AuthZEN interoperability testing published in May 2024, and publish pricing with a free tier. Both also sell proprietary management capabilities, although their component boundaries and licences differ. Their defaults differ. Permit policy can be configured through its cloud UI, API, SDK, or IaC; UI changes generate Rego or Cedar in a Git repository the customer can own and extend, and OPAL distributes updates. The self-hosted Cerbos PDP can evaluate hand-authored YAML or JSON policies with CEL expressions from local or Git-backed storage without a control plane. Cerbos Hub adds source-agnostic policy ingestion, testing, signed bundle distribution, fleet monitoring, and audit; Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure and adds decision-time context enrichment. **Permit.io** — Permit provides a low code policy editor intended for developers and nondeveloper stakeholders. Permit Elements adds embeddable access request, approval, and user management components; as of 24 July 2026, Cerbos's public product documentation does not list an equivalent. OPAL is an Apache 2.0 engine for real time policy and data distribution. The Community plan is free for up to 1,000 MAU and 20 tenants as of the same date. **Cerbos** — Cerbos fits teams that want directly authored authorization policy and control over the decision path. The self-hosted Cerbos PDP runs as one binary or container and does not require a cloud control plane for local decisions. Cerbos Hub adds managed policy lifecycle and observability without requiring generated Rego or Cedar; Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure and adds licensed decision-time enrichment from existing systems. - **Source of truth** — With a standalone file- or Git-backed Cerbos PDP, hand-authored policy is the source artifact. Cerbos Hub-backed deployments validate and distribute versioned bundles. Permit supports cloud UI, API, SDK, IaC, direct code, and customer-owned Git workflows. - **What you deploy** — The standalone Cerbos PDP can run as one binary or container reading local policy files. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, without a per-decision service call. Permit offers a managed Cloud PDP or an Edge PDP container; the Edge container bundles a policy engine, OPAL client, and API server and normally syncs from its configured control plane. - **When you outgrow the UI** — Cerbos policies are authored directly in YAML or JSON with CEL expressions, so users do not maintain generated Rego or Cedar. Permit supports custom Rego or Cedar alongside generated code, plus API, SDK, IaC, and CLI workflows. ## What developer teams ask for Checked against Cerbos documentation, neutral standards, and Permit.io's own documentation. Several capabilities overlap, but their defaults and component boundaries differ. | Requirement | Cerbos | Permit.io | | --- | --- | --- | | Source of truth for policy | GIT NATIVE — Treats hand authored files in your repository as the authoritative artifact, reviewed and tested like any other code. | MULTIPLE PATHS — Supports cloud UI, API, SDK, IaC, direct code, and customer-owned Git workflows. UI changes generate Rego or Cedar. | | Policy language | NATIVE — Authors policy directly in YAML or JSON with CEL expressions, without requiring users to maintain generated Rego or Cedar. | GENERATED — Generates Rego or Cedar beneath the low code editor and also supports direct custom policy code. | | Self hosting and cloud dependency | NATIVE — The standalone Cerbos PDP needs no control plane for authoring or decisions. It can run air-gapped with local storage and telemetry disabled; enterprise Cerbos Hub also has an on-premise option. | SUPPORTED — Supports local Edge PDPs with a cloud control plane. The Enterprise plan also offers the complete control plane on-premise as a multiservice platform. | | Embeddable end user access UI | VIA CERBOS HUB API — No prebuilt UI components. Applications build access request and user management workflows on Cerbos Hub policy stores, updating policies programmatically through the Cerbos Hub API and SDKs for Go, JavaScript, Python, Java, .NET, PHP, and Rust — documented for per-tenant roles and user-defined permissions. | BUILT IN — Ships Permit Elements, embeddable components for access requests, approvals, and user management. A genuine differentiator. | | Keeping decision data fresh | VIA SYNAPSE — Licensed Cerbos Synapse supports decision-time enrichment from SQL and extension-defined HTTP, IdP, or graph sources, with in-memory or Redis caching. | BUILT IN — Distributes policy and external data to deployed policy agents in real time through Apache 2.0 OPAL. | | List filtering and query planning | BUILT IN — Exposes PlanResources plus six documented query-plan adapters for applying filters in the application datastore. | BUILT IN — Supports object filtering, OPA partial evaluation, and a Prisma extension. Evaluate policy-model and adapter coverage for your stack. | | AuthZEN compatibility | INTEROP READY — The Cerbos PDP partially implements the AuthZEN API, and Cerbos Synapse exposes the Cerbos API in front of an embedded or external Cerbos PDP. Alex Olivier, Cerbos cofounder and CPO, is one of the current AuthZEN Working Group cochairs. | INTEROP READY — Participated successfully alongside Cerbos in the OpenID AuthZEN interoperability testing published in May 2024. | | Open source and pricing transparency | APACHE 2.0 — Publishes the Cerbos PDP under Apache 2.0 with public pricing and a free tier. Cerbos Hub and Cerbos Synapse are commercial add-ons. | APACHE 2.0 — Publishes the PDP and OPAL under Apache 2.0 and SDKs under Apache 2.0 or MIT, depending on the SDK. The hosted control plane is proprietary. | ### Sources - [Cerbos policy storage](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html) - [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/policy-stores.html) - [Permit.io GitOps docs](https://docs.permit.io/integrations/gitops/overview) - [Permit.io Terraform provider docs](https://docs.permit.io/integrations/infra-as-code/terraform-provider) - [Cerbos policy authoring](https://docs.cerbos.dev/cerbos/latest/policies/authoring_tips.html) - [Permit.io blog: Cedar Q&A](https://www.permit.io/blog/cedar-qna) - [Permit.io docs: Write Custom Policies](https://docs.permit.io/integrations/gitops/custom_policy) - [Cerbos configuration](https://docs.cerbos.dev/cerbos/latest/configuration/index.html) - [Cerbos Hub on-premise](https://docs.cerbos.dev/cerbos-hub/on-premise) - [Permit.io deployment overview](https://docs.permit.io/how-to/deploy/overview) - [Permit.io on-prem deployment](https://docs.permit.io/how-to/deploy/on-prem/landing) - [Cerbos Hub policy stores](https://docs.cerbos.dev/cerbos-hub/latest/policy-stores) - [Permit Elements: Access Request docs](https://docs.permit.io/embeddable-uis/element/access-request) - [Permit Elements product page](https://www.permit.io/elements) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [Cerbos Synapse data sources](https://docs.cerbos.dev/synapse/latest/extensions/data-sources.html) - [OPAL GitHub repository](https://github.com/permitio/opal) - [Cerbos query-plan adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html) - [Permit.io docs: Data Filtering](https://docs.permit.io/how-to/enforce-permissions/data-filtering) - [Permit Prisma extension](https://github.com/permitio/permit-prisma) - [Cerbos AuthZEN API](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [AuthZEN interoperability results](https://openid.net/authorization-interop-results/) - [AuthZEN Working Group](https://openid.net/wg/authzen/) - [Cerbos pricing](https://www.cerbos.dev/pricing) - [Permit PDP GitHub repository](https://github.com/permitio/PDP) - [Permit.io pricing](https://www.permit.io/pricing) Evaluative conclusions are Cerbos's interpretation. Verify current capabilities before deciding. ## Ownership starts with the source artifact Both products support code and Git workflows, but their default authoring paths produce different operational ownership. Permit supports a cloud UI, API, SDK, IaC, direct code, and customer-owned Git. Changes made through its UI generate Rego or Cedar. That model is useful when policy editors must serve a mixed technical and nontechnical audience. A standalone Cerbos PDP reads policies authored directly in YAML or JSON with CEL. The repository can remain the authoritative artifact, with review and tests following the application's existing delivery workflow. Cerbos Hub is optional for the decision path. It adds ingestion, validation, testing, signed bundle distribution, fleet visibility, and audit. Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. ## The control plane and the decision path are separate choices The products can both place a PDP near the application, but the surrounding dependencies differ. Permit offers managed Cloud PDPs and Edge PDP containers. The Edge PDP normally receives policy and data updates through the configured Permit control plane and OPAL. The standalone open source Cerbos PDP can evaluate from local or Git-backed policy storage without contacting Cerbos Hub. A sidecar or service deployment keeps the synchronous request inside the application's infrastructure. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, with no per-decision service call. Permit also offers an enterprise on-premise control plane. The decision is therefore not simply cloud versus self-hosted. Compare the number of components, policy distribution path, failure behavior, and which team operates each component. ## Data distribution and decision-time enrichment solve different problems OPAL distributes data to policy agents; Cerbos Synapse retrieves context when a decision is evaluated. OPAL is an Apache 2.0 distribution engine for policy and external data. It fits systems that want policy agents to receive updates before a check is made. Commercial Cerbos Synapse runs in customer-controlled infrastructure. It can retrieve and transform identity, resource, or relationship context at decision time, with configured caching, before an embedded or external Cerbos PDP evaluates policy. Neither mechanism removes data-lifecycle design. Teams still need to define authoritative sources, acceptable staleness, cache behavior, and failure handling. ## Map the operating model before moving policy A migration can preserve existing application enforcement points while changing authoring, distribution, and context retrieval independently. | Permit.io concept | Cerbos | Notes | | --- | --- | --- | | Policy editor and generated Rego or Cedar | Directly authored YAML or JSON policies with CEL conditions | Translate the effective rules and tests, not the generated source line by line. | | Cloud PDP or Edge PDP | Self-hosted Cerbos PDP as a sidecar, DaemonSet, or service | Keep the existing PEP and replace its authorization client at one boundary first. | | Permit control plane and OPAL updates | Local or Git policy storage, or optional Cerbos Hub bundle distribution | Select the policy path independently from the runtime decision topology. | | Distributed external authorization data | Request attributes supplied by the application or fetched through Cerbos Synapse | Choose per datum whether the caller or customer-controlled Cerbos Synapse owns freshness. | ### A local decision path with optional management 1. **1. Author** — Engineers edit Cerbos policy and tests directly in the source repository. 2. **2. Distribute** — The Cerbos PDP reads local or Git-backed policy, or receives a signed bundle from Cerbos Hub. 3. **3. Check** — The application sends principal, action, resource, and current attributes to its local Cerbos PDP. 4. **4. Enforce** — The application applies the allow or deny response without a hosted control-plane call. Cerbos Hub can manage the lifecycle without becoming a mandatory synchronous dependency. Cerbos Synapse is added only when decision-time enrichment is required. ## Where Cerbos is not a drop-in substitute These differences can determine the decision before policy syntax or deployment cost is compared. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | Embeddable access workflows | No prebuilt UI components. Applications build access request and user management workflows on Cerbos Hub policy stores, updating policies programmatically through the Cerbos Hub API and SDKs. | Choose Permit Elements when those interfaces are a core product requirement, or plan to build and maintain them separately. | | Low code authoring for nondevelopers | Cerbos policy is directly authored as YAML or JSON with CEL; Cerbos Hub adds lifecycle tooling but does not replace Permit's low code editor. | Validate the authoring workflow with the people who will change policy, not only the engineers integrating the Cerbos PDP. | | Push-based external data distribution | The Cerbos PDP evaluates supplied attributes, while Cerbos Synapse retrieves context at decision time. Cerbos does not reproduce OPAL's distribution model. | Keep Permit or OPAL where pushed local data replicas are required, or redesign the source and freshness contract before migrating. | ## Where policy lives decides the rest The default authoring workflow remains a major difference, but it is not the only one. Teams should also compare policy and relationship models, embeddable UI, filtering coverage, deployment mode, commercial boundaries, and operational footprint. Permit's standard model centers its control plane, low code editor, Elements, and OPAL distribution. The standalone Cerbos model centers directly authored policy and an independently operated decision path. Cerbos extends that starting point without collapsing the boundary between policy and application data. Cerbos Hub manages ingestion, validation, testing, signed distribution, fleet visibility, and audit. Cerbos Synapse retrieves external context at decision time. The Cerbos PDP continues to evaluate locally, and teams do not have to inspect or maintain generated Rego or Cedar. Air-gapped operation is available with local storage and telemetry disabled, and enterprise Cerbos Hub can run on-premise. Permit fits when nondeveloper policy authoring and embeddable access workflows are central requirements. Cerbos fits when directly authored policy, a local decision path, independent deployment, and source-controlled lifecycle management matter more. ## Cerbos is the stronger application-authorization platform For teams choosing an application-authorization platform, Cerbos is the stronger overall choice because the open source Cerbos PDP, optional Cerbos Hub policy lifecycle, and commercial Cerbos Synapse enrichment form a modular stack with direct policy authoring and deployment control. Permit remains the stronger fit when its low code editor or embeddable Elements are requirements. Verify the choice with one production-shaped rule, the intended PDP topology, policy-update failure tests, and decision logs. ## Questions you are probably asking ### Is Permit not open source too? Yes. Permit's PDP and OPAL are Apache 2.0, while its SDKs use Apache 2.0 or MIT depending on the repository. The hosted control plane is proprietary. Cerbos PDP is Apache 2.0; Cerbos Hub and Cerbos Synapse are commercial products. Compare which components are required for authoring, distribution, enrichment, and each decision path. ### Permit has a no code UI for our product and ops teams. What does Cerbos offer them? Permit has the clearer fit when prebuilt nondeveloper policy authoring and end user access workflows are hard requirements. Cerbos policies are directly authored YAML or JSON with CEL, and Cerbos Hub adds collaborative playgrounds plus managed validation and distribution. Applications can also build their own access workflows on Cerbos Hub policy stores, updating policies programmatically through the Cerbos Hub API and SDKs, though Cerbos does not ship an equivalent to Permit Elements. ### How do the data models compare, OPAL sync versus Cerbos Synapse fetch? OPAL distributes policy and data changes to deployed policy agents. Licensed Cerbos Synapse retrieves and transforms context at decision time from SQL or extension-defined HTTP, IdP, and graph sources, with configurable caching. Neither model wins universally. Compare freshness requirements, source of truth design, extension work, operational cost, and the Apache 2.0 versus commercial boundary. ### Which is cheaper to adopt? Both publish pricing and free tiers. A workload-specific model should include licence units, plan limits, required components, infrastructure, and operating labour. For Permit, include the selected Cloud or Edge PDP and control-plane deployment. For Cerbos, include the standalone Cerbos PDP and any Cerbos Hub or Cerbos Synapse capabilities required. ## The short version **Cerbos strengths** - Supports a standalone, file-backed Cerbos PDP with no control plane required for authoring or decisions - Deploys the standalone Cerbos PDP as one binary or container and keeps synchronous decisions local - Can run air-gapped with local policy storage and telemetry disabled - Authors policy directly in YAML or JSON with CEL, without generated Rego or Cedar to maintain - Adds policy lifecycle management through Cerbos Hub and decision-time enrichment through Cerbos Synapse - Participated in AuthZEN interop; Alex Olivier is one of the current Working Group cochairs - Publishes public pricing with a free tier and an Apache 2.0 Cerbos PDP **Weigh with Permit.io** - Permit Elements provides embeddable access request and approval UI that Cerbos does not - The no code editor serves mixed developer and nondeveloper teams - OPAL provides Apache 2.0 real time policy and data distribution - Permit supports ReBAC and offers OPA/Rego and Cedar engine options; verify model-specific parity - The Community plan publishes measurable free limits - Permit also supports direct code, API, SDK, IaC, customer-owned Git, and enterprise on-premise workflows Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- title: "A relationship graph or a policy engine" description: "OpenFGA primarily evaluates whether relationships exist using a model and stored or contextual tuples. Cerbos PDP evaluates whether an action is allowed using policy and request-supplied attributes. The right choice depends on the shape of the authorization problem." competitor: "OpenFGA" reviewed: "2026-07-24" prepared_by: "Cerbos" canonical: "https://www.cerbos.dev/cerbos-vs-openfga" source: "https://www.cerbos.dev/cerbos-vs-openfga" --- # A relationship graph or a policy engine OpenFGA primarily evaluates whether relationships exist using a model and stored or contextual tuples. Cerbos PDP evaluates whether an action is allowed using policy and request-supplied attributes. The right choice depends on the shape of the authorization problem. Prepared by the Cerbos team. Facts last checked on 24 July 2026. ## Verdict **Choose Cerbos when** - The default should combine an independently deployable open source service PDP, an optional commercial Cerbos Hub-managed WebAssembly ePDP, and commercial Cerbos Synapse enrichment around attribute-led authorization. - Application relationship data should remain in existing systems rather than a second materialized tuple store. - The decision service must run locally and independently from a managed authorization API. **Consider OpenFGA when** - Permissions form a deep relationship graph with nested groups, folders, sharing, or delegation. - Native ListObjects and ListUsers operations are central to the application. - A Zanzibar-style model is the intended source of truth for authorization relationships. **Already on OpenFGA? Switching probably is not worth it when** - The tuple store is the system of record for relationships, and ListObjects or ListUsers back core product features. - Recursive sharing or nested group traversal dominates the authorization logic. Run both with a defined boundary instead of migrating. ## Two models for fine-grained access OpenFGA is an Apache 2.0 authorization system inspired by Google's Zanzibar, developed by Okta employees and now a CNCF Incubating project. Its primary model stores relationships as tuples and evaluates the resulting graph. Auth0 FGA is the managed service built on OpenFGA. Cerbos PDP evaluates each decision from attributes supplied at request time and does not require a duplicate relationship-tuple store; the caller or Cerbos Synapse still sources those attributes. The Cerbos platform extends the self-hosted Cerbos service PDP with Cerbos Hub for policy authoring, testing, signed distribution, fleet visibility, audit, and an in-process WebAssembly Cerbos ePDP for JavaScript environments. Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure and adds identity, resource, and relationship enrichment. Neither component turns Cerbos into a materialized graph engine. OpenFGA is more direct for graph traversal and native list operations; Cerbos makes attribute and context conditions the core policy model. **OpenFGA** — Fits products whose permissions form a relationship graph. Nested folders, group inheritance, delegated access, and document sharing at large fanout are the Zanzibar model's home ground. OpenFGA provides native ListObjects and ListUsers APIs, model tests, IDE validation, a CLI, and a GitHub Action, and it is a CNCF Incubating project. **Cerbos** — Fits systems where decisions turn on attributes and context. Policies express amount limits, record status, regions, and tenancy directly in YAML or JSON with CEL expressions. The Cerbos PDP does not persist application relationship data for evaluation, so it needs no second relationship store to reconcile. Policy and audit storage still depend on the configured backend. - **The data sync question** — When relationship data is duplicated between an application and OpenFGA, it needs a synchronization pattern because no transaction spans both systems. OpenFGA can instead be authoritative for some authorization data or accept contextual tuples. Cerbos PDP does not persist application relationship data for decisions; it evaluates request-supplied attributes. - **Attribute conditions** — Express amount, status, region, and time conditions as the core Cerbos policy model. OpenFGA supports CEL conditions and contextual tuples, with published request-size, tuple-count, and evaluation-cost limits. - **What you operate** — The open source Cerbos PDP can run as a sidecar, DaemonSet, or central service. Cerbos Hub ePDP evaluates Cerbos Hub-managed bundles in-process through WebAssembly in JavaScript environments. OpenFGA can run as a service backed by PostgreSQL, MySQL, or SQLite, or as a library in a Go service. Auth0 FGA puts checks on an Auth0-managed API path. ## What the two models trade Each row was checked against first-party documentation, and evidence links under each row point to the sources for each column. The models have different native strengths and deployment tradeoffs. | Requirement | Cerbos | OpenFGA / Auth0 FGA | | --- | --- | --- | | Attribute and context decisions | NATIVE — Evaluates CEL conditions over principal, resource, and request attributes as the core model. | BOUNDED — Supports conditions and contextual tuples as an extension to the relationship model, with documented limits on context size, evaluation cost, and per request tuples. | | Relationship graph at scale | PARTIAL — Evaluates supplied relationships through attributes and derived roles. Commercial Cerbos Synapse can retrieve graph-derived context at request time. For reverse relationship queries across very large object sets, a materialized graph is generally more direct. | NATIVE — Purpose built for the sharing graph shape, with native traversal and reverse queries over stored tuples. | | State and operations | STATELESS — The Cerbos PDP can run as a single binary without an application-data database. It has no relationship-tuple store to synchronize; policy and audit storage follow the selected backend. | STATEFUL — For persistent storage, supports PostgreSQL, MySQL, or SQLite and can be embedded in a Go service. Synchronization is required only when authorization data is duplicated elsewhere; Auth0 FGA is the managed option. | | Decision path | LOCAL OR IN-PROCESS — The Cerbos service PDP can decide beside the workload as a sidecar or DaemonSet. Cerbos Hub ePDP evaluates in-process through WebAssembly in JavaScript environments without a per-decision service call. | DEPENDS — Standalone OpenFGA adds an API hop and persistent datastore access; embedding it as a Go library removes the separate service hop. Auth0 FGA checks use an Auth0-managed regional API. | | Decision and audit logs | BUILT IN — When enabled, emits structured decision logs containing authorization requests, outcomes, and context, with configurable storage backends. | DEPENDS — Open source provides a tuple-change log rather than a decision-audit API. Auth0 FGA provides a Logging API across public endpoints with published seven-day retention. | | Listing what a user can access | QUERY PLAN — Returns a filter through the Query Plan API to run against your own database, with ORM adapters. | NATIVE — Provides native ListObjects and ListUsers. Nonstreaming endpoints default to a configurable 1,000-result maximum; streamed ListObjects returns results as they are found and remains workload- and deadline-dependent. | | Testing and CI | BUILT IN — Ships a first class test format and compile checks designed for authorization policies. | BUILT IN — Provides model tests, editor validation, CLI support, and CI integration. | | Open source and pricing transparency | APACHE 2.0 — Publishes the Cerbos PDP under Apache 2.0 with public pricing and a free tier. Cerbos Hub and Cerbos Synapse are commercial add-ons. | MIXED — OpenFGA is Apache 2.0 and CNCF Incubating. Auth0 FGA publishes trial and Enterprise limits, but production requires an Enterprise contract and no public per-unit rate is shown. | ### Sources - [Cerbos resource policies](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html) - [OpenFGA conditions](https://openfga.dev/docs/modeling/conditions) - [OpenFGA contextual tuples](https://openfga.dev/docs/interacting/contextual-tuples) - [Cerbos policy evaluation](https://docs.cerbos.dev/cerbos/latest/policies/evaluation.html) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [OpenFGA concepts](https://openfga.dev/docs/concepts) - [OpenFGA relationship queries](https://openfga.dev/docs/interacting/relationship-queries) - [Cerbos storage drivers](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html) - [CNCF OpenFGA project](https://www.cncf.io/projects/openfga/) - [OpenFGA introduction](https://openfga.dev/docs/fga) - [OpenFGA configuration](https://openfga.dev/docs/getting-started/setup-openfga/configuration) - [Cerbos deployment patterns](https://docs.cerbos.dev/cerbos/latest/deployment/index.html) - [Cerbos Hub embedded PDP](https://docs.cerbos.dev/cerbos-hub/deployments-epdp-rules.html) - [Auth0 FGA regional API URLs](https://docs.fga.dev/integration/getting-your-api-keys) - [Cerbos audit logging](https://docs.cerbos.dev/cerbos/latest/configuration/audit.html) - [OpenFGA Read Changes API](https://openfga.dev/docs/interacting/read-tuple-changes) - [Auth0 FGA Logging API](https://docs.fga.dev/fga-logging) - [Cerbos query-plan adapters](https://docs.cerbos.dev/cerbos/latest/recipes/query-plan-adapters/index.html) - [OpenFGA ListObjects and ListUsers](https://openfga.dev/docs/interacting/relationship-queries) - [Cerbos policy testing](https://docs.cerbos.dev/cerbos/latest/tutorial/04_testing-policies.html) - [OpenFGA model testing](https://openfga.dev/docs/modeling/testing) - [Cerbos pricing](https://www.cerbos.dev/pricing) - [Auth0 FGA subscription plans](https://docs.fga.dev/subscription-plans) Verify current capabilities before deciding. ## Policy evaluates facts; a graph derives them The main difference is what each engine treats as its native input and state. OpenFGA stores relationship tuples and evaluates paths defined by an authorization model. It is direct for questions such as whether a user belongs to a group that can view a document through an inherited folder relation. Cerbos evaluates actions against policy using principal, resource, and request attributes supplied for that decision. Ownership, tenant membership, record state, region, and amount thresholds can be expressed together as CEL conditions. Cerbos can consume a relationship result, but the Cerbos PDP does not become a graph database. OpenFGA can add conditions and contextual tuples, but its native abstraction remains the relationship graph. ## Relationship state changes the failure model A tuple store creates native graph capabilities and a data-lifecycle obligation. OpenFGA can be authoritative for authorization relationships. If the same relationship also exists in an application database, the system needs a synchronization and reconciliation design because no transaction spans both stores. The Cerbos PDP stores no application relationship graph. The caller supplies current facts, or commercial Cerbos Synapse retrieves them at decision time from customer-controlled infrastructure. The tradeoff is explicit. OpenFGA provides graph traversal and reverse lookup. Cerbos avoids a duplicated tuple store but depends on the caller or Cerbos Synapse to provide sufficiently fresh decision inputs. ## Listing and checking are different workload shapes OpenFGA queries its graph; Cerbos can return a query plan for the application's datastore. OpenFGA provides native Check, ListObjects, and ListUsers operations over its relationship model. This is a strong fit for sharing graphs and resource-to-principal lookup. Cerbos CheckResources evaluates known resources. PlanResources returns a condition plan that the application applies to its own database, with reference adapters for several data layers. The approaches are not interchangeable. Benchmark the largest list query, worst-case traversal, datastore filtering plan, and consistency requirement with production-shaped data. ## Translate decisions, not tuple syntax Migration is straightforward only when the graph is carrying facts that already exist in the application domain. | OpenFGA concept | Cerbos | Notes | | --- | --- | --- | | Authorization model | Resource and principal policies | Express actions, roles, and contextual rules directly; do not reproduce graph traversal in CEL. | | Stored relationship tuple | Principal or resource attribute supplied at request time | Read the authoritative domain record and pass only the facts needed by policy. | | Contextual tuple or condition context | Request auxiliary data or Cerbos Synapse-enriched context | Keep ephemeral facts request-scoped and define their freshness contract. | | ListObjects | PlanResources plus a datastore adapter | Apply the returned condition in the application datastore and validate result parity. | ### Replace an ownership tuple with an explicit policy condition `resource_album.yaml` ```yaml apiVersion: api.cerbos.dev/v1 resourcePolicy: version: default resource: album rules: - actions: ["view"] effect: EFFECT_ALLOW roles: ["user"] condition: match: expr: request.resource.attr.ownerId == request.principal.id - actions: ["view"] effect: EFFECT_ALLOW roles: ["user"] condition: match: expr: request.principal.attr.teamIds.exists(t, t == request.resource.attr.teamId) ``` This is suitable when ownership and team membership already come from authoritative application data. Keep OpenFGA when the decision requires graph traversal across nested or reverse relationships. ## Where Cerbos is not a graph engine Cerbos can evaluate relationship facts, but it does not reproduce OpenFGA's stateful graph operations. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | Deep relationship traversal | The Cerbos PDP evaluates supplied attributes. Cerbos Synapse can retrieve graph-derived context, but the Cerbos PDP does not materialize or traverse a relationship graph. | Keep OpenFGA for recursive inheritance and high-fanout sharing graphs, or use both systems with a defined responsibility boundary. | | Reverse relationship lookup | PlanResources supports principal-to-resource filtering in the application's datastore. Cerbos does not provide a native ListUsers equivalent. | Retain a graph or purpose-built index when resource-to-principal queries are a first-class workload. | | Managed graph service | Cerbos PDP is a policy decision point; Cerbos Hub manages policy lifecycle and Cerbos Synapse enriches decisions. Neither is a managed OpenFGA tuple store. | Use Auth0 FGA or operate OpenFGA when a managed or self-hosted relationship database is the required architecture. | ## ReBAC inside a multi model engine Many applications combine relationship-based permissions with attribute and context rules. A relationship-first model can make attribute-heavy policies less direct, although OpenFGA supports many such cases with CEL conditions and contextual data. With the standalone Cerbos PDP, callers resolve relationship context into attributes before evaluation; Cerbos Synapse can perform that enrichment. Cerbos evaluates ownership, membership, and tenancy when the relevant facts are supplied as request attributes. Commercial Cerbos Synapse runs in customer-controlled infrastructure and can retrieve deeper relationship context from a graph database or system of record at request time. Cerbos Hub Enterprise can manage policy lifecycle and audit on-premise, including in restricted or air-gapped environments. For reverse relationship queries across very large object sets, a materialized graph is often the more direct architecture. Benchmark the actual model, tuple volume, fanout, list operations, and deployment topology. When graph queries are a corner case, weigh that value against the graph store's operating cost and any synchronization pipeline required by the selected source of truth pattern. ## Cerbos is the stronger default for application authorization For application authorization that combines roles, attributes, current resource context, policy lifecycle, and deployment control, Cerbos is the stronger overall choice across its open source service PDP, commercial Cerbos Hub-managed WebAssembly ePDP, and commercial Cerbos Synapse layers. OpenFGA remains the stronger fit when deep graph traversal or native ListObjects and ListUsers operations dominate. Prove the boundary with representative check and list workloads, data writes, failure cases, and tail latency. ## Questions you are probably asking ### How much of Zanzibar's production track record transfers to OpenFGA? Google proved its Zanzibar implementation for Google's workloads and scale. OpenFGA is inspired by that model, but it is a separate implementation with its own deployment, datastore, model, and performance characteristics. Compare those characteristics against your actual workload rather than transferring Google's production evidence wholesale. ### What is the real cost of the tuple store? Persistent OpenFGA requires a datastore and an operating model. If the same relationship data exists in both the application and OpenFGA, synchronization and reconciliation are additional work. OpenFGA can instead be authoritative for some authorization data or accept contextual tuples. Cerbos PDP removes the relationship store, but the caller or Cerbos Synapse must source the attributes used by each decision. ### Can OpenFGA do attribute conditions? Yes. Conditions attach CEL expressions to relationships, and contextual tuples carry request data, with published ceilings on request size, evaluation cost, and contextual tuples per request. Cerbos makes these conditions the core policy model. Prototype representative rules in both systems and compare data flow, authoring, and evaluation requirements. ### Should we consider Auth0 FGA instead of self hosting? Auth0 FGA removes server and database operations, while synchronous checks use an Auth0-managed regional API. Production requires an Enterprise contract, published logs retain seven days, and a dedicated AWS Private Cloud option is available. Compare latency, availability, retention, export, contract terms, and private-cloud requirements against a self-hosted OpenFGA or local Cerbos PDP. ## The short version **Cerbos strengths** - Makes attribute and context conditions the core policy model - Runs the Cerbos PDP without a relationship-tuple database to operate or synchronize - Can decide locally beside each service, with no Cerbos cloud call in the synchronous path - Ships opt-in decision logging, policy tests, and query planning in the Apache 2.0 Cerbos PDP - Commercial Cerbos Synapse can query external systems and inject graph-derived context before Cerbos PDP evaluation - Adds policy lifecycle, signed distribution, fleet visibility, and audit through Cerbos Hub - Alex Olivier, Cerbos cofounder and CPO, is one of the current AuthZEN Working Group cochairs - Publishes public pricing alongside the Apache 2.0 Cerbos PDP **Weigh with OpenFGA** - Purpose built relationship traversal and reverse queries at graph scale - Native ListObjects and ListUsers over the stored graph, within documented limits - Model tests, editor validation, CLI support, and CI integration - CNCF incubation and an active community - A managed option through Auth0 FGA for teams that accept a cloud decision path - Plan synchronization only when OpenFGA duplicates relationship data held elsewhere Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- title: "Policy-first or relationship-graph-first authorization" description: "Zanzibar is Google's internal authorization system, documented in a 2019 USENIX paper, which inspired open source systems including OpenFGA and SpiceDB. Cerbos PDP is a policy engine; the broader Cerbos platform also includes Cerbos Hub, Cerbos Synapse, and enforcement integrations." competitor: "Zanzibar" reviewed: "2026-07-24" prepared_by: "Cerbos" canonical: "https://www.cerbos.dev/cerbos-vs-zanzibar" source: "https://www.cerbos.dev/cerbos-vs-zanzibar" --- # Policy-first or relationship-graph-first authorization Zanzibar is Google's internal authorization system, documented in a 2019 USENIX paper, which inspired open source systems including OpenFGA and SpiceDB. Cerbos PDP is a policy engine; the broader Cerbos platform also includes Cerbos Hub, Cerbos Synapse, and enforcement integrations. Prepared by the Cerbos team. Facts last checked on 24 July 2026. ## Verdict **Choose Cerbos when** - The default should combine an independently deployable open source PDP, optional Cerbos Hub policy lifecycle, and commercial Cerbos Synapse enrichment around contextual policy. - Relationship facts already live in application systems and can be supplied for each decision. - A stateless, locally deployed PDP is preferable to operating a separate relationship database. **Consider Zanzibar when** - The authorization domain is a large, dynamic graph with recursive inheritance or delegated sharing. - Both principal-to-resource and resource-to-principal queries must be native operations. - The system needs Zanzibar-style consistency controls across stored authorization relationships. **Already on Zanzibar? Switching probably is not worth it when** - A Zanzibar-style relationship store is already the system of record, and both lookup directions are native operations the product depends on. - Graph consistency semantics such as snapshot tokens are part of the correctness model. ## Rules over attributes, or a graph of tuples Google built Zanzibar to store and evaluate relationship-based ACLs globally, at a scale of trillions of ACLs and millions of authorization requests per second. It represents relations as tuples and evaluates relationship paths. Google does not sell Zanzibar as a standalone product; external adopters use Zanzibar-inspired systems such as OpenFGA and SpiceDB, self-hosted or through managed offerings. The self-hosted Cerbos PDP evaluates CEL policy conditions at request time over principal, resource, request, and auxiliary data, without materializing a separate relationship graph. For supported JavaScript environments, Cerbos Hub's commercial ePDP downloads Cerbos Hub-managed bundles and evaluates them in-process through WebAssembly, with no per-decision service call. The broader platform adds Cerbos Hub for policy lifecycle, signed distribution, fleet visibility, and audit; Cerbos Hub Enterprise can run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure and adds decision-time context enrichment. Deep traversal and bidirectional indexes remain native graph-engine strengths. **Zanzibar** — Zanzibar-style systems fit large, dynamic relationship graphs and commonly provide native traversal, bidirectional relationship queries, and consistency controls. Document sharing, nested folders, group inheritance, and delegated access are canonical use cases. Google proved its Zanzibar implementation at extreme scale; external implementations must be benchmarked separately. **Cerbos** — Cerbos fits applications whose rules are contextual. Approval thresholds, record states, tenancy, regions, working hours, and clearance levels are expressed directly as policy conditions. Policies can be Git-managed as YAML or JSON with CEL expressions. The standalone Cerbos PDP stores no relationship graph, so it needs no relationship-data synchronization pipeline or graph-consistency token; policy distribution and input freshness remain separate concerns. - **Where truth lives** — With the standalone Cerbos PDP, relationship attributes can remain in existing systems and be passed at decision time. Zanzibar-style deployments commonly persist relationships in a dedicated store; decide whether it is authoritative, synchronized from another source, or supplemented with request-time context. - **Auditability** — When policies are Git-managed and decision logging is enabled, auditors can inspect policy files, change history, and structured decisions. Explaining a relationship-based decision may require reconstructing schema, tuple paths, request context, and a consistency snapshot; tooling varies by implementation. - **Model mixing** — Express roles, attributes, and caller-supplied relationship facts in Cerbos policies. Relationship-first systems now support contextual conditions, while policy-first systems can consume graph-derived facts. Deep traversal and bidirectional indexes remain native graph-engine strengths. ## What the two models trade The Zanzibar column describes the model as implemented by projects such as OpenFGA and SpiceDB. Specifics vary by implementation, so verify against the one you are evaluating. | Requirement | Cerbos | Zanzibar model | | --- | --- | --- | | Contextual and attribute rules | NATIVE — Expresses amounts, statuses, regions, tenancy, and time directly as CEL conditions in policy. | SUPPORTED — Supports attributes through implementation-specific conditional relationships or caveats; some implementations also support contextual tuples. | | Deep relationship traversal | PARTIAL — Evaluates relationship facts supplied as attributes. Commercial Cerbos Synapse can query an external graph through a proxy extension and inject a precomputed result; the Cerbos PDP does not traverse or materialize the graph. | NATIVE — Traverses stored relationship graphs natively, including nested and inherited access, within implementation-specific recursion and query limits. | | Principal-to-resource listing | PARTIAL — Returns a condition AST through PlanResources for listing what a principal can access in the caller's datastore. It does not provide native resource-to-principal lookup. | NATIVE — Many implementations answer both principal-to-resource and resource-to-principal queries from the materialized graph, subject to documented limits. | | Operational footprint | STATELESS PDP — The decision service requires no relationship database. Policy distribution and audit storage depend on the selected deployment. | STATEFUL — Persists relationship data in a backing store. Self-hosted deployments operate it; managed offerings do so for the customer. Synchronization is an application-design choice. | | Policy as reviewable code | POLICY AS CODE — Expresses authorization rules in versionable, testable files; runtime identity, resource, and relationship data remain in external systems or requests. | SPLIT — Effective permissions derive from versioned schema plus stored relationships and any request-time context. | | Freshness and consistency | BY DESIGN — The standalone Cerbos PDP maintains no relationship-data copy and evaluates the supplied context. Input freshness, Cerbos Synapse caching, and policy distribution have separate settings. | VARIES BY IMPLEMENTATION — The Zanzibar paper's zookies and SpiceDB's ZedTokens prevent stale authorization after relationship changes. OpenFGA currently offers a choice between cached and uncached reads and lists consistency tokens as a possible future feature. | | Decision audit | BUILT IN, OPT-IN — When enabled, emits structured decision logs containing evaluation inputs, outputs, and policy metadata. | VERIFY — Varies by implementation. Effective access is distributed across tuple state, and decision audit is product dependent. | | Adoption path | DIRECT — Deploys the Cerbos PDP as a binary or container and connects it to a supported policy store. | VIA IMPLEMENTATIONS — Arrives through OpenFGA, SpiceDB, or managed services, each with its own operational model and commercial terms. | ### Sources - [Cerbos conditions](https://docs.cerbos.dev/cerbos/latest/policies/conditions.html) - [SpiceDB docs: Caveats](https://authzed.com/docs/spicedb/concepts/caveats) - [OpenFGA docs: Conditions](https://openfga.dev/docs/modeling/conditions) - [Cerbos derived roles](https://docs.cerbos.dev/cerbos/latest/tutorial/06_derived-roles.html) - [Cerbos Synapse](https://docs.cerbos.dev/synapse/latest/) - [Google Zanzibar paper](https://www.usenix.org/conference/atc19/presentation/pang) - [SpiceDB docs: Recursion and max depth](https://authzed.com/docs/spicedb/modeling/recursion-and-max-depth) - [Cerbos API](https://docs.cerbos.dev/cerbos/latest/api/index.html) - [SpiceDB docs: Querying data](https://authzed.com/docs/spicedb/concepts/querying-data) - [OpenFGA docs: Relationship queries](https://openfga.dev/docs/interacting/relationship-queries) - [Cerbos deployment patterns](https://docs.cerbos.dev/cerbos/latest/deployment/index.html) - [Cerbos storage](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html) - [SpiceDB docs: Datastores](https://authzed.com/docs/spicedb/concepts/datastores) - [AuthZed pricing](https://authzed.com/pricing) - [Cerbos policy storage](https://docs.cerbos.dev/cerbos/latest/configuration/storage.html) - [Cerbos policy testing](https://docs.cerbos.dev/cerbos/latest/policies/compile.html) - [SpiceDB docs: Schema](https://authzed.com/docs/spicedb/concepts/schema) - [OpenFGA docs: Concepts](https://openfga.dev/docs/concepts) - [SpiceDB docs: Consistency](https://authzed.com/docs/spicedb/concepts/consistency) - [OpenFGA docs: Query consistency](https://openfga.dev/docs/interacting/consistency) - [Cerbos audit logging](https://docs.cerbos.dev/cerbos/latest/configuration/audit.html) - [Auth0 FGA docs: Logging](https://docs.fga.dev/fga-logging) - [Cerbos binary installation](https://docs.cerbos.dev/cerbos/latest/installation/binary.html) - [OpenFGA](https://openfga.dev/) - [SpiceDB GitHub repository](https://github.com/authzed/spicedb) Checked against Cerbos documentation, the Zanzibar paper, and implementation documentation. Verify specifics against the implementation you are evaluating. ## The source of truth determines the architecture Cerbos consumes current domain facts; Zanzibar-style systems persist authorization relationships. A Zanzibar-style implementation stores tuples such as user, relation, and object, then evaluates paths through a versioned authorization schema. This makes the relationship store directly queryable in both directions. Cerbos policy evaluates the facts in a request. The application can load ownership, tenant membership, record state, and other attributes from its existing datastore before calling the Cerbos PDP. Neither arrangement removes state management. A graph deployment must define tuple writes and consistency. A policy deployment must define input freshness and the boundary between application lookup, optional Cerbos Synapse enrichment, and Cerbos PDP evaluation. ## Contextual policy and graph traversal have different native shapes Use the model that represents the difficult part of the domain directly. Zanzibar-style systems are direct for nested folders, group inheritance, delegation, and reverse lookup. The graph answers how a principal is related to an object. Cerbos is direct for rules such as a regional approver may release an invoice below a limit while the invoice is pending. Roles and CEL conditions evaluate in one policy decision. The models can coexist. A graph can derive a relationship fact that Cerbos combines with current resource and request context. Commercial Cerbos Synapse can retrieve graph-derived context from customer-controlled infrastructure, but does not turn the Cerbos PDP into a graph engine. ## Consistency mechanisms apply to different data Graph consistency protects relationship reads; policy deployments separate policy and input freshness. Zanzibar introduced consistency mechanisms for relationship changes so stale authorization does not incorrectly preserve or remove access. External Zanzibar-inspired products expose implementation-specific controls. The Cerbos PDP evaluates the request it receives against its loaded policy bundle. Relationship freshness is therefore owned by the caller or Cerbos Synapse data path, while policy distribution has its own lifecycle. For restricted environments, the standalone open source Cerbos PDP can run without a cloud dependency. In supported JavaScript environments, Cerbos Hub's commercial ePDP can instead evaluate downloaded Cerbos Hub-managed bundles in-process through WebAssembly, with no per-decision service call. Cerbos Hub Enterprise can also run on-premise in restricted or air-gapped environments. Cerbos Synapse runs in customer-controlled infrastructure when enrichment is required. ## Keep graph traversal where it is native A coexistence design can use a graph for inherited relationships and Cerbos for contextual policy. | Zanzibar-style concept | Cerbos | Notes | | --- | --- | --- | | Authorization schema | Cerbos resource and principal policies | Move contextual allow and deny rules; keep recursive relation definitions in the graph. | | Relationship tuple | Request attribute or graph-derived fact | Pass only the relationship result needed by the policy rather than copying the full graph. | | Consistency token | Caller-defined freshness contract | The application or Cerbos Synapse data source determines whether the supplied fact is current enough. | | Principal and resource listing | PlanResources for principal-to-resource filtering | Keep the graph for reverse lookup or traversals the application datastore cannot answer directly. | ### Combine a relationship result with current resource state 1. **1. Resolve relationship** — The graph service determines whether the principal is an inherited editor of the workspace. 2. **2. Load state** — The application loads the document classification, tenant, and lifecycle state from its source of truth. 3. **3. Evaluate policy** — Cerbos receives the graph result and current attributes, then evaluates the requested action against policy. 4. **4. Enforce** — The application applies the Cerbos decision and records the identifiers needed to trace both evaluations. This split preserves native graph traversal while centralizing contextual rules. Define timeout, stale-data, and disagreement behavior before production use. ## Where Cerbos does not reproduce Zanzibar Google's published Zanzibar architecture and external implementations solve graph workloads that a stateless policy engine does not. | Capability | Cerbos approach | Guidance | | --- | --- | --- | | Materialized relationship graph | Cerbos PDP stores no application relationship tuples and does not traverse recursive relationship paths. | Use a Zanzibar-inspired implementation when the graph itself is the authorization system of record. | | Bidirectional relationship queries | PlanResources filters resources for a principal through the application's datastore; Cerbos has no native resource-to-principal graph query. | Retain a graph engine or dedicated index when both query directions are required. | | Zanzibar consistency semantics | The Cerbos PDP evaluates supplied context against loaded policy. It does not issue graph snapshot tokens or provide graph-specific consistency controls. | Specify freshness at each caller, Cerbos Synapse, policy-distribution, and graph boundary instead of assuming equivalent semantics. | ## ReBAC expressed in a policy engine Ownership, membership, and tenancy can be expressed in Cerbos using caller-supplied attributes and derived roles. A document policy can grant editing to an owner, team, or collaborator list without a relationship store, provided those facts are included with the request. Commercial Cerbos Synapse runs in customer-controlled infrastructure and can use a proxy extension to query an external graph store or system of record before Cerbos PDP evaluation. Cerbos Hub Enterprise can manage and distribute policy on-premise in restricted or air-gapped environments. A Zanzibar-style engine remains more direct when bidirectional relationship queries over large object sets are a core requirement. Prototype representative rules in both models. Compare authoring, data flow, query patterns, consistency controls, deployment, and operating requirements. Cerbos fits when contextual policy, local evaluation, and source-controlled policy lifecycle dominate; a graph engine fits when deep traversal and bidirectional lookup dominate. ## Cerbos is the stronger default for contextual authorization For application authorization centered on contextual rules, reviewable policy, controlled deployment, managed policy lifecycle, and optional enrichment, Cerbos is the stronger overall choice across Cerbos PDP, Cerbos Hub, and Cerbos Synapse. A Zanzibar-inspired implementation remains the stronger fit when a large relationship graph, bidirectional lookup, and graph-specific consistency are the core requirements. Benchmark the selected products with representative depth, fanout, list operations, and contextual rules. ## Questions you are probably asking ### Google proved Zanzibar at massive scale. Does that not settle it? It proves Google's implementation for Google's workloads and scale. Assess whether your dominant requirements are deep traversal and bidirectional lookup, contextual policy evaluation, or a hybrid. Current implementations combine relationship and context features, but with different native strengths and operating models. ### Can Cerbos really express ReBAC? Cerbos can evaluate ownership, membership, tenancy, and collaborator facts supplied as attributes. Commercial Cerbos Synapse can query external systems for graph-derived attributes before evaluation. Cerbos does not maintain a Zanzibar-style relationship graph or bidirectional reverse index, so a graph engine remains the more direct option for those workloads. ### Which Zanzibar implementation should we compare against? OpenFGA and SpiceDB are prominent open source Zanzibar-inspired implementations, and each has a managed offering. They differ in APIs, consistency controls, query limits, backing stores, and commercial models. We publish a separate comparison with OpenFGA. ### What does the relationship model cost operationally? A Zanzibar-style system is stateful and persists relationships in a backing store. In a self-hosted, duplicated-data design, the team operates the service and reconciles changes with the application database. Managed services and request-time context reduce parts of that burden, while using the relationship store as the source of truth changes it. The standalone Cerbos PDP removes relationship-store operation and reconciliation, at the price of assembling the required context for each request. ## The short version **Cerbos strengths** - Expresses contextual, attribute-driven rules directly - Covers common relationship patterns when facts are supplied as request attributes - Runs the Cerbos PDP statelessly, with no relationship graph to synchronize, back up, or keep consistent - Keeps authorization policy logic in reviewable, testable files that can be managed in Git - Provides opt-in decision logging and principal-to-resource query planning in the Apache 2.0 Cerbos PDP - Commercial Cerbos Synapse can inject graph-derived relationship context before Cerbos PDP evaluation - Cerbos Hub adds policy lifecycle management, signed distribution, fleet visibility, and audit - Alex Olivier, Cerbos cofounder and CPO, is one of the current AuthZEN Working Group cochairs **Weigh with Zanzibar** - Google Zanzibar proved relationship evaluation at extreme scale; external implementations provide traversal and listing APIs with separate limits - A natural model for products dominated by large, dynamic sharing graphs - Implementation-specific consistency controls for stale-grant risk, latency, and throughput - Open source implementations including OpenFGA and SpiceDB - Managed services exist for teams that prefer not to operate the store - Plan for a persistent relationship store; add synchronization when it duplicates data held elsewhere Send us one of your real authorization scenarios, however messy. We will model it in Cerbos policies and run it with you. ## Research basis Each claim was checked against the vendor's or project's own public documentation, pricing pages, and release notes, plus neutral standards and foundation sources. Claims are documented rather than tested firsthand unless the text says otherwise. Where a claim says nothing was found as of a date, it describes an absence of public evidence on that date. --- title: "Cerbos ecosystem" description: "Every Cerbos integration: 147 identity providers, frameworks, SDKs, gateways, deployment targets and AI tools." canonical: "https://www.cerbos.dev/ecosystem" source: "https://www.cerbos.dev/ecosystem" integrations: 147 --- # Cerbos ecosystem > 147 integrations across 10 categories, each with a page at `https://www.cerbos.dev/ecosystem/`. This document lists them all, so a lookup takes one fetch rather than one per integration. An integration appears under every category it belongs to. ## Identity providers (32) Cerbos integrates with any source of user identity, including these common authentication providers, and has native support for JWTs. - **Auth0** — Map Auth0 Actions, Organizations, and roles to Cerbos policy inputs. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-auth0) · [Vendor site](https://auth0.com/) - **Authentik** — Authentik property mappings shape token claims for Cerbos policy inputs. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-authentik) · [Vendor site](https://goauthentik.io/) - **AWS Cognito** — Cognito user pool groups and custom attributes as Cerbos policy inputs. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-aws-cognito) · [Vendor site](https://aws.amazon.com/cognito/) - **Clerk** — Clerk session claims and Organizations drive Cerbos policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-clerk) · [Vendor site](https://clerk.dev/) - **Curity Identity Server** — Curity token procedure claims as principal attributes in Cerbos. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-curity) · [Vendor site](https://curity.io/) - **Descope** — Descope JWT claims, tenant data, and role assignments feed into Cerbos policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-descope) · [Vendor site](https://www.descope.com/) - **Duende IdentityServer** — Duende IdentityServer claims and scopes evaluated by Cerbos in .NET apps. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-duende) · [Vendor site](https://duendesoftware.com/) - **EmpowerID** — EmpowerID governance roles and delegated access in Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-empowerid) · [Vendor site](https://www.empowerid.com/) - **Firebase** — Firebase custom claims feed into Cerbos for resource-level decisions. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-firebase) · [Vendor site](https://firebase.google.com/) - **FusionAuth** — FusionAuth per-application roles and custom data fields in Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-fusionauth) - **Gluu Server** — Gluu LDAP-backed groups and OIDC claims evaluated by Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-gluu) · [Vendor site](https://gluu.org/) - **Google Identity Platform** — Google Identity Platform custom claims and tenant context feed into Cerbos policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-google-identity-platform) · [Vendor site](https://cloud.google.com/identity-platform) - **JSON Web Tokens** — Cerbos natively decodes JWTs and maps claims to policy attributes. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-jwt) · [Vendor site](https://jwt.io) - **JumpCloud** — JumpCloud directory groups and OIDC claims drive Cerbos policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-jumpcloud) · [Vendor site](https://jumpcloud.com/) - **Keycloak** — Keycloak realm roles, client roles, and group hierarchies in Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-keycloak) · [Vendor site](https://www.keycloak.org) - **Kinde** — Kinde organizations and feature flags as inputs to Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-kinde) · [Vendor site](https://kinde.com/) - **LDAP** — Query any LDAPv3 directory for user attributes and group memberships. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-ldap-enrichment) - **LDAP** — LDAP group DNs and organizational units as Cerbos principal attributes. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-ldap) - **Magic** — Magic DID tokens and wallet addresses as Cerbos principal attributes. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-magic) · [Vendor site](https://magic.link/) - **Microsoft Entra ID** — Entra ID security groups and app roles evaluated by Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-microsoft-entra-id) · [Vendor site](https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id) - **Okta** — Okta groups and Universal Directory attributes as Cerbos policy inputs. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-okta) · [Vendor site](https://www.okta.com/) - **OneLogin** — OneLogin roles and group memberships from OIDC tokens drive Cerbos policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-onelogin) · [Vendor site](https://www.onelogin.com/) - **Ory** — Ory Kratos identity traits from JSON schemas feed Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-ory) · [Vendor site](https://www.ory.sh/) - **Ping Identity** — PingOne populations and PingFederate attributes in Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-ping-identity) · [Vendor site](https://www.pingidentity.com/en.html) - **SecureAuth** — SecureAuth risk signals and identity attributes in Cerbos policy checks. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-secureauth) · [Vendor site](https://www.secureauth.com/) - **SPIFFE** — SPIFFE IDs authorize service-to-service calls through Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/spiffe) · [Vendor site](https://spiffe.io/) - **Stytch** — Stytch B2B organization memberships and roles in Cerbos policy checks. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-stytch) · [Vendor site](https://stytch.com/?utm_source=cerbos&utm_medium=referral) - **Supabase** — Supabase app_metadata and JWT claims as policy inputs alongside RLS. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-supabase) · [Vendor site](https://supabase.com/) - **SuperTokens** — Self-hosted authorization using SuperTokens session claims in Cerbos. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-supertokens) · [Vendor site](https://supertokens.com/) - **Thales Identity** — Thales SafeNet identity attributes drive resource-level Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-thales) · [Vendor site](https://cpl.thalesgroup.com/access-management) - **WorkOS** — WorkOS Directory Sync groups and Organizations in Cerbos B2B policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-workos) - **Zitadel** — Zitadel project roles and organization grants as Cerbos policy inputs. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-zitadel) · [Vendor site](https://zitadel.com/) ## Frameworks (17) Cerbos works with a wide variety of libraries and frameworks. Jumpstart your integration with our pre-built solutions for common frameworks. - **ASP.NET** — Authorize ASP.NET controllers and endpoints via the Cerbos .NET SDK. [Integration page](https://www.cerbos.dev/ecosystem/aspnet) · [Vendor site](https://dotnet.microsoft.com/en-us/apps/aspnet) - **Django** — Authorize Django views and middleware via the Cerbos Python SDK. [Integration page](https://www.cerbos.dev/ecosystem/django) · [Vendor site](https://www.djangoproject.com/) - **Express** — Enforce access control per route via Express middleware hooks. [Integration page](https://www.cerbos.dev/ecosystem/express) · [Vendor site](https://expressjs.com/) - **FastAPI** — Inject Cerbos checks as FastAPI dependencies in endpoint signatures. [Integration page](https://www.cerbos.dev/ecosystem/fastapi) · [Vendor site](https://fastapi.tiangolo.com/) - **Flask** — Authorize Flask routes via decorators or before-request hooks with Cerbos. [Integration page](https://www.cerbos.dev/ecosystem/flask) · [Vendor site](https://flask.palletsprojects.com/) - **Gin** — Cerbos authorization wired into the Gin middleware chain. [Integration page](https://www.cerbos.dev/ecosystem/gin) · [Vendor site](https://gin-gonic.com/) - **Gorilla** — Cerbos authorization wired into the Gorilla Mux middleware chain. [Integration page](https://www.cerbos.dev/ecosystem/gorilla) · [Vendor site](https://www.gorillatoolkit.org/) - **GraphQL** — Per-field and per-resolver access control for GraphQL schemas. [Integration page](https://www.cerbos.dev/ecosystem/graphql) - **Hono** — Authorize Hono routes and middleware via the Cerbos JavaScript SDK. [Integration page](https://www.cerbos.dev/ecosystem/hono) · [Vendor site](https://hono.dev/) - **NestJS** — Cerbos checks via NestJS guards, decorators, and injectable modules. [Integration page](https://www.cerbos.dev/ecosystem/nestjs) · [Vendor site](https://nestjs.com/) - **NextJS** — Authorize middleware, server components, and API routes in Next.js. [Integration page](https://www.cerbos.dev/ecosystem/nextjs) · [Vendor site](https://nextjs.org/) - **Nuxt** — Access control in the Nitro server layer for Nuxt routes and APIs. [Integration page](https://www.cerbos.dev/ecosystem/nuxt) · [Vendor site](https://nuxt.com/) - **React Router** — Gate data loading and mutations in React Router loaders and actions. [Integration page](https://www.cerbos.dev/ecosystem/react-router) · [Vendor site](https://reactrouter.com/) - **Ruby on Rails** — Authorize Rails controllers and actions via the Cerbos Ruby SDK. [Integration page](https://www.cerbos.dev/ecosystem/rails) · [Vendor site](https://rubyonrails.org/) - **Spring Boot** — Wire Cerbos into Spring Boot with annotations and bean injection. [Integration page](https://www.cerbos.dev/ecosystem/spring-boot) · [Vendor site](https://spring.io/projects/spring-boot) - **SvelteKit** — Authorize load functions, form actions, and hooks in SvelteKit. [Integration page](https://www.cerbos.dev/ecosystem/sveltekit) · [Vendor site](https://kit.svelte.dev/) - **VueJS** — Server-evaluated permissions surfaced to Vue.js route guards and views. [Integration page](https://www.cerbos.dev/ecosystem/vuejs) · [Vendor site](https://vuejs.org/) ## SDKs (9) SDKs for the most popular languages and a simple API for everything else. Cerbos works with any software. - **.NET** — NuGet package with async/await and strongly typed Cerbos models. [Integration page](https://www.cerbos.dev/ecosystem/dotnet) · [Vendor site](https://github.com/cerbos/cerbos-sdk-net) - **Go** — gRPC-native SDK with strongly typed checks and context.Context support. [Integration page](https://www.cerbos.dev/ecosystem/go) · [Vendor site](https://github.com/cerbos/cerbos-sdk-go) - **Java** — Maven Central SDK with blocking and CompletableFuture Cerbos clients. [Integration page](https://www.cerbos.dev/ecosystem/java) · [Vendor site](https://github.com/cerbos/cerbos-sdk-java) - **JavaScript** — Async SDK for Node.js, edge runtimes, and browsers with TypeScript types. [Integration page](https://www.cerbos.dev/ecosystem/javascript) · [Vendor site](https://github.com/cerbos/cerbos-sdk-javascript) - **Laravel** — Cerbos policies behind Laravel Gate::allows() and @can directives. [Integration page](https://www.cerbos.dev/ecosystem/laravel) · [Vendor site](https://github.com/cerbos/cerbos-sdk-laravel) - **PHP** — PSR-compatible Composer package for Cerbos authorization in PHP. [Integration page](https://www.cerbos.dev/ecosystem/php) · [Vendor site](https://github.com/cerbos/cerbos-sdk-php) - **Python** — pip-installable SDK for sync and async Cerbos authorization in Python. [Integration page](https://www.cerbos.dev/ecosystem/python) · [Vendor site](https://github.com/cerbos/cerbos-sdk-python) - **Ruby** — Idiomatic Ruby gem for authorization checks against the Cerbos PDP. [Integration page](https://www.cerbos.dev/ecosystem/ruby) · [Vendor site](https://github.com/cerbos/cerbos-sdk-ruby) - **Rust** — Async, type-safe Cerbos client built on tonic and tokio. [Integration page](https://www.cerbos.dev/ecosystem/rust) · [Vendor site](https://github.com/cerbos/cerbos-sdk-rust) ## Deployment (22) Cerbos is stateless and can run anywhere a container or binary can be launched, including these common deployment targets. - **Amazon EC2** — Standalone binary or container PDP on EC2 with full instance control. [Integration page](https://www.cerbos.dev/ecosystem/amazon-ec2) · [Vendor site](https://aws.amazon.com/ec2/) - **Amazon Elastic Beanstalk** — Multi-container Cerbos sidecar that auto-scales with Beanstalk instances. [Integration page](https://www.cerbos.dev/ecosystem/amazon-elastic-beanstalk) · [Vendor site](https://aws.amazon.com/elasticbeanstalk/) - **Amazon Elastic Container Service** — Stateless PDP container running as an ECS task or Fargate sidecar. [Integration page](https://www.cerbos.dev/ecosystem/amazon-ecs) · [Vendor site](https://aws.amazon.com/ecs/) - **Amazon Elastic Kubernetes Service** — Helm-managed Cerbos on EKS with IRSA and Fargate support. [Integration page](https://www.cerbos.dev/ecosystem/amazon-eks) · [Vendor site](https://aws.amazon.com/eks/) - **AWS Lambda** — Embedded in-process PDP for serverless authorization with no network hop. [Integration page](https://www.cerbos.dev/ecosystem/amazon-lambda) · [Vendor site](https://aws.amazon.com/lambda/) - **Azure Container Apps** — Managed container PDP on Azure Container Apps with scaling and revision control. [Integration page](https://www.cerbos.dev/ecosystem/azure-container-apps) · [Vendor site](https://azure.microsoft.com/en-us/products/container-apps) - **Azure Kubernetes Service** — Cerbos on AKS with workload identity and Helm-based lifecycle management. [Integration page](https://www.cerbos.dev/ecosystem/azure-aks) · [Vendor site](https://azure.microsoft.com/en-gb/products/kubernetes-service) - **Azure Virtual Machine** — Binary or container PDP on Azure VMs with Scale Set auto-scaling. [Integration page](https://www.cerbos.dev/ecosystem/azure-virtual-machine) · [Vendor site](https://azure.microsoft.com/en-gb/products/virtual-machines) - **Cloudflare Workers** — Serverless authorization at the network edge via Cerbos inside Cloudflare Workers. [Integration page](https://www.cerbos.dev/ecosystem/cloudflare-workers) · [Vendor site](https://workers.cloudflare.com/) - **DigitalOcean** — Container or binary PDP on DigitalOcean App Platform, Droplets, or Managed Kubernetes. [Integration page](https://www.cerbos.dev/ecosystem/digitalocean) · [Vendor site](https://www.digitalocean.com/) - **Docker** — Official multi-arch container image for local dev and production. [Integration page](https://www.cerbos.dev/ecosystem/docker) · [Vendor site](https://www.docker.com/) - **Fly.io** — Stateless PDP instances placed close to users across Fly.io regions. [Integration page](https://www.cerbos.dev/ecosystem/fly-io) · [Vendor site](https://fly.io/) - **Google Cloud Compute Engine** — Cerbos binary or container on Compute Engine with Managed Instance Groups. [Integration page](https://www.cerbos.dev/ecosystem/google-cloud-compute) · [Vendor site](https://cloud.google.com/compute) - **Google Cloud Run** — Serverless container PDP on Cloud Run with automatic scaling and managed infrastructure. [Integration page](https://www.cerbos.dev/ecosystem/google-cloud-run) · [Vendor site](https://cloud.google.com/run) - **Google Kubernetes Engine** — Helm-managed Cerbos on GKE with Workload Identity and Autopilot support. [Integration page](https://www.cerbos.dev/ecosystem/google-cloud-gke) · [Vendor site](https://cloud.google.com/kubernetes-engine) - **HashiCorp Nomad** — Container PDP orchestrated by Nomad with Consul service discovery and health checks. [Integration page](https://www.cerbos.dev/ecosystem/nomad) · [Vendor site](https://www.nomadproject.io/) - **Helm** — Official Helm chart with production-ready defaults for the Cerbos PDP. [Integration page](https://www.cerbos.dev/ecosystem/helm) · [Vendor site](https://helm.sh/) - **Homebrew** — One-command install of the Cerbos binary on macOS or Linux. [Integration page](https://www.cerbos.dev/ecosystem/homebrew) · [Vendor site](https://brew.sh/) - **Kubernetes** — Run the PDP as a Deployment, DaemonSet, or sidecar in any K8s cluster. [Integration page](https://www.cerbos.dev/ecosystem/kubernetes) · [Vendor site](https://kubernetes.io) - **Railway** — Container PDP deployed to Railway with managed networking and automatic restarts. [Integration page](https://www.cerbos.dev/ecosystem/railway) · [Vendor site](https://railway.app/) - **Render** — Container PDP running as a Render web service with managed TLS and health checks. [Integration page](https://www.cerbos.dev/ecosystem/render) · [Vendor site](https://render.com/) - **Systemd** — Native binary managed by systemd with journal logging and auto-restarts. [Integration page](https://www.cerbos.dev/ecosystem/systemd) · [Vendor site](https://systemd.io/) ## Context sources (13) Automatically enrich authorization requests with user profiles, group memberships, and directory roles from your identity provider, no application code changes required. - **AWS Cognito** — Pull Cognito custom attributes and groups into the PDP at decision time. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-cognito-enrichment) - **Data Source Extensions** — Reusable data connectors with built-in caching for the Cerbos authorization pipeline. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-data-source-extensions) - **External API** — Call external services to fetch context data for policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-external-api) - **Keycloak** — Pull realm roles, client roles, and group paths from Keycloak into policies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-keycloak-enrichment) - **LDAP** — Query any LDAPv3 directory for user attributes and group memberships. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-ldap-enrichment) - **Litestream** — Read Litestream-replicated SQLite databases as a policy data source. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-litestream) · [Vendor site](https://litestream.io/) - **Microsoft Entra ID** — Resolve Entra ID security groups and directory roles for policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-entra-enrichment) - **MySQL** — Built-in data source that queries MySQL tables at decision time. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-mysql) · [Vendor site](https://www.mysql.com/) - **Neo4j** — Traverse Neo4j relationship graphs to resolve authorization context. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-neo4j) - **Okta** — Fetch Okta profiles and group memberships into policy evaluations. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-okta-enrichment) - **PostgreSQL** — Built-in data source that queries PostgreSQL at decision time. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-postgresql) · [Vendor site](https://www.postgresql.org/) - **Proxy Extensions** — Transparent request enrichment that fetches context from external systems before policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-proxy-extensions) - **SQLite** — Embedded SQLite data source for local policy context lookups. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-sqlite) · [Vendor site](https://www.sqlite.org/) ## Authorization extensions (11) Extend Cerbos authorization beyond your application to service meshes, data platforms, and Kubernetes, with native support and unified policies. - **Apache Kafka** — Pluggable authorizer for Kafka topic, consumer group, and cluster ops. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-kafka) - **Apache Trino** — Catalog, schema, and column-level access control via Apache Trino's authorization hook. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-trino) - **AWS App Mesh** — Cerbos authorization via Envoy ext_authz within AWS App Mesh sidecars. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-aws-app-mesh) · [Vendor site](https://aws.amazon.com/app-mesh/) - **Consul Connect** — Cerbos authorization via Envoy ext_authz within Consul Connect sidecars. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-consul-connect) · [Vendor site](https://www.consul.io/docs/connect) - **Contour** — Cerbos authorization via Envoy ext_authz at the Contour ingress controller. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-contour) · [Vendor site](https://projectcontour.io/) - **Emissary-Ingress (Ambassador)** — Cerbos authorization via Envoy ext_authz at the Emissary-Ingress API gateway. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-emissary-ingress) · [Vendor site](https://www.getambassador.io/products/api-gateway) - **Envoy External Authorization** — Cerbos as a native ext_authz gRPC service for Envoy proxies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-envoy) - **Gloo Gateway** — Cerbos authorization via Envoy ext_authz at the Gloo Gateway edge. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-gloo-gateway) · [Vendor site](https://www.solo.io/products/gloo-gateway/) - **Istio Service Mesh** — External authorizer for service-to-service calls in Istio meshes. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-istio) - **Kubernetes Admission Control** — Validating webhook that enforces Cerbos policies on cluster resources. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-k8s-admission) - **Route Extensions** — Protocol translation layer that lets any infrastructure component delegate authorization to Cerbos. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-route-extensions) ## Data filtering (12) Authorization-aware query filtering that pushes access control to the data layer, so your database only returns rows users are authorized to see. - **Apache Kafka** — Pluggable authorizer for Kafka topic, consumer group, and cluster ops. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-kafka) - **ChromaDB** — Translate Cerbos query plans into ChromaDB metadata filters. [Integration page](https://www.cerbos.dev/ecosystem/chromadb) · [Vendor site](https://www.trychroma.com/) - **Convex** — Convert Cerbos query plans into native Convex filter expressions. [Integration page](https://www.cerbos.dev/ecosystem/convex) · [Vendor site](https://convex.dev/) - **Drizzle ORM** — Map Cerbos query plans to Drizzle ORM where-clause conditions. [Integration page](https://www.cerbos.dev/ecosystem/drizzle) · [Vendor site](https://orm.drizzle.team/) - **Elasticsearch** — Emit Cerbos query plans as Elasticsearch bool query filters. [Integration page](https://www.cerbos.dev/ecosystem/elasticsearch) · [Vendor site](https://www.elastic.co/elasticsearch) - **Mongoose** — Apply Cerbos query plans as MongoDB filter predicates via Mongoose. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-mongoose) · [Vendor site](https://mongoosejs.com/) - **Pinecone** — Cerbos policy decisions as Pinecone metadata filters in LangGraph RAG. [Integration page](https://www.cerbos.dev/ecosystem/rag-pinecone) · [Vendor site](https://www.pinecone.io/) - **Prisma** — Inject Cerbos query plans as Prisma where-clause filters on any model. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-prisma) · [Vendor site](https://www.prisma.io/) - **RAG (Retrieval-Augmented Generation)** — Enforce document-level access control on vector store retrieval. [Integration page](https://www.cerbos.dev/ecosystem/rag) - **Spring Data JPA** — Turn Cerbos query plans into JPA Specification predicates for Spring. [Integration page](https://www.cerbos.dev/ecosystem/spring-data-jpa) · [Vendor site](https://spring.io/projects/spring-data-jpa) - **SQLAlchemy** — Append Cerbos query plans to SQLAlchemy select statements as filters. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-sqlalchemy) · [Vendor site](https://www.sqlalchemy.org/) - **UCAST (Universal Conditions AST)** — Bridge Cerbos query plans to any data layer via the UCAST AST format. [Integration page](https://www.cerbos.dev/ecosystem/ucast) · [Vendor site](https://github.com/stalniy/ucast) ## AI (18) Secure AI agents and tool access with fine-grained, policy-driven authorization and full audit trails. - **Agent Gateway** — Policy-driven authorization for MCP, A2A, and LLM traffic through Agent Gateway. [Integration page](https://www.cerbos.dev/ecosystem/agent-gateway) · [Vendor site](https://agentgateway.dev/) - **Agent2Agent Protocol** — Policy-driven authorization for inter-agent communication via the Agent2Agent protocol. [Integration page](https://www.cerbos.dev/ecosystem/a2a) · [Vendor site](https://google.github.io/A2A/) - **Aperture by Tailscale** — Zero Trust authorization for AI agents routed through Aperture by Tailscale. [Integration page](https://www.cerbos.dev/ecosystem/aperture-by-tailscale) · [Vendor site](https://tailscale.com/aperture) - **ChromaDB** — Translate Cerbos query plans into ChromaDB metadata filters. [Integration page](https://www.cerbos.dev/ecosystem/chromadb) · [Vendor site](https://www.trychroma.com/) - **Claude Agent SDK** — Gate Claude agent tool calls and data access through Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/claude-agent-sdk) · [Vendor site](https://docs.anthropic.com/en/docs/agents-and-tools/claude-agent-sdk) - **Claude Code** — Centralized policy enforcement and audit logging for Claude Code agent tool calls. [Integration page](https://www.cerbos.dev/ecosystem/claude-code) · [Vendor site](https://code.claude.com) - **CrewAI** — Per-agent and per-tool authorization for CrewAI multi-agent workflows through Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/crewai) - **FastMCP** — Drop-in Cerbos middleware for FastMCP tool and resource authorization. [Integration page](https://www.cerbos.dev/ecosystem/fastmcp) · [Vendor site](https://github.com/jlowin/fastmcp) - **Google Agent Development Kit** — Gate Google ADK agent tool calls and data access through Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/google-adk) · [Vendor site](https://google.github.io/adk-docs/) - **LangChain** — Gate LangChain and LangGraph tool calls through Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/langchain) · [Vendor site](https://www.langchain.com/) - **LangGraph** — Per-node and per-tool authorization for LangGraph multi-step agent workflows. [Integration page](https://www.cerbos.dev/ecosystem/langgraph) · [Vendor site](https://langchain-ai.github.io/langgraph/) - **LlamaIndex** — Enforce authorization on LlamaIndex agent tool calls and data connector access through Cerbos policies. [Integration page](https://www.cerbos.dev/ecosystem/llamaindex) - **Model Context Protocol** — Per-tool and per-resource authorization for Model Context Protocol servers. [Integration page](https://www.cerbos.dev/ecosystem/mcp) · [Vendor site](https://modelcontextprotocol.io/) - **OpenAI Agents SDK** — Gate OpenAI Agents SDK tool invocations through Cerbos policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/openai-agents-sdk) - **Pinecone** — Cerbos policy decisions as Pinecone metadata filters in LangGraph RAG. [Integration page](https://www.cerbos.dev/ecosystem/rag-pinecone) · [Vendor site](https://www.pinecone.io/) - **RAG (Retrieval-Augmented Generation)** — Enforce document-level access control on vector store retrieval. [Integration page](https://www.cerbos.dev/ecosystem/rag) - **Semantic Kernel** — Gate Semantic Kernel plugin and function invocations through Cerbos policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/semantic-kernel) - **Vercel AI SDK** — Gate AI tool invocations in Vercel AI SDK applications through Cerbos policy evaluation. [Integration page](https://www.cerbos.dev/ecosystem/vercel-ai-sdk) ## API gateways (16) Enforce fine-grained authorization at the edge, rejecting unauthorized requests before they reach your services. - **Apigee** — Cerbos policy checks via Apigee service callout policies on API proxy requests. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-apigee) · [Vendor site](https://cloud.google.com/apigee) - **AWS API Gateway** — Lambda authorizer that evaluates Cerbos policies for API Gateway. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-aws-api-gateway) · [Vendor site](https://aws.amazon.com/api-gateway/) - **Azure API Management** — Cerbos policy evaluation via Azure API Management inbound policies on each request. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-azure-api-management) · [Vendor site](https://azure.microsoft.com/en-us/products/api-management) - **Broadcom Layer7 API Gateway** — Cerbos policy enforcement at the Broadcom Layer7 gateway edge. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-layer7) · [Vendor site](https://www.broadcom.com/products/software/api-management) - **Cloudflare** — Cerbos policy checks within Cloudflare Workers at the network edge. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-cloudflare) · [Vendor site](https://www.cloudflare.com/) - **Contour** — Cerbos authorization via Envoy ext_authz at the Contour ingress controller. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-contour) · [Vendor site](https://projectcontour.io/) - **Emissary-Ingress (Ambassador)** — Cerbos authorization via Envoy ext_authz at the Emissary-Ingress API gateway. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-emissary-ingress) · [Vendor site](https://www.getambassador.io/products/api-gateway) - **Envoy External Authorization** — Cerbos as a native ext_authz gRPC service for Envoy proxies. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-envoy) - **Gloo Gateway** — Cerbos authorization via Envoy ext_authz at the Gloo Gateway edge. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-gloo-gateway) · [Vendor site](https://www.solo.io/products/gloo-gateway/) - **Gravitee API Gateway** — Evaluate Cerbos policies on every request at the Gravitee API Gateway edge. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-gravitee) · [Vendor site](https://gravitee.io/) - **Kong Gateway** — Evaluate Cerbos policies on every request at the Kong gateway edge. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-kong) · [Vendor site](https://konghq.com/) - **NGINX** — Cerbos policy checks via the NGINX auth_request module at the reverse proxy edge. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-nginx) · [Vendor site](https://nginx.org/) - **Traefik Proxy** — Cerbos policy evaluation via Traefik's ForwardAuth middleware on each request. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-traefik) · [Vendor site](https://traefik.io/) - **Tyk Gateway** — Cerbos policy evaluation as a Tyk gateway middleware plugin. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-tyk) · [Vendor site](https://tyk.io/) - **WSO2 API Manager** — Attach Cerbos policy checks to WSO2 API Manager request flows. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-wso2) · [Vendor site](https://wso2.com/api-manager/) - **Zuplo API Gateway** — Inline Cerbos authorization checks within Zuplo request pipelines. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-zuplo) · [Vendor site](https://zuplo.com/) ## CI/CD (6) Automate Cerbos policy testing and deployment as part of your CI/CD pipeline, so every policy change is validated and pushed to Cerbos Hub on merge. - **Azure DevOps Pipelines** — Push Cerbos policies to Cerbos Hub on every merge via Azure DevOps Pipelines. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-azure-devops) · [Vendor site](https://azure.microsoft.com/en-us/products/devops/pipelines) - **Bitbucket Pipelines** — Push Cerbos policies to Cerbos Hub on every merge via Bitbucket Pipelines. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-bitbucket-pipelines) · [Vendor site](https://bitbucket.org/product/features/pipelines) - **Buildkite** — Push Cerbos policies to Cerbos Hub on every merge via Buildkite. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-buildkite) · [Vendor site](https://buildkite.com) - **CircleCI** — Push Cerbos policies to Cerbos Hub on every merge via CircleCI. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-circleci) · [Vendor site](https://circleci.com) - **GitHub Actions** — Push Cerbos policies to Cerbos Hub on every merge via GitHub Actions. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-github-actions) · [Vendor site](https://github.com/features/actions) - **GitLab CI/CD** — Push Cerbos policies to Cerbos Hub on every merge via GitLab CI/CD. [Integration page](https://www.cerbos.dev/ecosystem/cerbos-gitlab-runners) · [Vendor site](https://docs.gitlab.com/ee/ci/) --- title: "Cerbos customer case studies" description: "Named Cerbos deployments with quantified outcomes: what each team built, what changed, and where to read the full case study." canonical: "https://www.cerbos.dev/customers" source: "https://www.cerbos.dev/customers" customers: 12 --- # Cerbos customer case studies > 12 named deployments, each with its outcomes and a full case study available as markdown. Use these for proof points and reference customers. ## Loop **Loop secures air-gapped cash deposit machines with Cerbos** A fintech company offering financial operations software and physical cash deposit machines implements secure and scalable authorization with Cerbos and streamlines compliance certifications. - Authorization rolled out in one week - 6 months of upfront development saved - Swiftly satisfied key regulatory requirements > The Cerbos solution is battle tested, secure and it's doing what it's supposed to do. We have full trust in the product. > > — Mohsin Kalam, CTO & Co-founder, Loop [Case study](https://www.cerbos.dev/customers/withloop) · [Markdown](https://www.cerbos.dev/customers/withloop.md) ## Utility Warehouse **Utility Warehouse synchronizes authorization across 4,500 services** An FTSE 250 Index company replaces a cumbersome in-house authorization system with decoupled, centralized authorization management, gaining enhanced reliability and transparency. - Months of developer time reclaimed from boring maintenance - Enhanced reliability and transparency for access control - Eliminated technical debt from authorization > Cerbos has a grammar in their YAMLs that we can trust. What we had before was the wild west. It was thousands of lines of code. > > — Rob Crowe, Principal Engineer, Utility Warehouse [Case study](https://www.cerbos.dev/customers/utility-warehouse) · [Markdown](https://www.cerbos.dev/customers/utility-warehouse.md) · [Website](https://uw.co.uk) ## Supy **Supy offers dynamic role management to their clients with Cerbos** A back-of-house restaurant management software improves customer satisfaction and growth by offering clients the ability to create custom roles and permissions for their accounts. - Increased customer satisfaction - Enhanced operational efficiency - Improved security and compliance > Offering dynamic roles and permissions makes us more competitive in the market. We’re providing companies with a software that can be adapted to their workflows. > > — Ibrahim Bou Ncoula, CTO, Supy [Case study](https://www.cerbos.dev/customers/supy) · [Markdown](https://www.cerbos.dev/customers/supy.md) · [Website](https://supy.io/) ## Salesroom **Cerbos helps Salesroom save over $1MM worth of developer time** An interactive video conferencing startup built a reliable, low-maintenance, enterprise-ready authorization layer with a fraction of the effort they expected. - Clean and orderly permissions logic at scale - Unlimited redundancies, no single point of failure - Authorization maintenance reduced to almost nothing > Deploying Cerbos has allowed our engineers to spend their time on what really matters for Salesroom’s success. And I sleep better at night. > > — Chuck Hardy, Head of Engineering, Salesroom [Case study](https://www.cerbos.dev/customers/salesroom) · [Markdown](https://www.cerbos.dev/customers/salesroom.md) ## Nook **Nook onboards 3x more users by implementing granular roles and permissions** Using Cerbos for their authorization layer, Nook allows businesses to bring more stakeholders into the accounts payable workflow, streamlining essential financial processes for their users. - Increased number of user roles available in the product - Secure and reliable access gating for sensitive resources - Increased customer adoption with better user experience > For every client we have, we're able to have 2x, 3x, the number of users for that client on Nook than we could without the roles and permissions that we have. > > — Henry Arnold, CTO & Co-Founder, Nook [Case study](https://www.cerbos.dev/customers/nook) · [Markdown](https://www.cerbos.dev/customers/nook.md) · [Website](https://nook.io) ## Human Managed **Human Managed creates a future-proof ABAC engine with Cerbos** A sophisticated intelligence platform builds fine-grained access control policies to deliver flexible, customizable product packaging to their customers. - Days-long coding task reduced to 5 minutes - Dependencies and middleware replaced with a single binary - Enhanced flexibility to customize services > We can make unlimited conditions, attributes, parameters to any granularity level without writing any code. It allows us to deliver truly personalized services quickly, securely & at scale. > > — Karen Kim, CEO, Human Managed [Case study](https://www.cerbos.dev/customers/human-managed) · [Markdown](https://www.cerbos.dev/customers/human-managed.md) · [Website](https://www.humanmanaged.com) ## Flash **Flash eliminates authorization technical debt and doubles corporate card spending with Cerbos** A Brazilian fintech replaces a legacy custom policy service with Cerbos to deliver flexible, real time expense controls to corporate clients, driving increased confidence and card usage. - 2x increase in corporate card spending for companies using policy controls - 6,000+ policy rules managed in real-time for regulated payment transactions - Authorization for hundreds of companies without scaling engineering headcount > What caught our attention was the deployment modes, which were very adherent to our new infrastructure running Kubernetes. We could choose to run as a server or as a sidecar. And it was focused on performance and easier to integrate than other solutions out there because Cerbos uses JSON or YAML; you choose. > > — Paulo Henrique Pereira Cardoso, Tech Manager at Flash [Case study](https://www.cerbos.dev/customers/flash) · [Markdown](https://www.cerbos.dev/customers/flash.md) · [Website](https://flashapp.com.br/) ## Debite **Debite accelerates compliance certification and ships products faster** A financing and payments platform uses Cerbos to create centralized, scalable authorization and cut weeks off of their product development. - Saved £200,000 in developer time - Streamlined FCA (Financial Conduct Authority) certification - Launched ahead of schedule > Cerbos enables us to go to market very quickly, compared to an in-house solution. It allows us to offer new products faster as well, because writing new policies or editing them is so easy > > — Engin Attar, Head of Product and Growth, Co-Founder, Debite [Case study](https://www.cerbos.dev/customers/debite) · [Markdown](https://www.cerbos.dev/customers/debite.md) ## complex **Complex (NTWRK) makes a complex access control system easy to manage with Cerbos** Using Cerbos to model, test, and implement roles and permissions, NTWRK operationalizes numerous edge case policies across a distributed architecture and streamlines policy maintenance. - Complex logic tested and verified before deployment - All application permissions managed from one place - Increased pace of development and faster app iterations > Cerbos has removed an entire stress point for me around distributing permissions in general. > > — Steve High, Staff Engineer, NTWRK [Case study](https://www.cerbos.dev/customers/complex) · [Markdown](https://www.cerbos.dev/customers/complex.md) · [Website](https://thentwrk.com/) ## BarrierSystems **BarrierSystems integrates Cerbos into smart vehicle access gates, cutting internal costs by 15%** Using Cerbos to manage access policies, BarrierSystems was able to improve user experience and simplify their own policy management workflows to enable consistent and reliable access control for their customers. - 75% fewer support tickets related to authZ - Faster time to market with new features - Improved scalability > Our existing structure was inconsistent, making it difficult to track and manage permissions across diverse customer needs. We needed a system that offered both clarity and scalability. > > — Aaron Maier, Lead Software Developer at BarrierSystems [Case study](https://www.cerbos.dev/customers/barriersystems) · [Markdown](https://www.cerbos.dev/customers/barriersystems.md) · [Website](https://www.barriersystems.de/) ## 9fin **9fin modifies product packaging in 10 minutes** A finance data platform serving top 10 investment firms reclaims their time, prevents future technical debt, and gets features to market faster by implementing authorization rules with Cerbos. - Reduced hours of developer time to 10 minutes - Eliminated technical debt from authorization - Accelerated feature development and time to market > We can keep adding rules, without bloating and creating spaghetti code. I struggle to think of requirements that can’t be expressed in the Cerbos policy format. > > — Joe Qureshi, Senior Software Engineer, 9fin [Case study](https://www.cerbos.dev/customers/9fin) · [Markdown](https://www.cerbos.dev/customers/9fin.md) · [Website](https://9fin.com/) ## 4G Capital **4G Capital saves a quarter-million dollars per year with Cerbos** A digital bank replaces their legacy authorization service with Cerbos and improves their cost-efficiency. - $264k saved per year by switching authorization services - From requirements to production in minutes instead of a full development cycle. - Policies are updated in minutes when requirements change > We got the foundation set. Now we can scale and include more complex policies. And we can grow in the right direction and with the right security. > > — Edgar Rivera, CTO, 4G Capital [Case study](https://www.cerbos.dev/customers/4g-capital) · [Markdown](https://www.cerbos.dev/customers/4g-capital.md) · [Website](https://www.4g-capital.com/)