By NHI Mgmt Group Editorial TeamPublished 2025-11-06Domain: Best PracticesSource: Cerbos

TL;DR: ISC2 Congress 2025 showed security teams moving from manual policy writing to policy as code, continuous assurance, and encoded governance for AI and machine identities, with Cerbos reporting that the winning pattern is versionable, testable, and auditable enforcement across the stack. The real shift is not documentation style but control design, because static review cycles cannot govern dynamic access, agent behavior, or rapidly changing compliance demands.


At a glance

What this is: This is an analyst view of ISC2 Congress 2025, where the central finding was that policy as code is replacing static compliance workflows and becoming the practical model for AI and machine identity governance.

Why it matters: It matters because IAM, NHI, and emerging agentic governance programmes now need controls that are enforceable in code, observable in telemetry, and defensible in audits.

👉 Read Cerbos' analysis of policy as code, AI governance, and compliance at ISC2 Congress 2025


Context

Policy as code is the practice of expressing access and governance rules in software rather than in static documents. This article argues that the old compliance model is breaking under the weight of modern systems, especially where machine identities and AI-driven decisions need controls that can be enforced continuously.

For IAM and NHI teams, the important change is not cosmetic. When policy becomes executable, governance can move closer to the systems it controls, which makes access decisions testable, auditable, and less dependent on manual interpretation. That shift also creates a clearer bridge between human IAM, non-human identity governance, and AI policy enforcement.


Key questions

Q: How should security teams implement policy as code in IAM and NHI programmes?

A: Start with the controls that create the most audit and privilege risk, then express them in version-controlled policy definitions that can be tested before deployment. Focus on enforcement points where access is actually decided, not just documented. That approach makes governance measurable, reduces drift, and gives auditors evidence from the system itself rather than from manual attestations.

Q: Why do manual compliance workflows fail in modern identity environments?

A: Manual workflows fail because they depend on periodic human review in environments where access changes continuously. Human attestation is too slow for cloud pipelines, service accounts, and AI-driven actions that can alter privileges in minutes. Continuous evidence collection and policy enforcement are better suited to identities that operate faster than review cycles.

Q: What should organisations do when AI systems need production access?

A: Treat AI access like any other privileged identity problem and define policy boundaries before granting production permissions. Specify allowed tools, data sources, and actions in enforceable rules, then log every policy decision. That keeps the AI governance discussion tied to access control rather than to abstract oversight language.

Q: How do teams know whether policy as code is actually working?

A: Policy as code is working when policy changes are testable, enforcement is consistent across systems, and audit evidence is produced automatically. If teams still need to reconstruct what happened from ticket trails and spreadsheets, the control is not yet behaving like executable governance.


Technical breakdown

Policy as code turns compliance into executable control

Policy as code means access rules, approval logic, and enforcement conditions are written in a machine-readable form that can be versioned, tested, and deployed like application code. That matters because static policy documents cannot keep pace with cloud services, pipelines, and runtime changes. When enforcement is embedded in infrastructure or application logic, the control itself becomes observable. This also reduces drift between written policy and actual behaviour, which is one of the most persistent failure modes in compliance programmes.

Practical implication: define access and governance rules in code so teams can test policy changes before they reach production.

Continuous assurance replaces manual attestation

Continuous assurance is the shift from periodic review to automated evidence collection and validation. Instead of waiting for a control owner to assemble proof after the fact, systems emit logs, policy decisions, and access events as they happen. This changes audit from a retrospective exercise into an always-on control plane. It also exposes whether the control is actually operating as designed, which is especially important when the environment includes service accounts, API keys, and workload identities that do not fit human review cadences.

Practical implication: instrument controls so evidence is produced automatically and can be reviewed without manual reconstruction.

AI governance depends on policy boundaries, not assumptions

The article’s AI theme is really a governance theme. Agentic systems can act across tools and data sources, so the security question becomes what they are allowed to do, not just how they were built. That requires explicit policy boundaries for machine identities, model-driven actions, and delegated execution. Without those boundaries, governance remains implicit and brittle. This is where identity teams need to connect policy, authorization, and runtime enforcement rather than treating AI oversight as a separate programme.

Practical implication: define and enforce allowed actions for AI and machine identities before they are granted production access.


NHI Mgmt Group analysis

Policy as code is no longer a control preference, it is a governance requirement. The article captures a market-wide shift away from static compliance artefacts toward executable policy, and that shift matters because modern environments change faster than manual review loops can track. When access, authorization, and evidence live in code, governance becomes testable rather than interpretive. The practitioner conclusion is that policy must now behave like software infrastructure, not documentation.

