What to Set Up Before an AI Agent Can Delete Something

The destructive AI agent stories all have the same shape. An agent is given a job and the access to do it. It encounters a situation nobody anticipated. It takes an action that is locally reasonable and globally catastrophic — dropping a database while "cleaning up", moving files that were live in a client presentation, merging code that looked right.

In every case the agent did what it was told. What was missing was a rule about what it must never do without asking, and that rule was missing because nobody had written it down before granting the access.

Guardrails are a design step, not a reaction

The instinct after an incident is to add a rule about the specific thing that went wrong. That produces a growing list of prohibitions that always trails the next failure by one incident.

The alternative is to define the boundary before the agent runs, from the direction of consequence rather than the direction of behaviour. You don't need to anticipate what it might do. You need to enumerate what you couldn't undo.

The four categories worth a checkpoint

Almost everything irreversible falls into one of these:

Delete. Files, records, branches, rows, messages. Deletion has no undo in most systems, and an agent tidying up has no way of knowing which of two identical-looking files is the one in active use.

Send. Email, messages, posts, notifications. Once it reaches another person, it's happened — and the damage is reputational, which no rollback addresses.

Spend. Purchases, subscriptions, API usage, provisioning. Cheap individually, unbounded when a loop goes wrong.

Grant. Adding access, changing permissions, sharing a link publicly. The worst category, because it converts one agent's mistake into a standing exposure.

If an action is in none of these, let the agent do it freely. The point of naming them is to stop applying friction everywhere — an agent that asks permission for everything gets its permissions widened by an exhausted human within a fortnight.

Write the rule as a sentence, not a setting

The useful form is specific and negative: never move files referenced in an active project folder. Never send to an external address. Never delete anything modified in the last seven days.

Vague guidance — "be careful with deletions" — has no failure mode the agent can detect. A specific negative rule does.

The test: could a new colleague follow this rule without asking you what you meant? If not, an agent can't either.

Ramp supervision like a new hire

The workable pattern isn't a permanent choice between supervised and autonomous. It's a ramp:

• Days one to three: the agent proposes, you approve everything. You're not checking the work — you're discovering which situations you failed to anticipate.
• Week one: spot-check. Approve the irreversible categories, let the rest run.
• Ongoing: the four categories keep their checkpoints permanently. Everything else runs.

Most people skip straight to the third stage because the first two feel slow. The first two are where the rules you didn't know you needed get written.

Tomas — the tidy-up that wasn't

Tomas manages IT for a 140-person architecture practice. He gave an agent access to reorganise a shared drive by naming convention, which had been an intern job for years.

Three days in it moved a set of files that were linked from a live client presentation. The links broke mid-meeting. Nothing was lost — the files still existed — but the client saw it happen.

The rule that would have caught it is one sentence: never move a file referenced from outside its own folder. Tomas hadn't written it, because until it happened it wasn't a category of thing he thought about.

He now requires a written scope before any agent gets write access, and the scope has one mandatory line: what should this never do without asking me?

Ines — the checkpoint that was a formality

Ines runs a licensing team in local government. Her workflow had an agent drafting decision letters with an officer approving each before sending — a control that worked for eight months.

Then the officer who designed it changed roles. Her replacement treated approval as a formatting check, because nobody had recorded that the step existed to independently verify the reasoning. Two letters went out with conditions that didn't match the application.

The control had never been a control. It was one person's understanding of why a step existed, and it left when she did.

The one thing

Every destructive agent story is a guardrail that didn't exist yet, written afterwards.

Delete, send, spend, grant. Four words, one sentence each, written before the access is granted rather than after the incident. That's most of the work.