human approval workflowhow to enforce approvals in ai workflowshuman approval before ai makes payment
What Is a Human Approval Workflow and Where Should It Sit in an AI-Automated Process?
A human approval workflow lets an AI agent prepare actions while a named person authorises them. See where to place gates, enforce them, and gate payments.
What Is a Human Approval Workflow and Where Should It Sit in an AI-Automated Process?
By Shiva Mangal, Grail Computer Labs
A human approval workflow is a set of steps where an AI system prepares an action but a named person must authorise it before it executes, applied to the actions where error, cost or irreversibility justify a pause. The pressure to get this right is rising. In a survey of 1,100 IT and security decision-makers, 70% of organisations now let AI take actions that required human approval a year ago (Help Net Security, 2026). Only 49% can audit every agent action (GlobeNewswire, 2026). This article shows where to place the approval step, how to enforce it, and what a payment gate should look like.
Key Takeaways
A human approval workflow lets an AI agent prepare work while a named person owns the risk decision, so the agent never commits a high-risk action alone.
Approval steps belong where an agent moves from preparing to committing, not at every step.
Approvals are only enforced when the executing system requires them. A rule in the agent's prompt is an instruction, not a boundary.
A payment gate should use maker/checker separation, approve the exact payload, and require two approvers for new payees or changed bank details.
What is a human approval workflow for AI agents?
A human approval workflow is a control in which an AI agent drafts or proposes an action and a named person authorises it before any system executes it. The agent handles preparation, such as gathering evidence and assembling the details. The person owns the risk decision. Unlike monitoring, which watches after the fact, the action cannot proceed without that decision.
A single hand pressing a physical approval stamp on a printed action sheet beside a queue of drafted sheets
The design is a split of labour. The agent reads across systems, summarises cases and drafts outputs. The human decides on the small set of actions that carry real consequences. That split keeps speed where speed is safe and puts judgement where judgement is needed.
The need is measurable. As of October 2026, 70% of surveyed organisations let AI take actions that needed human approval a year earlier, and only 49% can see and audit every action an agent takes (Help Net Security, 2026).
Three terms that get mixed up
Human-in-the-loop is a design in which a person approves an action before it runs.
Human-on-the-loop is a design in which the agent acts and a person monitors and can intervene.
Human oversight is the wider accountability: who is responsible for the agent, who reviews its record, and who can switch it off.
An approval workflow is the in-the-loop case. It is the strictest of the three, so it should be used selectively.
Where should a human approval step sit in an AI-automated process?
A human approval step belongs at the point where an agent moves from preparing to committing: before an action that is irreversible, moves money, changes access or falls outside the agent's agreed scope. Everything before that point, such as reading data, summarising cases and drafting outputs, can run without a person. Control concentrates at decision points, not at every step.
Practice already looks like this. In a 2026 Cloud Security Alliance survey run with Token Security, 53% of organisations run agents autonomously on low-risk tasks with human review for higher-risk actions, 24% use human-in-the-loop for most tasks, and 13% are fully autonomous (Cloud Security Alliance, 2026).
Donut chart: How organizations operate AI agents: autonomy models. Highest: Autonomous for low-risk tasks, human review for higher-risk actions at 53%.
An earlier guide on designing human approval for AI workflows covers the prepare-versus-gate split in short form.
Four triggers we use for a gate
We mark an action for approval when it meets any of four conditions:
A high-stakes decision.
An irreversible action.
Outlier behaviour, such as a request unlike the agent's usual work.
A boundary the organisation has set itself, such as a spending limit.
Regulators are moving in the same direction. Singapore's IMDA launched its Model AI Governance Framework for Agentic AI on 22 January 2026. It is voluntary and stresses meaningful human accountability and oversight (MDDI Singapore, 2026).
Financial institutions in Singapore have a further date to track. The Monetary Authority of Singapore (MAS) issued final AI Risk Management Guidelines on 7 October 2026. They cover all forms of AI, are proportionate to risk, and take effect on 7 October 2027 for sections 3 and 4 (MAS, 2026). Read the MAS text itself for paragraph-level requirements.
How to enforce approvals in AI workflows?
To enforce approvals in AI workflows, put the control in the system that executes the action, not in the agent's instructions. Give the agent a credential that can only draft or propose, require a separate human credential to release, and reject anything unapproved or expired. The only reliable way to prevent an AI agent from doing something is to make it physically impossible.
A conveyor of small parcels passing through a narrow gate where only some are lifted off by a hand
Rules in a prompt live in the same context as the agent. They are instructions, not boundaries. An agent that reasons around a prompt rule has not broken the system. The system never stopped it.
The gap between intent and enforcement is wide. The 2026 "Licensed to Act" survey found that 49% of organisations can see and audit every agent action, so about half cannot fully reconstruct who approved what (GlobeNewswire, 2026).
Five enforcement controls
Separate credentials. The agent's credential can create a proposal. Only a human credential can release it.
Approve the exact payload. The reviewer sees the amount, payee and details that will run, not a summary of intent.
Bind approval to one execution. An idempotency key is a unique identifier that lets a system recognise a repeated request and execute it only once. It stops an approved action from running twice.
Treat expiry as rejection. An approval that is not given in time means no.
Record the decision. Store the approver, time and payload with the action.
What happens when an agent exceeds its scope
The same Cloud Security Alliance survey asked what happens when an agent exceeds its scope. 38% require human approval, 24% require the action to be logged, and only 11% automatically block it (Cloud Security Alliance, 2026). Logging records a breach. Blocking prevents one.
Horizontal Bar chart: What happens when an AI agent exceeds its scope. Highest: Action requires human approval at 38%.
Our data: In a human-reviewed know-your-transaction (KYT) workflow built by Grail Computer Labs for a Singapore-based neobank, manual reviews took 30+ minutes and automated approvals sat at approximately 44%. A one-week build raised automated approvals to approximately 90% in testing, with people kept on the cases that needed judgement.
What human approval step should exist before an AI agent executes a payment?
Before an AI agent executes a payment, a named person should release the exact payment while the agent is limited to preparing it. This is the maker/checker pattern, also called four-eyes approval: the agent is the maker and a human is the checker. New payees and changed bank details should always need two approvers.
Two keys of different shapes on a desk beside a locked metal cash box and a signed payment slip
Maker/checker is a control in which one party prepares a transaction and a different party releases it, so no single actor can both create and approve a payment. Set separate initiate and release entitlements in the bank portal, ERP or treasury system. The agent holds only the initiate right.
Why click-to-approve is not enough
Payments are where agents are heading fastest. 85% of financial-services respondents expect AI agents to initiate and execute payment transactions on behalf of consumers, and 65% believe agent-led payments will need a new authorisation model (Cloud Security Alliance, 2026). An IMF note from 2026 lists mitigations that fit this pattern: mandate-based authorisation, separating decision-making from execution, agent identity, programmable payment controls, audit trails and tiered human-in-the-loop models (IMF, 2026).
Customers want the gate too. Worldpay's 2026 seven-market survey reports: "Many shoppers (59%) want to approve every individual purchase rather than grant an agent standing authority to buy." (Worldpay, 2026). In the same survey, 80% of consumers already open to AI shopping would let an agent play some role in payment (Worldpay, 2026).
A payment tier table
Payment situation
Agent may
Human required
Existing beneficiary, matched to an approved invoice, under a low ceiling
Prepare, and release if policy allows
None, or sampled after-the-fact review
Existing payee, no invoice match
Prepare only
One named approver
Amount above the ceiling
Prepare only
Approver with matching authority level
New payee or changed bank details
Prepare only
Two approvers
Finance teams should set the ceilings. We do not publish thresholds, because the right number depends on the organisation's risk appetite and payment rails.
How do you stop approvers from rubber-stamping AI decisions?
Stop rubber-stamping by designing the review so that approving takes real attention: show the exact change, keep queues small, require a reason on high-risk approvals and test reviewers with known-bad items. The underlying risk is automation bias. Measure approval and override rates to see whether reviewers are actually deciding.
A reviewer's desk with a short tray of documents, a magnifying glass and one document marked with a red flag
Automation bias is the tendency to over-trust an automated system that has usually been right. Singapore's MDDI warns of "greater automation bias, or the tendency to over-trust an automated system that has performed reliably in the past." (MDDI Singapore, 2026). The better the agent performs, the weaker the human check becomes.
Measurement matters here. As of October 2026, only 49% of organisations can audit every agent action (GlobeNewswire, 2026). Without a full record, approval and override rates cannot be calculated at all.
Controls that keep review real
Show the diff. Display what will change, not a description of the task.
Require a reason on high-risk approvals.
Keep queues small. If people review everything, the design is wrong. If they are surprised by important actions, it is also wrong.
Seed known-bad items into the queue and track whether reviewers catch them.
Track approval and override rates. A rate near 100% approval is a prompt to check the gate, not a sign of success.
Who is a human approval workflow not for?
A human approval workflow is not the right control for every AI process. It adds delay and cost where actions are low-risk and reversible, it cannot fix an agent that holds excessive permissions, and it depends on reviewers who have the time and authority to say no. The survey figures cited here are also self-reported.
Low-risk, reversible work. Drafting, summarising and searching do not need a gate. Gating them trains reviewers to click through. In the Cloud Security Alliance survey, 53% of organisations already run agents autonomously on low-risk tasks (Cloud Security Alliance, 2026).
Over-permissioned agents. If the agent can already execute payments, a later approval prompt is decoration. Fix the credential first. Only 11% of surveyed organisations automatically block an out-of-scope action (same survey, 2026).
Thin review capacity. A gate with no reviewer who has authority to intervene produces delay and no safety.
Evidence limits. The Cloud Security Alliance pages cited here do not show sample sizes, and the "Licensed to Act" vendor is not named in the coverage we retrieved. Treat percentages as indicators of practice, not benchmarks.
Frequently Asked Questions
Should a human approve every AI agent action?
A human should not approve every AI agent action. Approving everything creates queues that reviewers stop reading. Let the agent read, gather evidence and draft freely, and reserve human approval for irreversible actions, money movement, access changes and anything outside the agent's agreed scope.
Can an AI agent approve small payments on its own?
An AI agent can release small payments on its own only under tight conditions: an existing beneficiary, a match to an approved invoice, and a low ceiling set by the finance team. New payees, changed bank details and amounts above the ceiling should always go to a named human.
What is the difference between human-in-the-loop and human-on-the-loop?
Human-in-the-loop means a person approves an action before it runs, while human-on-the-loop means the agent acts and a person monitors the work and can intervene. Use in-the-loop for payments, access changes and irreversible actions. Use on-the-loop for low-risk, reversible tasks where an after-the-fact check is enough.
What AI agent actions should always require human sign-off?
AI agent actions that should always require human sign-off are high-stakes decisions, irreversible actions, outlier behaviour and anything that crosses a boundary the organisation has set. Payments to new payees and changed bank details belong on the same list, because errors there are hard to reverse.
Conclusion
A human approval workflow works when it is narrow, enforced by the executing system, and reviewed by people who can say no. The takeaways:
Let agents prepare freely. Gate the commit.
Place approval before irreversible, money-moving, access-changing and out-of-scope actions.
Enforce with separate credentials, exact-payload approval, single-use approvals and expiry-as-reject.
Use maker/checker for payments, with two approvers for new payees and changed bank details.
Measure approval and override rates so reviewers stay engaged.
The next step is a short audit. List every action an agent can take today, mark which ones cross the line, and check whether the executing system or only the prompt stops them.
