How should organisations govern AI-written Terraform before it reaches production?

Why This Matters for Security Teams

AI-written Terraform can turn infrastructure review into a control problem, not just a coding problem. The risk is not limited to syntax errors. It includes over-permissive IAM bindings, public network exposure, weak encryption defaults, and configuration drift that slips through because the code looks plausible. Governance needs to cover the full path from prompt to plan to apply, with clear ownership at each step. The NIST Cybersecurity Framework 2.0 is useful here because it ties governance, risk, and control execution together rather than treating review as a one-off checkpoint.

The practical mistake many teams make is treating AI output as a productivity issue instead of a control boundary. Terraform generated by an LLM can be fast, coherent, and still unsafe if it inherits outdated patterns, mislabels resources, or omits required guardrails. Current guidance suggests the safest model is to treat AI-generated infrastructure as untrusted until it passes the same checks as hand-written code, plus a few AI-specific ones such as provenance and prompt-to-output traceability. In practice, many security teams encounter the breach only after an overly broad role or exposed service has already been deployed, rather than through intentional policy enforcement.

How It Works in Practice

Governance works best when policy is embedded at three points: authoring, review, and merge. At authoring time, teams should constrain what the AI assistant is allowed to generate, for example by providing approved modules, baseline templates, and organisation-specific patterns. At review time, pull requests should check the output for security properties, not just formatting. At merge time, the pipeline should block anything that fails policy-as-code, secret scanning, or infrastructure linting.

Security teams should pay special attention to the difference between what the code intends and what the cloud provider will actually create. AI-written Terraform often produces resource blocks that are technically valid but operationally risky. For example, a storage bucket may be encrypted in one module but left public in another, or a security group may inherit a permissive rule because the model mirrored an older example. NIST SP 800-53 Rev. 5 Security and Privacy Controls provides a useful control baseline for mapping these checks to real enforcement points.

• Validate provider versions and syntax so generated code does not quietly depend on deprecated behavior.
• Scan for hardcoded values, especially credentials, API keys, and account identifiers.
• Check for wildcard permissions and broad trust policies before merge.
• Enforce encryption, logging, and network restrictions with policy-as-code, not reviewer memory.
• Require human approval for high-impact changes even if the AI generated the initial draft.

The strongest implementations also preserve traceability. Teams should know which prompt, model, and reviewer produced each change set, especially when the AI is being used to generate modules repeatedly. That supports incident response, rollback, and accountability when a pattern of unsafe output emerges. These controls tend to break down when Terraform is generated across many repos with inconsistent module standards because policy coverage becomes fragmented and reviewers start trusting the shape of the code instead of the effective cloud state.

Common Variations and Edge Cases

Tighter pre-production control often increases delivery friction, requiring organisations to balance developer speed against the risk of unsafe infrastructure reaching apply stage. That tradeoff is real, especially in fast-moving platform teams.

There is no universal standard for AI-written Terraform governance yet, so best practice is evolving. Some organisations treat generated code exactly like any other infrastructure-as-code change and rely on existing guardrails. Others add AI-specific approval steps for sensitive systems, such as identity platforms, regulated workloads, or internet-facing services. The second approach is usually stronger when the blast radius of a bad change is high.

Edge cases appear when teams use AI to generate module scaffolding, then let human engineers fill in the security details later. That can work, but only if ownership is explicit and the final review checks the rendered plan, not just the source file. Another common exception is use of pre-approved modules with narrow parameterisation. In those cases, the governance focus shifts from raw Terraform content to the safety of the module catalog itself and the controls around who can publish new modules. Where AI is being used to generate Terraform for identity, secrets, or privileged access workflows, the review should also confirm that the infrastructure design does not create new NHI or credential sprawl problems.

For teams building policy around this today, the right question is less “Was AI used?” and more “Can this change prove it is safe, traceable, and compliant before it reaches production?”

Related resources from NHI Mgmt Group

• How should organisations govern destructive AI agent actions in production?
• How can organisations test AI agent access before production use?
• What should organisations do before allowing AI-generated dependencies into production?
• How should organisations govern AI agents that can change production monitoring?