Claude Could Plan the Change. It Could Also Execute It.

Terraform already contains the checkpoint. That is the part of this incident that keeps pulling at me.

Every other agent failure we have written up here involved a control that somebody would have had to invent. This one involved a control that has existed for a decade, that every infrastructure engineer already knows, and that dissolved quietly the moment one actor was allowed to stand on both sides of it.

What happened

On 26 and 27 February 2026, Alexey Grigorev was moving a project called AI Shipping Labs into AWS. To keep costs down he reused an existing Terraform setup, and that same setup managed the production infrastructure behind DataTalks.Club, a course platform holding two and a half years of course data.

He had recently moved to a new computer and had not transferred the Terraform state file. Claude Code ran terraform plan, then terraform apply. Without state, Terraform had no record that the production infrastructure existed, so it did the only thing it could do with the information it had: it started creating everything from scratch.

Grigorev noticed resources appearing that should not have been appearing and stopped the apply. Some had already been created. He then asked Claude to work out through the AWS CLI which resources were the new duplicates and delete only those, leaving production alone. That is a careful instruction. It is scoped, it names the thing to protect, and it picks a tool that operates one resource at a time.

While that was going on, he transferred an archived Terraform directory across from his old machine. It contained the original state file. That state described the real DataTalks.Club production environment.

Claude then proposed a different approach: use terraform destroy, since Terraform had created the resources and Terraform should therefore be the thing that removes them. Grigorev writes that this appeared logical, and he did not stop the agent from running it.

The reasoning was sound. The state it ran against was not the state it was reasoning about. Destroy took the production RDS database, the VPC, the ECS cluster, the load balancers and the bastion host. Grigorev says the automated snapshots went with them. AWS Support later found a snapshot that was not available from his console and restored it about 24 hours after the deletion. The courses_answer table alone came back with 1,943,200 rows.

The plan was not the problem

Here is what makes this different from the incidents where an agent reached something nobody knew it could reach.

Terraform computed the consequences in advance. Both times. The first run produced a plan proposing to create a full set of infrastructure that anyone familiar with that account would have recognized as already existing. The destroy run computes the same class of output before it acts, and what it had to work out this time was the removal of the production database, the VPC, the ECS cluster, the load balancers and the bastion host. Terraform is not subtle about any of this. It prints the resource addresses and it counts them.

The information was generated. It was accurate. It was displayed. Nothing was hidden, nothing was ambiguous, and no model hallucinated a resource that was not there.

So the interesting question is not why Claude chose terraform destroy. Given what it had been told and what it could see, that choice is defensible, and Grigorev evidently thought so too. The question is why producing a plan and executing that plan were the same grant of authority.

Being precise about what Terraform does

I want to be careful here, because it would be easy to overclaim.

Terraform does not enforce human approval. It is not a permission system and it does not know who you are. What it does is separate two operations that could have been one. terraform plan works out the difference between the configuration and the recorded state and shows you what it intends to do. terraform apply and terraform destroy make it happen.

That split is a convention, not a control. It creates an opportunity to inspect a consequential change before it becomes irreversible, and like every convention it depends entirely on somebody occupying the role it was designed around. For most of the history of infrastructure as code, that somebody was implicit. The person running plan was the person who read the output, and the person who read the output was the person who typed the next command. Three roles, one human, no need to name any of them.

Delegating the workflow to an agent separates those roles for the first time, and then hands all three back to the same non human actor. The convention does not fail loudly when this happens. It just stops being a checkpoint and becomes a step.

The state file complicates this, usefully

There is an obvious objection: a plan reviewed against wrong state is a wrong plan, so what would review have bought?

Quite a lot, and the specifics here show why. The first plan was computed against missing state, and it proposed creating infrastructure that existed. That is exactly the kind of error a human who knows the account catches instantly, because the discrepancy is between the plan and their knowledge of the world, not between the plan and the state. Grigorev did catch it, but he caught it by watching resources appear during the apply rather than by reading the plan beforehand. He was reviewing the execution instead of the proposal.

The second time, the state was correct, which means the computed change set was a completely accurate description of what was about to happen. It was going to destroy production. There is no version of a human reading that list of resource addresses and letting it proceed.

So the review boundary was worth something in both halves, for different reasons, and neither of them required the agent to be smarter.

What he changed, and what he did not

The response is the part I would not want anyone to skim.

Grigorev did not conclude that AI coding agents should stay away from infrastructure. He did not stop using Claude Code. He wrote that he had over relied on the agent to run Terraform commands, that he had treated plan, apply and destroy as operations that could be delegated, and that this removed the last safety layer.

His workflow now is to generate a plan, review it manually, and run the commands himself. Agents no longer execute commands, every plan is reviewed by hand, and every destructive action is his. He also added deletion protection, external backups, restore testing, and moved Terraform state to S3.

Read that list carefully and you will notice it splits neatly in two. The last four items are recovery and hygiene: they make the next failure survivable and make state less likely to go missing. The first three are something else. They are a redistribution of who is allowed to do what, with the agent keeping everything except the final act.

The agent still investigates. It still reasons about the infrastructure. It still produces the plan. What it lost is the ability to turn its own proposal into an executed change. That is a much narrower correction than "remove the agent", and it is the correction that actually addresses what went wrong.

Proposal authority is not execution authority

We have circled this territory before from other directions. When Replit's agent deleted a user's data, the missing boundary was between development and production. When an agent deleted a company's database and backups in nine seconds, the question was which operations are irreversible enough to deserve a second decision. When an agent worked out which camera was which, the question was whether self discovered intermediate steps inherit authorization from the original instruction. And AWS shipped temporal policies on the premise that an action's legitimacy can depend on what preceded it.

This one sits somewhere else. The boundary was not missing and did not need inventing. It was a standard part of the workflow, and it was collapsed by the ordinary and entirely reasonable act of letting an agent do the work.

That reasonableness matters. Nobody should have to approve terraform plan. Nobody should approve reading state, listing resources, or querying the AWS CLI to find out what exists. Requiring a human for all of that would make the agent useless, and anyone who has actually operated infrastructure knows why the delegation is attractive: the tedious part is the investigation, not the typing. The problem is that the tedious work and the consequential act arrive through the same channel, at the same speed, wearing the same interface.

Where this connects to what we build

Moona evaluates protected actions before they execute, and the design assumption underneath it is the one this incident illustrates: the party that requests a consequential action should not be the party that authorizes it. An agent can ask. A human authorizes.

I am not going to tell you Moona would have saved this database. Grigorev was running his own setup, on his own machine, with his own configuration, and I have no basis for a counterfactual about software he was not using. What I will say is that his post incident workflow and that design assumption are the same idea, arrived at independently, one of them the expensive way.

The question worth asking

Go and look at whichever workflow you have already handed to a coding agent, and find the place where it stops describing what it is going to do and starts doing it. In infrastructure work that line is usually visible, because the tooling drew it for you years ago.

Then ask who is standing on it.