AI approval design
How should human approval work in an AI workflow?
Make approval a decision about a specific, understandable action, with enough evidence for the responsible person to accept, change or reject it.
Decide which actions require judgement
Human approval in an AI workflow is an authorised person’s decision to allow a defined action before it executes. It should identify what will change, which records or people are affected and the evidence supporting that change.
Agree the boundary with the process owner. Consider financial impact, external commitments, sensitive information, reversibility and uncertainty. A read operation can also be consequential if it reveals protected data. Do not let a model’s confidence score determine its own authority.
This guide focuses on permission to execute. The human handover guide covers transferring ownership of a case; the approval automation solution covers the wider request and decision process.
Show the action, not just a reassuring summary
The reviewer needs a compact, concrete preview. Name the destination, intended recipient, affected record, changed values and important consequences. Link the source evidence and make unresolved assumptions visible. If the proposal sends a message, show the actual message and recipient.
A generic “approve the next step” button leaves too much interpretation to execution. Present approve, reject and revise choices using language that explains their effects. Show whether the reviewer is approving one action or an explicitly bounded group.
W3C’s error-prevention guidance describes checking, confirmation and reversibility for relevant consequential submissions. Use accessible labels and readable comparisons so review works on a phone and with a keyboard.
Illustrative approval screen
Review the exact action before it runs.
Hypothetical supplier clarification. This is an explanation, not a live approval form.
- Proposed action
- Send one supplier clarification email
- Recipient
- Supplier contact supplier@example.com
- Authorised reviewer
- Assigned procurement owner
- What changes
- One external message is sent. No order or payment is approved.
Please confirm the specification
Please confirm the model reference and required installation clearance for case DEMO-014 before we continue the review.
Inspect the supporting evidence
Hypothetical intake record: the request does not include a model reference or installation clearance.
Open question: the specification is not yet confirmed. The proposed email requests clarification; it makes no delivery commitment.
Revision: v2 removes an unverified attachment reference. Any material change after approval needs a fresh decision.
Reviewer choices (illustrated below, not active controls)
- Approve this versionAuthorise only the action shown.
- Request a revisionReturn the proposal for correction.
- Reject the actionStop this proposal from executing.
After approval, recheck permission and proposal version. Show sent, failed or pending confirmation from the sending service, not from the agent’s claim.
Bind the decision to the action that executes
Keep an approval record for the exact proposal version and authorised reviewer. If the recipient, amount, record or material evidence changes, require a fresh decision. Define when approval expires and whether current conditions must be checked again before execution.
OWASP’s agent security guidance recommends independent execution checks and approval tied to the action parameters. The execution service should verify permissions and approval rather than trusting a model statement that approval was received.
Record execution separately. A timeout can leave the outcome uncertain even after approval. Check the destination system before retrying an action that could create a duplicate. The integration guide explains those transaction boundaries.
Design rejection and waiting as normal outcomes
Assign an owner and a fallback for each approval category. Decide what happens when the reviewer is unavailable, rejects a proposal or asks for evidence. A missed deadline should not silently become approval.
A queue should show why the item needs attention, its age and what blocks progress. Prevent multiple reviewers from making conflicting decisions against different versions. Allow an authorised person to cancel work that is no longer needed.
Keep routine, already-authorised tasks out of repetitive review where the agreed policy allows it. Too many vague prompts can encourage automatic acceptance. Review approval frequency and rejected proposals to improve the process rather than treating a high approval rate as proof of quality.
Follow one proposal through to a verified result
Hypothetical example: an agent prepares a supplier clarification email. The reviewer sees the case reference, exact recipient, message and the missing evidence it requests. The reviewer corrects an attachment reference before approving the revised version.
- The application saves the revised proposal and records the decision.
- The sending service checks current permissions, recipient and proposal version.
- The service sends once and records its delivery-provider result.
- The case shows sent, failed or pending confirmation, as appropriate.
If the recipient changes after approval, the existing decision cannot authorise the new send. If sending fails, the user sees the failure and recovery path. The workflow must not report success because the model produced a polished closing sentence.
Test what happens when the decision cannot be trusted
Include changed parameters, expired approvals, unauthorised reviewers, duplicate clicks, withdrawn requests and unavailable destination systems in acceptance testing. Verify that every rejected or invalid proposal stops before the protected action.
Ask reviewers to explain the proposal from the preview alone. Measure review time, correction effort, uncertain outcomes and incorrect execution alongside completion. Preserve the relevant decision evidence with controlled access and agreed retention.
Use the implementation checklist to assign owners and evidence for release. Start a discussion with LCR’s AI-agent team using one action, the person authorised to approve it and examples of the exceptions.
Sources and review date
Sources reviewed on 5 September 2026. Primary sources are linked beside the guidance they support. Examples are hypothetical. Confirm the chosen systems, operating responsibilities and first release with the delivery team.
Questions
Frequently asked questions
Does every AI action need manual approval?
No. Define permissions by the action’s consequences and the organisation’s policy. Keep higher-risk judgement with an authorised person and enforce the agreed boundary in the application.
Is approval the same as human handover?
No. Approval authorises a specified action. Handover transfers responsibility for continuing a case. A workflow may need either or both.
What if the proposal changes after approval?
Material changes should invalidate the previous decision. Present the revised action to an authorised reviewer before execution.
Should a timeout count as approval?
No. Keep the action pending or route it through the agreed fallback. Reviewer silence should not authorise a consequential action.
Plan the first useful release
Bring one workflow and the questions holding it back.
Use the assessment to organise the next discussion with the team.