When should an AI agent ask for human approval?

An agent can look up an order without help. The problem starts when the same run can also send an email, delete a record, publish a change, or alter a permission. If everything needs confirmation, people start clicking without reading. If nothing does, one misunderstood call can create a hard-to-reverse effect.

The practical answer is to classify the action, not the whole agent. Reads and reversible changes can often run autonomously. High-impact or hard-to-reverse actions should stop before the external effect. Durable execution for AI agents complements this design when approval takes time and the run must resume later.

The short answer

• Ask for approval for a specific action when a mistake is costly, difficult to undo, or needs another person to own the decision.
• Make the decision in the runtime, after tool validation and before the external effect. Do not let the model authorize its own call.
• Show the exact payload, persist pending state, and invalidate the approval if the arguments or target change.

Why should an agent not ask for approval for every tool?

In 2026, AWS guidance on agent oversight separates actions into autonomous, notify, and approve levels based on impact and reversibility (AWS, “Establish tiered human oversight and approval workflows”, 2026). The separation prevents two opposite mistakes: blocking simple work and letting a serious action pass without review.

A status lookup is usually reversible because it does not change the system. A draft may need only a record. Deleting data, sending an external message, changing permissions, or confirming a transaction changes the world outside the loop. The tool category helps, but context matters too: target, value, identity, frequency, and whether the action can be undone.

The model should not decide its own category. A prompt can ask it to be careful, but it cannot create an authorization boundary. Treat model output as a proposal. Code-level policy should decide whether that proposal proceeds, creates a notification, or becomes pending work.

How should you classify actions by risk and reversibility?

Start with three simple levels. AWS recommends that autonomous actions be low risk and reversible, notify actions proceed with operator visibility, and approve actions be high risk or irreversible (AWS, “Establish tiered human oversight and approval workflows”, 2026). This table is a starting point, not a universal policy.

Do not measure risk by call count. One write can be more dangerous than a hundred reads. Ask what changes, who is affected, whether the action can be undone, and who has authority to accept it. If the answer is unclear, prefer a pending decision or a safe rejection until the contract is clear.

What does a reviewer need to see before approving?

In 2026, AWS guidance for critical decisions calls for enough context to understand the operation, impact, and consequences, plus records of identity, timestamps, decisions, and escalations (AWS, “Human-in-the-loop for critical decisions”, 2026). A button labeled “approve agent action” is not useful review.

The approval request should represent the call that will run. Include at least:

• tool name and contract version;
• normalized arguments and the target that will change;
• operational reason and expected result;
• relevant data used to build the call;
• risk, reversibility, and compensation path;
• policy version, agent identity, and expiry;
• a unique identifier linking proposal, decision, and result.

Do not ask the model to summarize the action and show only that summary. The interface should expose the real arguments. If the runtime fetches new data after approval and rebuilds the payload, the new call needs another evaluation. The reviewer approved one concrete operation, not an open-ended intention.

Where should the approval gate sit?

Put the gate between deterministic call validation and execution of the external effect. AWS guidance places review for mutating actions in the execution path, rather than relying only on the prompt (AWS, “Implement tool authorization”, 2026). That way, a hostile instruction or a wrong model decision cannot reach the authorization endpoint directly.

The minimum flow is:

1. The model proposes a tool and arguments.
2. The runtime validates shape, identity, scope, and preconditions.
3. Deterministic policy classifies the risk.
4. The runtime executes, notifies, or creates a pending request.
5. The executor confirms that the decision belongs to the same call.
6. The tool produces the effect and records the result under the decision ID.

The code below is illustrative. policy, savePending, and execute are adapters that need their own rules and storage in a real system.

type Decision = "autonomous" | "notify" | "approve";

async function runTool(call: unknown) {
  const parsed = ToolCall.safeParse(call);
  if (!parsed.success) return { status: "rejected", reason: "invalid_input" };

  const decision: Decision = policy.evaluate(parsed.data);

  if (decision === "approve") {
    const pending = await savePending({
      tool: parsed.data.tool,
      arguments: normalize(parsed.data.arguments),
      policyVersion: policy.version,
    });
    return { status: "pending", approvalId: pending.id };
  }

  return execute(parsed.data, { notify: decision === "notify" });
}

The executor should not receive a loose “yes.” It should load the pending request, compare tool, normalized arguments, target, and policy version, and reject any mismatch. Validating AI agent tool calls in TypeScript explains the previous boundary, where input and output must be treated as untrusted data.

How do you pause and resume an agent after the decision?

The OpenAI Agents SDK models approval as an interruption: execution pauses, state can be converted to RunState, a person approves or rejects the call, and the runtime resumes from that state (OpenAI Agents SDK, “Human-in-the-loop”, 2026). Persistence is the important part. An approval that exists only in process memory disappears when the worker restarts. This explicit state fits the state-machine design for AI agents: approval is an observable transition, not a detail hidden in the prompt.

