What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Feature split between the open source PDP and the commercial hub: confirm current boundary
- AI agent and MCP authorization positioning: verify against vendor materials
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Cerbos is a policy decision point. You run it as a stateless service next to your application, usually as a sidecar container, and your code asks it a question rather than answering one itself: given this principal, with these attributes and roles, may they perform this action on this resource. Cerbos evaluates the applicable policies and returns a decision, optionally for many resources at once so a list endpoint can be filtered in a single round trip.
Policies are YAML files versioned in git: resource policies attach rules to a resource kind, and derived roles compute contextual roles such as owner or same-department from attribute comparisons. Conditions are expressions over principal and resource attributes, which makes the model attribute based rather than a flat role check. Because the engine holds no state and fetches no data, every attribute it reasons over must be supplied in the request. That keeps decisions fast and deterministic, and makes policy testable: Cerbos ships a test runner so policy changes get unit tests like any other code. The commercial hub layers policy CI, distribution to deployed decision points, and an embedded build that avoids a network hop.
Where it fits
This is a build and runtime component, not a scanner. Application developers integrate the client library and move authorization logic out of controllers and into policy files. The security or platform team then owns the policy repository, which is the real benefit: authorization rules become reviewable artifacts rather than scattered conditionals. Adoption requires refactoring existing permission checks, so it lands most cleanly in new services. In AI systems it gates what an agent or tool call may do on behalf of a user, which matters once agents act with delegated authority.
Strengths
- Policy lives in git with tests, so authorization changes go through code review instead of a console.
- Stateless and local, which keeps decision latency low and avoids a network dependency on a central service.
- Attribute based conditions handle ownership, tenancy and relationship rules that role lists alone cannot express.
- Language agnostic API means polyglot estates share one policy set.
Limitations
- The caller must supply every attribute the policy needs. Cerbos does not fetch data, so complex policies push data loading work back into the application.
- Migrating an existing codebase with embedded permission checks is a substantial refactor, not a drop in.
- Policy distribution, audit and governance at scale lean on the commercial hub, so the open source component alone leaves operational gaps.
Who it suits
Teams with multi tenant or relationship heavy authorization that has outgrown role constants in application code. Overkill for a small service with three roles and no tenancy, where a library level check is simpler and easier to reason about.
Used Cerbos? Recommend it under your own name and title.
Recommend this tool