Infrastructure as Code Gives AI Agents a Safer Path to Kubernetes Changes

AI agents can already make changes to cloud infrastructure through provider APIs. The harder question for platform teams is how to make those changes visible, predictable and reviewable. Infrastructure as code (IaC) offers a practical answer: let an agent propose edits to configuration, inspect the resulting plan, then require approval before applying it.

That workflow matters because infrastructure keeps changing. Kubernetes clusters need version upgrades, databases and networks evolve, and teams add regions or cloud providers. Provisioning a resource is only the beginning; the ongoing work is keeping the system’s actual state aligned with what the team intends to run.

Make infrastructure changes reviewable

With tools such as Pulumi, Terraform and OpenTofu, teams describe clusters and surrounding resources in code. A proposed change can be previewed before deployment, exposing which resources will be updated and which may need replacement. For an agent-assisted workflow, that preview gives engineers a concrete basis for review instead of asking them to trust a series of direct API calls.

Here’s the thing: agents can produce useful infrastructure edits, but their behavior isn’t deterministic by default. Giving an agent broad cloud credentials can make it difficult to understand what it changed or why. If it edits an IaC program or stack configuration instead, the change appears in a familiar diff. A human can assess the plan and approve it before anything reaches the cloud.

This approach keeps the agent involved in the work while placing a deliberate checkpoint between suggestion and deployment. The agent can handle much of the configuration effort; the team retains visibility into the proposed result and control over when it takes effect.

Manage the cluster and the services around it

Kubernetes is often treated as the center of infrastructure management, but many essential resources sit outside the cluster. An application may depend on an external database, networking, or other cloud services. IaC can represent those resources alongside the cluster and connect them to the workloads that rely on them.

That broader scope also changes how teams handle cluster upgrades. When a Kubernetes version is expressed in configuration, an upgrade can be a small code edit followed by a preview. Engineers can see the expected changes, including resources that would be replaced rather than updated, before they approve the rollout.

Keeping these dependencies in one program can help teams reason about the system as a whole. Helm orders chart manifests by resource kind; it doesn’t model dependencies on resources outside Kubernetes. IaC can express those external resources directly, making them part of the same infrastructure plan as the cluster and its applications.

For platform teams, reusable components offer another benefit. They can package infrastructure behind typed libraries that application teams consume, instead of asking every team to work directly with raw YAML. That creates a way to offer standard infrastructure building blocks while keeping implementation details under platform-team control.

Choose the control model that fits the task

Infrastructure-native Kubernetes tools—including Crossplane, AWS Controllers for Kubernetes, Config Connector and Azure Service Operator—use Kubernetes resources to manage cloud infrastructure. Their control plane runs inside an existing cluster and can continuously reconcile the declared state. When it detects drift, it may correct that drift automatically.

External IaC tools take a different route: they treat the Kubernetes cluster as one resource among many, and can provision it alongside the applications and services it supports. By default, changes are proposed and applied through an explicit workflow. Teams can also configure automatic drift correction when that behavior suits their needs.

That distinction affects how teams want changes to happen. Continuous reconciliation is useful when the desired state should be enforced automatically. A preview-and-approval workflow gives teams a chance to inspect changes before they land, which can be a better fit for sensitive infrastructure updates or agent-generated proposals.

Adapt across regions and cloud providers

IaC can also make infrastructure easier to reproduce across environments. A team moving a platform to another region, deployment stage or cloud provider can adjust the provider-specific configuration while carrying over Kubernetes resources that don’t depend on that provider.

That doesn’t make every migration automatic. Provider differences still matter, and teams need to account for them in their configuration. But describing infrastructure in code gives them a consistent starting point and a way to review what changes between environments.

Bring existing infrastructure into code gradually

Most organizations aren’t starting from an empty account. IaC supports incremental adoption: teams can import existing cloud resources into a program and compare the resulting plan against what is already running. A preview with no changes indicates that the configuration matches the observed state.

This makes IaC useful for bringing established infrastructure under clearer management, as well as for building new Kubernetes platforms. Teams can move one part at a time while keeping track of existing resources, rather than treating adoption as a full rebuild.

A declarative view of the environment can also help agents work with existing systems. When the current resources are represented in code, an agent can propose changes against a defined state, and engineers can inspect the plan before approving migration or maintenance work.

Keep GitOps workflows in place

Teams already committed to Kubernetes and GitOps can continue to use those practices. An operator can run IaC programs from inside a cluster, with a Kubernetes object pointing to a Git branch. Kubernetes resources remain managed through the existing model, while the operator executes the infrastructure program described by that object.

The practical takeaway is that IaC can sit alongside established cluster workflows while extending management to resources those workflows don’t cover. As agents take on more infrastructure tasks, code-based plans give teams a clear way to review their proposals, manage changes across hybrid environments and keep approval attached to the people responsible for production.