Claude Code policy authoring brings authorization into the repo

At a glance

What this is: Cerbos describes a Claude Code policy-authoring workflow that keeps authorization policy files in the repo, validates them against the real compiler, and still requires human review of deny paths and assumptions.

Why it matters: IAM and IGA teams should care because policy authoring is moving closer to the feature code, which changes how access models are drafted, reviewed, tested, and governed across human, NHI, and agentic workflows.

Context

Authorization gets brittle when policy logic spreads across ad hoc files, unclear tenant rules, and inconsistent review habits. In that environment, the real problem is not writing YAML faster, it is keeping the access model aligned with the application’s actual resource boundaries and decision logic.

Claude Code is presented here as a terminal-based agentic coding workflow that can draft Cerbos policies in the repo, run the real compiler, and surface assumptions before commit. The identity governance issue is that policy authorship is becoming part of the engineering loop, so access decisions now need controls that work at code velocity.

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: Why do policy generators still need human review for access control decisions?

A: Because the hardest errors are semantic, not syntactic. A generator can produce valid files that still encode the wrong tenant boundary, ownership rule, or deny condition, so human review is needed to confirm that the policy matches the real business constraint being enforced.

Q: What breaks when authorization is not tenant-aware?

A: Global authorization models break when the same user needs different permissions in different customer contexts. Static roles tend to overgrant access, blur administrative boundaries, and force application code to compensate for missing policy structure. Tenant-aware authorization prevents those collisions by keeping access decisions aligned to the correct customer boundary.

Q: What should security teams check before trusting an AI-generated policy bundle?

A: Check the assumptions the drafting session surfaced, then verify the bundle against the real compiler and test suite. If the assumptions are wrong, the generated policy can be technically correct and still be unsafe in production.

Technical breakdown

Repo-local policy authoring and compiled validation

Claude Code keeps policy files beside the application code, which matters because authorization logic is versioned, reviewed, and tested as part of the same change set as the feature that depends on it. The workflow described here compiles policies against the real Cerbos binary rather than treating the draft as a text artifact. That distinction matters: syntax, schema, and runtime policy semantics fail in different ways, and only compilation against the target engine proves that the policy will behave as intended. In practice, this turns authorization into a build-time control rather than a late-stage configuration task.

Practical implication: Treat policy compilation as a required gate, not a convenience step, before any authorization change merges.

Clarifying questions as authorization requirement discovery

The skill does not jump directly to policy YAML. It asks clarifying questions about ownership, tenancy, and move conditions because authorization bugs often come from unresolved business rules, not from broken syntax. This is the point where natural-language intent becomes policy structure: derived roles, attribute conditions, resource boundaries, and explicit deny paths. For identity teams, that matters because the hardest part of externalized authorization is not the policy language itself, but the requirement capture that decides what the policy should encode. The better the questions, the fewer hidden assumptions survive into production.

Practical implication: Use requirement interrogation as part of policy drafting, especially when tenant boundaries or ownership rules are ambiguous.

Deny paths and explicit assumptions are the real control surface

The article’s most important technical point is that the generated policy is only as safe as the assumptions that shaped it. Every rule includes an explicit deny path, and the review focus is supposed to start there because authorization mistakes usually appear in what is unintentionally allowed, not what is obviously blocked. That aligns with broken access control failure patterns: the issue is rarely a missing feature, but a malformed decision boundary. The workflow also surfaces assumptions after validation, which gives reviewers a chance to challenge the policy’s implicit model before it becomes part of the repo history.

Practical implication: Review deny logic and stated assumptions before approval, because that is where hidden over-permission usually enters.

NHI Mgmt Group analysis

Authorization authoring is moving from configuration work to governed software change. When policy creation sits inside the same repo as the application, access control becomes a first-class part of the delivery pipeline rather than a sidecar admin task. That shifts the control point from manual edits to code review, validation, and change history. For identity programmes, the implication is that policy governance now needs software-grade discipline, not just access-policy intent.

The hard problem is no longer writing policies, but preserving the business meaning behind them. Claude Code can draft syntax, derive structure, and compile against the target engine, but it cannot know whether an owner relationship, tenant boundary, or exception path matches the organisation’s real operating model. That means the governance gap lives in requirement interpretation, not in file generation. Teams should treat authoring assistance as a drafting accelerator, not as a substitute for policy ownership.

Externalised authorization only works when human reviewers own the deny surface. The article correctly keeps human review in the loop because authorization is a security decision, not a formatting task. This is where IAM, IGA, and application security intersect: access logic must be testable, reviewable, and tied to the actual business constraint being enforced. Practitioners should assume the most dangerous errors will be permissive edge cases, not obvious compilation failures.

Policy authoring inside an agentic terminal introduces a new governance pattern: assisted decision-making, not delegated authority. The agent can accelerate creation, but the organisation still owns the policy model, the exception logic, and the approval of the resulting change. That distinction matters because many teams will be tempted to interpret speed as automation of judgment. The real lesson is that authoring velocity has increased, while accountability for access decisions has not moved.

Named concept: policy-as-code with human-denied approval. The workflow demonstrates a practical model where authorization rules are drafted in the repo, validated against the real engine, and reviewed with special attention to deny paths before merge. That pattern is useful because it makes access control auditable without pretending the agent can judge the business meaning of every rule. Practitioners should govern the drafting loop as code, but the approval loop as security.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: Authorisation Models Guide

What this signals

Policy authoring is becoming part of the delivery pipeline, not a separate governance afterthought. Teams that already struggle to keep authorization rules aligned with application change will feel the pressure first, because assisted drafting shortens the time between requirement and deploy. The practical response is to move review, testing, and exception handling closer to the repo where the policy lives.

Access reviews alone do not solve policy quality when the mistake is in the rule itself. If the business meaning of tenant ownership, resource scope, or deny conditions is wrong at authoring time, later recertification will simply preserve a bad model. IAM and IGA teams should focus on how policy is written, not only on who is later granted access.

Policy authoring accelerators only help when they are constrained by a clear access model. Without explicit resource boundaries and approval rules, an agent can produce faster versions of the same governance ambiguity. The control challenge is to make the drafting loop deterministic enough that reviewers can challenge meaning, not syntax.

For practitioners

• Define the policy review boundary Separate draft generation from approval so the agent can produce policy structure, but a human still owns deny logic, tenant boundaries, and exception handling.
• Validate policies against the target compiler Run policy compilation and tests against the real authorization engine before merge, rather than relying on syntactic review of YAML alone.
• Document the access model before prompting Write down ownership, tenant scope, and resource relationships first so the agent is constrained by the real business rules, not inferred ones.
• Review assumptions before accepting the bundle Inspect the assumptions the drafting session surfaced, because hidden assumptions are where permissive policy errors usually hide.

Key takeaways

• Authorization policy generation inside the repo changes IAM governance from a manual admin task into a code-review and compiler-validation workflow.
• The main failure mode is not broken syntax but unclear tenant scope, ownership, and deny logic that the agent cannot infer safely on its own.
• Human reviewers still have to own the access model and exception paths, because policy generation accelerates drafting without transferring accountability.

Key terms

• Externalized Authorization: A design pattern where access decisions are removed from application code and handled by a separate policy layer. This makes authorization easier to govern, test, audit, and reuse across services, especially when roles, attributes, and request context change frequently.
• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• 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.
• Policy Assumption: A policy assumption is an unstated rule about ownership, tenancy, identity, or resource scope that shapes the resulting access decision. In AI-assisted authoring, assumptions matter because the generator may preserve them even when they do not match how the organisation actually operates.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.