Continuous assurance is the only credible response to dynamic identity estates. Manual attestations and periodic GRC workflows were built for slower systems and clearer ownership boundaries. That model breaks down when the same estate contains human users, service accounts, APIs, and workload identities whose privileges change more often than review cycles can keep up. Practitioners should treat automated evidence generation as the control plane for auditability, not as an optional efficiency gain.

AI governance inherits NHI governance before it becomes its own discipline. The article rightly links agentic systems to policy enforcement because autonomous or semi-autonomous behaviour still depends on identities, permissions, and decision boundaries. The practical insight is that AI oversight fails if it is detached from authorization design. Security teams should evaluate AI agents through the same lens they use for privileged machine identities, then extend that lens to runtime decision limits.

Executable policy creates measurable accountability across security and compliance. A policy that can be versioned, tested, and enforced produces a much stronger audit story than one that exists only in prose. That does not eliminate human judgment, but it does reduce ambiguity about what was intended and what was enforced. The implication for practitioners is clear: if a policy cannot be tested, it is not yet a reliable control.

Identity governance is converging across human, machine, and AI domains. The article reflects a broader pattern where access control, compliance evidence, and authorization logic are being unified. That convergence is important because the same governance failure can now appear in three places: a human access review, a service account entitlement, or an AI agent’s tool permission. Teams should stop treating these as separate operating models and start governing them as one identity system with different actors.

From our research:

  • 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably prove who or what still has access.
  • For a broader lifecycle perspective, see NHI Lifecycle Management Guide, which shows how provisioning, rotation, and offboarding need to work together.

What this signals

Policy as code is becoming the control language for identity governance. As security programmes absorb more machine identities and AI-driven workflows, the old separation between policy authorship and policy enforcement will keep breaking down. With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the issue is no longer whether teams can document intent. The issue is whether they can enforce it continuously where identity decisions actually happen.

A second pressure point is evidence quality. Continuous assurance changes how boards, auditors, and control owners evaluate risk because telemetry becomes the proof instead of a manual attestation trail. That means identity programmes need to think like control engineers, not just policy administrators, and they need governance artefacts that can be inspected in the same way software changes are inspected.

For practitioners, the forward signal is clear: the identity stack is converging around runtime enforcement, measurable access decisions, and machine-readable governance. Teams that still separate IAM, NHI, and AI oversight into disconnected workstreams will struggle to produce a consistent control narrative, especially when incidents or audits demand a single source of truth.


For practitioners

  • Embed policy in version-controlled code Move critical authorization rules, access conditions, and enforcement logic into version control so changes can be reviewed, tested, and rolled back with the same discipline as application code.
  • Automate evidence collection for audits Instrument systems to capture access decisions, policy evaluations, and enforcement events continuously so audit evidence comes from the control plane rather than manual reconstruction.
  • Map AI and machine actions to explicit policy boundaries Define what AI agents, service accounts, and workloads are allowed to do before production rollout, then enforce those limits at the authorization layer rather than by convention.
  • Test policy changes before they reach production Use policy simulation and pre-deployment tests to catch access drift, broken exceptions, and unintended privilege expansion before they affect live systems.

Key takeaways

  • Policy as code is replacing static compliance workflows because modern identity environments change too quickly for manual governance to keep up.
  • The central risk is not only access sprawl but also the inability to prove control, which is why automated evidence and runtime enforcement matter.
  • Practitioners should treat AI, machine, and human identity governance as one control problem with different actors, not as separate programmes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Policy as code depends on access permissions being enforced consistently.
NIST Zero Trust (SP 800-207)Continuous verification aligns with zero trust enforcement and runtime policy checks.
OWASP Non-Human Identity Top 10NHI-03Executable governance is directly relevant to rotation, exposure, and excessive privilege controls.

Use zero trust principles to shift access decisions from static approval to continuous evaluation.


Key terms

  • Policy as code: Policy as code is the practice of writing governance and authorization rules in machine-readable form so they can be versioned, tested, and enforced automatically. It closes the gap between policy intent and operational control, which is especially important in environments where identities and permissions change frequently.
  • Continuous assurance: Continuous assurance is an operating model where control evidence is gathered and validated in real time rather than at review intervals. It makes auditability part of the system itself and works best when access decisions, policy checks, and identity events are emitted automatically.
  • Machine identity: Machine identity is the credentialed identity assigned to software, workloads, APIs, service accounts, and related non-human actors. It is governed through issuance, privilege scope, rotation, monitoring, and offboarding, and it becomes a primary control surface when policy is enforced in code.
  • Policy boundary: A policy boundary is the set of allowed actions, data sources, and execution limits that define what an identity may do. For AI and machine actors, it turns abstract governance into enforceable constraints and helps prevent delegated access from expanding beyond intended scope.

Deepen your knowledge

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

This post draws on content published by Cerbos: ISC2 Congress 2025 and the move to policy as code. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-11-06.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org