VSCode is where most policy work actually happens. The YAML lives in a folder. The schema files sit next to it. The test fixtures are open in another tab. Whatever agent is doing the heavy lifting, the editor is the place where the engineer reviews the diff. So it makes sense to bring authorization policy generation into VSCode itself rather than running it elsewhere and switching back.
The Agent Skills standard now works inside VSCode through GitHub Copilot agent mode. The Cerbos policy skill drops in alongside whatever else you have installed, and the result is a workflow where the bundle, the compiler output, the diffs, and the test fixtures all live in the same window. No context switch between the prompt, the file tree, and the result.
This guide walks through installing the skill, what a VSCode session looks like, how validation runs in the integrated terminal, and how the skill fits inside the broader Copilot customization layer.
Installing the policy skill in VSCode
GitHub Copilot agent mode reads skills from .github/skills/ and .agents/skills/ for project scope, and from ~/.copilot/skills/ for personal scope. The cross-agent installer drops the skill in the right directory automatically.
npx skills add cerbos/skills --skill cerbos-policy -a github-copilot
Once the files are in place, Copilot picks the skill up the next time the agent panel opens. There's also a gh skill CLI subcommand for discovering and installing skills from inside the GitHub flow. Configurable extra paths through the chat.agentSkillsLocations setting let teams pin a shared skills directory across the organisation.
Inside the agent panel, the skill shows up in the / slash menu by default, or Copilot picks it automatically when the description matches the conversation. The skill source lives in our skills repo for inspection.
A typical VSCode policy session
Open the repo in VSCode. Open the agent panel. Describe the access model in plain English.
"Document collaboration tool. Owners create documents. Collaborators with the editor role can edit. Collaborators with the viewer role can read. Comments are visible to everyone with access to the document. Documents in a private folder need an explicit invite."
The skill doesn't jump to YAML. It asks clarifying questions first. What happens when an owner removes themselves. Can a viewer be promoted by an editor. Are private folders inheritable. The questions are deliberate because authorization bugs come from the gaps between vague requirements.
Once the spec is confirmed, the skill writes the full bundle in a single pass. You'll see schemas under _schemas/, derived roles, shared variables, resource policies, and a testdata/ directory with fixtures and a test suite. Each file appears in the explorer alongside whatever else is in the repo. Diffs open inline.
A note on using AI to write security policies
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'd review 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.
How validation works in VSCode
The skill validates against the real Cerbos compiler. In VSCode this runs in the integrated terminal so the output is visible alongside the files.
docker run --rm -v "$(pwd):/policies" ghcr.io/cerbos/cerbos:latest compile /policies
When the compile fails, the skill works through the errors in priority order. YAML syntax first, then schema validation, then compile errors, then test failures. One fix per iteration. Tests are never deleted to force a passing state. After three failed attempts the skill stops and hands back to a human.
When the bundle compiles, the skill writes a summary of what it produced and the assumptions it made. Treat that summary as a review checklist for the diff that VSCode is showing.
What VSCode adds
Two things stand out.
The editor experience is the obvious one. Reviewing a generated policy is a tight loop of diff inspection, condition adjustment, and test refinement. VSCode is built for that loop. The skill drops files into the explorer, the diffs open in the same view as your application code, and the test fixtures are right there for inspection.
Copilot's customization layer is the other. .github/copilot-instructions.md provides always-on context. File-scoped *.instructions.md files let you put policy-specific guidance next to the YAML it applies to. MCP servers and hooks can wire validation into the agent loop. The Cerbos skill sits inside that ecosystem rather than competing with it.
For teams that already write authorization policies in VSCode by hand, the move to skill-driven generation is incremental. Same files, same compiler, same review process. What changes is who writes the first draft.
When to slow down
Authorization is security. The skill saves drafting time. It does not replace review.
Every generated policy needs a human eye on the deny paths. The skill writes deny tests by default and the review should confirm those tests match the real constraint. For high-risk domains (financial, health, regulated data), pair the generated policy with a security review focused on the conditions and the audit log coverage.
Multi-tenant systems with cross-tenant escalation paths usually want a PBAC layer on top of the resource policies. The skill writes this when asked. The boundary between tenant and platform policies is a decision the team needs to make first.
If your repo already has policy structure and conventions in place, point the agent at the existing tree before generating new policies. The skill respects existing structure rather than producing a parallel set of files. Our authorization failure patterns write-up covers what tends to go wrong when teams skip review.
Getting started
Install the skill, open VSCode on the repo, and describe the next permission. For broader context, our policy authoring guide covers the same ground from a non-agent angle.
Try Cerbos to deploy and manage the policies the skill produces, or book a workshop to walk through your authorization model with us.
Go deeper:
- How to adopt externalized authorization (eBook) for a step-by-step playbook on decoupling authorization from application code
- Building a scalable authorization system (eBook) for the architecture side of the same problem
Using a different agent?
The Cerbos policy skill also works in:
FAQ
Tagged in
