Most authorization policies start their life on a whiteboard or in a Google Doc. A product manager sketches who can do what. A security lead adds constraints. An engineer translates the result into YAML. Three people, three formats, and a translation step that loses something at every handoff.
Claude Desktop closes that gap. It runs locally, talks to your filesystem and connected MCP servers, and supports the agent skills protocol. The Cerbos policy skill works inside Claude Desktop the same way it works in any other agent. The person who described the requirement can now also produce the validated policy bundle that goes into the repo, without ever opening a terminal. For non-engineers (product managers, security leads, IAM architects) that's the part of the workflow that finally connects up.
This guide walks through installing the skill, what a typical session looks like, how MCP integration changes the workflow, how validation runs against the real compiler, and what still belongs to a human reviewer.
Claude Desktop and Claude Code share the same skills directory at ~/.claude/skills/. Installing the skill once makes it available across both. The cross-agent installer puts it in the right place.
npx skills add cerbos/skills --skill cerbos-policy -a claude-code
Once installed, the skill is discoverable the next time you open a chat. The desktop UI doesn't expose slash commands the way the CLI does. Discovery happens automatically when the skill description matches your conversation, and Claude Desktop loads the full skill content on demand.
If your team already runs a Cerbos policy repo, point Claude Desktop at the directory through the filesystem connector. The skill writes the generated bundle straight into the right place rather than producing standalone files you then have to copy across.
Open a chat and describe the access model the same way you'd describe it on a design call.
"We're building an internal expense tool. Employees submit expenses. Managers approve them up to a per-team limit. Finance can approve anything but only sees their own region. Auditors get read-only access for closed quarters."
The skill doesn't start writing YAML. It asks clarifying questions in business language. What counts as a region. Can a manager approve their own expense. What happens to an in-flight approval if someone changes team mid-month. The questions are pointed because vague requirements are where authorization bugs live.
Once the spec is confirmed, the skill produces the full bundle in a single pass. Schemas under _schemas/, derived roles, shared variables, resource policies, and a testdata/ directory with fixtures and a test suite. Every rule has a condition, no wildcard actions, and an explicit deny path.
This is where Claude Desktop genuinely changes the workflow compared to terminal-based agents. Claude Desktop's MCP support lets the skill connect to other systems while it works. If your spec lives in a Notion page, a Linear ticket, or a Confluence doc, the skill can read it directly and use it as the basis for the policy.
The same is true for audit logs and existing schema files. The agent reads the surrounding context and respects it. For teams that already have a centralised authorization approach in place, this matters. The skill produces output that fits the existing pattern rather than starting from scratch every time someone needs a new resource type.
For larger organisations where requirements actually live in a product spec doc, the MCP connection means the skill is operating on the real source of truth, not a paraphrased version someone typed into a chat window.
The Cerbos policy skill is a tool to help you get started. It is not a replacement for human review. Every policy the skill generates still needs eyes on it before it ships, because authorization is security and you should never trust AI with security decisions you haven't reviewed. Use the skill to accelerate the draft, then review like you would any other PR.
The review should focus on the deny paths first. The skill is explicit about the assumptions it made along the way, and those assumptions are where most policy mistakes hide. OWASP's broken access control guidance is a good external reference for what reviewers should look for.
The skill validates against the real Cerbos compiler. It runs the compile step in Docker:
docker run --rm -v "$(pwd):/policies" ghcr.io/cerbos/cerbos:latest compile /policies
When the compile fails, the skill works through errors in priority order. YAML syntax first, then schema validation, then compile errors, then test failures. One fix per pass. Tests are never deleted to make a build pass. After three failed attempts the skill stops and hands back with context, rather than thrashing.
The output is a bundle that compiles, has tests, and matches a known-good shape. That's the same artefact an engineering team would produce by hand, and it's ready for review and PR.
For high-risk domains the same advice applies in Claude Desktop as anywhere else. Money, health, regulated industries, and multi-tenant systems all need a second pair of eyes on the conditions and the audit log coverage. Our broader authorization failure patterns write-up covers what tends to go wrong when teams skip this step.
If you're working in an existing repo, point the skill at it and let it respect the structure. Don't ask it to generate a new layout from scratch when there's already a convention. That convention is usually what makes review fast.
Install the skill through npx, open Claude Desktop, point the filesystem connector at your policy repo, and describe your next permission. The full skill source and the patterns it uses are in our skills repo. For more on the workflow from an engineering angle, our policy authoring guide covers the same ground.
Try Cerbos to deploy and manage the policies you produce in Claude Desktop, or book a workshop to map your access model with us.
Go deeper:
The Cerbos policy skill also works in:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。