Store the pending request in durable storage with the run ID, tool, arguments, policy, expiry, and status. Another worker can resume the run, but the decision must remain tied to the same call. If approval may remain open for a while, store an agent or contract version so a new definition cannot execute an old pending request.

Timeout is also a decision. When the reviewer does not respond, the system can reject, route to another person, or keep the request blocked. It should not release the action because nobody answered. AWS recommends timeout, escalation, and safe fallback rules so a workflow does not remain stuck without an owner (AWS, “Human-in-the-loop for critical decisions”, 2026).

For long agent runs, I use RemoteCode to keep context and evidence across long-running agent sessions. It is my own tool. The mention belongs here because approval must survive the interval between a proposal and its resumption without relying on process memory.

Which failures turn approval into a formality?

An approval can exist in a database and still protect nothing. The first problem is approving a summary while the executor uses different arguments. The second is leaving the approval endpoint reachable by the agent itself. The third is asking for review on every call until people stop reading.

The GhostApproval case shows an important variation: a person can approve an apparent path while the runtime writes to the resolved target. The same principle applies to tools. The reviewer needs to see the real resource that will change, and the executor needs to apply the same boundary after the click.

There is also a gap between an external effect and its receipt. An API may complete the operation and the application may crash before saving the result. An ignorant retry can send the message or create the record a second time. For each approved action, define an idempotency key, a state lookup, or a compensation path before allowing a repeat.

How can you verify that the gate protects the tool?

Test the executor without relying on the model to choose the right path. The test should prove the boundary behavior and make clear what happens when the run stops halfway through.

• a valid read proceeds without approval;
• a low-impact write follows its defined level and creates a notification;
• a high-impact write creates a pending request before calling the service;
• arguments changed after the click require a new approval;
• a new policy does not execute a pending request created under an incompatible version;
• rejection and timeout do not call the tool;
• resuming twice does not create two external effects;
• agent observability in CI makes the trail searchable; logs connect agent, tool, arguments, decision, reviewer, timestamps, and result.

The criterion is not “a button appeared.” You should be able to show that the call the person saw is the call the executor accepted. If that equality cannot be checked, approval is only an interface layer.

Frequently asked questions

Does every tool that writes to a database need approval?

No. A small, reversible, bounded write can be autonomous or notify-only when the policy, scope, and compensation path are clear. Approval should follow impact and reversibility. Changing permissions, deleting data, or crossing a trust boundary deserves stronger treatment than updating an internal draft.

Can the model decide when to ask for approval?

It can provide signals, but it should not be the final authority. The runtime needs independent rules over tool, target, identity, value, context, and reversibility. If classification depends only on agent text, an injected instruction can try to downgrade a dangerous action into the autonomous path.

Does human approval eliminate prompt-injection risk?

No. It limits the autonomy of some actions, but it does not fix weak validation, broad permissions, mutable payloads, or an interface that hides the real target. Keep authorization outside the agent's reach, show concrete arguments, and test hostile inputs alongside the normal path.

Conclusion

An agent should ask for human approval when it is about to produce a high-impact, hard-to-undo effect or one that needs explicit accountability. The block belongs in the runtime, after validation and before the tool, with the decision tied to the exact payload.

Start with three levels: autonomous, notify, and approve. Persist pending work, define timeout behavior, invalidate changed calls, and test replay like any other operation with an external side effect. The person then reviews decisions that matter while the agent remains useful for repeatable work.

Sources consulted

• OpenAI Agents SDK, “Human-in-the-loop”, retrieved 2026-08-20, https://openai.github.io/openai-agents-python/human_in_the_loop/
• AWS, “Establish tiered human oversight and approval workflows”, retrieved 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentrel02-bp05.html
• AWS, “Human-in-the-loop for critical decisions”, retrieved 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentsec04-bp02.html
• AWS, “Implement tool authorization”, retrieved 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentsec02-bp01.html
• Reddit, “Approval is not review if the human cannot inspect the action”, retrieved 2026-08-20, https://www.reddit.com/r/AI_Agents/comments/1t7d3cb/approval_is_not_review_if_the_human_cannot/
• Reddit, “Human in the loop is meaningless unless we define what was approved”, retrieved 2026-08-20, https://www.reddit.com/r/AI_Agents/comments/1vhvqp0/human_in_the_loop_is_meaningless_unless_we_define/
• Reddit, “Human approval on agent writes is mostly theater”, retrieved 2026-08-20, https://www.reddit.com/r/mcp/comments/1uzsx6h/human_approval_on_agent_writes_is_mostly_theater/