Backups are a recovery tool. They assume something breaks, you notice, and you restore. Every part of that assumption weakens when the thing touching your infrastructure is an AI agent running unattended.
The gap between failure and detection
A failed disk announces itself. An AI coding agent with over-scoped database credentials does not. It executes a migration that drops a column, the application keeps serving requests, and nobody notices until a customer reports missing data — potentially days later, well past your backup retention for the state you actually wanted.
Backups are not immutable by default
If the credentials an agent holds can reach your backup storage, your backups are part of the blast radius rather than protection from it. This is what Object Lock and write-once storage policies exist to prevent, and it is almost never configured on a default hosting setup.
Scope is the real control
The meaningful protections happen before anything needs restoring:
- Credential scoping. An agent that only needs to read staging data should hold a key that can only read staging data. Most tools are handed far more access than their task requires, simply because it is faster to set up.
- Environment isolation. Agents that generate or modify code belong in an air-gapped sandbox, not connected to the same database serving live customers.
- Human-in-the-loop gates. Destructive operations — schema changes, bulk deletes, deploys — should require an approval step that a runaway automation loop cannot satisfy on its own.
Restoring is the expensive path
Recovery from backup costs downtime, data loss between snapshots, and the time to work out what actually happened. Scoping costs an afternoon of configuration. The economics are not close.
None of this argues against backups — keep them, ship them off-site, and test the restore. Just do not mistake them for a guardrail. They are what you fall back on when the guardrails were never there.