An approval dialog is useful only if the person can understand the action and influence what happens next. A stream of vague “Allow?” prompts can create the appearance of oversight while leaving the important decision hidden.
Consider an assistant preparing a customer update. It reads internal notes, drafts a message, selects recipients, and proposes sending it. The approval should concern the actual message and recipients. Asking the user to approve a long shell command or an agent’s reassurance is a poor substitute. This is a design scenario, not a report of measured human behavior.
OWASP’s excessive-agency guidance recommends limiting functionality, permissions, and autonomy, including approval for consequential operations. That recommendation does not make every approval interface effective. OWASP excessive-agency guidance
Decide what deserves interruption
Review should correspond to a meaningful choice. Reading an already authorized document and sending that document outside the organization have different consequences. Treating them identically consumes attention without explaining the difference.
Define an action policy before designing the dialog. In this scenario, drafting can proceed within the authorized workspace. External sending requires review of the payload and audience. A request to broaden the recipient list after approval requires a new decision.
This is not a universal policy. Different products may have standing authorization for routine communication. The requirement is that the boundary be explicit and understandable, with a way to change or revoke it.
| Action | Illustrative handling | Reason |
|---|---|---|
| Read approved source notes | Continue within task scope | Existing access and purpose |
| Save a local draft | Continue with visible progress | Review remains possible before sending |
| Send to new external recipients | Request specific approval | Information leaves the workspace |
| Change payload after approval | Invalidate or renew approval | The reviewed action has changed |
| Retry after uncertain send result | Reconcile first | Avoid a duplicate message |
Show what the user is deciding
Present the account performing the action, recipients, subject, message body, attachments, and relevant consequences. Identify uncertain or missing information. The person should not have to reconstruct the proposal from an execution trace.
Separate a concise summary from inspectable detail. “Send the customer update to three recipients” is a useful heading only when the exact addresses and message are available before confirmation. An attachment count should lead to filenames and the actual files, not an unexplained bundle.
For a changed document, show the diff and target. For a permission change, show who gains which access. For a purchase, show the item, amount, currency, and account. A generic approval component can provide common controls, but the evidence needs to match the action.
Keep the proposal faithful to execution
The executor should bind approval to the relevant arguments and resource versions. If the agent revises the message afterward, the existing approval must not silently carry forward to the new text.
One design is to store an immutable proposal record and have the approval refer to its identifier and content digest. Execution then resolves that exact proposal, rechecks current authority, and records the outcome. This is a design pattern, not a ready-made guarantee: the serialization, storage, and execution paths must actually preserve the binding.
Approval should expire when relevant conditions change. A user can lose access; a destination can become invalid; a resource can be replaced. Renewed review is meaningful when it explains which condition changed, rather than merely repeating the original dialog.
Give refusal a useful path
A reviewer needs more than approve or abandon. Where appropriate, let them revise a recipient, edit the draft, narrow the operation, or request clarification. Keep the changes visible and return the revised proposal through the same authorization process.
Do not interpret closing a dialog, waiting too long, or navigating away as approval. The system should retain a pending or canceled state and explain it when the user returns.
If review is unavailable, stop the dependent action while continuing any independent authorized work. A timeout is a workflow condition, not a source of new permission. Make that state observable to operators so a backlog does not become invisible.
Reduce noise through scope, not concealment
Repeated low-value prompts are a product signal. Identify whether a tool is too broad, a task scope is unclear, or an operation could be represented more directly. Do not solve the problem by hiding consequential actions inside a larger approved batch.
Batching can be appropriate when the user can inspect the complete set and the consequences are coherent. A batch of draft saves differs from a batch containing an unrelated external upload. Provide item-level exclusions when the workflow needs them.
Anthropic’s containment discussion observes that nontechnical users should not be expected to judge complex shell commands. That supports translating actions into reviewable domain concepts instead of exposing implementation details as the decision surface. Anthropic on containment and oversight
Evaluate whether review changes outcomes
In a controlled review exercise, include a correct proposal, a wrong recipient, a changed attachment, and a stale approval. Observe whether reviewers can identify the consequential difference and whether the executor respects their decision.
Do not treat a fast approval as evidence of understanding. Ask reviewers to describe the action and consequence in their own words during usability research. Avoid claiming a universal fatigue threshold or completion-time target without evidence from the people and workflow involved.
Inspect bypass paths too: mobile interfaces, keyboard shortcuts, background execution, and resumed sessions. The review control needs consistent semantics across those paths.
State the remaining limits
People can make mistakes, and a clear dialog does not guarantee detection of every harmful proposal. Approval belongs alongside scoped credentials, permission checks, and recoverable execution where recovery is possible.
Document what review establishes: a particular person authorized a particular action under stated conditions. It does not establish that the source information was true or that every downstream effect is reversible.
Read permission-boundary evaluation for execution checks and incident response for situations where an approved action still produces an unexpected outcome.