Most authorization bugs trace back to a missing spec, not a broken policy. Someone wrote a rule based on what they thought the requirement was, the actual requirement was slightly different, and the gap turned into an incident six months later. The fix is upstream of the policy file. It's in how the requirement gets captured.

AWS Kiro is built around exactly this problem. Kiro is a spec-driven coding agent. Before it writes code, it produces a structured spec, a design doc, and a task plan. Only then does the implementation start. That sequence happens to be the same sequence the Cerbos policy skill expects. Spec first, validated bundle second. Pairing the two gives you a workflow where the access model is captured properly upfront, the policy bundle is generated against that spec, and the audit trail of how the policy came to exist is preserved in the repo.

This guide walks through installing the skill, what a spec-then-policy workflow looks like in Kiro, how validation runs against the real compiler, and how the skill picks up AWS-specific identity attributes.

Installing the policy skill in AWS Kiro

Kiro supports the Agent Skills standard natively. Its default agent auto-loads any skill in the right directory, no configuration needed. The cross-agent installer puts the skill there.


npx skills add cerbos/skills --skill cerbos-policy -a kiro-cli

Project-scoped installs land at .kiro/skills/cerbos-policy/. Global installs go to ~/.kiro/skills/. Kiro reads only the skill metadata at startup and loads the full content on demand when the description matches what you're doing.

Custom Kiro agents can also pin the skill explicitly through "resources": ["skill://.kiro/skills/**/SKILL.md"] in their .kiro/agents/<agent>.json definitions. The skill source lives in our skills repo for inspection.

A spec-then-policy workflow in Kiro

Open Kiro on the repo where the Cerbos policies should live. Describe the access requirement in plain English.

"We are adding incident management to the platform. On-call engineers respond to incidents in the services they own. Service owners can edit any incident on their service. Security responders get read-only access to all incidents. Incident commanders override during major incidents."

Kiro's first move is to produce a spec document. The skill plugs into this step rather than fighting it. It asks clarifying questions about edges that the spec didn't yet capture. What does "during major incidents" mean. Is incident commander a permanent role or a temporary assignment. Does service ownership change with on-call rotations.

The answers go into the spec. Once the spec is approved, Kiro moves into design and task planning. The skill then takes the approved spec and produces the bundle. Schemas under _schemas/, derived roles, shared variables, resource policies, and a testdata/ directory with fixtures and a test suite. Each rule has a condition. No wildcard actions. Explicit deny paths. The bundle traces back, line by line, to the spec that was approved.

That traceability matters. Most authorization bugs live in the gap between vague requirements and concrete policy. Kiro's discipline of producing a spec before code closes that gap directly.

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 Kiro

The skill validates the bundle against the actual 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 back to a human.

When the bundle is green, the skill writes a summary of what it produced and the assumptions it made. Kiro keeps that summary alongside the spec, so the trail from requirement to validated policy is readable in one place.

What Kiro adds

Two things stand out.

Kiro forces the spec to exist. Most agents are happy to start writing YAML the moment you describe a permission. Kiro insists on capturing the spec first. The skill is built around the same belief, which is why the two compose well. Steering files in .kiro/steering/ give you a place to record team-wide authorization conventions that every Kiro session inherits, and hooks on userPromptSubmit and postToolUse can run validation gates without anyone needing to remember to do so.

Kiro is also comfortable with AWS-shaped systems. If your application uses Cognito for identity or runs on services with their own attribute model, Kiro can read those configurations and feed them into the policy spec.

The skill picks them up and uses real attributes rather than placeholders. For teams already running authorization across AWS infrastructure, this is the closest the workflow gets to native.

When to slow down

A few scenarios deserve more care than a single skill run can provide.

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. The review needs to confirm those tests match the actual constraint.

Multi-tenant systems usually want a PBAC layer on top of the resource policies. The skill writes this when asked. The boundary between tenant policies and platform policies is a decision the team needs to make first, ideally captured in the Kiro spec.

If your repo already has policy structure and conventions in place, point the skill at it before generating new policies. It respects existing structure rather than creating a parallel tree. Our authorization failure patterns write-up covers what tends to go wrong when teams skip review.

Getting started

Install the skill, open Kiro on the repo, and describe the next permission you need. Kiro will draft a spec. The skill will turn it into a validated bundle. The full skill source and the patterns it uses are in our skills repo. Our policy authoring guide covers the broader workflow 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.