Automation becomes risky when a system can create irreversible effects faster than a person can understand them. An approval button is not enough: the workflow needs a clear proposal, the right reviewer, durable pending state, expiry, replay protection and evidence of what actually happened after the decision.
Persist a unique proposal ID, actor or agent identity, target resource, requested operation, risk tier, evidence snapshot, policy version, creation time and deadline. The approval decision should refer to that immutable proposal. If inputs change, invalidate the approval and request review again rather than silently applying consent to a different action.
| Action class | Possible policy | Example control |
|---|---|---|
| Reversible, low impact | Automatic within narrow limits | Update an internal draft or retry a read-only sync |
| Material customer effect | One authorized reviewer | Send a customer notice or change an account setting |
| High impact or financial | Strong review, possibly two-person rule | Issue a large refund, change payout details or bulk-disable accounts |
| Prohibited or unsafe | Hard deny; approval cannot override | Bypass identity controls or exfiltrate restricted data |
Risk should depend on scope, reversibility, amount, affected users and confidence in the evidence, not simply whether an AI produced the request. A human gate is not a substitute for authorization, input validation or least privilege. The execution service must re-check current permissions and policy after approval.
Show the exact proposed change, affected objects, expected consequence, source evidence, uncertainty, policy reason and a safe preview. Distinguish model-generated explanation from verified system facts. Do not pressure reviewers with preselected approval or hide rejection. If confidence or source data is inadequate, offer defer or request-more-information states.
Authenticate the reviewer independently, authorize them for the specific action and tenant, and bind the approval token to one proposal. Use short expiry and one-time consumption; protect callback links from forwarding and logging. Apply separation of duties where the proposer must not approve their own high-risk action. Record who decided, when, what version they saw and what the executor changed.
Pending work needs a durable workflow record rather than a process waiting in memory. On expiry, choose a safe terminal state such as rejected or needs-human-attention. Make the decision endpoint idempotent; a duplicate callback must not run the action twice. Use a compare-and-swap transition so two reviewers cannot both consume one pending proposal. If execution fails after approval, retain the decision and report the action as failed; do not imply that approval equals completion.
Track time to decision, approval and rejection rates by risk tier, expirations, overrides, execution failures after approval and reviewer workload. High approval speed with no rejections can mean the gate is rubber-stamping. Periodically sample decisions and test that unapproved, expired and cross-tenant proposals cannot execute.
Related: identity and authorization for agents and agent memory and data boundaries.
A trustworthy approval gate is a durable, risk-based and auditable workflow transition. Show the reviewer exactly what will happen, revalidate authority at execution, expire stale consent and make duplicate decisions harmless. Human judgment only helps when the system gives people control and meaningful evidence.