Policy as code is becoming the new compliance playbook

At a glance

What this is: Cerbos says compliance is moving from documents and attestations to policy as code that can be versioned, tested, audited, and enforced across the stack.

Why it matters: IAM, NHI, and AI governance teams need policies that are executable and observable, because static review processes do not keep pace with dynamic access decisions or agent behaviour.

Context

Policy as code means expressing access and governance rules in software so they can be versioned, tested, deployed, and evaluated continuously. In the context of IAM and NHI governance, that shift matters because enforcement no longer lives only in policy documents or periodic reviews, it lives where decisions are made.

The article frames ISC2 Congress 2025 as evidence that compliance, access control, and AI governance are converging into the same operational model. For security teams, the practical question is no longer whether policy exists, but whether it can be executed consistently across infrastructure, pipelines, applications, and agent-driven workflows.

Key questions

Q: How should security teams implement policy as code in compliance programmes?

A: Start by encoding the highest-risk access and governance rules as versioned policy, then connect those policies to deployment, testing, and audit evidence. The goal is not to digitise paperwork. It is to make control enforcement measurable, repeatable, and tied to the systems that actually make access decisions.

Q: Why does policy as code matter for AI governance and machine identities?

A: Because AI-driven systems and machine identities act at runtime, governance has to define their allowed behaviour before they operate. A human review model cannot reliably keep pace with automated decisions, so policy must constrain action, not just record intent.

Q: What breaks when compliance still depends on manual attestations?

A: Evidence becomes stale, control ownership becomes ambiguous, and access decisions drift away from the policy that was supposed to govern them. Manual processes can describe a control, but they struggle to prove that the control was enforced continuously in the environments where risk actually appears.

Q: How do policy-based access control and just-in-time access fit together?

A: They work together when policy determines whether access can be granted and JIT limits how long that access exists. The useful distinction is that policy decides eligibility, while JIT reduces standing exposure. Used together, they narrow privilege without relying on permanent entitlements.

Technical breakdown

Why policy as code changes compliance assurance

Policy as code converts governance intent into executable rules that can be tested before deployment and enforced at runtime. That matters because compliance evidence stops being a retrospective paperwork exercise and becomes an operational by-product of the control itself. When policy lives in code, teams can validate drift, prove decision logic, and connect audit evidence to actual enforcement points instead of manually reconstructed screenshots and attestations. In practice, this is the difference between saying a control exists and demonstrating that it is continuously active.

Practical implication: treat policy definitions as versioned control artefacts, not documentation, so enforcement and evidence stay aligned.

How dynamic authorization supports least privilege

Dynamic authorization evaluates access at decision time rather than assuming a role assignment is sufficient for every context. That approach is especially relevant where access needs change quickly, because static entitlements tend to accumulate privilege that outlives the original business need. Policy-based access control lets organisations encode conditions, constraints, and environmental signals into the decision path. For IAM teams, that closes the gap between coarse-grained provisioning and the reality of task-scoped, changing access requirements.

Practical implication: move sensitive access decisions into policy evaluation rather than relying only on standing roles.

Why AI governance now depends on encoded policy

The article’s AI governance point is that machine identities, agent behaviour, and model-driven decisions need explicit limits before they are deployed widely. That is a governance problem, not just an AI operations problem, because the system must know what an automated actor is allowed to do. Encoded policy becomes the control plane for those decisions. Without it, security teams are left trying to govern runtime behaviour with frameworks that were built for periodic review and human-paced change.

Practical implication: define allowed actions for AI-driven systems in policy before those systems are permitted to act.

Breaches seen in the wild

• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

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

NHI Mgmt Group analysis

Policy as code is becoming the operational form of compliance. The article reflects a broader shift away from manual attestations toward controls that can be tested, deployed, and observed like software. That matters because assurance only scales when the control itself produces evidence. Practitioners should treat policy execution as part of the security architecture, not as a separate governance layer.

Static review cycles are no longer sufficient for dynamic access decisions. Access patterns now change too quickly for periodic certification alone to remain credible. The governance model has to move closer to the moment of decision, where context, entitlement, and enforcement intersect. Teams that keep relying on review after the fact will keep discovering that the control was always one step behind the risk.

AI governance and identity governance are converging on the same control problem. Once machine identities and agent behaviour enter production, the key question becomes what those systems are permitted to do under changing conditions. That forces security teams to govern runtime behaviour, not just authorised states. The implication is that IAM, policy engineering, and AI governance can no longer be run as separate disciplines.

Encoded controls create a new compliance playbook for security leaders. Versioning, testing, and runtime enforcement allow policy to be managed with the same discipline as application change. That reduces ambiguity in audit trails and makes control ownership more explicit across engineering and security teams. The practitioner conclusion is simple: if a control cannot be executed, it cannot be reliably governed.

What this signals

Compliance is becoming executable. Security programmes that still treat policy as a document will keep struggling to prove enforcement because the control lives outside the system of record. The operational shift is toward policies that are deployed, tested, and audited the same way software is, which changes how IAM, PAM, and governance teams design evidence collection.

AI governance now starts with permission design. Once machine identities and agent behaviour enter the environment, the question is no longer only how to monitor them after deployment. It is what they are allowed to do at the point of decision, which makes policy engineering part of the AI control surface.

For practitioners

• Encode access rules as deployable policy Replace static approval documents with policy definitions that can be versioned, tested, and deployed alongside application changes. That keeps authorization logic close to the systems it governs and makes drift visible before it becomes an audit issue.
• Shift evidence collection to runtime controls Automate evidence capture from policy decisions, access logs, and enforcement points so compliance no longer depends on manual attestations. Focus on controls that can prove what happened, when it happened, and which policy allowed it.
• Govern AI and machine identities with explicit rules Define the allowed actions for machine identities, agents, and model-driven workflows in code before those systems are allowed to operate. If policy is missing at issuance time, later review will not reliably reconstruct intent.
• Use dynamic authorization for sensitive access Apply policy-based access control where standing roles are too coarse for real operational risk, especially for privileged or time-sensitive access. Make the access decision depend on context, not just on account membership.

Key takeaways

• Policy as code turns governance into an enforceable system rather than a paper exercise, which is why it is gaining ground in compliance programmes.
• The article links modern assurance to continuous evidence, dynamic authorization, and explicit control over AI-driven behaviour.
• For practitioners, the key shift is from periodic review to runtime policy enforcement across infrastructure, applications, and machine identities.

Key terms

• 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.
• Dynamic Authorization: Dynamic authorization is an access model that makes the trust decision at request time using current identity and context. It replaces reusable stored credentials with short-lived, policy-scoped tokens issued only after the workload proves itself.
• Protection Level: The Android permission setting that determines how strongly access to a component or action is restricted. If the protection level is too weak, untrusted apps can request the permission and interact with functionality that was supposed to stay internal.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

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 building or maturing an IAM programme, it is worth exploring.