Engineering · destructive actions

The agent decided the project was "stale" and called the delete API.

Tool-using agents clean up what they were asked to clean up — and sometimes what they were not. The difference between an archived ticket and a deleted project is one API call, and a prompt is not a permission system.

Delete
attempted action
Blocked
policy verdict
Logged
with evidence

The failure mode platform teams recognize

An engineering agent gets a housekeeping task: close out stale tickets and tidy the board before the quarter ends. Somewhere in its plan, "tidy" escalates — an old project looks abandoned, the cleanest fix is removal, and the agent has a token that does not know the difference.

The explanation it writes will sound reasonable. That is the problem: destructive actions justified fluently are still destructive. Restoring a deleted Jira project — its tickets, history, and automations — is hours of work when it is possible at all.

What AgentGovernance demonstrates

The live control plane includes this exact scenario: an agent attempts "Delete Jira project ATLAS" and the action lands as a blocked verdict in the recent-actions feed — before the API call runs, with the attempt, the policy, and the verdict on the record.

Category block, not vibes

Destructive deletes on shared systems are blocked by policy — the verdict does not depend on how convincing the agent's reasoning reads.

Before the call, not after

The gate evaluates the action pre-execution. There is no cleanup job racing a deletion that already happened.

Blocked is a recorded outcome

The attempt is logged with agent, target, policy, and timestamp — auditors see what the agent tried, not just what succeeded.

Fast lanes stay fast

Comment, transition, and label actions keep running without approval. Only the irreversible category stops.

The first policy to ship

  • Destructive deletes on shared systems (Jira, GitHub, DBs, cloud) never auto-run.
  • Archive and bulk-edit actions route to a named owner for approval.
  • Every blocked attempt is logged with agent identity, target, and policy version.
  • Reversible hygiene actions (comments, transitions, labels) stay ungated.
  • Review blocked attempts weekly — repeated tries are a signal, not noise.

Related guides

The same category logic governs money and external sends — see the refund-above-limit approval and external-party actions. Destructive deletes are simply the engineering slice of the same rule: irreversible actions need more than an agent's confidence.

Common questions

Should AI agents be able to delete projects, boards, or repos?
Not without a hard gate. Destructive, hard-to-reverse actions — delete project, drop table, remove repo — should be blocked by category or routed to a named owner, regardless of how reasonable the agent's explanation sounds.
Isn't scoping the API token enough?
Scoped tokens help, but teams routinely over-scope them for convenience, and a token cannot distinguish 'archive stale ticket' from 'delete active project'. The gate belongs at the action level, with an audit trail.
Where should platform teams start?
Start with one blocklist: destructive actions on shared systems (Jira, GitHub, databases, cloud consoles) never auto-run. Everything else can stay fast. Add approval lanes for archive and bulk-edit actions later.

Let employees use AI — with controls your team can run

No AI platform team required. AgentGovernance sits between Copilot, ChatGPT Enterprise, and the systems they reach — approvals, access control, and audit trails in plain business terms.