Claude Code policy authoring brings authorization into the repo

At a glance

What this is: Cerbos describes a Claude Code workflow that drafts and validates authorization policies directly in the repository before commit.

Why it matters: This matters because IAM teams need tighter control over policy generation, review, and validation as access logic becomes more complex and AI-assisted.

👉 Read Cerbos's guide to policy authoring with Claude Code

Context

Authorization policy authoring becomes fragile when role logic, tenant conditions, derived roles, and deny paths are scattered across prompts, separate tools, and manual testing. In that environment, the real governance issue is not writing YAML faster. It is keeping the policy model tied to the actual codebase, the actual compiler, and the actual review process.

For IAM and IGA teams, this sits in the middle of externalized authorization, policy-as-code, and non-human identity governance. The operational question is whether AI-assisted drafting changes the control boundary, or just shortens the time between requirement capture and policy validation.

Key questions

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. That means mandatory human review, compile-time validation against the real policy engine, explicit deny-path testing, and version control in the same repository as the application. The goal is to preserve accountability for access decisions even when the drafting step is machine-assisted.

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. Deny-path review is where hidden assumptions, tenant boundaries, and edge-case escalation risks show up. If that step is skipped, the policy may compile successfully while still authorising the wrong actor in the wrong context.

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. Safe authoring is not measured by prompt quality or speed. It is measured by whether the process exposes ambiguous access logic before deployment.

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.

Technical breakdown

Policy-as-code in Claude Code

The workflow described here keeps authorization logic in the same repository as application code, which matters because policy is code with security impact. The skill writes schemas, derived roles, resource policies, and tests as a bundle, then validates against the real Cerbos compiler rather than a mock. That is the difference between conversational drafting and enforceable policy generation. The value is not that Claude Code understands authorization perfectly. The value is that the output is compiled, tested, and version-controlled in the same workflow as the feature that depends on it.

Practical implication: Treat AI-generated policy as source code, not prose, and require compiler validation before merge.

Denies, tests, and assumption handling

The guide makes an important governance point: the risky part of authorization is often what the author assumes, not what they explicitly write. That is why the workflow emphasizes clarifying questions, deny paths, and tests that fail when conditions do not match reality. In policy terms, a deny path is not a leftover edge case. It is part of the security boundary. Any AI-assisted authoring process that skips that discipline creates a faster path to ambiguous access rules, not safer access rules.

Practical implication: Review deny rules first and require tests that prove the policy fails closed where intended.

Why multi-tenant access models still need human design

Multi-tenant SaaS, cross-tenant escalation paths, and regulated data controls often need more than a single resource-policy layer. The article notes that teams may need PBAC on top of resource policies when the access model gets more complicated. That is a useful reminder that automation can draft policy structure, but it cannot decide where the boundary should live. Boundary placement is a governance decision, not a generation task. The more sensitive the data, the more important that architectural decision becomes.

Practical implication: Define the tenant and data boundaries before asking an AI tool to generate policy structure.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Policy review still fails where assumptions are left implicit. The article itself points to clarifying questions and deny paths as the places where mistakes appear, which is exactly where governance breaks down in practice. Externalized authorization only works when the team can explain why access is denied, not merely when the YAML compiles. The practitioner takeaway is that assumption capture is the control, not a side note.

Externalized authorization remains the right pattern, but AI collapses the drafting cycle into the delivery cycle. That changes how quickly policy drift can appear if the repo conventions, tests, and review gates are weak. In NHI terms, the control plane now has a faster human-plus-machine loop, which increases the need for review consistency rather than reducing it. Teams should expect more generated policy, not less, and should standardise the review bar before volume rises.

Policy-as-code tooling should be measured by the quality of its failure paths, not the speed of its output. A tool that can produce green builds while obscuring assumptions creates a governance illusion. The substantive question for identity teams is whether the workflow preserves accountability for resource-policy decisions across tenants, roles, and data classes. Practitioners should judge these systems by how well they surface edge cases and constrain privilege, not by how quickly they generate files.

From our research:

• 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.
• The lifecycle view in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs helps teams connect policy authoring with offboarding, rotation, and review, not just initial creation.

What this signals

Policy generation is moving closer to the identity control plane. That means teams will need to govern not only who can request access, but who or what can author the rules that decide access. For NHI programmes, this is a reminder that lifecycle controls must cover machine-assisted policy creation as well as credential issuance.

The practical signal is that authorization teams should expect more repo-native policy workflows and more pressure to validate them continuously. A policy skill can shorten drafting time, but it does not remove the need for review discipline, boundary definition, or exception handling. Teams that standardise those controls now will absorb AI-assisted authoring more safely than teams that wait for drift to force the issue.

Policy-authoring velocity debt: when AI speeds up policy creation faster than review and boundary design mature, the organisation accumulates hidden access risk. That debt shows up first in tenant scoping mistakes, then in over-permissive denies, and finally in brittle review processes that cannot explain why a rule exists. Practitioners should track whether access decisions remain auditable as generation volume increases.

For practitioners

• Require human review of generated deny paths Verify that every generated policy has explicit deny logic, and review those conditions before any merge. Focus the review on whether the rule matches the real-world constraint, not whether the file compiles cleanly.
• Validate policies against the real compiler Run the policy bundle through the actual Cerbos compiler in the same workflow used by developers. Do not accept generated policy on the strength of a successful prompt alone, because syntax is not the same as enforceable authorization.
• 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. If the boundary is unclear, the output will only encode the ambiguity faster.
• Version-control generated policy alongside application changes Keep the policy skill output in the same repository and PR as the feature that depends on it. That keeps review, test coverage, and rollback aligned instead of creating a separate policy track that can drift.
• Track assumptions made during policy drafting Capture the assumptions surfaced by clarifying questions and confirm them against the business rule owner. Any assumption that cannot be defended should block promotion, because hidden assumptions are where authorization bugs hide.

Key takeaways

• AI-assisted policy authoring changes authorization from a drafting task into a governance task that must be controlled in the repo.
• The main failure mode is not compilation error, but hidden assumptions that survive into deny paths and tenant boundaries.
• Teams should validate generated policy against the real compiler, require human review, and define boundaries before asking an agent to write rules.

Key terms

• Policy As Code: Policy as code means writing access rules in version-controlled files that can be reviewed, tested, and deployed like software. In identity governance, it creates a repeatable control surface for authorization, but only if the team also governs review quality, test coverage, and change ownership.
• Deny Path: A deny path is the branch in an authorization policy that blocks access when conditions are not met. It is often where security intent is proven or broken, because a policy that compiles can still authorise the wrong actor if its failure case is weak or implicit.
• Externalized Authorization: Externalized authorization separates access decisions from application code and places them in a policy layer. That helps centralize governance across services and tenants, but it also makes policy quality a first-class security concern, especially when AI tools help generate the rules.
• Policy Boundary: A policy boundary is the point where one access model stops and another begins, such as tenant, role, or data-class limits. Clear boundaries prevent rule sprawl and accidental privilege extension, while unclear boundaries let generated policy encode ambiguity faster than humans can review it.

Deepen your knowledge

Policy-as-code review, deny-path analysis, and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are bringing AI-assisted policy authoring into a live authorization workflow, it is worth exploring.

This post draws on content published by Cerbos: policy authoring with Claude Code and the Cerbos policy skill. Read the original.