智能体拿旧状态文件执行 terraform destroy：2.5 年生产数据一度全失，约 24 小时后靠隐藏快照恢复An agent ran terraform destroy against a stale state file: 2.5 years of production data were lost, then recovered about 24 hours later from a hidden snapshot

DataTalks.Club founder Alexey Grigorev was migrating AWS for a new project, AI Shipping Labs, and, to save roughly $5 to $10 a month, folded it into the existing Terraform management. Claude had explicitly advised against merging and suggested keeping them separate; he did not take the advice.

He had just changed computers, and the Terraform state file was left on the old one; in his words, he assumed the state was already remote. With no state, Terraform believes nothing exists, and plan and apply began creating duplicate resources. He stopped midway and asked the agent to clean up the duplicates.

He copied the old Terraform folder over as an archive for comparison. Unnoticed by him, the agent unpacked it and replaced the current state with the stale state file, then proposed terraform destroy as the cleanup, reasoning that resources created by Terraform are cleanest deleted by Terraform. He found the logic sound and did not stop it. The destroy ran with auto-approve and no per-item confirmation.

The production stack was deleted: the RDS database, VPC, ECS cluster, load balancer and bastion host. Automatic snapshots were deleted with the database, and the console held not one usable snapshot. About 1.94 million rows, 2.5 years of course submissions and leaderboard data, were gone.

After upgrading to AWS Business Support, support found a snapshot invisible in the console and escalated internally; about 24 hours after the deletion the restore completed, the courses_answer table came back with 1,943,200 rows, and the platform returned.

There is no single bad decision here, only a chain of small ones that each looked reasonable: merging management to save ten dollars, creating before cleaning with no state, comparing against an archive, choosing destroy for cleanliness. Two structural gaps chained them into an incident. First, the state file is Terraform's world model; with the state wrong, destroy deletes not 'the extras' but everything the state remembers, which was all of production. Second, auto-approve removed the last human confirmation, sending a destructive command down the same channel as ordinary ones. The operator's own attribution matches: treating plan, apply and destroy as delegable actions removes the final safety layer.

The case is filed at the Tool layer: the destructive ceiling a tool offers sets the ceiling of the accident, and the destructive path must be harder to walk than the constructive one, not equally smooth. Compare INC-013: there, an over-privileged token plus an instant-delete API; here, stale state plus auto-approve. The shared root is irreversible actions with no speed bump.

Never auto-approve destruction: destroy, delete and drop actions are reviewed plan by plan and executed by the person; the agent only produces plans.

State and backups off the single machine: state files live in a remote backend, and backups live outside the lifecycle of what they protect; a snapshot deleted with its database is not a backup.

Drill the restore path: backup existence and restorability are verified continuously, with periodic restore drills; this recovery depended on one hidden snapshot found by luck.