Notifications
Clear all
Topic starter
10/07/2026 9:09 pm
TL;DR: Cloud Custodian’s decade-long evolution shows that governance as code is moving from cloud hygiene into AI infrastructure and data platforms, with the article citing 500M+ downloads, 500+ contributors, and adoption across major cloud providers and enterprise environments. The practical shift is clear: continuous policy enforcement now has to cover AI workloads, data sprawl, and autonomous provisioning, not just misconfigured cloud resources.
NHIMG editorial — based on content published by Stacklet: 10 years of keeping the cloud clean with Cloud Custodian
By the numbers:
- Cloud Custodian has reached 500M+ downloads, with 500+ contributors shaping the project over ten years.
- The community completed the CNCF Incubating process in September 2022 after an independent security audit, continuous fuzzing, and signed container artifacts.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Review machine identities behind automation flows Map which service accounts, workload identities, and automation credentials can create or modify cloud and AI infrastructure.
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.
👉 Read Stacklet's decade review of Cloud Custodian and governance as code →
Governance as code for AI and data workloads: what changes now?
Explore further
10/07/2026 9:32 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Governance as code now spans cloud, AI, and data workloads
