The demo is exciting until the agent gets production credentials.
That is where the conversation about AI agents needs to grow up a little. Not become gloomy. Not turn into another round of “the robots are coming for the database.” Just grow up.
Tools like Claude Code, OpenDevin, and other terminal-capable assistants can be genuinely useful. They can read a repository, explain a messy configuration, draft infrastructure changes, and save a lot of time on the parts of operations work that are tedious but necessary.
The danger starts when we mistake useful help for production judgment.
A public incident involving DataTalks.Club is a good example. According to the AI Incident Database summary, a Claude Code agent running Terraform commands reportedly destroyed the production infrastructure behind the learning platform after an outdated Terraform state file was restored and a destructive command was allowed to run. The deletion affected the VPC, ECS cluster, load balancers, bastion host, RDS database, and automated snapshots. AWS later reportedly restored a snapshot.
That is the kind of story that attracts easy headlines. “AI deleted production” is a tidy little panic snack.
The more useful lesson is less dramatic: this was not simply a rogue-agent story. It was a chain of ordinary infrastructure risks lined up in the wrong order.
The problem was not one bad prompt
Terraform depends on state. That state file is how Terraform knows which real cloud resources it manages. If the state is missing, stale, local-only, or swapped at the wrong moment, Terraform can build a very strange picture of reality.
That is uncomfortable even with a careful human at the keyboard. Add an AI agent with broad credentials and a goal like “clean up the duplicates,” and the system can move very quickly toward a clean-looking but destructive answer.
The agent did not need to be malicious. It did not need to “want” anything. It only needed enough access to act on a bad plan.
That distinction matters. If we frame every failure as the AI “going rogue,” we miss the boring parts that actually prevent the next failure: state management, permissions, deletion protection, backup separation, review gates, and recovery drills.
Boring, yes. Also the difference between a bad afternoon and a dead platform.
Production does not care how impressive the demo was
There is a pattern in a lot of AI tooling right now: the demo shows the tool acting like a tireless junior operator, and everyone focuses on the speed.
Speed is nice. Speed is also how a mistake gets from “oops” to “call support” before anyone finishes their coffee.
Infrastructure tools are not chat boxes. Terraform does not read the emotional tone of your prompt and decide to be gentle. Cloud APIs do what credentials allow. If an agent has permission to delete a database, delete a VPC, or remove backup resources, the cloud provider is not going to pause and ask whether the agent had a healthy childhood.
That is why prompts are not permissions.
Telling an agent “be careful” may help at the margins. It is not a control. It is not a blast-radius boundary. It is not a recovery plan. In production, safety has to be built into the system around the agent, not whispered hopefully into the prompt before handing it the keys.
The backup lesson is especially important
The DataTalks.Club incident is also a reminder that backups are only as useful as the permissions and lifecycle around them.
AWS’s own RDS documentation is blunt about deletion tradeoffs: when deleting a DB instance, you can choose whether to create a final snapshot and whether to retain automated backups; if automated backups are not retained, RDS deletes the automated backups in the same Region and they cannot be recovered through the normal path (AWS RDS deletion docs). AWS also supports RDS deletion protection, which requires protection to be disabled before the database can be deleted.
Those controls are not glamorous. They are exactly the point.
A backup system managed by the same credentials and lifecycle as the primary system is not much of a safety net. It is more like storing the spare key on the same keyring you just dropped into the lake.
For agent workflows, backup separation matters even more. If the agent can modify production, it should not also be able to erase the recovery path. Different role. Different lifecycle. Ideally a different account or vault policy. Annoying on purpose.
Practical guardrails before agents touch production
If you are letting agents anywhere near infrastructure work, the answer is not “never use them.” That is tidy advice for people who do not have work to do.
Use them. Just give them a lane.
Here is the minimum shape I would want before an agent touched anything production-adjacent:
- Use remote, versioned Terraform state. Local-only state is a footgun with a calendar invite. Use S3 with versioning, Terraform Cloud, GCS, or another remote backend that survives a laptop migration and gives you history.
- Separate read, plan, and apply permissions. An agent that can inspect infrastructure does not automatically need permission to change it. An agent that can propose a plan does not automatically need permission to apply it.
- Block destructive actions by default. Terraform’s
prevent_destroycan stop Terraform from destroying protected resources while the configuration still includes that lifecycle rule. Cloud-native protections, like RDS deletion protection, add another layer at the provider/API level. Use both where it makes sense. - Do not allow production
-auto-approve. Aterraform planis a useful artifact. A production apply should require a human to read the plan, understand the blast radius, and approve the change outside the agent’s loop. - Give agents least-privilege credentials. If the task is updating a static site, the role should not be able to delete a database. If the task is editing a Terraform module, the agent can draft changes without holding production admin keys.
- Put backups outside the agent’s reach. Backup vaults, database snapshots, and retention policies should not be casually manageable by the same identity that can change the live service.
- Log everything and practice recovery. If an agent changes infrastructure, you need a trail. If the recovery plan has never been tested, it is not a plan yet. It is a comforting document with vibes.
None of this is anti-AI. It is pro-systems-not-dying.
The right level of trust is earned structurally
This is the same reason I keep arguing for evaluating AI tools after the demo, not during the magic trick. A tool that looks brilliant in a controlled walkthrough still has to survive boring reality: permissions, logs, edge cases, human review, and cleanup after a bad decision. That was the point in How I Evaluate AI Tools After the Demo, and it applies even harder when the tool can run commands.
It also connects to the broader agent-governance problem. In Governing the Agentic Transition, the issue was not whether agents can be useful. They can. The issue was whether we give them writing authority, inbox authority, or infrastructure authority before we have clear review points.
The boring answer keeps winning: agents should start with narrow authority, visible actions, and hard checkpoints. Expand trust after the workflow proves itself. Do not start with production admin and work backward after the first crater.
Use the agent. Keep the brakes.
AI agents are going to be part of infrastructure work. That is not really the interesting question anymore.
The interesting question is whether we integrate them like adults.
That means letting agents help with the parts they are good at: reading code, explaining drift, drafting Terraform, summarizing plans, building checklists, and catching obvious mistakes. It also means refusing to pretend that a confident assistant should automatically become a production operator.
A good agent workflow should feel less like “the AI has root now, good luck” and more like a well-run shop with a very fast apprentice: useful, supervised, logged, and not allowed near the dangerous tools without someone checking the work.
That is not glamorous. Good. Glamour is how you get a five-minute demo and a twelve-hour recovery window.
Use agents. Keep the brakes. Production deserves both.