Human Approval for AI Agents: An Authority Model

Approval is an authority model.

Put the permission check in the application or tool gateway that performs the action. A model instruction to ask first is not an execution control. Describe permitted targets, fields, recipients and amounts where relevant. Keep credentials scoped to that boundary so a different tool path cannot silently broaden it.

This method assumes an authenticated approver, a policy store and a tool interface that can reject execution. Inventory any tools that bypass those controls. If the application cannot enforce the required boundary, keep that action under human execution until it can.

Classify the action, not the agent.

For each action, ask how many people or records it can affect and how its effects could be repaired. A read can disclose restricted material. An internal update can trigger notifications, invoices or another workflow. Classify the downstream effect rather than the name of the tool call, and apply the stricter class when one proposal combines several actions.

Start with these six classes, then narrow them to actual operations. “Update a customer record” is too broad: correcting an internal label and changing a billing address may need different authority. Record exceptions in policy, with an owner and test cases. The same authority matrix appears on our AI agent development service.

Give the approver a decision they can inspect.

Show the intended effect, exact target, proposed change or complete message, relevant source references, uncertainty and the limits of recovery. Include downstream effects and the before-value where available. Let the approver inspect the evidence under their own access rights. Do not place sensitive source content in a notification merely because the notification system is convenient.

Bind the approval to the case, target, payload, policy version and expiry. Changing a recipient, amount, attachment or material input creates a fresh proposal. An approval for one case does not grant authority over similar cases. Offer approve, reject and request-more-evidence decisions; treat a request for evidence as pending.

Absence and failure need explicit defaults.

For an action requiring approval, use a fail-closed default: after the agreed waiting window, do not execute it. Record expiry and escalate to an authorised cover person or queue. Define the window from the business process; it is not a delivery commitment. Reaching the end of the escalation chain leaves the action stopped for human resolution.

Name cover for leave and departures, and test that delegated authority has the right scope and expiry. The agent must not approve its own proposal or select a less restrictive policy after rejection. Avoid using the same agent credential for requesting and granting authority. An emergency process needs a human owner and a separate record.

If the approval service, identity check or decision record is unavailable, stop the approval-required action. An undelivered notification is not an approval. On recovery, reconcile the pending case against the durable decision and execution records. Do not replay an old approval until its expiry, payload and current state have been checked.

Check again at execution time.

Immediately before acting, verify that the approver still has authority, the decision is valid, the target is unchanged and policy still permits the action. Use a version or conditional write when the tool supports it. If the approved before-state has changed, return to review rather than applying an old decision to a new situation.

Attach a stable action key across attempts when the downstream system supports idempotency. Confirm how long it retains keys and whether it rejects a different payload under the same key. A timeout after sending may mean an action happened without a response. Query or reconcile the result before retrying; a locally generated key alone does not prevent duplicates in another system.

After acting, check the resulting state or delivery record against the intended effect. Record partial or uncertain outcomes and stop dependent actions where needed. Verification failure should enter the agreed recovery path and alert an owner. Test the case where execution succeeds but writing the local result record fails.

Distinguish rollback from compensation.

Deployment rollback restores application code or configuration. It does not reverse a message, payment or business record already changed. Action compensation is a separate operation, such as a correction or restoring a field after checking for intervening edits. It needs its own authority, evidence and verification.

For an irreversible or disputed effect, preserve the record and route resolution to the responsible human. Do not label a correction as an undo. Practise recovery against representative failures before granting the corresponding write permission, including the case where compensation itself fails.

Keep an audit record that supports reconstruction.

Use related events under a stable case ID rather than overwriting one status field. Capture proposal, decision, attempts, verification and compensation with timestamps. Store protected evidence references when copying raw content would expand access or retention. A payload hash helps check correspondence to retained content; it does not establish who approved it or whether the action was appropriate.

The client decides retention with the people responsible for its data and obligations. Specify retention for decisions, payloads, logs and backups separately, including deletion and access review. Test reconstruction using an authorised reviewer: can they explain what was proposed, who permitted it, what ran and what was repaired without giving them unrelated source access?

Reduce oversight through a recorded policy change.

A possible progression is propose-only, approval on each eligible action, then automatic execution within a narrow reversible class with retrospective sampling. Define the eligible class, evaluation window, evidence threshold, sampling method and owner before changing mode. Use observed errors, near misses and reviewer corrections as evidence; successful easy cases alone are insufficient.

Sample across risky subgroups, tools and uncommon inputs as well as routine cases. Keep high-impact classes under their required approval or human-execution boundary. Return the affected class to per-action approval after a permission breach, failed recovery, material drift or a model, prompt or tool change that has not passed regression checks. Sampled review happens after action and cannot prevent that action’s harm.

Use the acceptance scorecard to agree the evidence for each mode. Bring the action inventory, approver map and recovery limits to an AI agent development discussion.