Agent skill for writing authorization policies

Writing authorization policies has always been the bit I wanted to make easier. The Cerbos policy language is expressive, the CEL conditions are powerful, but there's still a learning curve when you're staring at a blank file trying to model your access control requirements.

So we built a skill that does it for you.

What it actually does

You describe what you need in plain English. "Editors can update posts in their own department. Admins can do everything. Viewers are read-only except they can't see salary data." That kind of thing.

The skill asks you clarifying questions until it has a clear picture of your resources, roles, actions, and conditions. It'll also push back on things that seem too broad. Say "admins can do everything" and it'll ask whether admins really need delete access, or whether you want an explicit list of actions. 5 years of helping teams model their authorization has taught us that the vague requirements are where security holes hide, so the skill steers you toward least-privilege and explicit deny-by-default from the start.

Once it has a clear spec, it generates everything in one pass: schemas, derived roles, resource policies, test fixtures, and test suites. The generated policies follow patterns we've seen work across hundreds of production deployments. Things like scoping derived roles tightly, using attribute conditions instead of role proliferation, and structuring tests to cover both the allowed and denied paths.

Once the files are written, it runs cerbos compile via Docker to validate the whole bundle. If something fails (and sometimes it does), the skill reads the errors and fixes them. It keeps iterating until the compiler is happy or it's tried 3 different fixes for the same problem, at which point it tells you what's wrong and lets you take over.

The workflow

There are 5 phases, and the skill follows them in order:

1. Spec intake. Asks questions in plain business language ("who can delete a project?") until roles, resources, actions, and conditions are nailed down. Nudges you toward zero trust principles along the way: explicit permissions over implicit ones, narrow scopes over broad grants. Produces a short spec and confirms it with you before writing anything.

2. Write. Generates all files in a single batch: schemas first, then derived roles and shared variables, then policies, then test data and test suites. Every generated policy follows the same patterns we use internally and recommend to customers. No wildcard actions, no overly permissive defaults, conditions on every rule that needs them.

3. Validate. Runs docker run --rm -v "$(pwd):/policies" ghcr.io/cerbos/cerbos:latest compile /policies and check for any errors.

4. Fix. If validation fails, it works through errors in priority order: YAML syntax, schema validation, compile errors, then test failures. One fix per iteration. Never deletes a test to make things pass (that rule is in there because I know how tempting it is).

5. Finalize. Reports what was created and flags any assumptions it made along the way.

What you get

A complete policy bundle ready to drop into your Cerbos PDP:

• _schemas/ with your principal and resource attribute schemas
• derived_roles/ with shared role definitions and exported variables
• resource_policies/ (or role_policies/) with your actual authorization rules
• testdata/ with fixtures and test suites that exercise your policies

Install it

Works with Claude Code, Cursor, Codex, OpenCode, and a bunch of other agents.

npx skills add cerbos/skills --skill cerbos-policy

If you're using Claude Code directly:

claude plugin marketplace add cerbos/skills

The repo is at github.com/cerbos/skills.

Why we built this

Cerbos policies are code. They live in your repo, they're version controlled, they're testable. That makes them a natural fit for AI coding agents that already live in your editor and understand your codebase.

The tricky part was getting the output right. Authorization policies have sharp edges. A missing condition or a wrong role binding and you've got a security hole. So we packed the skill with the full Cerbos reference material (policy schemas, CEL patterns, testing recipes) and wired it to always validate against the real compiler. The agent doesn't just generate YAML and hope for the best. It proves the policies compile.

We also baked in 5 years of learnings from working with teams building authorization. Every recommendation the skill makes, from how it structures derived roles to how it models attribute conditions to how it generates test cases, comes from patterns we've seen succeed (and fail) in production. The zero trust defaults, the preference for explicit deny, the way it pushes you to define schemas upfront: that's all stuff we learned the hard way by watching what breaks when you skip it.

We've been using this internally for a few months now and it's genuinely changed how fast we can put together policy bundles for demos and customer POCs. I think it'll save you a fair amount of time too, especially if you're new to Cerbos and want to get something working quickly without picking up bad habits along the way.

Give it a try and let us know how you get on. We're tracking feedback and bug reports on the GitHub repo.

For a general guide on how to write, test, and validate authorization policies - read this write-up.