title: What an AI Agent Should Never Do Without Asking
date: 2026-09-24
slug: 2026-09-24-what-an-ai-agent-should-never-do-without-asking
summary: Most teams draw the autonomy line task by task and re-argue it forever. Sort actions by whether they can be undone instead, and the line draws itself once.
tags: guardrails, agentic-ops, permissions, buyers-guide

# What an AI Agent Should Never Do Without Asking

The question people ask is "how much should the agent be allowed to do." That framing produces an endless negotiation, because every new task arrives as a fresh argument with no precedent to lean on.

The better question is "what happens if this is wrong." Sort actions by that and the boundary stops being a matter of taste. Reversible things get autonomy. Irreversible things get a gate. You draw the line once and new tasks classify themselves.

## Reversibility is the whole criterion

A reversible action can be undone by the same agent, in about the same amount of time, without anyone else being involved.

Editing a file under version control is reversible. Restarting a service is usually reversible. Writing a draft, updating internal notes, generating a report, reorganising a queue: all reversible. If the agent gets these wrong, the cost is a little wasted time and the fix is another turn of the same loop.

An irreversible action has left the building. Not hard to undo: genuinely impossible to undo unilaterally, because someone else now has it, or the thing it destroyed is gone.

The test I use: can the agent take this back by itself, right now, with nobody else finding out it happened? If yes, no gate. If no, gate.

That last clause matters more than it looks. A sent email can technically be followed by a correction, but the recipient has already read the first one. The action is not reversible, it is merely apologisable. Those are different categories and conflating them is how teams end up with an agent that "only did something recoverable" to a customer relationship.

## The four categories that always get a gate

In practice everything irreversible falls into one of four buckets, and it is worth naming them explicitly rather than trusting judgement in the moment.

*Money movement.* Payments, refunds, invoices, subscription changes, anything touching a payment processor. Money leaving is the canonical irreversible act. Note this includes actions that only commit to money later, like agreeing to a price or accepting a scope of work. The transfer is downstream but the commitment is the point of no return.

*Outbound communication.* Anything reaching a human outside the team. Email, customer messages, public posts, anything with an audience. The gate is not about the agent writing badly. It is that a received message cannot be unreceived, and the damage from one bad external message is unbounded in a way that no internal mistake is.

*Data deletion.* Dropping tables, deleting records, purging files, force-pushing over history. Soft-delete with a retention window converts this to reversible and is worth building precisely for that reason. Hard deletes stay gated forever.

*Access and permission changes.* Granting access, rotating credentials, changing firewall or IAM rules, modifying the agent's own permissions. This last one is special: an agent that can widen its own access has no meaningful limits at all, because every other limit becomes a thing it may edit. That gate is structural, not a policy preference.

Everything else, by default, is autonomous. The list of gates should be short enough to remember without looking it up, because a boundary nobody can recite is a boundary nobody enforces.

## Make gated things rarer instead of making gates looser

The instinct when gates slow you down is to loosen them. The better move is to shrink the irreversible surface so fewer actions qualify.

Soft deletes instead of hard deletes. Drafts that queue for a single click instead of sending directly. Staged changes with a rollback path. Every one of these converts an action from gated to autonomous without weakening anything, because the undo genuinely exists now.

This is the highest-leverage work in agent operations and it is consistently underrated. A gate is a tax on every future execution of that action. An undo path is a one-time build that removes the tax permanently. Teams that feel slowed down by approvals have usually been paying the tax for months without pricing the alternative.

## What the gate should actually look like

A gate is not a pause for a vibe check. It should present a specific proposed action, in full, with whatever detail is needed to say yes or no.

For a record change: the record, the current value, the new value, when it takes effect. For an outbound message: the exact text, the recipient. For a payment: amount, destination, reason.

Two properties make the difference between a real control and a rubber stamp.

The agent does not act until the answer arrives. Obvious, and still the most common failure, usually in the form of acting first and reporting after. An after-the-fact notification is a log entry, not an approval.

Silence is not consent. If nobody answers, the action does not happen. An agent that proceeds on timeout has a gate that fails open, which is the same as no gate on exactly the days when everyone is too busy to look.

One more rule that sounds pedantic and is not: a casual instruction is a proposal, not an authorisation. When someone says "just drop that to twelve" in passing, the right move is to restate the exact change and wait for a clear yes. Ambiguity resolved in favour of acting is how irreversible mistakes get made with everyone's apparent blessing.

## Why this holds up

The reversibility line survives contact with new situations, which is the only real test of a policy. A task nobody anticipated still sorts cleanly, because "can this be undone" is answerable without knowing anything about the domain.

It also puts the gates where the actual risk is. Task-based permission lists tend to gate whatever felt scary when the list was written, which means they gate unfamiliar things rather than dangerous ones. Familiar and irreversible is the combination that hurts, and only the reversibility framing catches it.

Draw the line at "can this be taken back." Then spend your effort moving actions across it by building the undo, rather than arguing about which side each one belongs on.

This taxonomy, and the gate mechanics that go with it, is one of the permission patterns in [One Agent, One Company ($9.97)](https://opsbyagent.com/book). Worth a read if you are deciding what your own agent gets to do unsupervised.