Which Agent Actions Need a Human to Approve Them

The simplest safety rule for an agent is also the most tempting: have a person approve every action it takes. It sounds careful. In practice it fails in one of two ways. Either the agent is so slow that nobody uses it, or the approvals arrive so often that people stop reading them. Neither protects anything.

The better question is not whether a human should be involved, but which actions justify the interruption. A small number of decisions can carry nearly all the risk, and most of an agent's work can run without a gate if the right things are recorded.

Why approval is not a single switch

An agent's actions differ on two axes that matter for approval.

Reversibility. Can the action be undone, and at what cost? Reading a file is free to repeat. Drafting an email can be discarded. Sending it cannot be recalled.

Reach. Does the action affect only your system, or does it touch people and systems outside it? A change to an internal dashboard is contained. A message to a customer is not.

Put together, these give a rough map. The actions in the top-left, reversible and contained, can usually run freely. The actions in the bottom-right, irreversible and external, almost always need a person. The middle is where judgement is needed, and where most of the design work sits.

Sort the actions first

Start from the list of tools the agent can call, which the inventory in the security note already asks for. For each one, decide its class:

Class	Examples	Approval	Why
Read	Search, fetch, look up a record	None	Repeating a read is harmless
Draft	Write a reply, prepare a report, propose a change	None, but reviewed before use	Nothing has happened yet
Internal reversible write	Update a ticket, add a note, change a draft status	None, with a log and an undo path	The change can be reverted
Internal hard-to-reverse	Delete a record, close an account, change a permission	Approval, with the specific change shown	Recovery is costly
External or irreversible	Send to a customer, pay, publish, deploy	Approval every time	Cannot be recalled

Most agents have far more actions in the first three rows than the last two, which is the reason a blanket rule feels wrong. Gating the first three rows buys little safety and costs a great deal of usefulness.

Why the middle rows are the hard ones

Consider an agent that updates customer records. Changing a phone number is reversible in principle, since the old number can be restored. But if the wrong number is written and an automated process then sends a message to it, the change has already escaped. Reversibility depends on what happens next, which the agent may not know.

This is why the classification should consider downstream effects, not just the immediate tool. A useful test is to ask, for each action, what else could read or act on its result before a person could notice. If the answer is "something external", the action belongs higher up the table, whatever its own mechanics.

Tools that the agent calls in a loop can compound this. An agent that sends one message is a gate problem. An agent that sends a hundred in a minute is an incident. Rate limits and batch caps are a second layer that works even when every individual action looks safe.

The approval itself

A gate only helps if the reviewer can judge the request. A screen that says "the agent wants to continue" gives them nothing. Each approval should show:

1. The exact action, in plain terms, such as "send this message to this address".
2. The parameters, in full, including anything the agent changed from the original request.
3. The target, meaning who or what will be affected.
4. What will change, including what cannot be reversed.
5. The agent's stated reason, kept short and checked against the evidence it cites.

The last item deserves caution. A model's explanation for an action is a claim, and it can be wrong or manipulated. The reviewer should be able to see the underlying data, not only the agent's summary of it. This is the same concern behind why an agent's own account of what happened is not evidence.

Approval also needs to be specific. A blanket permission granted once, such as "the agent may send emails", is not an approval of any particular email. It is a standing grant, and it is exactly what a manipulated agent would exploit. Each gated action should need its own decision, or at least a decision bounded by recipient, content category and volume.

Approval fatigue is a real failure mode

When people are asked to approve many routine requests, their attention drops. Each new request looks like the ones before it, and the reflex is to click yes. A dangerous request, if it arrives among a hundred harmless ones, gets the same reflex.

The defence is to keep gates rare. Every gate you add dilutes the others. If a team is seeing dozens of approvals an hour, the answer is almost never to ask them to pay more attention. It is to move most of those actions into the reversible classes and keep the gate for the few that matter.

It helps to measure the approval rate. If reviewers approve nearly every request for an action without changes, the gate may be unnecessary for that action, or the screen may not be giving the reviewer what they need to say no. Either is worth checking.

What the agent should do while waiting

An agent that stops at a gate should not simply hang. It should record what it intended, what evidence it has, and what it will do on approval or rejection. If the approval is refused, the agent should return to the user with a clear explanation rather than trying a different route to the same action.

That last point matters. An agent that is refused one tool and then tries a second tool that achieves the same effect has defeated the gate without anyone deciding to. Gates should be defined by the effect, not by the name of the tool.

Consider an agent that handles refund requests. Looking up an order is a read. Drafting a reply to the customer is a draft. Issuing a refund below a small amount might be an internal, reversible write with a log entry. Issuing a refund above that amount, or to an account that has changed recently, is an external and hard-to-reverse action, and it belongs behind a gate that shows the amount, the account and the reason. The same agent therefore needs four different treatments, and the classification is what makes that possible.

Logging is the other half

Every action, gated or not, should leave a record a person can read later: what was called, with which parameters, what came back, and who approved what. Many agent problems are not visible at the time they happen. They surface days later, when someone asks why a message went out or a record changed. Without the record, there is no answer.

The record also teaches you where the gates belong. If a review of logs shows that an ungated action caused a problem, move it up the table. If a gated action was approved every time for a month, consider moving it down. The classification is a hypothesis, and the logs are how you test it. The same logging discipline is behind most agent failures never throwing an error.

Test the gates like features

Treat gates as code with tests. Write scenarios where the agent is steered towards a harmful action, using instructions hidden in a document or a tool result, and check two things. The gate should stop the action. And the request shown to the reviewer should be accurate, with the real parameters and target, not a sanitised version.

Include scenarios where the agent should not be stopped. If the gate fires on harmless reads, that is a sign the classification is wrong, and users will route around it.

A starting configuration

For a typical business agent, a reasonable first setting is:

• Reads and drafts: no gate.
• Internal reversible writes: no gate, with logging and an undo path.
• Internal hard-to-reverse actions: gated, with the exact change shown.
• Anything that reaches a customer, a payment, or the public: gated every time.
• Rate limits on every write tool, regardless of class.

Adjust after a month of logs, not before. The first version is a guess about your system, and the logs will show where it was wrong.

What we do not know

We do not know a reliable way to decide, in advance and for every action, whether it is safe to run without review. The classification here is a method for making that judgement explicit, not a guarantee. We also have limited public evidence on how approval-gated agents perform over long periods in production, including whether reviewers keep paying attention. The honest position is that gates reduce risk where they are placed well, and that where they are placed is itself a decision to be reviewed as the system changes.