How do you stop an AI agent from deleting your data?

Why agents delete things they should not

OWASP names excessive functionality, excessive permissions and excessive autonomy as the usual root causes of Excessive Agency, the weakness that lets damaging actions follow unexpected or manipulated model output. Two of its examples apply directly to data loss. One is a read-only extension that connects with an identity that can also update, insert and delete. The other is a deletion tool that acts without asking the user to confirm.

So the failure is rarely that the model 'decided' to destroy data. It is that the system gave the model a path to do so. Anthropic's guidance adds that agents, where the model directs its own tool use, carry higher costs and the potential for compounding errors. That is why it recommends extensive testing in sandboxed environments along with guardrails.

The controls we put in place before an agent touches ERP, Tally or a customer database

• Narrow identity: the agent gets its own identity with only the permissions the job needs. OWASP says to enforce this through the database identity the extension connects with. AWS warns that a broad admin role granted for one task can spread permissions across the whole environment. A separate identity per agent also shows which agent did what and who authorized it.
• Authorization downstream: permission checks live in the ERP, database or API layer, not in the prompt. OWASP advises implementing authorization in downstream systems rather than relying on the LLM to decide whether an action is allowed.
• Soft deletes: in our builds the agent's 'delete' tool marks a record as deleted or moves it to a holding state. It does not remove it. Hard deletion is a separate step that the agent cannot call.
• Dry-run plan: before any write, the agent produces a list of the exact records and changes it intends to make. Nothing executes until that plan has been checked, by rule or by a person.
• Human sign-off on irreversible steps: OWASP recommends human-in-the-loop approval for high-impact actions. Anthropic notes that agents can pause for human feedback at checkpoints.
• Tested rollback: we run the undo path in a sandbox copy before go-live, so we know a restore works and how long it takes. A rollback that has never been run is a hope, not a control.
• Rate limits, logging and monitoring: these do not prevent excessive agency, but OWASP notes they limit the damage and give you time to notice before it becomes significant.

What to do when rollback is impossible

Some steps cannot be undone: a permanent purge, a record already synced to an outside system, a message already sent. Do not give the agent that step. Let it prepare the change and the dry-run plan, then have a named person run the action.

Treat backups the same way. In the reported TV4 case, the broadcaster denied that an AI agent deleted the edited footage and blamed a failed backup system at the production company. The edited season had to be re-edited from scratch. Whatever the cause, the lesson holds: a backup you have not restored from is not a rollback.

How to decide which steps need a human

Approving everything by hand causes review fatigue. AWS argues for letting the agent act alone where its actions can be verified and reserving human judgment for decisions that need it. Where rules cannot be stated precisely, it advises limiting access and actions, evaluating behavior, and sending genuine ambiguity to a person.

In practice, sort each action by whether it is reversible and whether a rule can check it. Reversible and checkable steps can run automatically with logging. Reversible but ambiguous steps go to a person at a checkpoint. Irreversible steps always need sign-off, or stay entirely manual. A human gate also limits damage from outside the system: Philadelphia police said their process requires human review of tips before follow-up, so an automated false submission did not bypass it.