Guardrails Before Destructive Automation

The most dangerous line of code an agent or script can run is a delete. A cleanup routine meant to remove test data can, with one unapplied filter, sweep away real records instead. When a query that should be scoped comes back unscoped, “delete everything returned” becomes catastrophic. Treat any automated deletion as guilty until proven safe.

Build the guardrails into the destructive path itself, not into your good intentions. Require an explicit, non-empty filter before a delete can execute — fail closed if the scope is missing. Add a dry-run mode that prints the exact records to be affected and a count, and gate real execution behind a sanity threshold: if a “cleanup” is about to touch far more rows than expected, halt and ask a human.

Know your undo story before you need it. Many systems have no self-serve restore, and backups age out fast, so recovery is a race against retention windows. Before running anything irreversible, confirm whether it can be reversed and how long you have.

When it does go wrong, own it fast and plainly: stop all related automation immediately, preserve the exact list of what was affected, open the time-sensitive recovery path first, and give the affected party a straight, apologetic heads-up. Speed and honesty limit the blast radius more than any explanation.