CyberFreezeDev- Home
- Blog
- How-to guides
- Human approval for AI agents: where to put the checkpoint
Human approval for AI agents: where to put the checkpoint
An AI agent should propose and a person should approve wherever an action moves money, reaches a customer or deletes data. Here is how to build the queue, what to do when nobody answers, and what to log.
Put a human checkpoint in front of every action an AI agent cannot easily undo: moving money, sending a message to a customer, and deleting or overwriting records. The agent proposes the action, it waits in an approval queue, a named person approves, edits or rejects it, and the decision is logged. If nobody answers in time, the action expires rather than going ahead.
If you are new to the idea, our glossary entry on human in the loop covers the basics. This guide is about building it into an AI agent that uses tools.
Which agent actions need a human checkpoint?
OWASP's 2025 list of risks for language model applications names "excessive agency" as one of them: an agent with too many functions, too many permissions or too much autonomy. Its advice is to "require a human to approve high-impact actions before they are taken". Its example is an email assistant that a malicious message tricks into forwarding private data. The fix there is to let the agent draft and have a person send.
A workable rule is to sort every tool the agent can call by what happens if it is wrong.
| Action | Examples | Checkpoint |
|---|---|---|
| Moves money | Payments, refunds, discounts, issuing an invoice, recording a payment | Always approve |
| Reaches a customer | Emails, WhatsApp replies, quotes, posts on social media | Approve until the error rate is measured, then sample |
| Deletes or overwrites | Deleting records, merging contacts, bulk updates | Always approve, and keep a backup |
| Changes access | Sharing files, adding users, changing permissions | Always approve |
| Reads or drafts | Searching, summarising, drafting, tagging | No approval needed |
Tools that only read can run freely. Give the agent read-only access wherever it does not need to write, which removes most of the risk before any approval step.
How should an approval queue work?
A queue is a list of proposed actions waiting for a decision. Each item should show:
- What the agent wants to do, in plain words: "Refund £42.00 to order 1187".
- The source it worked from: the customer's email, the bill, the record it plans to change.
- Why: the rule or reasoning that led there, and the model's confidence if you have it.
- Three buttons: approve, edit then approve, reject with a reason.
Give each queue one owner and a backup, so items never sit with "the team". Route by type and value: refunds to the accounts lead, customer replies to the support lead, anything over a set amount to a director.
In n8n, the AI Agent node can require human review before a tool runs. The workflow pauses and sends the request through Slack, Microsoft Teams, Gmail, Outlook, Telegram, WhatsApp or n8n's chat. The reviewer sees the tool name and the parameters the AI chose. If they approve, the tool runs with those parameters; if they deny, the action is cancelled and the agent is told. You can apply review to every tool or only the risky ones, and n8n advises describing the review setup in the agent's system prompt so it handles a refusal sensibly.
What happens when nobody answers?
Decide the timeout before launch, because an agent waiting forever is a hidden backlog. Three rules work for most businesses:
- Expire, do not proceed. If an approval is not given in time, the default is to do nothing. A refund that nobody approved is not issued.
- Remind, then escalate. Send one reminder to the owner, then pass the item to the backup or a manager.
- Tell the person waiting. If a customer is waiting on the action, send a holding reply written by a person in advance, not one the agent invents.
n8n's Wait node stores the paused execution in the database and has a Limit Wait Time setting that resumes the workflow after a set interval or at a set time. Point that branch at your expiry and escalation steps.
What should the audit trail record?
For every proposal: what the agent proposed, the inputs it used, who approved or rejected it, when, what they changed, and what was finally done. Keep the edits as well; they show where the agent goes wrong and become test cases.
Check that the record really says who approved. n8n's own Slack documentation is a good example: its default approval links are signed, so nobody can tamper with them, but anyone who has the link can respond and n8n cannot tell who clicked. Turning on Capture Who Responded records the responder's identity, and Restrict Who Can Approve limits approval to the people you list. Post sensitive approvals to a private channel or direct message, because the list controls who can respond, not who can see.
Two working examples
An n8n approval workflow. We have built an approval workflow on n8n with AI routing and an audit trail: requests are read by a model, sent to the right approver, and every step is logged. The model does the reading and routing; people make the decisions.
Fint's Inbox. In Fint, our accounting product for Indian businesses, an AI agent proposes records, and a person confirms each one in an Inbox. Money is never recorded without that confirmation, and Fint keeps an audit trail.
Both follow the same pattern: the AI proposes, a person decides, and the log shows who decided. For when you need an agent at all rather than a fixed workflow, read AI agent vs workflow automation.
Build approvals in from the start
Adding approval after launch means rewriting the tools the agent calls. Our AI agent development work starts by listing those tools, marking which ones move money, reach customers or delete data, and designing the queue, timeouts and log around them. If you are planning an agent and want the checkpoints in the right places, tell us what it will do. Book a consultation.
