AI Agents · Production Safety · 2026
AI Agent Human-in-the-Loop Approvals: When an Agent Should Stop and Ask
The most useful production agents are not fully autonomous at every step. They can move quickly on low-risk work, pause before irreversible actions, collect approval, then resume from the same state.
Quick answer
Human-in-the-loop (HITL) for AI agents means the workflow can pause before a sensitive action, show a person what the agent intends to do, wait for approve/reject/edit, then continue from the same workflow state.
Use it around side effects such as sending email, deleting files, changing production data, issuing refunds, publishing content, running shell commands, approving payments or calling sensitive MCP/tools. Do not force approval for harmless retrieval or internal reasoning unless your risk model requires it.
What human-in-the-loop actually means for an AI agent
A standard chatbot can ask, “Are you sure?” but a production agent needs something stronger. The approval must exist in the execution layer, not only in natural-language instructions.
OpenAI's current agent guidance separates automated guardrails from human review: guardrails validate inputs, outputs or tool behavior, while human review pauses a run so a person or policy can approve or reject sensitive work. That distinction matters because the model itself should not be the only authority deciding whether a risky action is allowed.
A good approval system therefore has four parts: risk classification, interruption, decision capture and resumable state.
Which AI-agent actions should require approval?
Approval should be based on consequence, reversibility and privilege. If a tool only reads public information, requiring a person every time usually destroys the value of automation. If a tool can create a financial, legal, operational or security side effect, approval becomes much more useful.
| Action | Default recommendation | Reason |
|---|---|---|
| Search public web | Auto-run | Low-impact and reversible |
| Read internal document | Policy-based | Depends on access sensitivity |
| Draft an email | Auto-run | No side effect until sent |
| Send external email | Approve | External communication is irreversible |
| Create a draft ticket | Usually auto-run | Easy to review or delete |
| Close/delete a ticket | Approve | Potential operational impact |
| Run read-only SQL | Policy-based | Depends on data sensitivity and query cost |
| Run UPDATE/DELETE SQL | Approve | Can change production state |
| Publish a website change | Approve or scoped automation | Public side effect |
| Issue payment/refund | Approve | Financial consequence |
| Run shell command | Approve or sandbox | Can modify system or exfiltrate data |
Use a risk matrix instead of one global approval switch
One of the most common design mistakes is making every tool either fully automatic or fully manual. A better pattern is to score each action by several factors:
- Impact: what happens if the action is wrong?
- Reversibility: can it be safely undone?
- Scope: one record, one user, or the whole system?
- Privilege: public data, internal data, or admin access?
- Confidence: is the agent operating in a known workflow or making an unusual decision?
A low-risk read can run automatically. A medium-risk edit may require approval only when confidence is low. A high-risk action should pause regardless of confidence.
Practical approval architecture
The gate should inspect the actual tool name and structured arguments. For example, “send_email(to, subject, body)” is easier to approve safely than a vague natural-language description such as “contact the customer.”
The approval UI should show exactly what will happen: destination, amount, file path, command, record IDs or external recipient. A human should be able to approve, reject or edit the request without rebuilding the entire workflow.
Pause and resume from the same state
A strong HITL design does not restart the agent from scratch after approval. The run should preserve its state, expose the pending action, store the decision and resume at the interruption point.
OpenAI's current Agents SDK documentation describes this interruption-and-resume pattern explicitly: approval pauses the workflow, the application resolves the pending decision, and the same serialized state can continue later. This is important for long-running workflows because recreating context from prompts can introduce duplication or inconsistent decisions.
Approval is not a substitute for permissions
Even an approved action should still run with the minimum required permission. Human approval cannot compensate for an agent that has a permanent admin token with access to every system.
Use both controls together:
- tool allowlists
- least-privilege API credentials
- resource-level scopes
- separate read and write tools
- sandboxed execution for code or shell work
- approval for privileged side effects
For broader safety controls around agents, see the AI agent guardrails guide.
What should be stored in the approval audit log?
If an agent can take real-world actions, the audit trail should answer who requested the action, what the model proposed, what the human saw, who approved it and what actually executed.
| Field | Why keep it |
|---|---|
| Run ID | Connects the decision to the exact workflow |
| User/request ID | Shows who initiated the task |
| Tool name | Identifies the side-effecting capability |
| Tool arguments | Shows exactly what was proposed |
| Risk level | Explains why approval was required |
| Approver | Provides accountability |
| Decision | Approved, rejected or edited |
| Timestamp | Supports incident investigation |
| Execution result | Confirms what actually happened |
Common human-in-the-loop failure modes
1. Approval fatigue
If a person must approve dozens of harmless actions, they will start clicking approve without reading. Reduce unnecessary prompts and reserve human attention for meaningful risk.
2. Vague approval screens
“Agent wants to continue” is not enough. Show concrete tool arguments and expected side effects.
3. Approval after the action
The gate must exist before execution. Logging a destructive action after it ran is observability, not approval.
4. Restarting the workflow after approval
This can duplicate tool calls or lose the exact plan that was reviewed. Persist resumable state.
5. Treating high model confidence as authorization
Confidence and permission are different concepts. An agent can be very confident and still lack authority to perform an action.
Approval workflow test plan
- Verify low-risk read tools execute without unnecessary prompts.
- Verify sensitive write tools always interrupt before execution.
- Reject an action and confirm no side effect occurs.
- Edit tool arguments during review and confirm only the approved version executes.
- Let an approval expire and confirm the workflow fails closed.
- Restart the application and confirm pending state can be restored safely.
- Test duplicate approval submissions and ensure the tool executes only once.
- Test an unauthorized approver and confirm the decision is rejected.
- Verify logs capture proposal, decision and actual execution result.
For agents that use tools heavily, pair this with systematic evaluation. See the AI agent evaluation and testing guide.
How this fits into the full agent stack
Human approval should not be the whole safety architecture. A production agent typically combines instructions, tool permissions, input/output/tool guardrails, sandbox boundaries, tracing, evaluations and human review.
If you are still building the basic workflow, start with how to build an AI agent with ChatGPT. For orchestration and automation patterns, see AI agent workflow automation.
Frequently asked questions
What is human-in-the-loop in AI agents?
It is a workflow pattern where an agent can pause before a sensitive action, present the proposed action to a person or approval policy, and resume only after a decision is recorded.
Should every AI agent tool require approval?
No. Approval should focus on actions with meaningful side effects, privilege or irreversibility. Over-approving low-risk steps creates bottlenecks and approval fatigue.
Is a confirmation message inside the prompt enough?
No. For important actions, the enforcement should exist outside the model in the tool or workflow layer so the action cannot execute until approval is resolved.
Can an agent resume after approval?
Yes. Modern agent runtimes can preserve workflow state, expose pending approvals and continue from the interrupted run after a decision.
Primary sources
Bottom line
The goal is not to make an AI agent ask permission constantly. The goal is to let it move quickly when consequences are low and stop reliably when consequences are high. Put approval around real side effects, enforce it outside the model, preserve resumable state, log every decision and keep tool permissions narrow.