An editor asks an agent to prepare a newsletter. The agent researches the topic, drafts the message, and selects a mailing list. An approval dialog appears: “Proceed?” The editor accepts. Before dispatch, the agent changes the recipient segment to include inactive subscribers.
The interface collected a click, but it did not preserve a useful authorization boundary. Approval should connect a responsible person’s decision to the specific action that executes. That requires more than placing a confirmation screen somewhere in the workflow.
Review the consequence, not the intention
Start with the action object. For a newsletter, it includes the sending account, recipient segment and version, subject, body revision, attachments, and any scheduled send time. For a deployment, it includes the environment, immutable artifact, and intended configuration changes.
Display the fields that determine the consequence. “Send campaign 42 to the reviewed 318-member segment” communicates a decision; “let the assistant continue” grants unclear scope. The number here is an illustrative interface example, not a report from a real campaign.
If the recipient set can change, decide whether approval covers a frozen membership snapshot or a defined rule evaluated at execution. Show that choice. A dynamic segment can be appropriate, but the reviewer should understand what it authorizes.
Keep preparation cheap and commitment explicit
An agent can gather material, check formatting, and prepare a preview before the user decides. Put the gate after the proposal becomes concrete and before the irreversible effect.
That does not mean every read needs approval. Requiring confirmation for routine preparation can bury consequential decisions among trivial ones. Group low-risk work under a defined scope and reserve focused review for meaningful commitments.
Separate the controls in the interface. Editing the draft, rejecting the action, and approving it should have distinct outcomes. A rejected proposal should not return to the queue merely because an agent paraphrased it and tried again.
Store authorization outside model output
Accept approval through an authenticated application route. Derive the approving actor and account from server-side identity. A tool result, retrieved page, or generated sentence saying “approved” is not equivalent to that route.
Persist the action representation, its digest, the approver, scope, expiry, resource version, and permitted uses. The executor should retrieve this record from a trusted store. A model-supplied approval identifier is only a reference to inspect, not proof by itself.
A digest helps detect differences between reviewed and executed content. Anyone with the content can calculate it, so matching hashes do not authenticate the approver. Keep cryptographic integrity checks separate from identity and permission checks. See deterministic application boundaries for the serialization distinction.
Define changes that invalidate the decision
Write the invalidation rules before implementing the screen. For the newsletter, a useful starting policy is:
| Change after approval | Effect on approval |
|---|---|
| Different sender or audience | Require a new decision |
| Revised body, subject, or attachment | Require a new decision |
| Changed scheduled time | Recheck the policy shown to the reviewer |
| Internal display label only | Preserve approval if explicitly excluded from action semantics |
| Approver loses the required role | Reject execution under current policy |
An expiration time limits stale decisions, but it does not replace resource version checks. A five-minute-old approval can already refer to content that changed.
For reusable standing rules, store their scope explicitly: permitted action types, accounts, ceilings, exclusions, and expiration. The user should be able to inspect and revoke them. Do not silently transform a one-time approval into a standing rule.
Redeem approval atomically
Two workers can race to execute the same approved action. Marking approval consumed after the remote call permits both to proceed. Marking it consumed before a durable execution record exists can lose the action if the worker crashes.
Consume the authorization and create its execution intent in one transaction. Dispatch the intent separately, using downstream idempotency when supported. Record the result against the original intent.
If the remote outcome is unknown, preserve that state. A second approval is not a substitute for finding out whether the first execution succeeded. The retry guide explains the crash window between remote success and local acknowledgement.
Design rejection and revocation paths
A useful failure message says which condition changed and what the user can do. “Approval expired; review the current proposal” is actionable. “Something went wrong” invites a retry without understanding the consequence.
Revocation needs a defined boundary too. It can prevent undispatched work from starting; it may not stop an external action already accepted by another service. Show that distinction when cancellation is requested, and retain execution evidence for reconciliation.
Keep a review history with the proposal version and decision. Limit access to that history because approved content can itself contain sensitive information. An audit record should be useful without becoming an unrestricted copy of every message and attachment.
Pair review with constrained execution
Human approval does not justify giving the executor every credential on the machine. Use narrowly scoped tools and identities so the approved action has an equally narrow execution path.
Anthropic’s sandboxing explanation describes filesystem and network isolation as complementary controls around tool execution. They constrain the environment independently of the approval interface. Claude Code sandboxing
Before shipping a gate, ask whether a reviewer can identify the consequence, whether changed content invalidates the decision, and whether the executor checks the same trusted record. Approval becomes meaningful when the system can demonstrate that what happened is what the person actually authorized.