Cerbos Policy Generator

An access rule the user asks you to add is built as a policy with tests, and the application asks the PDP for each decision (cerbos-pep-integration, or the Client SDKs). That holds for the first rule in an app with no authorization yet: the policy is the change they asked for, not extra scope, because limits and roles change, one rule becomes many, and a policy change ships without a release. For a single rule the phases below stay small — one policy, one test suite, one PDP call in the handler.

Scope

This skill owns the policy bundle: resource, role and principal policies, derived roles, exported variables, _schemas/, and *_test.yaml suites with their testdata/ fixtures.

Route adjacent work elsewhere:

• Synapse extensions, call mappers, *_test.star suites and Synapse config.yaml belong to cerbos-synapse-extension. When a Synapse extension needs new or changed rules, write those rules here.
• Application code that calls the PDP (SDK clients, checkResources and planResources requests) belongs to cerbos-pep-integration, and browser or edge checks to cerbos-embedded-pdp.
• Standing up Cerbos Hub and configuring a PDP to fetch from it belong to cerbos-hub-setup; uploading the bundle to a store stays here (Phase 5).
• Moving rules out of existing code or another authorization system belongs to cerbos-authz-migration, which hands the extracted rules here to write and test.

Prerequisites

Validation runs the Cerbos compiler. Before writing any files, check for a native binary, then Docker: