How to build a human approval workflow for SaaS AI agents
Design safe AI-agent approvals with risk tiers, exact action previews, independent authorization, expiring decisions, idempotent execution and an auditable review trail.
In this guide
When should an AI agent pause for human approval?
Require approval when an AI agent is about to create a consequential or hard-to-reverse side effect, such as issuing a refund, changing access, sending a message, exporting private data, deleting a record or making a binding commitment. The model may propose an action, but trusted application code should enforce the approval boundary. Low-risk, reversible work can follow a separately tested policy; a prompt that tells the model to ask first is not an access-control mechanism.
Classify actions by impact and reversibility
Make an inventory of every tool action, its affected tenant and records, financial or safety impact, reversibility, and potential audience. Define which actions may run automatically, which need confirmation from the requesting user, and which require a trained reviewer or a second approver. Base the tiers on the actual consequence, not on how confident the model sounds.
Keep the approval decision outside the model
The server should create a pending action only after it validates the caller, tenant, object permissions, policy and proposed arguments. Give the reviewer an authenticated application interface. Do not accept model-generated text, a hidden prompt instruction, a callback from an untrusted client, or a replayed approval token as evidence that a person authorized the operation.
Show reviewers the exact action and meaningful context
Display the target record, requested change, amount or recipients, source of the request, relevant evidence, consequences and what cannot be undone. Mask unrelated personal data. A vague button such as “continue” makes informed review difficult; the approver must be able to compare the proposed change with the user’s request and applicable policy.
| Tool action | Risk and reversibility | Required approver | Fields shown | Expiry and fallback |
|---|---|---|---|---|
How do you prevent approval bypass and stale decisions?
Bind approval to one exact, versioned action
Store a server-created action ID, tenant, requesting identity, target object, normalized arguments, relevant record version, policy version, approver and expiry. Make any material change to the target, amount, recipient, scope or arguments invalidate the earlier approval. Do not let one approval authorize a broader batch or a later tool call.
Recheck permissions and current state at execution time
Treat approval as one required condition, not as a replacement for authorization. Immediately before execution, confirm that the user and approver still have the required permissions, the record still has the reviewed version, the action remains within policy, and the approval has not expired or been revoked. This closes the gap where permissions or facts change while a request waits in a queue.
Make retries safe without repeating the side effect
Use a unique idempotency key tied to the pending action and record an execution state such as pending, approved, executing, completed, rejected or expired. In a transaction, claim the action before calling a downstream system; reconcile ambiguous timeouts by checking the downstream result instead of blindly issuing a second payment, email or deletion. Keep duplicate approvals and duplicate delivery from running the action twice.
How should review, timeout and audit behavior work?
Fail closed when a required reviewer is unavailable
Keep the action pending or reject it when the review service times out, loses its state or cannot verify the reviewer. Tell the user what is waiting and offer a safe alternative, such as a human support route. Never treat a timeout, blank response, SDK error or agent resume as approval.
Give approvers a narrow, accessible queue
Separate the requester's identity from the person who approves high-impact actions. Support accessible controls, clear language, keyboard use and a safe way to reject or request changes. Set a service-level target and escalation path, but never encourage reviewers to approve a queue they cannot inspect. A reviewer should be able to see whether the action was already executed.
Keep a privacy-conscious decision record
Record the action ID, policy and record versions, decision, approver identity, time, execution result and request correlation ID. Store only the evidence needed to reconstruct the decision, restrict access, set retention, and protect the audit log against tampering. Avoid placing full prompts or unrelated customer records in the approval record.
Human approval for AI agents: FAQs
Can a model approve its own proposed action?
No. A model can prepare a request and explain its evidence, but approval must come from an authenticated person or a separately enforced policy engine. The execution service must verify the decision and recheck authorization.
Should every AI tool call require a person to approve it?
Not necessarily. Use risk-based tiers. A narrow, reversible lookup may run automatically after authorization, while data export, payments, deletion, access changes or external communications may need explicit review. Test the policy against real workflows and revise it when consequences change.
What should happen if an approval request expires?
Mark it expired and require a fresh action proposal and review. Do not silently revive it after a retry or apply an old approval to changed arguments. Tell the user how to resubmit safely.
Does an agent SDK approval feature secure the whole product?
No. Approval pauses are workflow controls. Your application still owns authentication, authorization, tenant boundaries, reviewer identity, persistence, expiry, idempotency, audit access and downstream execution.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- Guardrails and human reviewOpenAI API documentation
- OWASP Top 10 for Agentic Applications 2026OWASP Gen AI Security Project
- Agent Control Standard (ACS)OWASP Gen AI Security Project
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)National Institute of Standards and Technology
- Production best practicesOpenAI API documentation