How to use AI agents to review infrastructure without turning automation into blind trust.
Provisioning infrastructure is a daily reality for SRE, DevOps, Platform, and Cloud Engineering teams. That doesn’t mean every SRE should spend the day writing Terraform. But when we talk about resilience, there’s a fair expectation: an SRE should understand infrastructure well enough to spot decisions that quietly compromise availability, security, or operability.
Everyone should understand Infrastructure as Code. Not everyone needs to be hands-on with it every day.
But this isn’t a text about who should write Terraform. I want to talk about something I’ve been doing a lot lately: using AI agents to review Terraform code.
The question is simple:
Can we trust that review, or are we just adding a new layer of risk?
Infrastructure as Code is still software
Any time we write code or automate a task, we need a validation phase. IaC is no different.
Terraform, OpenTofu, Pulumi, CDK, CloudFormation, and Crossplane let us define, version, review, and reproduce infrastructure as code. With Terraform we can generate an execution plan before applying and write tests to check expected behavior.
The catch is that, unlike a visual glitch in an app, a small infrastructure change can:
- Delete an important resource.
- Expose data publicly.
- Rewrite network rules.
- Grant excessive permissions.
- Generate unexpected cost.
- Cause a production outage.
IaC is code — but its consequences are very real.
AI raised the speed, and the risk
AI agents can now build modules, modify resources, write variables, and suggest full architectures in Terraform. That’s a real productivity boost. But the faster we create infrastructure, the faster we create misconfigured infrastructure.
An agent can produce Terraform that’s perfectly valid syntactically and still design something unsafe. It might grant an over-permissive IAM policy, skip encryption or backups, pick a resource pricier than needed, ignore replacement impact, or violate internal standards it was never told about.
So the fact that code was AI-generated doesn’t reduce the need for review. If anything, it increases it.
The agent that writes shouldn’t be the only one that reviews
A common move is to ask the same agent: “Review the code you just wrote.”
It helps, but there’s a trap: the agent tends to repeat the same assumptions it used to generate the code. Running the same prompt three times doesn’t give you three independent analyses — just three variations of one answer.
A better approach is to split the review into specific perspectives:
Security — over-permissive IAM, public resources, unencrypted data, secrets in code or state, wide-open firewall rules, missing logs or audit trails.
Resilience & operations — high availability, backups and restore, update strategy, replacement risk, dependencies between components, observability, and rollback capability.
Cost & efficiency — sizing, unnecessary resources, data transfer, storage, over-provisioned services, and cheaper alternatives.
Now we’re not asking “review again.” We’re running reviews with different goals.
Embracing Risk doesn’t mean ignoring risk
One of SRE’s core principles is Embracing Risk. It doesn’t mean accepting any change or trusting automation blindly. It means accepting that zero risk doesn’t exist and consciously deciding which risks are acceptable.
To capture AI’s benefits — speed, productivity, efficiency — we need to reduce the probability and impact of failure. So the real question isn’t “Can the agent review my Terraform?” It’s:
What needs to exist in my process so I can trust a change reviewed by an agent?
The answer lives less in the model and more in the pipeline built around it.
What a safer pipeline looks like
1. Deterministic validation. Before any AI review, run checks that don’t depend on a model’s opinion: terraform fmt, terraform validate, lint, tests, security scans (tfsec, Checkov), policy checks, and terraform plan. Remember: validate confirms syntax and internal consistency, plan shows proposed changes — neither guarantees the architecture is safe.
2. Specialized agent review. After the deterministic gate, agents analyze what needs context: Is this aligned with company standards? Does it increase the blast radius? Is there a simpler solution? Is it consistent with the rest of the repo? Feed the agent real context — internal docs, approved modules, security requirements. Without context, it reviews the code, not the solution.
3. Analyze the plan, not just the .tf. The review must clearly surface what will be created, modified, destroyed, or replaced, plus any IAM, networking, or data-impacting changes. Code shows intent; the plan shows what Terraform intends to execute.
4. Policy as Code. Some decisions shouldn’t depend on a human’s or an agent’s interpretation — they should be hard rules: buckets can’t be public, databases must be encrypted, resources need mandatory tags, destructive changes require extra approval. The agent can recommend; policy must block.
5. Gradual deployment. Even after every review, risk remains. Promote changes through environments — Dev → Staging → Pre-prod → Production — and split large changes into smaller deliveries. The smaller the change, the easier it is to understand its impact and recover from it.
6. Post-deployment validation. A pipeline shouldn’t end at terraform apply. After applying, verify: are resources healthy, are metrics stable, do logs show errors, is expected access working, did any security rule drift, is the cost still within budget? A successful apply doesn’t mean the change produced the intended result.
So — confidence or risk?
A bit of both.
AI agents can genuinely improve Terraform review. They analyze large amounts of code, compare patterns, catch inconsistencies, and raise questions a manual review might miss. But an agent shouldn’t be treated as the single source of trust.
Trust comes from the combination: deterministic validation, automated tests, security scans, Policy as Code, plan analysis, multi-perspective reviews, human approval proportional to risk, gradual rollout, and post-deployment checks. The best use of AI isn’t to replace these controls — it’s to make them run better and faster.
In the end, the question isn’t whether we can trust AI agents. It’s:
Have we built a process safe enough to enjoy AI’s speed without depending blindly on it?
AI didn’t remove the need for good judgment — it raised the price of skipping it. If your review process is the last line of defense between a prompt and production, make it count.
Cheers,
Douglas Mugnos
MUGNOS-IT 🚀
