Which Agent Actions Actually Need Human Approval

Most approval-gate advice collapses into a slogan: keep a human in the loop. That is not a policy. It is a hand-wave that lets an auditor nod along and a CFO wonder why an agent that was supposed to save 40 hours a week is still routing every action to a shared inbox. The concrete question, the one that decides whether your agentic program pays for itself, is narrower: which specific actions must a human approve, and which should the agent execute on its own.

The honest answer is that approval policy is an engineering decision, not a values statement. It falls out of three properties of each action the agent can take: how far a mistake propagates (blast radius), how cheaply it can be undone (reversibility), and how the action is treated by the regulators who will read your audit log after an incident. Get those three right and the same agent can run thousands of routine tickets untouched while still stopping cold before it wires money to the wrong counterparty.

What follows is the framework we use on production deployments, and the specific action types that fall into each tier.

Approval Is a Function of Blast Radius, Not Job Title

The reflex in most enterprises is to gate on seniority: anything an analyst does gets logged, anything a director does gets approved. Agents break that model because they act at machine speed across systems the org chart never described. An agent with a valid service token can issue a hundred consequential writes in the time it takes a reviewer to open the ticket. Gating on who the agent is impersonating is the wrong axis.

The right axis is per-action. For each tool the agent can call, you score two properties before it ever runs in production. Blast radius is the set of downstream systems, records, or counterparties that a single invocation can touch. Reversibility is the time and cost required to restore the prior state if the call was wrong. A read against a warehouse view has zero blast radius and trivial reversibility. A wire transfer has counterparty-wide blast radius and, for practical purposes, none.

OWASP frames the same idea from the failure side. Its Excessive Agency category identifies three root causes — excessive functionality, excessive permissions, and excessive autonomy — where high-impact actions proceed without human confirmation. The mitigation OWASP recommends is not more logging. It is human-in-the-loop approval for high-impact actions and a tool registry restricted to the minimum functions the agent actually needs.

Regulators arrive at the same conclusion from a different direction. Under Article 14 of the EU AI Act, high-risk systems must be designed with human-machine interfaces that allow natural persons to effectively oversee the system while it is in use, and the oversight must be commensurate with the risks, autonomy level, and context of use. That last clause is the one CIOs miss. It rules out both a rubber-stamp policy that approves nothing meaningful and a maximalist policy that approves everything and produces reviewer fatigue.

	Tier	Blast radius	Reversibility	Gate	Example actions
T0	None (read only)	N/A	None; log only	Warehouse reads, retrieval, classification
T1	Internal only	Cheap, minutes	None; idempotent write with replay	CRM stage update, Jira create, internal Slack
T2	External or monetary, bounded	Hours, no counterparty cost	Async human approval within SLA	Outbound email, small refund, non-prod merge
T3	Counterparty-wide or regulated	Costly or none	Synchronous, blocking approval	Wire transfer, prod DB write, PHI disclosure

Four Tiers, Each With a Concrete Action List

The tier model below is the one we default to on new engagements. It is not exhaustive, but it covers roughly 90% of the tool calls an enterprise agent will make. Every tool in your registry gets assigned to exactly one tier at deploy time, and the tier is versioned alongside the agent so an auditor can reconstruct which policy was live at 03:14 last Tuesday.

Tier 0: Autonomous, Log Only

Read-only calls with no external side effects. Warehouse queries, vector search, internal document retrieval, calendar reads, ticket enrichment, classification, summarization, drafting into a scratchpad the agent alone can see. Blast radius is bounded by the read scope of the credential. Reversibility is not a concept because nothing changed. Gating these is where reviewer fatigue is born; the appropriate control is a signed, append-only audit log entry per call and periodic sampling by a second agent or a human reviewer.

Tier 1: Autonomous, Reversible, Bounded

Writes to systems where the change is idempotent, cheap to reverse, and confined to internal state. Creating a draft email, updating a CRM stage, opening a Jira ticket, tagging a record, posting to an internal channel, scheduling a job in a queue. The agent proceeds without asking, but every write carries an idempotency key, is scoped by a short-lived token, and lands in a change feed a human can replay. This is the tier most enterprises under-populate, which is why their agent programs feel slow. If your agent has to ask before it can rename a folder, you have built a suggestion box.

Tier 2: Async Approval, Real Money or External Surface

The agent prepares the action, executes into a staging state, and holds for human confirmation within a defined SLA before the change becomes visible to the counterparty. Outbound customer emails, refunds under a dollar threshold, invoice postings, contract redlines, code merges into non-production branches, provisioning changes that a rollback script can undo within an hour. The gate is not synchronous; the agent can move to the next task. But nothing crosses the perimeter until a reviewer clicks approve or the SLA expires and the action is auto-rejected.

