Governance as code now spans cloud, AI, and data workloads

At a glance

What this is: This is a retrospective on Cloud Custodian’s first ten years and its expansion from cloud governance into AI and data workloads.

Why it matters: It matters because IAM, platform, and cloud security teams now have to govern machine-generated infrastructure, shared policy enforcement, and access-driven risk across cloud and AI estates.

By the numbers:

• 500M+ downloads
• The community completed the CNCF Incubating process in September 2022 after an independent security audit, continuous fuzzing, and signed container artifacts.

👉 Read Stacklet's decade review of Cloud Custodian and governance as code

Context

Governance as code means expressing policy in code so it can be evaluated and enforced continuously across cloud resources, infrastructure pipelines, and runtime environments. This matters because manual review cannot keep pace with multi-cloud estates, AI-generated infrastructure, and the growing number of identities and permissions that attach to machines, workloads, and agentic systems.

The article frames the problem as a governance gap rather than a tooling gap. Cloud security, IAM, and platform teams are being pushed toward the same question: how do you keep policy consistent when resources are created faster than humans can review them, and when AI systems can participate in provisioning and deployment? That is now a mainstream operating model, not an edge case.

Key questions

Q: How should teams govern AI infrastructure with the same discipline as cloud resources?

A: Start by applying one policy model across cloud, AI services, and deployment pipelines, then enforce it at creation time and runtime. The practical test is whether a policy can stop unsafe change before it reaches production. If governance only reports on AI infrastructure after the fact, it is already too late to control cost, access, or exposure.

Q: Why do AI agents create a new governance problem for cloud and IAM teams?

A: AI agents can generate infrastructure changes at machine speed, which compresses the time available for review, approval, and exception handling. That means traditional controls built around human-paced change no longer scale cleanly. Teams need policy that governs the agent’s permissions, the deployment path, and the resulting infrastructure state at the same time.

Q: What breaks when governance is only a dashboard and not an enforcement layer?

A: Visibility alone does not remove risky resources, block bad deployments, or correct drift. If a team can see misconfigurations but cannot act on them continuously, the same risks keep accumulating across cloud, data, and AI estates. Effective governance must change state, not just describe it.

Q: How do cloud security and identity teams decide what to automate first?

A: Prioritise controls that can be enforced continuously and that affect the largest number of resources, such as policy checks in CI/CD, Kubernetes admission, and entitlement review for automation identities. That approach reduces both misconfiguration and delegated-access risk while keeping the change path manageable for engineering teams.

Technical breakdown

Governance as code and continuous policy enforcement

Governance as code uses declarative rules to define what compliant infrastructure looks like, then evaluates those rules continuously against live cloud resources and delivery pipelines. The key architectural shift is that policy is no longer a periodic audit artifact. It becomes executable logic attached to provisioning, runtime state, and remediation workflows. That matters in cloud and identity programmes because the control point moves closer to creation time, when drift, over-permissioning, and misconfiguration first appear.

Practical implication: Treat policy definitions as operational controls and place them in the same change management path as infrastructure code.

Shift-left enforcement in IaC and Kubernetes admission

Shift-left governance applies the same policy logic before resources are deployed. In infrastructure as code, policy can block unsafe changes during pull request review or pipeline validation. In Kubernetes, an admission controller can enforce rules at cluster entry, stopping workloads that violate policy from being admitted. This is relevant because many cloud and workload risks become much cheaper to stop at definition time than to detect after deployment.

Practical implication: Use pre-deploy checks and admission controls together so the same policy governs both pipeline state and cluster runtime.

AI infrastructure governance and machine identity sprawl

AI workloads change the governance problem because the resources are more dynamic and the access patterns are broader. GPU fleets, model endpoints, vector stores, and training pipelines all introduce new cost and security surfaces, while AI agents can generate infrastructure changes at machine speed. That creates a governance problem that overlaps with NHI and machine identity, because the systems creating and using access are often non-human. The operational challenge is policy scope, not just policy content.

Practical implication: Extend governance to AI service identities, automation credentials, and infrastructure permissions before autonomous provisioning becomes normal.

NHI Mgmt Group analysis

Governance as code has become an identity-adjacent control model, not just a cloud efficiency pattern. The article shows that the same policy logic used to stop idle resources and misconfigurations is now being pushed toward AI services, data platforms, and automated provisioning. That expands the control surface into machine identities, service credentials, and delegated infrastructure actions. Practitioners should treat policy enforcement as part of identity governance for non-human systems, not as a separate cloud task.

AI infrastructure is turning governance debt into runtime risk. When AI agents can create infrastructure code and deploy it automatically, the gap between intent and enforcement narrows dangerously unless controls are continuous. This is where policy engines, workload permissions, and AI-specific guardrails intersect. The field is moving from reviewing what was built to governing what machines are allowed to build. Practitioners should re-baseline access, approval, and exception workflows around autonomous change.

