AI Already Writes Your Terraform. The Problem Isn't Writing — It's Approving.

The bottleneck moved#

For years, writing Terraform was the slow part: understanding the provider, mapping dependencies, testing in staging. That changed. HashiCorp is now positioning its HCP Terraform platform as the control plane for a new generation of AI-driven infrastructure, arguing that the rapid adoption of coding agents is shifting the biggest infrastructure challenge from writing configuration to verifying and safely executing it.

The reason is simple: code that took days now takes seconds, so the bottleneck has moved from authoring to verification and approval — exactly where HCP Terraform's enterprise controls live. For a platform team, this isn't a speed upgrade. It's a full role shift.

Agents propose, the platform decides#

The operating model HashiCorp proposes is direct: the agent can propose. It should not decide. A human engineer used to review a Terraform change before applying it; an agent can generate configuration, execute a plan, observe the result, modify its approach, and try again in a continuous loop. That breaks the assumption traditional infrastructure-as-code review was built on.

The answer isn't watching the agent's every move. It's routing every AI-generated change through the same governed control plane as any other change, with short-lived, dynamically issued credentials instead of standing cloud access: the model uses project-scoped identities and OIDC-based credentials issued for individual runs and revoked afterward, limiting the blast radius if an agent is compromised.

This isn't new: Pinterest already solved a version of it without AI#

The governance pattern HashiCorp describes for agents already exists, built for human engineers. Pinterest recently disclosed its Resource Provisioner Pipeline (RPP), its own Terraform execution engine: it ensures least-privilege access and requires dual-control reviews, important for the company's AWS infrastructure since it adds strict guardrails to GitHub Actions workflows. The system governs thousands of resources across hundreds of repositories owned by different teams.

• OIDC role chaining: a workflow first assumes a central role limited to pre-authorized GitHub workflows, before escalating to a role scoped to the owning team
• Backend validation before acting: the pipeline checks that the Terraform code path matches the exact S3 backend and KMS key for that workspace, catching misconfigurations that would otherwise point at the wrong state file
• Real dual control: a human code review approval and an explicit pull request comment are both required to trigger apply, keeping planning and execution as separate, auditable steps

The point isn't whether Pinterest uses AI agents. The point is that the same pattern — scoped identity, validation before action, approval separated from execution — is exactly what an organization needs before letting an autonomous agent touch its infrastructure. Governance isn't improvised when AI arrives. It's extended.

The other risk: providers growing faster than your governance#

There's a second, AI-independent risk compounding the problem: the Terraform provider ecosystem keeps expanding without pause. AWS continues expanding its infrastructure portfolio at a pace that makes the provider an increasingly important abstraction layer; Terraform is no longer simply provisioning EC2 instances, networks, and S3 buckets, but increasingly representing higher-level capabilities around AI, resilience, security, databases, and application services.

That growth has a governance cost. Provider upgrades can affect schemas, defaults, state, and resource behavior — the withdrawal of version 6.57.0 earlier this year showed that even mature tooling can introduce upgrade risk, so provider versioning should be treated like application dependency management: pin versions, test upgrades, review changelogs, and promote changes through controlled environments.

What changes for platform teams#

The most important implication isn't technical. As AI reduces the time required to write infrastructure configuration, the platform team's work increasingly shifts toward creating the boundaries within which AI can operate safely: providing approved modules, defining policies, establishing identity boundaries, and determining what agents are allowed to change, while application teams consume those capabilities without bypassing organizational standards.

• Review work doesn't disappear — it moves from reading every line of code to designing the policies every change, human or agent, must satisfy
• Approved modules stop being an optional best practice and become the only source of truth an agent is allowed to consume
• Audit stops being after-the-fact documentation and becomes the evidence that explains why a change shipped, who approved it, and which policy allowed it

The underlying message, whether in HCP Terraform's model or Pinterest's pipeline, is the same: infrastructure as code was always a governance problem wearing a tooling costume. Solving it well — identity, policy, and the right expertise working as one connected system in Build, not a bolted-on project — is what separates a pipeline that scales from one that quietly accumulates risk. We've touched this from other angles in our notes on infrastructure drift and agents and AI agent governance in the enterprise.