Human-in-the-loop approval gates for AI agents

Human oversight is not the presence of a person somewhere in the process. It is a designed authority boundary. The person must see the proposed action, understand its consequence, have permission to decide, and be able to approve, reject, edit, or escalate before execution.

A weak implementation asks, "Continue?" after hiding the recipient, data scope, policy result, or downstream effect. A strong implementation makes the decision legible and binds it to the exact action that later reaches the tool.

What problem does an approval gate solve?

Agentic systems can select tools and compose multi-step plans. That flexibility is useful, but it expands the gap between a user's initial request and the concrete side effect. Approval gates close that gap at the moment consequence becomes specific.

Intent is not authority

A user asking an agent to "handle the renewal" has not necessarily authorized a new price, a multi-year term, a bank transfer, or a message to a counterparty. The agent can prepare options, but each material commitment needs the authority required by policy.

A plan can change after initial consent

Models, tools, and data can change what the system proposes. Approval granted to one amount, recipient, attachment, or destination must not silently carry over to a modified action. This is why approval needs parameter binding rather than a reusable yes/no flag.

Review creates an accountable transition

The gate turns a proposed action into a human decision with a durable state. Investigators can later distinguish what the agent recommended, what the reviewer saw, what the reviewer changed, and what actually executed.

Which actions belong behind which approval tier?

Approval should scale with consequence, reversibility, data sensitivity, and authority. The table is a starting profile, not a universal policy.

Tier	Typical action	Default treatment	Reviewer	Evidence required
0: Observe	Read public or low-sensitivity data	Allow under standing policy	None	Identity, source, purpose
1: Prepare	Draft, classify, summarize, recommend	Allow, prohibit external effect	Task owner on output use	Inputs, versions, limitations
2: Communicate	Send a message or publish content	Review exact recipient and content	Content or account owner	Draft digest, recipients, approval
3: Change	Update a system of record or schedule	Parameter-bound approval	Resource owner	Before state, proposed change, after receipt
4: Commit	Spend, sign, grant access, delete, deploy	Separation of duties or dual approval	Authorized approver	Policy, limits, two-party decision where required
5: Prohibited	Outside legal, safety, or policy boundary	Deny regardless of approval	Escalation owner	Denial reason and attempted scope

The important distinction is not the number of tiers. It is that classification occurs before execution, maps to an explicit decision rule, and cannot be overwritten by model confidence.

What information must the reviewer see?

The review view should answer five questions without requiring the reviewer to inspect raw model traces.

What will happen?

State the concrete operation in plain language. "Run tool" is insufficient. "Send the attached requirement summary to three named recipients" is reviewable.

Why is it proposed?

Show the task, relevant evidence, and the policy path that led to review. This is not an invitation to accept a long chain-of-thought narrative. The reviewer needs concise grounds, source links, uncertainties, and any rule that required escalation.

What will change?

Show a before-and-after representation when the action modifies durable state. For data transfers, show fields, destination, retention expectation, and classification. For messages, show recipients and attachments. For purchases, show item, amount, account, and terms.

What authority is being used?

Name the reviewer role, limit, policy, delegation, and expiry. A reviewer should know whether they are deciding as a record owner, budget owner, security approver, licensed professional, or incident commander.

How can the reviewer respond?

Provide approve, reject, edit, and escalate where the workflow permits them. An edit should create a new proposal and new parameter digest. The system should never reinterpret a reviewer comment as approval unless policy explicitly defines that behavior.

How does parameter binding prevent approval drift?

The system computes a digest over the material parameters the reviewer saw. The approval record stores that digest. Immediately before tool execution, the runtime recomputes the digest and requires an exact match.

approval_scope = canonicalize({
  action,
  target,
  material_parameters,
  data_scope,
  policy_version,
  expires_at
})

approval_digest = HASH(approval_scope)

before execution:
  require current_digest == approval_digest
  require approval unused
  require now < expires_at
  require reviewer authority still valid

Material parameters depend on the action. A message includes recipients, subject, body digest, and attachments. A payment includes source account, recipient, amount, currency, and purpose. A deployment includes artifact digest, environment, configuration revision, and rollback boundary.

What state model should the approval use?

A durable state machine prevents duplicate execution and ambiguous retries.

1. Proposed. The agent submits a complete candidate action.
2. Policy checked. The system classifies consequence and reviewer requirements.
3. Pending review. The exact review package is frozen and assigned.
4. Edited. A reviewer or authorized operator changes material parameters, producing a new proposal.
5. Approved, rejected, or escalated. A named reviewer resolves the request.
6. Reserved. The runtime claims the single-use approval before sending the action.
7. Executed or failed. The tool returns a durable receipt or error.
8. Verified. The system confirms the intended state from the authoritative target where required.
9. Expired or revoked. Stale authority can no longer be used.

