How human approval workflows reduce AI risk in regulated organisations.
Short answer. A human approval workflow stops an AI agent’s proposal short of execution until a named person authorises that exact action. It differs from reviewing output because the approval binds to one specific proposal. A general policy that someone checks things afterwards does not bind to anything. Built properly, it also handles rejection, expiry and who is allowed to approve, with a record for each step.
Regulated organisations already run approval workflows for payments, access grants and change requests. An AI agent that can send, post or modify a record needs the same gate. The proposal coming from a model instead of a person does not earn it a lighter one.
What is a human approval workflow for an AI agent?
It is the pipeline between an agent producing a proposed action and that action reaching a system of record. The agent drafts an email, a ledger entry, a permission change or a support reply. The workflow captures that proposal, presents it to an approver, and only allows execution once the approver’s decision is recorded against it. Nothing the agent proposes changes a system of record before that gate.
What is the difference between reviewing output and approving an action?
Reviewing output checks whether text or a result looks right. It does not by itself control whether an irreversible action happens, because the check can occur after the action has already fired, or apply only to a sample of cases. Approving an action authorises one specific state change: this email sends, this entry posts, this access grants.
OWASP’s LLM06:2025 Excessive Agency guidance names three root causes of an agent doing damage: excessive functionality, excessive permissions and excessive autonomy. Reviewing output addresses none of the three directly. A binding approval workflow addresses autonomy, by putting a human decision between the proposal and the system it touches. The permissions cause is a separate fix, covered in AI access is not one permission, it is five.
What must the approver actually see?
Three things, every time. The exact proposal as it will execute, in full. The recipient or record it will act on, named plainly. And the source data the agent used to produce the proposal, so the approver can judge whether it was reasonable to draft. Leave any of the three out and the approval becomes a formality. It stops functioning as a control.
How do you bind the decision to the proposal?
Tie the approval to the specific content shown. Binding it to the task in general defeats the point. Give each proposal an identifier, and log that identifier alongside the approver’s decision and a copy of what was displayed. If the agent revises the proposal after approval but before execution, that is a new proposal and needs a new approval. Security teams know this gap by another name: the time between check and use is exactly where privileged-access controls fail when they are built loosely.
What happens on rejection?
A rejected proposal does not execute, in whole or in part. The workflow logs the rejection with the approver’s identity and, where captured, the reason. A second check confirms the source system shows no change from the rejected proposal. The agent may generate a new proposal for the same task, but the workflow should treat it as a fresh submission, separate from the one that was turned down.
What about expiry and replay?
An approval should carry a time window. Underlying conditions move: a balance changes, a ticket closes, a person leaves. An approval granted against yesterday’s state should not authorise an action against today’s, so an expired approval must be blocked at execution time and the block logged. The same identifier should also be usable once. A workflow that lets one approval authorise two executions has a replay gap (the same approval reused to trigger the action twice), whatever else it gets right.
What is separation of duties for an AI approval workflow?
The person who requests or configures a task should not also be the person who approves the agent’s proposal for it, at least for anything with real impact. Keep the requester’s identity and the approver’s identity as separate fields in the record, and block self-approval at the workflow level. Do not leave it to a person to decline their own request. The same principle that keeps one person from raising and approving their own invoice applies here.
Where do these workflows fail in practice?
The table below pairs each failure mode with what actually goes wrong and the control that closes it, along with the record that proves the control ran.
| Failure mode | What goes wrong | The control and its record |
|---|---|---|
| Approval bound to a summary | The approver signs off a paraphrase; the executed action carries a different amount, recipient or scope | Render the literal content the agent will send or post; log that exact content against the decision |
| Stale approval replayed | The environment changed after approval, but the action still fires against the old state | Time-bound, single-use approval identifiers; re-check the source state at execution and log the check |
| Requester approves their own proposal | One person routes a task through the agent and then approves the result themselves | Separate requester and approver identity fields; enforce the block on self-approval in the workflow itself |
| Rejection not verified | The approver says no, but the agent or a retry executes the action regardless | An independent check of the source system after rejection, logged as a pass or a fail |
| Shared service account | The agent runs under one shared login, so no record shows which human actually approved | Individual approver identity tied to the decision, distinct from any shared credential the agent uses |
| No expiry on approval | An old approval is used weeks later against a record that has since changed | An expiry window on the approval token; expired attempts blocked and logged |
How do you test an approval workflow before you rely on it?
- Submit a low-stakes proposal and capture exactly what the approver saw on screen, separate from the underlying request.
- Approve it, then compare the action that executed against the proposal that was shown.
- Have the agent generate a second, different proposal for the same task, and confirm the first approval cannot authorise it.
- Reject a proposal and check the source system directly for any change. Do not trust the workflow’s own status field.
- Wait past the approval’s expiry window, attempt execution, and confirm it is blocked and the attempt is logged.
We describe the auditor’s version of this same test in how to prove AI controls to an auditor. Run it yourself before an auditor runs it for you.
What does the EU AI Act require here?
Article 14 of the EU AI Act requires high-risk AI systems to be designed so that a natural person can effectively oversee them while in use. Oversight measures must match the system’s risk and level of autonomy. The Digital Omnibus, in force since 27 July 2026, moved the application dates for high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems (dates reviewed against the regulation text on EUR-Lex, reviewed through 3 October 2026). The article does not mandate a specific workflow design. It sets the outcome; the binding, expiry and rejection handling above are one way to reach it. Confirm with counsel which of your systems fall under Annex III before you treat this as settled.
Questions buyers ask.
Does Article 14 of the EU AI Act require a human approval workflow specifically?
No. It requires effective human oversight for high-risk systems, matched to their risk and autonomy, without naming a workflow pattern. Binding approval to an exact proposal, with expiry and a rejection path, is one design that can satisfy the requirement. Confirm scope with counsel first.
Is reviewing the AI’s output the same as human oversight?
No. OWASP’s excessive-agency guidance and the Act’s oversight requirement both point past content review to whether a person controls execution. Output review alone still lets an agent act before anyone can stop it, unless execution is gated on that person’s decision.
What is excessive agency, and how does an approval workflow address it?
OWASP LLM06:2025 names three causes: excessive functionality, excessive permissions and excessive autonomy. An approval workflow addresses autonomy directly, by putting a human decision between the agent’s proposal and any state change in a connected system.
Can a rejected proposal be resubmitted automatically?
Not without a fresh proposal and a fresh approval. Treat a rejection as a stop. The workflow should log any resubmission as a new event tied to a new identifier, separate from the one that was turned down.
This is the same discipline, tying every approval to a specific record, that sits behind the twelve tests in the Agentic AI Procurement Handbook. It is what I would check first when a regulated organisation asks whether its AI agent is safe to run. Handvantage builds Vantage Workspace, a self-hosted AI workspace built so that AI actions go through human approval and leave a record, so weigh my view accordingly. This is an evaluation method. It is not legal advice, and your compliance function should confirm which obligations apply to your systems.
The workspace site turns this into a test protocol for a pilot: Human approval for AI agents: what the approver must see.
Josh Olayemi · Founder, Handvantage · September 2026 · About the author
