--- title: "Agent skill for writing authorization policies in OpenCode" description: "OpenCode is open source, self-hosted, and provider-agnostic, so the whole authorization policy workflow stays inside your security perimeter. This guide walks through installing the Cerbos policy skill in OpenCode, drafting policies in plain English, validating against the real Cerbos compiler locally, and pairing the skill with AGENTS.md." author: "Alex Olivier" date: "2026-07-07T14:11:00.000Z" canonical: "https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-open-code" image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Agent_skill_for_writing_authorization_policies_in_Open_Code_d8d7696b75.png" tags: ["documentation","engineering","guide"] source: "https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-open-code" --- # Agent skill for writing authorization policies in OpenCode Most coding agents are tied to a vendor. Claude Code is Anthropic. Codex is OpenAI. Kiro is AWS. For teams that need to run an agent on their own infrastructure, route prompts through a self-hosted gateway, or simply prefer open source for governance reasons, the choices are narrower. OpenCode is the obvious one in that group. It's an open-source CLI agent, runs against any LLM provider, and supports the agent skills protocol natively. That matters for authorization work specifically. The team writing the policies is usually the same team paying close attention to how those policies leave the building. The [Cerbos policy skill](https://github.com/cerbos/skills) runs in OpenCode the same way it runs in any other compliant agent, but with one important property. The entire workflow (skill, compiler, model if self-hosted) can run inside an environment your security team controls. Nothing about the policy ever needs to leave the perimeter unless you choose to send it there. This guide walks through installing the skill, what an OpenCode session looks like, how validation runs locally, and where OpenCode's open-source posture changes the calculus for security-conscious teams. ## Installing the policy skill in OpenCode OpenCode has explicit support for the Agent Skills standard. Skills land in .opencode/skills/ or .agents/skills/ for project scope, and \~/.config/opencode/skills/ for global. The cross-agent installer puts them in the right place. ``` npx skills add cerbos/skills --skill cerbos-policy -a opencode ``` OpenCode loads skills on demand through a native skill tool. The agent sees the metadata at startup and pulls in full skill content the moment it decides to use one. There's no slash command. Discovery is description-driven, which means the skill description is what determines whether OpenCode picks it. If your team runs OpenCode in a shared dev container, the install can be added to the container's setup so every developer has the skill available without manual setup. The skill source is in [our skills repo](https://github.com/cerbos/skills) and is open for inspection before installing. ## A typical OpenCode policy session Run opencode in the repo where the [Cerbos policies](https://docs.cerbos.dev/cerbos/latest/policies/) should live. Describe the access model the same way you'd describe it on a design call. "Logistics platform. Drivers see their assigned routes. Dispatchers see all routes in their depot. Customers see only their own deliveries. Admins manage everything inside their region. External auditors see read-only data for closed quarters." The skill doesn't start writing YAML. It asks clarifying questions in business language. Can a dispatcher see another depot in the same region. Are drivers also customers when they're off-shift. What happens to a closed quarter when an audit reopens it. The questions are deliberate because most [authorization bugs](https://www.cerbos.dev/blog/avoid-authorization-errors) come from gaps in the requirement, not gaps in the syntax. Once the spec is confirmed, the skill produces the full bundle in a single pass. Schemas under \_schemas/, [derived roles](https://docs.cerbos.dev/cerbos/latest/policies/derived_roles.html), shared variables, [resource policies](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html), and a testdata/ directory with fixtures and a test suite. ## 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](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) is a good external reference for what reviewers should look for. ## How validation works in OpenCode The skill validates against the real Cerbos compiler. ``` docker run --rm -v "$(pwd):/policies" ghcr.io/cerbos/cerbos:latest compile /policies ``` When the compile fails, the skill walks 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 control back to the developer. When the bundle is green, the skill writes a summary of what it produced and the assumptions it made. The whole sequence runs locally, including the model call if you've configured OpenCode to use a self-hosted endpoint. Nothing about the policy ever needs to leave the perimeter. ## What OpenCode adds Two things make OpenCode a particularly clean fit for security-conscious teams. Model choice is the first. OpenCode is provider-agnostic. Some teams run it against a model hosted in their own VPC. Others use a commercial provider but route everything through an internal gateway for logging and policy enforcement. The Cerbos skill is unaffected by which model is on the other end. The clarifying questions, the bundle structure, and the validation step are all driven by the skill itself, not the model. So the same skill that gives you a clean bundle on Claude Sonnet gives you a clean bundle on a self-hosted Llama. The open-source posture is the second. The skill source, OpenCode source, and the Cerbos compiler are all open and inspectable. For teams whose review process for new tooling has a security checkpoint, this matters. Nothing happens behind the scenes that can't be read in the source. OpenCode also reads AGENTS.md and supports MCP servers and custom modes through opencode.json, so the skill composes with the rest of your conventions rather than overriding them. For organisations with centralised authorization requirements driven by compliance rather than convenience, the combination of local-only execution, open source, and provider-agnostic model choice is usually the deciding factor. ## When to slow down A few scenarios call for more care than a single skill run can deliver. Anything regulated, financial, or health-related should pair the generated policy with a focused review on the deny paths. The skill writes deny tests by default and the review should confirm those tests match the real constraint. Multi-tenant systems usually want a [PBAC layer](https://www.cerbos.dev/features-benefits-and-use-cases/pbac) on top of the resource policies. The skill writes this when asked. The tenant boundary is a decision the team needs to make first. If your repo already has policy structure and conventions, point OpenCode 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](https://www.cerbos.dev/blog/authorization-failure-patterns) write-up covers what tends to go wrong when teams skip review. ## Getting started Install the skill, open OpenCode in your policy repo, and describe the next permission you need. For broader context on the workflow, our [policy authoring guide](https://www.cerbos.dev/blog/authorization-policies-how-to-write-test-validate-with-ai-help) covers the same ground from a non-agent angle. [Try Cerbos](https://hub.cerbos.cloud/) to deploy and manage the policies the skill produces, or [book a workshop](https://www.cerbos.dev/workshop) to walk through your authorization model with us. Go deeper: * [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) (eBook) for the architecture the bundle plugs into * [The IAM security checklist for 2026](https://www.cerbos.dev/ebooks-webinars) (Checklist) for a security-team view of the same problem ## Using a different agent? The Cerbos policy skill also works in: * [Claude Desktop](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-claude-desktop) * [Claude Code](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-claude-code) * [Cursor](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-cursor) * [VSCode](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-vs-code) * [Codex](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-codex-cli) * [Pi](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-pi) * [Kiro](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies-in-aws-kiro)