Notifications
Clear all
Topic starter
10/06/2026 11:13 pm
TL;DR: Policy generation still depends on getting scope, conditions, and deny-by-default right before a single file is written, according to Cerbos. Its policy skill turns plain-English authorization requirements into schemas, derived roles, policies, and test suites, then validates the bundle against the real compiler.
NHIMG editorial — based on content published by Cerbos: a skill for generating and validating authorization policies from plain English
Questions worth separating out
Q: How should security teams use AI to draft authorization policies safely?
A: Use AI to draft, not decide.
Q: Why do authorization policies fail when requirements are too vague?
A: Vague requirements hide the real trust boundary.
Q: How do teams know whether generated policies are actually safe to deploy?
A: They should verify that the bundle compiles, that tests cover both allowed and denied paths, and that the final rules still reflect the intended business model.
Practitioner guidance
- Force access requirements into structured inputs before generation Capture principals, resources, actions, and conditions in a reviewable spec before any policy file is created.
- Reject broad grants unless they are converted into explicit action lists Do not accept statements like blanket admin access or unrestricted delete permissions.
- Validate every generated policy bundle against the live compiler Use the actual policy engine, not a mocked lint pass, to test schema fit, role bindings, and condition logic.
What's in the full article
Cerbos' full post covers the operational detail this post intentionally leaves for the source:
- The exact workflow used by the Cerbos policy skill to move from plain-English requirements to a complete policy bundle.
- The generated file set, including schemas, derived roles, resource policies, test fixtures, and test suites.
- The compile-and-fix loop that revalidates policy output against the real Cerbos engine in Docker.
- The specific installation commands for Claude Code, Cursor, Codex, OpenCode, and other supported agents.
👉 Read Cerbos' guide to AI-assisted authorization policy generation →
AI coding agents and authorization policies: are your controls keeping up?
Explore further
12/06/2026 5:05 am
Policy generation is not policy governance. Automating the drafting of authorization files can reduce friction, but it does not remove the need for tight access modelling, explicit scoping, and review discipline. The risky part is not the output format, it is the possibility that the generated policy looks complete while still encoding the wrong trust boundary. Practitioners should treat AI-assisted policy creation as a drafting aid, not an authority source.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
- The average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities.
A question worth separating out:
Q: What should organisations do before letting an AI tool write access rules?
A: Define the policy model first, including principals, resources, actions, and condition logic. Then decide who approves the generated output, how exceptions are handled, and how the policy will be recertified when roles or resources change. Without that lifecycle, AI simply speeds up the creation of brittle access rules.
👉 Read our full editorial: Authorization policy generation for AI coding agents needs guardrails