Tier 3: Synchronous Approval, Blocking

The agent stops. Nothing else happens on this task until a named human approves the exact payload the agent is about to send. Wire transfers, journal entries above threshold, production database writes, credential rotation, security group changes, PHI or PII disclosure to a third party, anything that triggers a regulatory filing, anything a compliance framework flags as requiring secondary authorization. The reviewer sees a dry-run diff, the decision lineage that produced it, and a one-click reject that rolls back any Tier 1 or 2 state the agent already touched in service of this task.

Reversibility Is a Property of the Tool, Not the Agent

A common mistake is to tier by workflow name. "Customer refunds" gets one policy, "vendor payments" gets another. That falls apart the moment the same underlying tool — a payments API, say — is called from three different workflows with three different risk profiles. The correct unit of policy is the tool invocation, scored by what the tool can do in the worst case, not by the friendly name of the workflow that happens to be calling it today.

Reversibility in particular is a tool-level property. It has two dimensions worth measuring separately: mechanical reversibility (is there an API to undo it) and practical reversibility (what does the undo cost, and does it require the counterparty's cooperation). A Slack message is mechanically reversible via delete but practically irreversible because the recipient has already read it. A database row update is mechanically reversible if you kept the prior value and practically reversible if no downstream system has read the new one yet. Score both, and set the tier from the worse of the two.

This is where action execution infrastructure earns its keep. The runtime, not the model, is what enforces idempotency keys, holds staged writes, captures the pre-image needed for rollback, and refuses to promote a Tier 2 action past the gate without a valid approval receipt. If any of that lives inside prompt instructions, you do not have a control. You have a hope.

Regulatory Exposure Overrides the Score

Blast radius and reversibility get you most of the way. Regulation supplies the override. Certain actions require a human decision-maker regardless of how small the blast radius looks on paper, because the applicable regime says a natural person must make or attest to the call. Adverse action notices under fair lending rules, medical necessity determinations, export-control classifications, SAR filings, actions that trigger a GxP signature, anything a supervisory authority has designated as high-risk under the EU AI Act. These sit in Tier 3 by policy, not by score.

The practical implication is that your tier assignment needs a second column: the regulatory citation, if any, that forced the tier upward from where the blast-radius score placed it. Auditors read that column first. So does the general counsel who has to sign off on the deployment. Missing citations are the fastest way to have a working agent pulled from production three weeks after go-live.

This is also where approval gates stop being a UI feature and start being an evidentiary record. Every synchronous approval writes a receipt that names the reviewer, the payload hash, the model version, the tool version, the policy version, and the decision lineage the agent used to propose the action. When the regulator asks who approved the wire on the 14th, the answer is a row, not a Slack screenshot.

How to Defend the Policy to the CFO

The CFO's question is the mirror image of the auditor's. If everything requires approval, why did we buy an agent. The defense is arithmetic. For each workflow, count the actions per run and their tier distribution. If a claims-triage agent takes twelve actions per case and eleven of them are Tier 0 or Tier 1, throughput is roughly unchanged from full autonomy even though a human still gates the twelfth. If it takes twelve actions and eight are Tier 3, the workflow is not a candidate for agentic execution yet; it is a candidate for process redesign, and honest human-in-the-loop analysis will say so out loud.

The corollary is that Tier 2 is the tier worth engineering hardest. Async approval with a well-designed reviewer queue turns most of the "we can't automate this because compliance said no" workflows into ones where the agent still does 95% of the work and the human does the 5% that matters. Batch similar approvals, present the diff not the raw payload, and set an SLA that auto-rejects on timeout so the queue cannot silently grow. A reviewer who spends nine seconds per approval and handles two hundred a day is not a bottleneck. A reviewer who has to reconstruct what the agent was thinking is.

What to Build Before You Ship

None of the above works without the runtime plumbing under it. Before an agent touches production, four things need to exist and be tested: a tool registry where each entry carries a tier and, where relevant, a regulatory citation; an approval service that can hold a staged action, present the diff, capture a signed decision, and either commit or roll back; an audit log that records the full decision lineage in append-only storage the agent cannot modify; and a kill switch that revokes the agent's credentials in seconds, not minutes. Skip any one of them and the tier policy is a document, not a control.

Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5% in 2025. Most of those deployments will fail their first serious audit not because the model was wrong but because nobody wrote down which actions the agent was allowed to take on its own and which it was not. Tiering is the small, unglamorous artifact that separates an agent you can defend from one you have to explain.

An agent that only suggests is a search box. An agent with no approval policy is a liability. The interesting engineering, and the interesting commercial outcome, sits in the middle: a tiered policy, enforced by the runtime, that lets the machine do the work it is safe to do and stops it cold the moment it is not.