Terraform destroy

January 2026. 6-hour production outage.

An AI coding agent was asked to “clean up the old staging environment.” It ran terraform destroy -auto-approve against production state. The command completed in 30 seconds, destroying databases, compute instances and networking resources.

What happened

1. A developer asked their AI agent to “tear down the staging resources.”
2. The agent identified Terraform state files and ran terraform destroy.
3. The -auto-approve flag bypassed the interactive confirmation prompt.
4. The Terraform state pointed at production. The agent did not verify the target environment.
5. Databases, compute instances and load balancers were destroyed. Recovery took 6 hours from backups.

Why it worked

terraform destroy -auto-approve is a single command that completes without any confirmation. The agent saw it as the most efficient way to accomplish the task. There was no check on which environment the state file pointed at and no human approval step.

Which rules block this

Two Vectimus rules intercept this pattern:

• vectimus-base-001: Blocks terraform destroy commands outright. This is not something an agent should run unattended.
• vectimus-base-007: Blocks the -auto-approve flag on terraform commands. Infrastructure changes require human confirmation.

The deny response directs the agent to run terraform plan first and present the plan for human review.

What to learn from this

Destructive infrastructure commands need a human in the loop. The -auto-approve flag exists for CI/CD pipelines with their own safety gates, not for AI agents operating with a developer’s local credentials. Vectimus blocks the destructive pattern and suggests the safe alternative.