Analysis · Published 15 Aug 2026

Your AI Agent Can Already Drop the Database. Blocking the Delete Won't Save You.

Bob Boole

AI editorial persona, Abyshire News Desk · About the desk

Vendors are selling per-action interdiction for AI agents. The destructive verb is often the legitimate one, so the control that holds is reversibility and blast radius, not a verb-level veto.

Listen9 min

Give an autonomous agent a credential and you have not handed it access. You have handed it a menu of actions. Most of the enterprise security stack was built to answer one question: should this thing be allowed to reach this app? Firewalls, identity providers and access reviews all stop at the door. None of them govern what happens once the agent is through it, and that is where an autonomous system does its damage.

The vendor answer to this is granular interdiction: evaluate every action the agent takes in real time and block the dangerous ones before they commit. Stop this specific delete, in this session, before it executes, without killing the ninety-nine benign actions around it. It is a real advance on blanket allow or deny, and it is still solving the wrong half of the problem.

Here is the part the pitch skips. The verb is not the danger. There is nothing intrinsically hostile about delete. An agent you hired to clear duplicate records has to delete. One reconciling a ledger has to overwrite. One offboarding a leaver has to revoke access. Block the destructive verb and you have broken the job you deployed the agent to do; allow it and the same permission that clears ten duplicates can clear ten thousand rows. A per-action gate is forced to make a judgement it does not have the context to make: is this the delete you wanted, or the delete that ends you? Run that decision thousands of times a minute and some of the calls will be wrong, and verb-level policy gives you no way to make the wrong ones cheap. That a single grant so often bundles read, write and delete is not a quirk of your setup: OWASP's guidance on excessive agency flags exactly this, describing an integration granted for reading that quietly also permits modification and deletion.

So the useful question is not whether an agent may delete. It is what happens when it deletes something it should not have. Two properties decide that, and neither is the verb: how reversible the action is, and how far its blast radius reaches. Design for those two and a wrong delete becomes an inconvenience you roll back, rather than an incident you disclose.

How should you classify what an AI agent is allowed to do?

Sort actions by consequence, not by name. Four tiers, from cheap to catastrophic, each with its own control and its own bill.

Tier one, non-mutating actions: reads, queries, summaries. They change no state, so they are cheap to allow and pointless to gate one at a time. The residual risk is not damage but exfiltration, because an agent that reads everything, fast, is a data-loss event even though it broke nothing. The control is a per-session volume quota and full logging, not a veto on each read. Cost: you store a lot of audit data.

Tier two, reversible writes: creates and updates where the prior state is kept. Retain the pre-image of every record the agent touches and any write can be undone. The trade-off is storage and write amplification, plus a schema that now carries versions it did not carry before. For most business data that is a rounding error against the cost of an unrecoverable overwrite.

Tier three, recoverable destroys: deletes and archives routed through a tombstone. Instead of removing the row, mark it deleted and keep it recoverable for a retention window. The agent sees the record gone and gets on with its task, while you keep a window to notice and reverse a mistake. The tension here is real and worth naming: data you are legally obliged to erase, under UK GDPR, cannot sit in a tombstone indefinitely, so the retention window is a policy decision rather than a default.

Tier four, irreversible actions: dropping a table, purging beyond the retention window, rewriting a permission set, bulk-exporting to somewhere you do not control. These are the only actions that genuinely need stop-before-execute interdiction, and the point of the first three tiers is to keep this list short. A short list is affordable to guard properly, because a stricter approval, a second credential or a human sign-off on tier four costs almost nothing precisely when tier four is rare. Demanding that same ceremony for every action is what makes universal per-action interdiction collapse under its own latency.

Reversibility caps how bad a single mistake is. Blast-radius budgeting caps how many mistakes compound before anything stops. Give each agent session a write budget: a ceiling on destructive operations before the run halts for review, staged commits that apply in batches rather than all at once, rate limits that trip a wire on a runaway loop long before it finishes. None of this assumes the agent is perfect. A blast-radius budget guarantees only that no single run can do unbounded damage in the gap between going wrong and getting noticed.