Data platforms now need the same governance discipline as compute and clusters. The article’s extension into Snowflake and Databricks reflects a broader reality: data access, query sprawl, and sharing controls are now governance problems, not only analytics problems. For identity teams, this means entitlements and delegated access across data platforms deserve the same lifecycle rigor as cloud accounts and service principals. Practitioners should align data governance with identity governance rather than operate them separately.

Cloud Custodian’s history underscores a durable concept: policy must be executable to be useful. The named concept here is executable governance, meaning policy that can detect, block, and remediate instead of merely reporting. That distinction matters because dashboards do not reduce attack surface or cost sprawl on their own. The article’s decade-long narrative supports a simple conclusion: if policy cannot act continuously, it cannot govern continuously. Practitioners should measure governance by enforcement, not by visibility alone.

Open source stewardship matters because governance tooling is itself a control dependency. The CNCF path, independent security audit, fuzzing, and signed artifacts all indicate that the trust model for governance tooling must be explicit. In identity-heavy environments, the security of the control plane matters as much as the resources being governed. Practitioners should evaluate governance platforms the way they evaluate other security-critical infrastructure: provenance, maintainability, and operational trust all matter.

What this signals

Executable governance is becoming the dividing line between policy that informs decisions and policy that actually shapes runtime behaviour. For security and platform teams, that means governance controls must now live where resources are created, changed, and terminated, including pipelines, admission points, and AI service workflows.

The practical signal is that cloud, data, and identity programmes will keep converging around the same control questions: who can create, what can be deployed, and which exceptions can persist. As autonomous provisioning grows, teams that do not inventory their automation identities will struggle to know which control failures are human-made and which are machine-made.

This is also where AI governance starts to overlap with identity governance in a material way. If AI systems can generate infrastructure or alter deployments, their access should be treated like any other privileged machine identity, with ownership, scoping, and review tied to the NHI lifecycle.

For practitioners

• Extend policy coverage to AI-native resources Add AWS Bedrock, Vertex AI, model endpoints, vector databases, and training pipelines to the same governance inventory used for cloud and cluster resources. The goal is one policy baseline across infrastructure and AI services, with the same exception handling and approval logic.
• Enforce policy before deployment and at admission Apply the same policy rules in pull requests, CI pipelines, and Kubernetes admission so violations are blocked before they reach production. This reduces reliance on after-the-fact remediation and gives teams one continuous control path.
• Review machine identities behind automation flows Map which service accounts, workload identities, and automation credentials can create or modify cloud and AI infrastructure. Reclassify any standing access that can change policy scope, resource placement, or deployment timing without human review.
• Unify cloud, data, and identity governance metrics Track misconfiguration, over-permissioning, idle resource exposure, and uncontrolled data sharing in one governance view. That makes it easier to see whether policy is reducing risk across the full estate rather than shifting it between tools.

Key takeaways

• Governance as code is no longer only about cloud hygiene, because AI infrastructure and data platforms now sit inside the same enforcement problem.
• The article’s numbers show a mature open source control plane, but the more important shift is the move from visibility to continuous enforcement.
• For practitioners, the control question has changed from what can be observed to what can be blocked, remediated, and governed at machine speed.

Key terms

• Governance as Code: Governance as code is the practice of encoding policy into executable rules that can be tested, enforced, and remediated automatically. Instead of relying on periodic review, teams apply the same policy logic across infrastructure, pipelines, and runtime systems so compliance and security are continuously checked.
• Executable Governance: Executable governance is policy that can change system state, not just describe desired state. In practice, it can block unsafe changes, remediate drift, and enforce exceptions in real time, which makes it materially different from dashboards, reports, or audit findings that do not alter behaviour.
• Machine Identity: Machine identity is the set of credentials, permissions, and trust relationships used by non-human systems such as workloads, services, automation, and AI agents. It becomes a governance concern when those identities can create, modify, or access infrastructure without the same review discipline applied to human users.
• Kubernetes Admission Controller: A Kubernetes admission controller is an enforcement point that evaluates requests before they are accepted into the cluster. It is used to stop workloads that violate policy, making it a practical control for shifting governance left from runtime detection to deployment-time prevention.

What's in the full article

Stacklet's full post covers the operational detail this analysis intentionally leaves for the source:

• The evolution of Cloud Custodian from enterprise problem to open source control plane, including the community and stewardship milestones that shaped it.
• The concrete governance-as-code workflow across IaC validation, Kubernetes admission, and live cloud remediation.
• The details of the AI and data platform extensions, including how the project is being applied to AI-native services and analytics platforms.
• The CNCF maturity path and security hardening steps that support enterprise adoption decisions.

👉 Stacklet's full post covers the project timeline, community milestones, and AI and data governance direction.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It helps practitioners connect identity controls to the operational realities of automation, cloud change, and privileged machine access.