Workflow design · Published 16 September 2026 · Updated 7 October 2026
Human-in-the-loop AI agents: what exactly is being approved?
A human-in-the-loop AI agent pauses a defined operation so an authorized person can approve, reject or change what happens next. The application must enforce that decision against the actual action—not just the agent's explanation. A review button does not establish who can approve, what they approved or whether the action is still valid when it runs.
This guide designs the approval step itself. The security checklist covers the broader control set; the pilot guide covers the overall release decision. The examples below are hypothetical, not client performance claims or a security certification.
What is human-in-the-loop authorization for AI agents?
Human-in-the-loop authorization combines a person's decision about a proposed action with application-enforced permission checks. The reviewer must have authority for that account and operation; the executor must still have permission when the action runs. Approval cannot grant access that the system's policy denies. An agent pausing for feedback is not necessarily enforcing authorization.
For example, an operator may be allowed to inspect and edit a draft without being allowed to approve an external send. A service identity may execute an approved message without being allowed to approve its own proposal. Record these distinctions before connecting the agent to a production tool.
| Operation | Permission to verify | A decision that must be rejected |
|---|---|---|
| Read account context | Read access to the specific account and permitted fields. | Access to another account because the requester knows its ID. |
| Create a proposed draft | Permission to add a draft to that account's review queue. | Using draft creation to send the message. |
| Approve the proposal | Reviewer authority for this operation, account and proposal version. | A reviewer approving an account outside their scope. |
| Execute the approved send | Current executor permission, valid approval and unchanged payload. | Executing after access was revoked or the recipient changed. |
| Edit a reviewed proposal | Edit permission and creation of a new reviewable version. | Reusing approval of the old message for the edited one. |
Download the approval permission-matrix template (CSV). The operation examples are prefilled; your actual identities, account scope, permission evidence and test results are blank. This is a planning aid, not an access policy or proof that controls work. Test the boundary with approved test accounts before release.
Choose the boundary by the consequence of the action
A workflow might summarize permitted CRM records without manual review, then queue a proposed message before external delivery. Other actions may need a different owner or a stronger approval rule. Define this per action with the business and security owners. Do not let a model confidence score grant permission to send, delete or change access.
Keep drafting, approving and executing separate. A person who can read an account should not automatically be able to approve changes to it. The approval endpoint must authenticate the reviewer and check their authority for the specific account and operation. See OWASP's authorization guidance for deny-by-default and per-request checks.
Show the reviewer a concrete proposal
For an external follow-up message, display the exact recipient, subject and body, the relevant source record, and the account under which the message will be sent. Distinguish retrieved evidence from an agent-generated interpretation. A summary such as “follow up with the customer” is not enough to review the recipient or the claims in the message.
- Identity: proposal ID, version, requester, account and permitted reviewer.
- Action: the specific operation and full relevant payload.
- Context: source references, record version and assumptions that must still hold.
- Decision: approve, reject or request changes, with reviewer identity and timestamp.
- Lifetime: an explicit expiry and the conditions that invalidate approval.
- Receipt: attempted, confirmed, failed or unknown execution outcome.
Bind approval to the action that will actually run
Store an immutable proposal version or equivalent protected representation of the reviewed payload. Changing the recipient or body creates a new proposal that needs review. A payload hash can help detect differences, but it does not authenticate the reviewer or replace trusted storage and authorization checks.
Recheck permissions, relevant target state and policy at execution time. An unchanged proposal can still become invalid because an account was closed or a reviewer's access was revoked. How long approval remains valid depends on the workflow; there is no universal safe expiry.
Make waiting and failure explicit states
Use persisted state so a pause survives a worker restart. Frameworks such as LangGraph provide interrupt and resume primitives, while Cloudflare documents workflow approval patterns. These primitives help coordinate a pause; your application still owns reviewer authorization and action validity.
| Event | Next state | What must not happen |
|---|---|---|
| Proposal awaits review | Pending | Execution before a decision. |
| Authorized approval arrives | Ready for execution-time checks | Treating approval as proof of successful delivery. |
| Reviewer rejects or changes the action | Rejected or new proposal | Reusing the old approval. |
| Approval expires | Expired; notify owner | Interpreting silence as approval. |
| Provider times out after an attempt | Unknown; reconcile | Blindly repeating a possibly completed action. |
A retry can create duplicate side effects. Use durable coordination and a downstream idempotency mechanism where the provider supports one. If the outcome is uncertain, query the provider's receipt or reconcile the record before retrying. An in-memory flag is not a reliable guarantee across workers, crashes or deployments.
Test the approval boundary, not just the happy path
Download ten approval-boundary test scenarios (JSON). They cover rejection, expiry, changed content, wrong-account reviewers, revoked authority, duplicate execution and uncertain provider responses. The observed-result fields are blank. This is a planning fixture, not executable authorization logic or evidence that a deployed system passed.
Run these cases against the application boundary, including attempts that bypass the review screen. A hidden button is not an access-control test. Record both the decision and the resulting external state using synthetic or approved test data.
Budget for the people in the loop
Review capacity is part of the design. In an illustrative workflow with 600 tasks per day, a 15% review rate creates 90 reviews. At two minutes each, that is 180 minutes, or three hours of review time per day, before rework, breaks and peak arrivals. These are hypothetical inputs, not a staffing benchmark.
Name the queue owner, cover absences, and measure queue age, approval latency, rejection reasons and unresolved outcomes. Report human-assisted completion separately from autonomous completion. Use the operating-cost guide to budget review effort and the cost calculator to organize assumptions before commissioning a build.
What should the implementation handoff include?
Ask for a permission matrix, proposal and decision records, tested invalidation rules, retry/reconciliation behavior, queue ownership and a stop procedure. Start with one consequential action. Broader autonomy should follow evidence that the surrounding controls work, not a more persuasive demonstration.