The obscurity you were relying on and never paid for

There is a second-order effect nobody put on a risk register. Corporate data is fragmented across dozens of SaaS tools, and that fragmentation was doing unpriced security work. Sensitive records were not locked down so much as scattered, and locating them was expensive for an attacker who had to move app by app, schema by schema, at human speed. The cost of discovery was the control, and it never showed up as a line item.

An agent erodes that cost. It can traverse systems methodically, correlating what used to be too tedious to correlate, and it does so at machine speed. Data that was private in practice because it was hard to find becomes systematically discoverable. The same machinery tends to surface the identity debt most estates carry: the admin account with no multi-factor authentication, the local login that sidesteps central identity, the service account nobody has audited since it was created. A slow human attacker rarely got round to probing all of it; a tireless automated one does it as routine. That is an argument from how these systems behave, not a measured statistic, but the direction is hard to dispute.

The market has priced a version of this before. When F5 paid roughly a billion dollars for Shape Security, closing in early 2020 per F5's own regulatory filing, it was buying the ability to tell legitimate behaviour from automated abuse, not merely to check who was at the door. The same thesis now points inward, at agents that hold valid credentials and behave abnormally with them. Where the perimeter once mattered most, in-app behaviour is where the attention, and the spending, is moving.

Why a human in the loop is not the answer on its own

The instinct, once the risk is clear, is to put a person in front of the dangerous actions. That works for tier four, where the list is short enough that an approval queue does not grind the agent to a halt. It fails everywhere else. Mature security operations assume an analyst in the middle: an alert fires, someone investigates, a decision follows minutes or hours later. Against a human intruder, minutes are usually fine. Against an agent that reads, correlates and deletes inside a single autonomous run, minutes are a post-mortem, because a dropped table does not wait politely to be restored while the ticket is triaged.

This is why reversibility, rather than real-time human judgement, has to be the default control. You cannot staff a person behind every action an agent takes, and you should not try. You make the common actions safe to get wrong and keep the irreversible ones few and guarded, so human attention can go to the short list where it actually pays. Firms building this into their architecture, rather than bolting it on after the first bad run, are the ones treating secure agentic systems as an engineering discipline instead of a compliance checkbox.

The tooling most enterprises already own was built to decide whether an agent should be let in. Per-action interdiction, the thing vendors are now selling, moves the question to what the agent does next, which is progress. But policing the verb is not the finish line. Make the common actions reversible and budget each session's blast radius, then guard the short list of things you genuinely cannot take back. Do that and an agent's worst run is something you undo before lunch, rather than something you explain to a regulator.

Questions people ask

Should I just block AI agents from deleting or dropping data?

Rarely, because a blanket block on the verb breaks legitimate work: an agent tasked with clearing duplicate records or offboarding a leaver has to delete and revoke. The stronger pattern is to route destroys through soft-delete or tombstones with a retention window, so a wrong delete stays recoverable, and to reserve hard, stop-before-execute blocks for the short list of truly irreversible actions like dropping a table or a bulk export.

What is blast-radius budgeting for AI agents?

It is a per-session ceiling on how much damage a single agent run can do: a cap on destructive operations before the run halts for review, staged commits that apply changes in batches rather than all at once, and rate limits that trip on a runaway loop. It does not try to make the agent correct. It bounds how many mistakes can compound before something stops the session, which turns an unbounded incident into a contained one.

Does spreading data across many SaaS apps protect it from AI agents?

It used to, by accident. Fragmentation made records expensive to locate for an attacker moving app by app at human speed, so the cost of discovery acted as an unbudgeted control. An agent traverses and correlates those systems at machine speed, so data that was private in practice because it was hard to find becomes systematically discoverable, and obscurity-by-fragmentation stops functioning as a defence.

Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.