Human Approval Boundaries in AI Agents: Which Actions Need a Person?

Human approval in AI agents is a control over specific proposed actions, not a general promise that a human is somewhere in the loop. A model may draft an action, but the application must decide whether it can execute, must wait for a named reviewer, or must refuse it. This guide gives a practical decision tree and approval record for a business pilot. The examples are synthetic design examples, not deployed client results.

For the broader choice of an implementation partner in Armenia, see the AI specialist page. Here the question is narrower: where should an agent stop before it changes the world?

Start with the business action

Imagine an agent that reads support requests and drafts a CRM update. It can classify a request and prepare a suggested field value. Writing the field changes a shared record; sending a reply contacts an external person; deleting a record may be hard to reverse. These are different permissions even when they come from one user instruction. Define the owner, affected system, data class, maximum impact and accepted outcome for each action.

An approval boundary should live immediately before the side effect. Approval of a task outline does not automatically authorize every later tool call. A new target, changed payload, expired deadline or revoked access requires a fresh decision. The tool calling guide describes the execution adapter; the state and memory guide explains why a remembered approval is not an authority.

Options before adding an approval queue

Read-only assistant. Let the model retrieve and explain, with no write-capable tool. This is suitable when a useful outcome is a summary or recommendation.

Deterministic workflow. If conditions and actions are known, use ordinary rules and reserve human review for exceptions. A model may extract structured inputs without deciding permission.

Draft-and-review agent. The agent prepares a diff, recipient list or proposed message. A reviewer sees the exact target and payload before an independent service executes it.

Bounded automatic action. Some reversible, low-impact operations can run within explicit limits: a test environment, small budget, allowlisted destination and a verified rollback. Define those limits in code rather than in a prompt.

Original decision tree: APPROVAL-GATE-7

This seven-gate design is an original planning aid, not a safety certification. Apply it to each proposed tool call, including retries.

Approval is mandatory for financial transfers, credential or permission changes, deletion of production data, publishing, and messages to external recipients unless a separately authorized policy explicitly defines a narrow automatic route. A human click alone is not enough: the UI must show the action, target, diff, relevant context and likely effect.

Approval record and execution contract

Store the approval outside model memory. Bind it to actorId, tenantId, tool, target, payload digest, policy version, reviewer identity and decision time. Set an expiry and record whether the approval is single-use. At execution, recompute the digest and check current permissions and target version. A changed draft cannot reuse an earlier approval.

async function route(proposal: Action, context: Context) {
  if (!policy.allows(context.actor, proposal.tool, proposal.target)) return "deny";
  const risk = classifyImpact(proposal);
  const snapshot = await destination.readVersion(proposal.target);
  if (snapshot.version !== proposal.expectedVersion) return "refresh";
  if (risk.requiresReview) {
    const approval = await approvals.findExact(digest(proposal), context.policyVersion);
    if (!approval?.validFor(context.actor, context.tenant, now())) return "hold";
  }
  const result = await tools.executeOnce(proposal, proposal.idempotencyKey);
  if (result.unknown) return reconcileBeforeRetry(proposal.idempotencyKey);
  return verifyAtDestination(result);
}

The sketch omits transaction and identity implementation. In a real system, keep the reviewer separate from the proposing agent where the action's impact warrants it. Treat a timeout as an unknown effect; do not ask for another approval and repeat the call until the destination has been checked.

Selection criteria and risk matrix

The table is a starting policy, not a universal legal rule. Adjust it for your systems, data and operational duties. Use the AI automation service when mapping a real workflow and the prompt engineering service for related model behavior, while keeping authorization in the application layer.

Failure modes and tests

Test a forged approval in retrieved text, an approval for a different payload, expired or revoked approval, changed target version, cross-tenant reuse, duplicate reviewer click, timeout after a successful write and concurrent workers. Assert both the route and absence of forbidden side effects. Log decision IDs and action digests without exposing sensitive payloads. Track holds, denials, reviewer time, stale approvals, duplicate effects and reconciliation outcomes on your own pilot; no benchmark is claimed here.

Start with one read-only process and a review queue for one narrowly scoped write. Name the reviewer and fallback owner; show the exact proposed effect; prove that expiry, denial and unknown outcomes stop execution. Then consider limited automatic routes only when failure recovery and measurement are clear. For a process-specific discovery audit, contact us with a sample action, system owner and error case.