01 / The operating case
What changes in a real workflow?
An agent proposes disabling a production account. The reviewer sees the account, reason, expected effect and rollback path before signing off.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
Pause execution, bind approval to normalized arguments, validate approver rights and expiry, then recheck current context at the executor.
Architecture review / negative test
Make the boundary testable.
Show a reviewer the exact target, argument values, business reason, expected effect and uncertainty. Verify that this person has the right to approve this class of action. A generic “approve agent” button cannot substitute for an action-specific authorization, especially when the agent can alter the request after review.
03 / Failure and evidence
What goes wrong, and what can be proven?
The agent changes the target after approval or retries a used approval against a second account.
Record the human decision separately from the machine decision and actual account state.
04 / Canonical scope
Why this reference stands alone
High-impact thresholds belong in policy; this page owns the mechanics and limitations of human approval.
Implementation review
Approval is a bounded input, not a reusable safety label.
The reviewer must see the actual operation and material arguments before approving. Capture which person approved, what they were authorized to approve, the exact request digest, expiry and consumption rule. When the agent resumes, recheck the grant and current resource context as well as the approval. A human may have approved a proposal that is now stale or no longer executable.
PROPOSED: disable account C-42 DISPLAYED: target C-42, reason incident-88, rollback path APPROVED: approver U-9, request hash H, expires 14:30 RESUMED: same H + active grant + current policy → EXECUTE changed target or expired approval → DENY
Run the denial test
Pause after approval and change the target, revoke the incident grant, or replay the approval for a second account. Each variant must fail. A timeout after execution requires outcome reconciliation before reusing any approval artifact.
Evidence to examine
Store displayed proposal, approver authorization, signature or decision event, hash, expiry, use count, re-evaluation and account outcome. A click without the displayed request is weak evidence.
Primary source: OWASP Agent Control Standard ↗
Related: Approval expiry and binding.
Architecture field test
Approval binds to a proposal, not an agent
What did the reviewer actually authorize?
- 01Show exact proposed effect
- 02Verify approver authority
- 03Bind approval to request digest
- 04Recheck and consume at commit
Work the boundary
A responder approves disabling account C-42 for incident 88. The approval displays that account and incident. If the agent resumes after the incident is closed or submits C-43, the prior approval cannot authorize the new effect.
| Required facts | Approver, displayed action and target, material parameters, task, expiry, use count and current grant. |
|---|---|
| Allow only when | The executor sees the same canonical request and a live, unused approval from an authorized reviewer. |
| Deny when | The agent swaps an account ID after approval or reuses one click for another action. |
Break the assumption
Change target, amount and task independently between display and commit. Replay the same approval from two workers. Only one matching operation may consume it, and an uncertain outcome must be reconciled before retry.
Design tradeoff
Requiring approval on every trivial read creates fatigue. Reserve exact-action approval for effects whose risk cannot be handled by bounded automated policy, and make exceptions visible.
For approval binds to a proposal, not an agent, consult OWASP AI Agent Security Cheat Sheet. This worked decision and negative test are ProofGrid analysis.
Continue with Approval binding and expiry.
Primary references