Which agent actions actually need your approval?

Your coding agent asks permission before changing one file.

The same class of agent may already be allowed to read a private inbox, use a logged-in browser or call a connected tool.

The visible approval is attached to the action verb. The real risk may sit somewhere else.

This is how an operation ends up reviewing harmless edits while broad standing permissions escape serious examination. “Edit” looks consequential. “Read” looks safe. “Deploy” may have a rollback button. “Change permissions” can be revoked. None of those verbs tells you enough to decide where a person belongs.

Singapore's Model AI Governance Framework for Agentic AI makes the same problem visible in one of its case studies. Tencent's CodeBuddy requires no approval to read files, but it sets approval rules for edits, shell commands, network requests and external tools. The duration changes too: one session, one project, one command or a fresh check when the action becomes suspicious.

That is already more useful than “keep a human in the loop.” It asks where the loop should close.

But it still leaves an operator with the hard part: how do you classify an action before the first incident tells you the answer?

The shortcut we tested

The cleanest rule is reversibility.

If the complete effect cannot be restored, require approval. Sending a message, making a payment and publishing a page all qualify. Deleting an object may justify a stronger rule: the agent prepares the action, but a person executes it.

If the effect can be restored, let the agent proceed and keep a log.

The rule is attractive because anybody can use it. It also has a strong practical basis. IMDA lists irreversible actions among the significant checkpoints that should require human approval. Its examples include permanently deleting data, sending communications and making payments.

We put that shortcut against a second classifier from Tenex's Citizen SDLC. Tenex scores blast radius across four dimensions:

1. reach and capability: what can the system touch, and can it read, write or execute?
2. reversibility and autonomy: can the effect be undone, and how much of the path can the agent choose?
3. exposure: who sees the result, and how far does it travel?
4. data sensitivity: what kind of information does the action touch?

We then enumerated 28 action classes from a live operating system that researches, drafts, publishes, observes responses and maintains commercial records. We scored every class twice. Under the four-dimension rule, any HIGH dimension created an approval boundary. The thresholds and the full inventory are recorded with the result.

The two rules did not select substantially the same set.

Reversibility alone selected 11 of 28 action classes.

The four-dimension rule selected 19 of 28.

Eight reversible classes crossed another threshold. Reversibility missed 42% of the fuller classifier's approval set.

The reversible actions that changed the result

Three examples carry most of the argument.

Reading a private inbox. The action changes nothing and is completely reversible in the narrow sense. But the data-sensitivity dimension is high. The right boundary is not a prompt before every email. It is scoped standing access to named accounts, fields and purposes, with an audit trail.

Changing permissions. The permission can be revoked. That does not make the change low-risk. For the period in which it exists, it expands what the agent or another identity can reach. A revocable high-privilege grant still deserves exact approval or human execution.

Deploying versioned code. A rollback exists, so a reversibility-only rule can let the action through. Production reach and public exposure still cross the threshold. The appropriate boundary may be an exact pre-approved release through a guarded pipeline, not a person approving every build command.

Five other classes produced the same disagreement: reading credentials or using a logged-in session, running broad shell or computer control, writing personal relationship data into a CRM, changing the rules that govern future agent behaviour, and modifying a recurring scheduled task.

All can be undone. All can do meaningful damage before they are undone.

That is the mechanism the shortcut misses. Reversibility asks about recovery. Approval also has to ask about reachable power during the interval before recovery.

Approval is not one button

The usual argument gives you two bad choices: ask a person every time, or remove the person.

The comparison produced five more useful states:

1. Auto with a log. Use it when every dimension stays inside the agreed boundary.
2. Scoped standing approval. Approve a stable tool, data source, account or command class once. Monitor the boundary, not every execution.
3. Exact pre-approval. Approve the precise copy, release or artifact upstream. Execution may then be automatic and verbatim.
4. Per-action approval. Use it for external messages, unusual commands and commitments whose context changes every time.
5. Human-only. The agent may prepare the action but cannot execute it. Deletion can live here.

This avoids the approval queue Tenex warns about without pretending every action inside an undoable system is safe. The person is spent on the boundary, and deterministic policy handles the routine path once that boundary is clear.

The four questions to use on Monday

List actions, not job titles and not agent names. “Customer-service agent” is too broad. “Read a customer record,” “change the delivery address,” “issue a refund” and “send the confirmation” are four different rows.

For each row, ask:

1. What can this action reach or change?
2. Can its complete effect be restored, including obligations and what another person has already seen?
3. Who can receive or observe the result?
4. Does it touch private correspondence, personal data, confidential operations, secrets or regulated data?

If any answer crosses your high threshold, choose an approval boundary before the action class. If no answer does, allow it inside a named scope and log it. If the action is unknown or the classification is uncertain, deny it until somebody classifies it.

The threshold is an operating decision, not a universal constant. A prototype with synthetic data and no production credentials should not inherit the same settings as a system that can reach payroll, customers or infrastructure.

The principle is smaller and more durable:

Reversibility is a veto, not a complete classifier.

If an action cannot be fully undone, it needs a checkpoint. If it can be undone, you still have three questions left.