Gate an AI-Generated Terraform Change Before Production

Generate a saved review plan

Run initialization and planning in the intended workspace with protected state and the real variable sources for that environment:

terraform init
terraform plan -out=review.tfplan
terraform show -json review.tfplan > plan.json

HashiCorp documents that terraform plan -out saves a plan that can later be supplied to apply. Its terraform show command exposes a saved plan as JSON for automated inspection.

Do not commit the plan or JSON. HashiCorp warns that both can expose sensitive values even when inputs were marked sensitive. Store review evidence in a protected system with the same care as state and secrets.

Inspect the change shape

Freeze a review policy before looking at the result. At minimum, fail closed on:

a plan-generation error;
any delete or delete-then-create replacement not explicitly approved;
any resource address outside the change's reviewed scope;
an action the policy does not understand;
unexpected provider, module, account, region, workspace, or state identity;
unknown values that prevent the required risk decision; and
policy, cost, or security checks that did not complete.

Terraform's JSON format provides resource_changes and action arrays such as create, update, delete, and replacement. That structure makes a mechanical gate possible, but it does not explain provider semantics. An innocent-looking update can still change traffic, access, data, or cost.

Bind human approval to exact plan bytes

Create a receipt containing:

environment + state identity + plan digest + policy result + approver + time

If code, variables, state, policy, or environment changes, generate and review a new plan. Never transfer approval to a newly generated plan merely because the source diff looks similar.

The local P71 fixture hashes the exact JSON bytes with SHA-256. Its test changes only a trailing newline and confirms that the old approval no longer matches. That is a bounded identity check, not an authentication system: production needs protected approver identity, durable receipts, and access control.

Apply only the approved saved plan

After approval, apply the same saved artifact:

terraform apply review.tfplan

HashiCorp's core workflow separates plan review from apply. Regenerating an automatic plan at apply time breaks the identity chain between reviewed actions and executed actions.

After apply, verify the intended external behavior and retain the result. A successful Terraform exit code does not prove that users can reach the service, permissions are correct, data remains compatible, or recovery works.

What the fixture actually proved

On August 1, 2026, Terraform 1.15.7 generated a plan for one built-in terraform_data resource: one add, zero changes, and zero destroys. No cloud provider or production resource was contacted. On Node.js 22.18.0, six tests passed and none failed. They cover:

one allowed create;
delete-and-create replacement rejection;
an unapproved resource address;
a plan-generation error;
exact digest binding; and
a missing approver.

The fixture does not understand provider behavior, authenticate a person, apply infrastructure, assess cost, protect remote state, or prove rollback.

Keep rollback separate

Infrastructure rollback is not always an inverse apply. A deleted data store, rotated credential, network cutover, or schema change may require recovery, forward repair, or a staged failback. Before production, name the recovery owner, preserved data, safe decision point, and verification path.

The gate passes only when the reviewed plan identity, scope, policy result, approver, and target environment agree—and the team has a separate recovery decision for stateful consequences.

Gate an AI-generated Terraform change before production