A human approval step is the cheapest insurance policy in agent operations and the most over-applied governance pattern. Done well it catches the actions that should never happen and stays out of the way for everything else. Done badly it produces approval fatigue, rubber-stamping, and incidents anyway. This guide walks the production pattern: where to insert the gate, what the approver needs to see, how to time out gracefully, and the graduation rules that move trusted actions out of approval over time.

The framing builds on the four-level trust model in agent trust models. Approval gating is the operational mechanism for trust level 3 (approve-then-act). NIST's AI RMF and the OWASP LLM Top 10 both emphasise human oversight as a control surface (NIST AI RMF, retrieved 2026-05-09).

Where to insert the gate

The gate goes immediately before the irreversible action. Not at the end of the agent's plan; not at the start; not at every step. At the action.

Concretely, the agent's tool wrapper for a high-risk action does this:

  1. Receive the proposed action and arguments from the agent.
  2. Validate against allow-lists and policy.
  3. Submit the action to the approval queue with full context.
  4. Wait for approval, rejection, timeout, or escalation.
  5. Execute on approval; abort and report on rejection; escalate on timeout.

The agent's loop sees the approval response as a tool result. The agent does not run the approval logic itself; the orchestration layer does. This separation is what makes the approval auditable independently of the agent's reasoning.

What counts as "high-risk" maps to the trust-level decision matrix in trust models: high blast radius, irreversible, or low frequency. Sending email externally, transferring money, deleting records, posting to a public channel, signing a document. Reading data, drafting text, internal computations: usually no gate.

The timeout pattern

Set a timeout that matches how long the action remains useful. Three example tiers:

Action typeUseful windowTimeout
Customer email reply~24 hours before stale24 hours
Meeting scheduling~2-4 hours before slot disappears2-4 hours
Invoice payment~5 business days5 business days
Internal Slack triage~30 minutes30 minutes

On timeout the agent must not auto-act. Auto-acting on timeout is the most common pattern in over-engineered approval systems and the most common source of incidents. The correct timeout behaviour:

  1. Log the timeout with full context.
  2. Escalate to a fallback approver (a manager, a shared queue).
  3. Downgrade the original approver's queue priority for future approvals.
  4. If the escalated fallback also times out, the action is dropped, not executed.

Auto-execute-on-timeout is acceptable only for the lowest-risk auto-graduated actions where the gate exists for surveillance rather than control. Even there, log the auto-execute distinctly from approved executions so the audit can distinguish them.

What approvers need to see

Approvers without context default to two failure modes: rubber-stamping (approving everything) and blanket rejecting (rejecting on principle). Both are dangerous. Five fields keep approvers in the productive middle:

  1. Agent identity and prompt version. Which agent is asking and which version of its prompt produced this action.
  2. Goal context. What was the user request, and what state has the agent established so far.
  3. Proposed action with full input arguments. Not a summary; the actual payload that will be sent if approved.
  4. Alternatives considered. What other actions the agent looked at and why it rejected them.
  5. Reversibility cost. If this action turns out to be wrong, what does undoing it look like.

The fifth field is the most under-implemented and the most useful. Approvers who can see "this email cannot be unsent; if wrong, you will need to send a follow-up apology" approve more carefully than approvers who see only the email body.

Preventing approval fatigue

Approval fatigue is the slow death of approval systems. The pattern: approvers see hundreds of items per day; quality of review drops; bad actions get approved; an incident happens; the team adds more approvals; fatigue worsens.

Three rules contain the spiral:

The graduation pattern is covered in trust models. The cluster post on monitoring agent activity covers the dashboards that tell you when an action is ready to graduate.

Audit fields per approval

Every approval event writes a row to the audit table with eight fields:

  1. Timestamp (ISO 8601 with timezone, monotonic).
  2. Approver identifier (user ID, role, queue ID).
  3. Agent identifier (with prompt version, model version).
  4. Action type (sendEmail, postPayment, etc.).
  5. Action arguments (full payload as submitted).
  6. Decision (approve / reject / timeout / escalate).
  7. Reasoning text if provided by the approver.
  8. Downstream action ID linking to the executed action's audit row.

The trail is immutable. Append-only storage. Retention matches the underlying action's regulatory requirement (typically 7 years for financial actions, 6 for healthcare, 3-7 for general).

Graduating actions out of approval

The criteria to remove an approval gate:

When the criteria are met, drop the gate. The action moves to level 4 (autonomous-with-guardrail). If the next 30 days produce an incident, restore the gate immediately and run the post-incident recovery covered in trust models.

Rollout pattern for first deployment

The rollout sequence that produces the fewest incidents:

  1. Week 1. Approve every action of every type. Approval queue is loud; the team feels the workload. This is intentional. The signal is which actions are safe enough to graduate.
  2. Week 2. Auto-approve the action types where rejection rate is below 1 percent. Keep the rest at level 3.
  3. Week 3-4. Continue graduating low-rejection action types. Add batch approval for any remaining high-volume low-risk types.
  4. Month 2. Review the audit log. Identify any action that approvers consistently spent over 30 seconds reviewing. Either improve the approval interface for that action or downgrade it to level 2 (suggest, not approve-then-act).
  5. Quarterly. Re-audit the trust matrix. Actions whose blast radius or reversibility cost has changed (because of policy or product changes) get reassessed.

The rollout pattern looks slow because it is. Speed at the cost of skipping the audit produces the incidents that approval was meant to prevent. The cluster post on how we test AI agents covers the test discipline that supports rollout decisions.

Frequently asked questions

Where should the human approval step go in an agent flow?

Immediately before the irreversible action (sending an email, posting a payment, deleting a record), not after the agent finishes its full plan. Approving a final summary is theatre; approving the specific action is governance. Insert one approval per high-risk action, not one approval at the end of the run.

How long should the agent wait for approval?

Set a timeout that matches how long the action remains useful. For email replies, 24 hours. For meeting scheduling, 2 to 4 hours. For invoice payment approvals, 5 business days. On timeout the agent should not auto-act; it should escalate to a fallback approver, log the timeout, and downgrade the original approver's queue priority.

What does an approval interface need to show?

Five things: the agent's identifier and prompt version, the goal context, the proposed action with full input arguments, the alternative actions the agent considered (and why it rejected them), and the reversibility cost if the action turns out to be wrong. Approvers without all five default to rubber-stamping or to blanket rejecting.

How do I prevent approval fatigue?

Three rules. First, approve once per action, not per run. Second, batch low-risk approvals into a single decision (twenty triage tags with one click). Third, graduate actions out of approval as they pass an incident-free threshold; the trust model in the cluster post on agent trust models defines the graduation pattern. Approval fatigue produces incidents because tired approvers approve everything.

How is approval tracked for audit?

Every approval event records eight fields: timestamp, approver identifier, agent identifier, action type, action arguments, decision (approve / reject / timeout / escalate), reasoning text if provided, and downstream action ID. The trail is immutable and queryable by approver, action type, and time window. Audit is the difference between governance and theatre.

Three takeaways before you close this tab

Sources