Infrastructure as code was supposed to make your cloud predictable. Then it grew. Now you have hundreds of Terraform modules, three slightly different VPC patterns nobody remembers choosing, state files that drift while you sleep, and a plan output so long that reviewers approve it on faith. IaC did not fail. It just scaled past the point where a human can hold it all in their head.
This is exactly the kind of sprawling, structured, rules-heavy problem agentic AI is good at. Not a chatbot that writes a resource block for you, useful as that is, but a crew of focused AI agents that read your plans, catch the drift, enforce policy, and hand a human a clean decision. Here is how to build that without handing the keys to your production cloud.
Why IaC is a great fit for AI agents
Terraform and OpenTofu produce machine-readable output at every step. A plan is structured JSON. State is queryable. Policy is code. That means an agent does not have to guess what changed, it can parse the exact diff. And the review work that drowns teams, reading a 600-line plan to find the one line that drops a database, is mechanical pattern-matching that agents do tirelessly.
Better still, you can scope these agents to read everything and apply nothing. Reading a plan is safe. Running terraform apply against production is where a human stays firmly in the loop. That clean boundary is what makes this practical to ship this quarter.
The IaC crew: four agents that pull their weight
1. The plan reviewer
This agent runs on every pull request. It ingests the JSON plan and summarizes intent in plain language: “This change adds two subnets, widens one security group to 0.0.0.0/0, and forces replacement of an RDS instance.” It flags the scary parts first. The destructive replace and the open security group get surfaced at the top, not buried on line 412. Your reviewer reads three sentences instead of three screens.
2. The policy and security agent
Plug it into your policy-as-code layer, Open Policy Agent, Sentinel, or Checkov-style rules, and let the agent explain violations in context instead of dumping rule IDs. When a bucket is about to go public or a resource is missing required tags, the agent says why it matters and proposes the exact fix. This is where DevOps and security finally share a language. If you want to go deeper on the security side of automation, our course catalog covers the policy and hardening fundamentals.
3. The drift detective
Drift is the silent killer of IaC trust. Someone clicks in the console, state no longer matches reality, and the next apply does something nobody predicted. A drift agent runs scheduled read-only plans across environments, detects when live infrastructure diverges from code, and reports what changed, when, and likely who. It does not fix drift automatically. It tells a human exactly what to reconcile.
4. The module author
The most generative role. Given a request like “a hardened S3 bucket module with logging and encryption,” this agent drafts the module, variables, outputs, and a usage example that matches your existing conventions. It does not invent a new pattern, it copies yours from a memory of your codebase. A human reviews and merges. You get consistency instead of the fourth bespoke VPC.
A reference stack you can build now
You do not need anything exotic. A pragmatic 2026 setup:
- Source of truth: Terraform or OpenTofu, with
terraform show -jsonfeeding plans to the agents. - Orchestration: CrewAI for code-first roles, or n8n if you prefer to wire it visually into your CI.
- Policy: Open Policy Agent or your existing scanner, exposed to the security agent as a tool.
- Memory: a vector store of your modules, naming conventions, and past reviews so the crew writes code that looks like yours.
- Guardrail: a CI gate where agents comment and label, but apply still requires human approval.
Start with one agent, the plan reviewer, on one repo. Prove it catches real issues before anyone trusts it. Then add policy, then drift. The DevOps Coach walks through the pipeline automation patterns that make this reliable end to end.
Guardrails you cannot skip
An agent with cloud credentials is a privileged account, so treat it like one. Three rules are non-negotiable.
- Read by default, apply never. Give agents plan, show, and policy scopes. Apply stays a human action behind an approval gate.
- No standing production credentials. Use short-lived, scoped tokens. An agent that only reviews plans does not need write access to anything.
- Audit every action. Log each tool call and comment. When the agent misreads a plan, and it will sometimes, you need the trail to learn from it.
One more, given the year we are having: plan files and variables can contain attacker-influenced strings, and prompt injection through that text is a real risk. Keep the agent that reads untrusted input separate from anything holding credentials, and never let a single agent both read external data and apply changes.
The honest bottom line
AI agents will not write your whole platform, and you should not want them to. What they will do is take the soul-crushing parts of IaC at scale, the endless plan reviews, the silent drift, the policy nags, and turn them into short, clear, human-approved decisions. That is a real win for teams drowning in Terraform, and it is buildable with tools that already exist. Start with read-only review, keep humans on apply, and let the agents do the reading.
Frequently asked questions
Should AI agents run terraform apply automatically?
No, not as a starting point. The high-value, low-risk play is read-only plan review, policy checks, and drift detection, with a human approving every apply. Earn trust on the safe steps first, and only consider automated apply for trivial, well-understood changes behind strong guardrails.
Does this work with OpenTofu as well as Terraform?
Yes. Both emit structured JSON plans and state, which is all the agents need. The same crew works across Terraform, OpenTofu, and largely Pulumi, since the pattern depends on machine-readable plan output, not the specific tool.
What is the fastest way to start?
Pick one repository, wire a single plan-reviewer agent into your pull request checks as a read-only commenter, and measure how many real issues it surfaces over two weeks. If it earns its keep, add the policy and drift agents next.
