n8n Human-in-the-Loop AI Agent Approvals (2026)

You open the Tools connector on the AI Agent node, add a human review step, pick a channel, and wire the tools you want supervised through it. From then on, when the model decides to call one of those tools, the run stops. An approval request goes out. The execution drops into the waiting state and sits there.

Approve, and the tool runs with the arguments the model chose. Deny, and the call is cancelled. n8n documents nine channels for this — Chat, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp Business Cloud, Google Chat, Microsoft Outlook.

Underneath, it is the same machinery as the Wait node: the execution data gets offloaded to the database, and a resume call brings it back. That inheritance is the whole story. Everything that is true of a Wait node operationally is true of your approval gate, and most of the failures below are that inheritance showing up at the worst possible moment.

This is the one that surprises people, and it is not a bug. The approval URL is signed and tied to a single execution, so nobody is guessing their way in. But it carries no identity check on the other end. Whoever holds the link can click it.

A forwarded email is a forwarded approval. An approval sitting in a shared inbox is an approval anyone on that alias can grant. And afterwards your execution log records that the run was approved — never by whom. For an internal notification that is fine. For anything with money or customer data on the other side, “someone approved this” is not an audit trail.

Three ways out, in ascending order of effort:

1. Use Slack or Teams and restrict the approvers. Those channels let you list which user IDs may respond, which moves you from possession-based to identity-based. It is the cheapest real improvement available and it takes about two minutes.

2. Add a second factor out of band. Send the request on one channel and a short PIN on another, then check the PIN in a Switch node after the resume. Crude, but it means intercepting one channel is not enough.

3. Drop to the Wait node in webhook mode. You lose the pretty one-click card and you build your own approve/deny endpoint, but the resume URL is a real webhook — which means Basic, Header, or JWT auth on it. This is what I use for anything that moves money.

This is the failure I see most often in agents other people built, and it is architectural rather than accidental. The review step protects the tool it is wired to. It does not protect the agent.

So you gate the “Send Invoice” tool, feel good about it, and leave a general-purpose HTTP Request tool attached because the agent needed it for something else last month. The model now has two paths to the same billing API, and exactly one of them asks permission. It is not being adversarial when it picks the ungated one — it is picking the tool whose description best matches the task, which is the only thing it was ever doing.

The audit is quick and worth doing today. List every tool on the agent. For each one ask a single question: can this spend money, send an external message, or write to a system of record? Every yes gets gated or detached. There is no third option, because a capability the agent holds is a capability it will eventually use — that is the same lesson as choosing between a tool and a subworkflow, where the boundary you draw is the behavior you get.

A waiting execution is not a failed execution. It does not turn red, it does not fire your error workflow, and it does not show up in whatever alert you wired for failures. It just sits in the executions list with a Waiting badge, indefinitely, looking completely healthy.

The reviewer is in a meeting. Then they are on a plane. Then it is the weekend. Nine days later somebody asks why the customer never got the thing, and you find one lonely pending approval that has been patiently doing nothing since the Thursday before last. Nothing errored. That is the problem.

Both the approval step and the Wait node offer an optional time limit, and you should be setting it every single time. But the limit alone only converts a stuck run into a resumed one — you still have to decide what a timeout means. Put an IF node right after the approval and branch on it explicitly.

On timeout, default to deny. Escalate to a backup approver, notify a channel, log it — but do not let the timeout path fall through into the approved branch. A fall-through quietly converts “nobody answered” into “yes,” which is the precise opposite of what a human-in-the-loop step exists to do. This is the same discipline as designing control flow around agent failures: the default branch has to be the safe one, because the default branch is the one that runs at 3am when nobody is watching.

Let me kill a myth first, because it circulates a lot: pruning does not delete your pending approvals. n8n's execution data docs are explicit that executions with the new, running, or waiting status are not eligible for pruning. So an approval that outlives the 336-hour default of EXECUTIONS_DATA_MAX_AGE is safe on that count. Status protects it.

What is not protected is the storage under it. The Wait node offloads execution data to the database, which is exactly why a pending approval survives a restart — and exactly why it does not survive a database that was never durable in the first place. SQLite inside a container with no persistent volume, a Postgres data directory on a bind mount that gets recreated, a volume you blew away during a docker compose cleanup: every one of those takes your pending approvals with it, silently, with no failed execution to show for it.

I lost an afternoon to a version of this that had nothing to do with n8n's logic at all — a Postgres volume on a macOS bind mount that was quietly corrupting itself under gRPC-FUSE. The workflows were fine. The storage was lying. If you self-host on a Mac, read why Docker bind mounts corrupt databases on macOS before you trust anything long-lived to that stack.

One more piece if you run queue mode: the resume arrives as an inbound HTTP call, so the webhook process has to be alive and reachable to receive it. A worker scaled to zero is fine. A webhook process that is down means every approval click in that window lands on nothing, and the person clicking gets an error page while your execution keeps waiting.

You click Deny. The tool does not run. Good — that part is real, and it is enforced in the workflow rather than in the prompt. But what the agent receives is a message saying the call was denied, and a language model has no innate concept of a permission boundary. It has a concept of things that failed and might work if you try again.

So it tries again. Usually with slightly different arguments, because that is the sensible response to a failure. Or it moves on and reports to the user that the task was completed, because the conversation has to go somewhere and success is the more probable continuation. Neither behavior is a bug in n8n. It is a gap in your prompt.

n8n's documentation actually makes this a requirement rather than a suggestion — you are told to include the tool setup and the human review step in your system prompt. Most builds skip it. Something like this is enough:

Then verify it, because the whole point of a denial is that it is rare and you will not notice it silently misbehaving. Trigger a denial deliberately, read the trace, and confirm the agent stopped instead of looping. That is table stakes for observability on an n8n agent — if you cannot see the tool calls, you cannot see the retry.

Five rules, and they take under an hour to apply to an existing agent:

1. Gate by capability, not by vibe. Every tool that spends, sends, or writes goes through review. Everything else — reads, lookups, calculations — stays ungated so the agent is still useful and the human is not approving forty things a day. Approval fatigue is a real failure mode; if you gate everything, people start clicking Approve without reading, and you are back to zero oversight with extra latency.

2. Slack with restricted approver IDs by default. Email links only for low-stakes internal notifications. Anything financial gets the Wait node with authentication on the resume URL.

3. A limit on every wait, and an IF node behind it. Timeout means deny plus escalate. Never a fall-through.

4. A daily check for stale waiting executions. One scheduled workflow that queries the n8n API for executions in the waiting state older than 24 hours and posts the list to a channel. This is fifteen minutes of work and it is the single highest-value thing in this article, because it converts an invisible failure into a visible one. Silence is not the same as nothing being wrong.

5. An idempotent action behind the approval. The approval resumes an execution that then does the real work — and that work can still be retried, double-clicked, or replayed. Put an idempotency gate in front of it so one approval can never become two invoices.