FIELD GUIDE

High-risk tool taxonomy for approvals

Human approval is not a single yes/no prompt placed somewhere inside an agent loop. The approval threshold should follow the risk of an operation, the resource it touches, the actor’s authority and the reversibility of its consequences. A reliable system makes that classification before it grants an execution token.

A practical risk taxonomy

Classify tools as observe, draft, internal reversible write, external communication, sensitive administrative change, financial transfer, and destructive operation. Default to read-only for unclassified methods. Require a reviewer for actions that create external commitments or move information to new recipients, even if the API claims they are reversible. Apply stricter controls when effects propagate across accounts, have legal meaning, or are impossible to undo promptly.

Bind an approval to a transaction

Display the actor, target account, destination, exact method, amount or payload, evidence, expected effects and expiry. Hash those parameters and issue a one-use authorization scoped to that exact request. If the model changes a recipient, invoice number, email body or file after approval, invalidate the token. Authentication confirms who approved; authorization confirms that person had authority over that action. Never let a subordinate agent reuse another operation’s grant.

Example escalation design

An agent reviewing accounts-payable documents can find discrepancies and draft a supplier email autonomously. Sending that email requires recipient and final text approval. Updating vendor banking data should be a distinct, high-risk workflow with two-person verification and an independent destination check. A payment request may require separate financial controls outside the AI service. This approach preserves most of the benefit of automated preparation without quietly granting broad signing authority.

Failure handling

A request waiting for approval should have a fixed expiry, immutable proposed arguments and durable state. A rejection should stop the action, not invite repeated phrasing until a different reviewer approves. If execution times out after submission, reconcile against the destination system before a retry; do not assume no action happened. Always record who approved and which exact side effect was observed, while redacting sensitive payloads.

Measure the control

Track unsafe auto-executions, approval bypass attempts, false escalations, median reviewer handling time, stale decisions and completed actions lacking a reconciled result. Review samples of both approved and rejected requests. Approval UX matters: a hurried reviewer seeing a vague ‘continue?’ button has less information than an attacker controlling the destination text. Product-tier entitlements are not inferred here; implement the policy in the execution layer regardless of vendor.

Match review friction to actual harm

Do not ask a reviewer to approve each harmless read of a public article, but do demand specific approval for committing funds, sending private data to outsiders or permanently deleting a record. Where a workflow has dozens of similar safe actions, authorize a bounded batch with explicit targets and expiry rather than one indefinite “approve all” grant. A reviewer should be able to inspect the source evidence and decline without losing the complete draft.

Production acceptance and review test

Test a payload mutation after approval, an approval copied across tenants, a late approval arriving after the target record changed, and a repeated approval request after the first was rejected. Confirm each invalid case fails before any external effect. A completed approval queue entry is not itself evidence of a completed action; reconcile the destination and show the reviewer the observed result.

Scope, version and availability

Features documented by a current vendor page are not assumed to have existed in earlier releases. Where a historical launch date is provided, it is supported by a dated first-party publication. Exact subscription tier, market availability, quotas, API billing, licensing permissions and deployment regions are not asserted without a directly applicable record. This is researched editorial guidance rather than a claim of independent hands-on testing, deployed operation or statutory certification.

Sources and Further Reading

CONTINUE EXPLORINGExplore related files ↗