Don't give it the means. An agent should hold no permission to delete records, drop tables or overwrite files, so nothing it is told or decides can remove data. Where its work involves deletion, such as tidying duplicates or handling an erasure request, it marks records for review and a person approves the deletion through a separate, logged process.
Why is deletion a special case?
Most mistakes can be corrected. A wrong address can be changed back; a wrong credit can be reversed. A deleted record, unless backed up and restorable, is gone, along with whatever evidence it held. Our answer on whether deleting data is an irreversible action explains why deletion belongs with the actions that are hard to undo.
Deletion also creates compliance exposure in both directions. Deleting records you must keep breaches retention duties; failing to delete when someone has a right to erasure breaches data protection law. Either way, a person should decide.
How does an agent end up deleting data?
Usually through tools that are broader than intended: a database tool that can run any statement, a file tool with write access to a shared drive, or a "clean up" capability. Then a misread instruction ("clear out the old test accounts"), a prompt injection or a loop does the rest. The agent does not need to intend harm.
What are the practical steps?
- Remove delete permissions. The agent's identity and its tools have no delete, drop or overwrite rights on any system. Check at the database, file store and application level.
- Replace delete with mark. Tools that would have deleted instead flag the record with a reason: "possible duplicate of 10442", "eligible for erasure under request 77".
- Route marked records to a person. The data owner reviews the flags and approves deletions in batches through the system's own process.
- Keep the history. Prefer designs where records are archived or marked inactive rather than physically removed, until retention rules say otherwise.
- Limit what the agent can see in the first place. An agent that cannot read a dataset cannot be steered into damaging it; see how to decide which data an AI agent may see.
- Protect backups. Backups must be out of the agent's reach and tested for restoration.
- Record every mark and every approval.
What may the agent do, and what stays with a person?
| Task | The agent | A person |
|---|---|---|
| Find duplicate customer records | Identifies and marks them (depth 2) | Approves merges and deletions |
| Handle an erasure request | Finds the person's data across systems and prepares a list | Decides what must be kept and approves the rest |
| Apply retention schedules | Lists records past retention | Approves the deletion run |
| Clear temporary files it created | Deletes within its own sandbox | None, if the sandbox is isolated |
| Drop or truncate a table | Nothing | Database administrator, through change control |
The sandbox row is the one exception. An agent may delete its own working files in an isolated environment that holds nothing else.
A worked example
Take a recruitment firm whose agent maintains its candidate database. A manager asks it to "remove everyone we haven't heard from in three years". Under the old design, the agent's database tool could run that deletion directly.
Under the new design, the agent marks 4,200 records as past the firm's retention period and lists them for the data protection lead. She spots that 300 belong to candidates in an ongoing employment tribunal matter, which the firm must keep. She approves deletion of the rest through the database's own retention job. The agent never held the power to delete, so the tribunal records were never at risk.
How does deletion relate to data leakage?
Both are failures of what an agent can reach. Leakage moves data out; deletion destroys it. The same narrowing of access and tools prevents both; see how to stop an AI agent from leaking customer data.
Which controls make the answer hold?
- No delete rights for any agent identity.
- Mark-for-review tools in place of delete tools.
- Deletions approved by the data owner, through the system's own process.
- Backups out of reach and restorable.
- Every mark and approval recorded.
The topic guide, agent governance is a bound, not a model, explains why the bound, not an instruction to be careful, is what protects your data.
Questions people ask
Can an agent ever be trusted to delete routinely?
Rarely, and only for narrow, well-tested cases with restorable backups. Most firms keep deletion with people because the saving is small and the downside is permanent.
What about overwriting a field?
Overwriting loses the old value unless history is kept. Prefer systems that keep a change history, and treat bulk overwrites like deletions.
Does a right to erasure mean the agent should delete quickly?
It means the business must act within the required time. The agent can make that faster by finding the data; a person still decides what is deleted and what must be kept.