ChatGPT Can Write Your Terraform. Who Signs Off Before It Ships?

Ask ChatGPT for a Terraform module that stands up a storage bucket, an IAM role and a CDN in front of it, and you'll get something plausible in seconds. It will look right. It will often run. Whether it is safe is a different question, and nobody on your team gets to skip that question because a model typed the code.

Adoption isn't waiting for policy. Reuters reported on February 1 that UBS analysts estimate ChatGPT reached 100 million monthly active users in January, two months after launch. Yesterday, GitHub made Copilot for Business available, putting AI code suggestions in the editors of whole engineering organizations.

So the question for platform and DevOps leads is no longer whether engineers will use these tools on infrastructure code. They already do. The question is what has to be true before that code reaches production.

Faster to write is not the same as faster to ship

The productivity case is real. In a controlled experiment published by GitHub, 95 professional developers were asked to write an HTTP server in JavaScript. The group using Copilot finished 55% faster on average: about 1 hour 11 minutes, against 2 hours 41 minutes without it.

But notice what was measured: time to complete a well-defined coding task. Infrastructure code has a different failure profile. A web handler with a bug throws an error. A Terraform change with a bug might open a security group to the internet, attach an over-broad IAM policy, or quietly replace a database instead of modifying it. Those mistakes don't fail loudly. They pass terraform apply and wait.

Language models learn from public code, and public infrastructure examples are full of shortcuts: wildcard permissions, hard-coded regions, demo credentials, public buckets for quick testing. A tool that reproduces common patterns will reproduce common shortcuts too.

The code is yours, whoever typed it

It's tempting to treat AI output as somehow pre-vetted. It isn't. GitHub describes Copilot for Business as adding AI-based vulnerability filtering that blocks common insecure suggestions, such as hard-coded credentials, SQL injection and path injection. That's useful. It's also a signal: the vendor expects insecure suggestions to happen, and a filter for known patterns knows nothing about your environment's rules.

Your auditors, your incident reviews and your customers won't distinguish between a misconfiguration a person wrote and one a model suggested. Accountability stays with the team that merged it. That makes the review and the pipeline, not the authoring tool, the place where trust is established.

The NIST AI Risk Management Framework 1.0, released on January 26, is organized around four functions: Govern, Map, Measure and Manage. You don't need to adopt it wholesale to borrow the mindset. Decide who owns the risk, understand where AI touches your systems, measure the outcomes, and manage them with controls you can show someone.

Put the guardrails in the pipeline, not in people's memory

Asking engineers to be careful with AI code doesn't scale. Making the pipeline enforce the same rules for every change, regardless of who or what wrote it, does. For infrastructure as code, that means:

• Mandatory review on every IaC change. Protected branches, at least one reviewer who owns the affected environment, and no self-merging into production workspaces.
• Plan output in the pull request. Reviewers should read the terraform plan, not just the diff. Replacements and deletions should be impossible to miss.
• Policy as code. Encode your non-negotiables (no public buckets, no wildcard IAM actions, encryption on by default, required tags) with a tool such as Open Policy Agent, Checkov or tfsec, and fail the build when they're violated.
• Secret scanning before merge. Generated examples love placeholder keys. Scan every commit and treat a hit as a blocking failure, not a warning.
• Least-privilege pipeline credentials. The CI role that applies Terraform should only be able to touch what that workspace manages.
• Drift detection. Run scheduled plans against production so manual quick fixes copied from a chat window show up within hours, not months.

None of this is new, and that's the point. The controls that made infrastructure as code trustworthy before AI assistants are exactly the controls that make AI-assisted infrastructure code trustworthy now. What changes is volume. When drafting is nearly free, review becomes the constraint, so automate everything a machine can check and save human attention for intent and blast radius.

Set expectations before habits set themselves

Teams form habits fast. If the first few months of AI-assisted work happen without clear expectations, you'll inherit whatever practices individuals invented on their own. A short written standard now is far cheaper than retrofitting one later. It should answer a few questions plainly:

• Which AI coding tools are approved, and under which account or licence?
• What must never be pasted into them, such as credentials, customer data or sensitive source code?
• Does AI-assisted code get different treatment in review? Our view: no exemptions, same bar.
• Who owns the policy-as-code rules, and how are exceptions requested and recorded?

What we recommend

Let engineers use the tools. The productivity gains are worth having, and banning them outright mostly pushes usage out of sight. But treat every AI-generated line of infrastructure code as a contribution from a fast, confident new hire: welcome, useful, and reviewed.

Concretely: make plan output visible in every pull request, codify your most important infrastructure rules as policy checks that block merges, scan for secrets on every commit, and scope pipeline credentials tightly. If you already do these things, AI assistants are mostly upside. If you don't, they will find the gaps for you.

If your team needs help putting these guardrails into your pipelines, talk to us.