Notifications
Clear all
Topic starter
10/06/2026 10:53 pm
TL;DR: Authorization work can stay inside the repo, with policies compiled against the real engine and tests validated before commit, according to Cerbos. Its policy skill in Claude Code shows how AI can accelerate policy writing, but human review still has to own the deny paths and the assumptions behind them.
NHIMG editorial — based on content published by Cerbos: policy authoring with Claude Code and the Cerbos policy skill
Questions worth separating out
Q: How should security teams govern AI-generated authorization policies in the repo?
A: They should treat generated policies as security code, not assistant output.
Q: What breaks when policy generation skips deny-path review?
A: The access model becomes overly permissive because the team validates syntax instead of security intent.
Q: How do you know if AI-assisted policy authoring is actually safe?
A: Look for evidence that the workflow surfaces assumptions, runs the actual compiler, and fails closed when tests do not match the intended constraint.
Practitioner guidance
- Require human review of generated deny paths Verify that every generated policy has explicit deny logic, and review those conditions before any merge.
- Validate policies against the real compiler Run the policy bundle through the actual Cerbos compiler in the same workflow used by developers.
- Define tenant boundaries before generation Document where cross-tenant access stops, where PBAC is needed, and which attributes are authoritative before asking the agent to draft policies.
What's in the full article
Cerbos's full guide covers the operational detail this post intentionally leaves for the source:
- The exact Claude Code install flow for the Cerbos policy skill, including marketplace and cross-agent paths.
- The step-by-step validation loop that runs the real Cerbos compiler and orders failures by priority.
- The structure of the generated bundle, including schemas, derived roles, shared variables, and test fixtures.
- The situations where human review, PBAC boundaries, and regulated-data constraints need extra care.
👉 Read Cerbos's guide to policy authoring with Claude Code →
Claude Code policy authoring: what it changes for IAM teams?
Explore further
12/06/2026 4:37 am
Authorization policy generation is becoming a non-human identity governance problem, not just a developer productivity problem. The moment a CLI agent can draft policies, write tests, and compile them in the repo, the control question shifts from authoring speed to trust boundary. That makes policy files part of the NHI attack surface because the actor is no longer just a human reviewer. Practitioners should treat generated policy as machine-originated security logic and govern it accordingly.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why repo-bound policy generation still needs governance around who can create, review, and approve access logic.
A question worth separating out:
Q: Should teams use PBAC on top of resource policies for complex SaaS access?
A: Yes, when tenant boundaries, cross-tenant escalation paths, or regulated data make simple resource rules too blunt. PBAC adds context-aware decisioning on top of base policies, which helps when a single role model cannot express the full constraint set. The important part is deciding that boundary before generation starts.
👉 Read our full editorial: Claude Code policy authoring brings authorization into the repo
