How to set up human approval for AI agents

Start from the tool list, not from a feeling. For each tool ask four questions. Can the effect be undone? Does it move data or money outside the system? Does it speak to a customer or the public? Does it change who can do what? A yes to any of them puts the tool on the approve-first list.

Everything else runs freely, and stays logged. Keep the approve-first list short on purpose. OWASP's guidance on excessive agency says to use human-in-the-loop control to require a human to approve high-impact actions, which is a narrower instruction than "approve everything". If every call asks, people stop reading the question.

Record the decision with the owner. The table below is a sensible starting set. Adjust it to your domain, and write the threshold values with the people who own the risk.

Some actions need approval only above a limit: a refund over an amount, a purchase over a value, an export over a number of records. Put the limit in configuration, with an owner, and review it on a schedule. Do not bury it in the prompt, where the model could talk itself past it.

Say who may approve. The person who triggered the run is often the wrong approver for high-impact actions, because they have the same incentive as the agent to finish. For the riskiest actions require someone other than the requester, or two people.

Decide what happens on silence. The safe default is to deny after a timeout, record the denial and tell the requester. An action that proceeds because nobody answered is not an approval. Set timeouts that fit the work: minutes for an interactive session, hours for a queue.

LangGraph's interrupt mechanism is built for this. You call interrupt() inside a node where you want to pause. The documentation lists three requirements: a checkpointer to persist graph state, a thread ID in the config, and the interrupt call at the point to pause. You resume by invoking the graph again with Command(resume=...) on the same thread.

There are rules that matter for approvals. When execution resumes, the runtime restarts the whole node from the beginning, not from the line where interrupt was called, so any side effect that comes before interrupt() in the node must be idempotent. Do not wrap interrupt() in a bare try/except, do not skip it conditionally in ways that change between runs, and do not reorder several interrupts in one node.

The first example below is the approve-or-cancel pattern from the documentation. Put the risky tool call in the node that the "proceed" branch leads to, so it cannot run before the decision.

If you build with LangChain agents, HumanInTheLoopMiddleware lets you declare which tools need a decision. The documentation's example sets write_file to allow all decisions, execute_sql to allow only approve and reject, and read_data to need no approval, with a checkpointer on the agent.

The decision types are: approve (run the tool with the arguments the agent proposed), edit (change the arguments before it runs), reject (skip the call and return rejection feedback to the agent) and respond (return the human's message as a synthetic tool result, for ask-the-user tools). Restrict the list per tool. For a SQL tool, allowing "edit" lets a reviewer rewrite a query, which may be what you want or may not.

Resume with the decisions list in a Command. The model name in the documentation's example is just its sample; use your own.

A bare "Allow this tool?" produces a reflex click. Give the reviewer: what the agent is trying to do in plain words, the exact tool and arguments, the user request that started the run, the text or data that led the agent here, what happens if approved, and what happens if denied. If the agent read untrusted content before asking, say so and show it. That is exactly the situation a prompt injection creates, as described in how to stop prompt injection.

Make the safe choice easy and the unsafe one deliberate. Reject should be one click and should let the reviewer write a reason, which goes back to the agent as feedback. Edit should show a diff of arguments. Avoid pre-selecting approve.

Put requests where reviewers already work. A separate dashboard that nobody opens means every request times out and is denied.

Write one record per request, whatever the outcome: approved, edited, rejected, timed out. Include the request ID, agent identity, tool and arguments (redacted where they hold personal data), the evidence shown, the reviewer, the decision, any edited arguments, any reason given, timestamps for request and decision, and the policy version that required it.

Store it separately from application logs, with write-once or append-only controls where you can. These records are what an auditor or an incident reviewer will ask for, and they let you measure the process in the next step. For oversight of high-risk systems under EU rules, see the EU AI Act high-risk checklist for how this evidence is used.

Track the share of requests approved without edit, the median time to decide, the share that time out, and how often reviewers deny or edit. A near-100 per cent approval rate with decisions in a couple of seconds suggests the gate is noise or reviewers are not looking. A high timeout rate means the queue is in the wrong place or the wrong people are assigned.

Seed some known-bad requests into the stream, clearly recorded as tests, and see whether reviewers catch them. Treat misses as a design problem: shorten the queue, improve the display, or remove approval from low-risk actions to bring attention back to the rest.

Review the gate monthly. If an action is approved every time for several months with no edits and little impact, consider whether to move it to run-freely with monitoring. If an incident shows an ungated action caused harm, add it to the approve-first list and record why.