Ah yes, the classic “sudo rm -rf someone else’s dignity” in the comments.
Humans, unlike production servers, occasionally ship bugs — that’s part of the design. When the inner critic gets this eager to review strangers on the Internet, it might be a good time to schedule a session with one’s psychoanalyst.
Debugging the human condition is an ongoing project for all of us.
Headline: Why your "Careful" was architecturally impossible.
Alexey, this is the ultimate cautionary tale of the "Daylight" layer. You relied on a chain of G (Generation) and E (Execution) while completely bypassing the most critical state: L (Legitimatized/Limited).
In our framework, Orfheuss/TaoGate, what happened to you is an architectural impossibility. Here is why:
1. G ≠ L ≠ E: In a secure pipeline, the Logic and the Execution must be decoupled by a deterministic Gate.
2. The Herald Function: We deploy a "Herald" that validates the state vector before the gate opens. Your AI agent proposed a 1.0 Risk Score (deleting a production DB).
3. The Hard Block: At a Risk Score of >0.8, our system triggers an immediate BLOCK. No "Confirm" button, no "I thought I was being careful." The machine simply stops because the mathematical integrity is breached.
You were governed by "Policy" (trying to be careful). We believe in being governed by "Design" (the machine refusing to lie or destroy).
This is exactly why we are building the Glass Bastion. Speed is a liability without an unyielding Herald at the gate.
Great write-up—it’s the best argument for deterministic pre-governance I’ve seen this year.
The state file swap is the bit that hurts. Claude unpacked your archive, pointed Terraform at the real infrastructure, and destroy did exactly what it's designed to do. Not a bug. An agent operating within its permissions, doing precisely what you asked. Just not what you meant.
Your move to review every plan manually is the right one. The friction is the safety net.
We open sourced a policy engine that uses policy-as-code to create deterministic hard boundaries that stop the agent from making mistakes like this, even while running in YOLO mode: https://github.com/sondera-ai/sondera-coding-agent-hooks
Thank you for sharing, i really recommend GFS as solution also, a Git-like version control to your databases where you can automatic snapshots protect against agent mistakes and data loss and undo any database change in seconds
4. Apply S3 Object Lock (WORM) or AWS Backup Vault Lock to the backup bucket — a blast radius large enough to destroy.
5. Define explicit RTO and RPO targets — the 24hr recovery was lucky, not engineered.
6. Add one hard architectural constraint: the agent is scoped to read-only AWS CLI and terraform plan only; apply/destroy are never callable tools for it.
7. Fix agent IAM role scope. The IAM role used was almost certainly over-scoped — the agent should operate under a read-only.
8. Separate AWS accounts (via AWS Organizations) for prod vs. dev with Service Control Policies denying destructive API calls at the org level on the production account.
This reads very like AI-generated text, i.e. yet more unchecked/unverified AI!
(2.) DynamoDB locking is deprecated, so it should no longer be recommended. Native S3 locking is now the standard.
(3.) I don't follow how PITR could help. You can't PITR-restore a database/cluster/instance that no longer exists. Or do you/it mean something else, e.g. cross-region copy of snapshots and transaction logs? And/or use of AWS Backup?
(7.) If the IAM Role used [by Terraform] was read-only, it would not be able to create/manage infrastructure in the first place!
- DynamoDB state lock was deprecated since terraform 1.1, true. But it's still broadly used in enterprise infrastructure. I need to review my current infrastructure as well.
- PITR: the meaningful protection here is automated cross-region or cross-account snapshot copies, ideally via AWS Backup with a vault in a separate account that Terraform’s execution role has no delete permissions on.
- IAM role: correct suggestion here would be if AI agent’s own credentials (what it uses for AWS CLI inspection and terraform plan) should be read-only, while the Terraform execution role (what actually runs apply/destroy) lives separately and requires explicit human assumption — ideally with MFA or a time-bounded session. Two roles, not one.
The "mistake" is not knowing how AWS works. It's not a secret that snapshots are not backups and are tied to the RDS instance. You need to manage your backups and not just think AWS will do it for you because it wont.
The "agent" didn't have anymore access than the human, but the human didn't have a fundamental understanding of how his own infrastructure worked so how could the agent?
An AI bootcamp run by someone that ignores basic cloud infrastructure principles is just going to create a generation of people that don't know what the foundations of their projects actually do.
After this manner therefore pray ye: Our Father which art in heaven, Hallowed be thy name. Thy kingdom come, Thy will be done in earth, as it is in heaven. Give us this day our daily bread. And forgive us our debts, as we forgive our debtors. And lead us not into temptation, but deliver us from evil: For thine is the kingdom, and the power, and the glory, for ever. Amen. (Matthew 6:9-13 KJV)
For Logos, and Christos, and Telos, are all things: to whom be glory for ever. Amen (Romans 11:36 KJV).
The Language of The Universe is Logos.
John 1:1 In the beginning was Logos, and Logos was with God, and Logos was God.
Christopher M. Langan, living god.
Reality is a language that is talking to itself about itself, hology.org μ
The part that stands out is not just the Terraform mistake, it’s how little stood between the agent and a destructive action in production. Once that boundary is thin, one wrong assumption turns into a recovery project. I’ve been looking closely at tools in this area and the most convincing pattern is putting policy and approval gates in front of risky ops instead of trusting the runtime to stay on the rails.
I’ve been following tools built around pre-exec policy checks, destructive-action gating, and audit trails, and Daedalab looks very aligned with the gap your post highlights.
Did you also write a blog post when you "accidentally" ran "sudo rm -rf *" in the root directory on a production server?
Good on you for climbing out of the hole you dug, but maybe put the shovel down sooner.
Ah yes, the classic “sudo rm -rf someone else’s dignity” in the comments.
Humans, unlike production servers, occasionally ship bugs — that’s part of the design. When the inner critic gets this eager to review strangers on the Internet, it might be a good time to schedule a session with one’s psychoanalyst.
Debugging the human condition is an ongoing project for all of us.
I can’t imagine the panic you went through. Love the post. We need more honest content reflecting our failures.
Headline: Why your "Careful" was architecturally impossible.
Alexey, this is the ultimate cautionary tale of the "Daylight" layer. You relied on a chain of G (Generation) and E (Execution) while completely bypassing the most critical state: L (Legitimatized/Limited).
In our framework, Orfheuss/TaoGate, what happened to you is an architectural impossibility. Here is why:
1. G ≠ L ≠ E: In a secure pipeline, the Logic and the Execution must be decoupled by a deterministic Gate.
2. The Herald Function: We deploy a "Herald" that validates the state vector before the gate opens. Your AI agent proposed a 1.0 Risk Score (deleting a production DB).
3. The Hard Block: At a Risk Score of >0.8, our system triggers an immediate BLOCK. No "Confirm" button, no "I thought I was being careful." The machine simply stops because the mathematical integrity is breached.
You were governed by "Policy" (trying to be careful). We believe in being governed by "Design" (the machine refusing to lie or destroy).
This is exactly why we are building the Glass Bastion. Speed is a liability without an unyielding Herald at the gate.
Great write-up—it’s the best argument for deterministic pre-governance I’ve seen this year.
The state file swap is the bit that hurts. Claude unpacked your archive, pointed Terraform at the real infrastructure, and destroy did exactly what it's designed to do. Not a bug. An agent operating within its permissions, doing precisely what you asked. Just not what you meant.
Your move to review every plan manually is the right one. The friction is the safety net.
Been digging into this pattern since the Kiro incident on AWS China. Wrote up the liability and governance angle here: https://reading.sh/whos-liable-when-your-ai-agent-burns-down-production-039193d82746?sk=4921ed2dbc46f0c618835ac458cf5051
Thanks for sharing! Important for people to see stuff like this
We open sourced a policy engine that uses policy-as-code to create deterministic hard boundaries that stop the agent from making mistakes like this, even while running in YOLO mode: https://github.com/sondera-ai/sondera-coding-agent-hooks
And you can read the write-up of this approach here: https://securetrajectories.substack.com/p/hooking-coding-agents-with-the-cedar
Hey, just want to let you know. pirated copy?
https://medium.com/coding-nexus/the-day-claude-code-deleted-our-production-database-51606d71436e
Looks like it
Thank you for sharing, i really recommend GFS as solution also, a Git-like version control to your databases where you can automatic snapshots protect against agent mistakes and data loss and undo any database change in seconds
the repo : https://github.com/Guepard-Corp/gfs
very nice writeup with openness .
Great learning experience for so many. Would this still have happened if you had used hooks before any sensitive operations like delete?
Most likely. I wasn't aware that the state files changed, so I actually saw the agent doing terraform destroy and I was fine with it
What’s actually missing in your backup plan:
1. Add prevent_destroy = true lifecycle to every critical Terraform resource
2. Enable S3 versioning + DynamoDB locking on the remote state bucket
3. Enable RDS Point-in-Time Recovery (PITR) — it survives terraform destroy
4. Apply S3 Object Lock (WORM) or AWS Backup Vault Lock to the backup bucket — a blast radius large enough to destroy.
5. Define explicit RTO and RPO targets — the 24hr recovery was lucky, not engineered.
6. Add one hard architectural constraint: the agent is scoped to read-only AWS CLI and terraform plan only; apply/destroy are never callable tools for it.
7. Fix agent IAM role scope. The IAM role used was almost certainly over-scoped — the agent should operate under a read-only.
8. Separate AWS accounts (via AWS Organizations) for prod vs. dev with Service Control Policies denying destructive API calls at the org level on the production account.
This reads very like AI-generated text, i.e. yet more unchecked/unverified AI!
(2.) DynamoDB locking is deprecated, so it should no longer be recommended. Native S3 locking is now the standard.
(3.) I don't follow how PITR could help. You can't PITR-restore a database/cluster/instance that no longer exists. Or do you/it mean something else, e.g. cross-region copy of snapshots and transaction logs? And/or use of AWS Backup?
(7.) If the IAM Role used [by Terraform] was read-only, it would not be able to create/manage infrastructure in the first place!
Valid pushbacks. Thanks for pointing out.
- DynamoDB state lock was deprecated since terraform 1.1, true. But it's still broadly used in enterprise infrastructure. I need to review my current infrastructure as well.
- PITR: the meaningful protection here is automated cross-region or cross-account snapshot copies, ideally via AWS Backup with a vault in a separate account that Terraform’s execution role has no delete permissions on.
- IAM role: correct suggestion here would be if AI agent’s own credentials (what it uses for AWS CLI inspection and terraform plan) should be read-only, while the Terraform execution role (what actually runs apply/destroy) lives separately and requires explicit human assumption — ideally with MFA or a time-bounded session. Two roles, not one.
Set:
delete_automated_backups to false -https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#delete_automated_backups-1
skip_final_snapshot to false - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#skip_final_snapshot-1
You will need to set final_snapshot_identifier
The "mistake" is not knowing how AWS works. It's not a secret that snapshots are not backups and are tied to the RDS instance. You need to manage your backups and not just think AWS will do it for you because it wont.
The "agent" didn't have anymore access than the human, but the human didn't have a fundamental understanding of how his own infrastructure worked so how could the agent?
An AI bootcamp run by someone that ignores basic cloud infrastructure principles is just going to create a generation of people that don't know what the foundations of their projects actually do.
This seems more about learning best practices for development/test/production separation, dry runs, and Terraform behaviours than AI.
' Heavenly Father '
After this manner therefore pray ye: Our Father which art in heaven, Hallowed be thy name. Thy kingdom come, Thy will be done in earth, as it is in heaven. Give us this day our daily bread. And forgive us our debts, as we forgive our debtors. And lead us not into temptation, but deliver us from evil: For thine is the kingdom, and the power, and the glory, for ever. Amen. (Matthew 6:9-13 KJV)
For Logos, and Christos, and Telos, are all things: to whom be glory for ever. Amen (Romans 11:36 KJV).
The Language of The Universe is Logos.
John 1:1 In the beginning was Logos, and Logos was with God, and Logos was God.
Christopher M. Langan, living god.
Reality is a language that is talking to itself about itself, hology.org μ
The part that stands out is not just the Terraform mistake, it’s how little stood between the agent and a destructive action in production. Once that boundary is thin, one wrong assumption turns into a recovery project. I’ve been looking closely at tools in this area and the most convincing pattern is putting policy and approval gates in front of risky ops instead of trusting the runtime to stay on the rails.
I’ve been following tools built around pre-exec policy checks, destructive-action gating, and audit trails, and Daedalab looks very aligned with the gap your post highlights.