Vice President · TheGreyMatter.ai
In brief
An approval should authorize a specific action under specific conditions, with enforcement outside the model's prose.
Key takeaways
- Show the exact action and its consequence before approval.
- Invalidate approval when the relevant payload or conditions change.
- Separate proposal, authorization, execution, and outcome in the audit record.
A confirmation button is useful only when the person clicking it understands what will happen and the system executes that approved action. Agent workflows need an approval contract that connects a visible proposal to a bounded operation. The design below is a proposed implementation pattern for consequential actions, with a hypothetical customer-message example. It is not evidence that any particular product implements these controls.
1. Classify actions by consequence
Inventory what the agent can read, draft, modify, send, purchase, or delete. Separate low-impact reversible work from operations that affect customers, money, access, or public information. Decide which actions require approval and who has the authority to give it. Avoid routing every minor step through the same confirmation screen; excessive prompts can make meaningful review harder to distinguish from routine interface friction.
OWASP's excessive agency guidance identifies unnecessary functionality, permissions, and autonomy as relevant risks. Its recommendations include limiting available tools and requiring independent approval for high-impact actions. Apply those principles at the tool boundary. If a task only prepares a message, provide drafting capability. Enabling a powerful send-or-delete interface and asking the model not to use it creates authority the task does not require.
2. Make the proposal reviewable
For a hypothetical customer email, display the exact recipients, subject, body, attachments, sending identity, and relevant source evidence. State whether sending creates an external commitment. If the agent inferred a detail, mark that uncertainty rather than burying it in polished prose. The reviewer should be able to edit, reject, or defer the proposal. A generic request to continue does not explain which consequence the person is accepting.
Keep the review small enough to perform. When a proposed batch contains many actions, show meaningful differences and allow narrower approval. Use sampling only when the organization's policy and the action's consequences make sampling appropriate. A reviewer should not approve a hundred materially different messages through a single summary that hides the actual recipients or commitments. The interface needs to match the authority being granted.
3. Bind approval to the action
Store an approval record tied to the exact action data, approving identity, permitted scope, and expiration. At execution, verify that the proposed data still matches. If a recipient, amount, attachment, or material message content changes, request a new approval. This prevents a person from approving one operation while the agent later performs another. The destination system should still enforce its own permissions and validation rules.
Decide what happens when underlying facts change between approval and execution. A cancelled order, revoked permission, or updated account status can make yesterday's approved action inappropriate today. Recheck the relevant preconditions immediately before acting. Expiration should reflect the workflow's pace and consequence rather than a universal duration. Approval is a bounded decision about a current proposal, not an indefinite delegation to improvise replacements.
4. Handle retries and uncertainty explicitly
Assign a stable action identifier and use destination-supported idempotency where available so a retry does not create a duplicate operation. Consider the case where the external service completes the action but the response is lost. The workflow should reconcile with the destination before resending blindly. Show an uncertain state to the operator until the outcome can be established. A timeout is not proof that nothing happened.
Keep proposed, approved, executing, completed, failed, and uncertain states distinct. Record the external receipt or object identifier when one exists. Limit the sensitive content stored in the audit trail while retaining enough evidence to investigate. An approval event proves that someone authorized a proposal; a delivery receipt or destination record provides different evidence about execution. Neither alone demonstrates that the recipient understood or acted on the result.
5. Test the approval boundary
Use a controlled environment to change an approved payload, replay an expired approval, remove an approver's authority, and interrupt execution after the external call. Confirm the expected result for each case. Test rejection and cancellation as carefully as approval. Include a scenario in which untrusted source text tells the agent to bypass review. Source content must not acquire the power to redefine the application's authorization rules.
Review approval quality after launch. Look for repeated rubber-stamping, unclear previews, frequent corrections, and actions that should have required a different owner. Adjust the workflow and training before increasing its scope. A useful approval design lets people spend attention on the actual decision while software enforces its boundaries. The measure of success is faithful execution of an informed authorization, with a traceable response when execution becomes uncertain.
Common questions
Does every agent action need human approval?
No. Set the boundary according to the action's consequences, reversibility, and existing authorization. Preserve human review for decisions that require it while keeping routine permitted work efficient.
What should happen if an approved action changes?
Material changes should invalidate the approval. Present the revised recipients, content, amounts, or other relevant details and obtain authorization for that specific proposal before execution.
Sources and evidence
AI assisted editorial analysis. Primary sources checked October 10, 2026. The procedures are editorial recommendations, not vendor instructions, reported customer results, or claims of personal experience. Numerical examples are hypothetical.
One useful next step: Choose one idea from this note and test it at the smallest scale that could teach you something this week.