Retries need their own rule. A transport retry using an idempotency key may remain inside the same approval. A changed action, new target, expired quote, or changed policy requires new approval.

How should policy decide whether review is required?

The gate should be invoked by deterministic policy over action attributes, not by asking the model whether its own action is risky.

if action.prohibited:
  deny
else if action.data_classification > actor.clearance:
  deny
else if action.consequence >= HIGH:
  require two authorized reviewers
else if action.external_effect or action.sensitive_transfer:
  require parameter_bound_approval(resource_owner)
else if action.reversible and action.within_standing_limit:
  allow with audit
else:
  require task_owner_review

The model may supply context, but the policy engine owns the decision. Policy versions and evaluated attributes belong in the audit record so a reviewer can reconstruct why the gate opened.

How do separation of duties and dual approval work?

Some actions should not be proposed and approved by the same identity. The system can require a reviewer from a different role, reporting line, or administrative domain.

Dual approval should mean two independently authorized decisions over the same immutable proposal. It should not mean one person approves and another clicks a generic release button without seeing the package. Record both decisions, their authority, order, and expiry.

Avoid rules that create predictable bottlenecks without reducing risk. Use consequence and resource ownership to decide when independence matters. Then measure queue time, escalations, after-hours behavior, and emergency overrides.

What makes an emergency override governable?

An emergency path may be necessary, but it should be narrower and more visible than the normal path.

• Restrict override authority to named incident roles.
• Require a reason code and incident reference.
• Bind the override to one action, target, and short expiry.
• Alert an independent owner immediately.
• Record the normal policy decision that was bypassed.
• Require after-action review and explicit closure.
• Test that the override cannot become a standing permission.

An undocumented bypass is not resilience. It is an alternate production path with weaker controls.

How do you design the reviewer experience?

Human factors determine whether the control works under load.

Show difference, not just content

For changed records or documents, emphasize what the agent added, removed, or transformed. Reviewers should not reread an entire artifact to discover a material change.

Put the consequence beside the button

The approval action should state what follows: "Approve and send," "Approve and deploy," or "Approve access for 24 hours." Generic "Confirm" language hides consequence.

Make uncertainty visible

Show missing sources, stale data, conflicting evidence, low-confidence extraction, and policy exceptions. Do not turn model confidence into a reassuring percentage unless it has an established interpretation for the exact task.

Prevent batch blindness

Large queues encourage rubber stamping. Group only truly homogeneous low-consequence items. Require individual review when recipients, amounts, access, or sensitive data differ. Provide queue limits and staffing signals before the backlog becomes a safety problem.

What should the audit trail capture?

At minimum record the proposal ID, parameter digest, reviewer identity and role, decision, reason, policy version, review time, expiry, single-use reservation, tool request reference, downstream receipt, and final verification state.

The trail should also capture rejections and edits. A system that logs only approved actions cannot show whether policy stopped harmful proposals or whether reviewers routinely corrected a particular failure mode.

Which metrics reveal whether the gate works?

Do not optimize for approval rate. A high approval rate might indicate good proposals or automatic behavior by overloaded reviewers.

Useful measures include:

• time from proposal to first review;
• rejection and edit rates by action class;
• proportion of approvals close to expiry;
• reviewer workload and queue age;
• actions blocked by parameter mismatch;
• duplicate execution attempts;
• emergency override frequency and closure time;
• incidents involving an approved action;
• downstream reversals or corrections;
• proposals abandoned after a policy escalation.

Review these measures by consequence tier, team, and workflow. Aggregate figures can hide one high-risk path behind thousands of low-risk approvals.

What failure modes should testing cover?

Test more than the ideal approval.

1. The action parameters change after approval.
2. The approval expires before execution.
3. Reviewer access is revoked between decision and execution.
4. Two workers attempt to consume one approval.
5. The tool accepts the request but the response times out.
6. The policy bundle changes while review is pending.
7. The reviewer edits a material parameter.
8. The approval service is unavailable.
9. The audit write fails before or after the tool call.
10. An emergency override is attempted without an incident.
11. A low-risk action unexpectedly reaches a sensitive target.
12. A reviewer tries to approve outside their limit.

A gate is credible when these cases produce defined, observable states and the final tool boundary independently rechecks authority.

How should buyers evaluate an approval-gate claim?

Ask the vendor to demonstrate one consequential workflow from proposal through verified outcome. Change a material parameter after approval and confirm execution stops. Expire the approval. Revoke the reviewer. Attempt duplicate consumption. Interrupt the tool response. Request the resulting records.

The answer should name the action classification, policy version, parameter-binding construction, expiry rule, reviewer authority, execution receipt, and failure behavior. A screenshot of a confirmation dialog proves only that a dialog exists.