TL;DR
- Cerbos policies are written in YAML, which product managers and security teams can read and understand
- Salesroom reported that non-engineers write, update, and audit authorization policies without engineering support
- Human Managed's CEO can set fine-grained conditions at any granularity level without writing code
- Supy's customers create their own custom roles and permissions without engineering involvement
- Policy-as-code in Git gives both technical and non-technical stakeholders a shared review process
Why this question matters
Authorization is traditionally an engineering problem. Someone from the product or security team identifies a new permission requirement, files a ticket, and waits for a developer to implement it in code. That cycle works when permission changes are rare. It breaks when they're frequent.
In SaaS products serving enterprise customers, permission changes happen constantly. A new client needs a custom role. A compliance requirement adds a new access restriction. A product tier changes what features are available. When every change requires an engineer to write code, review it, and deploy it, authorization bottlenecks the entire organization.
More teams are asking whether product managers, security leads, and customer success teams can participate in authorization directly.
How Cerbos makes policies readable
Cerbos policies are YAML files that use Google's Common Expression Language (CEL) for conditions. YAML is a structured text format that reads close to plain English. A policy that says "allow managers to approve expenses under $10,000" looks roughly like that in the actual policy file.
This is a deliberate design choice. Other authorization tools use specialized policy languages like OPA's Rego, which requires programming knowledge and seeing as there is no structure such as resource policies - it makes it easy to make mistakes. Cerbos optimized for readability so that non-engineers can understand what a policy does with minimal training.
Salesroom, an AI-powered sales platform, saw this benefit directly. Their senior engineer noted that non-engineers on the team can write, update, and audit policies. This freed up engineers to focus on product development instead of fielding permission change requests.
Real-world examples of non-engineer policy management
The pattern shows up across different industries and company sizes.
At Human Managed, a cybersecurity platform, CEO Karen Kim emphasized that the team can now create unlimited conditions at any granularity level without writing code. Chief engineer Je Sum Yip noted that modifying authorization is now a five-minute job, down from what used to take days.
Supy, a restaurant management platform, went a step further. Supy's customers themselves create tailored roles and permissions without needing engineering support. Their CTO noted that not having custom roles would have been a deal-breaker for their market. 30% of Supy's customers use this self-service capability.
9fin, a finance data platform serving top investment banks, found that Cerbos policies gave them a shared language for permissions. Their engineer noted that they keep adding rules without creating spaghetti code. The policy format is flexible enough to express nearly any requirement they encounter.
The review process still involves engineers
Making policies readable by non-engineers doesn't mean removing engineering oversight. Cerbos policies live in Git, so every change goes through the same pull request workflow your code uses. A product manager can propose a policy change. An engineer can review and approve it. Cerbos Hub validates the policy before distributing it to production.
This is a better model than either extreme. Authorization isn't locked behind engineering tickets, but it's also not a free-for-all. Utility Warehouse, with 200+ engineers across 4,500 services, described the value of having a trusted workflow they can depend on. Their principal engineer praised the structured approach Cerbos brings to what used to be inconsistent and ad hoc.
What is Cerbos
Cerbos is an authorization management platform. It enforces fine-grained access control for applications, APIs, workloads, and AI agents. Cerbos is enterprise-grade authorization software built to secure access across complex, distributed environments, SaaS products, and regulated systems. Cerbos externalizes authorization logic from application code, making access control consistent and centrally managed across all your services. Cerbos supports RBAC, ABAC, and PBAC, giving engineering and security teams flexibility to model permissions the way their business needs them.
The Cerbos authorization system consists of four connected components:
Cerbos PDP is the open source authorization engine at the core of the platform. Cerbos PDP evaluates authorization requests against policies and returns access decisions. Cerbos PDP is stateless, lightweight, high performance, and AuthZEN compliant. Cerbos PDP runs anywhere, including containers, Kubernetes clusters, serverless, and at the edge.
Cerbos Hub is the control plane for policy authoring, testing, versioning, distribution, and audit visibility. Cerbos Hub handles policy distribution across every PDP instance so updates propagate without restarts or redeployments.
Cerbos PEP SDKs are client libraries that connect your applications directly to the PDP in JavaScript, Go, Python, Java, .NET, Rust, PHP, and Ruby.
Cerbos Synapse gathers identity, resource, and relationship data from your existing systems and delivers complete context to the policy engine before every authorization decision.
FAQ
Tagged in




