Luna

Posted on Jul 28 • Originally published at builderlog.net

AI Human in the Loop: 5 Stop Gates Before an Agent Acts

#ai #productivity #smallbusiness #buildinpublic

An AI human-in-the-loop control is useful only when the workflow stops before the action and shows a named reviewer what will actually happen. Put a hard stop before unapproved input, external communication, money movement, novel exceptions, and privileged changes. Then require a trusted preview, an explicit decision, and a receipt.

Run the free 60-second first-task check

The short answer and scope

Reviewed on 2026-07-29 for a beginner workflow using approved test data. The scope excludes autonomous sending, publishing, payment, deletion, code execution, and permission changes.

Human review is not a decorative “approve” button after the model has already acted. It needs:

a stop that technically prevents the action;
a named reviewer with enough context to decide;
a preview built from trusted system state rather than model-written reassurance;
approve, reject, edit, and return-to-manual choices; and
a receipt showing the proposed action and the human decision.

NIST AI RMF Govern 3.2 calls for roles and responsibilities to be defined for human-AI configurations and oversight. The OECD AI Principles call for context-appropriate human agency and oversight. Those are governance outcomes, not a ready-made interface or proof that a reviewer will catch every error.

Copy the five stop gates

Apply every gate before an AI-assisted workflow receives authority.

Stop gate	Stop when	Reviewer must see	Safe outcome
Input	The input contains a secret, personal record, confidential file, or unapproved source	Source identity, data class, redactions, and allowed-use rule	Reject, redact, or use fictional input
External action	The workflow will email, message, publish, submit, or contact someone	Exact destination, final payload, identity used, and timing	Edit, approve one action, or keep as draft
Money	The workflow will purchase, refund, transfer, price, or create a commitment	Amount, recipient, policy, evidence, and reversal path	Reject or route to an authorized owner
Exception	The source conflicts, required evidence is missing, or the case is outside known rules	Missing fact, conflicting sources, uncertainty, and manual route	Stop and classify as an exception
Privilege	The workflow will delete, execute code, change access, expose a secret, or alter production state	Exact command or diff, target, blast radius, backup, and rollback	Reject, sandbox, or require a separate privileged owner

These are Builderlog stop gates, not the text of a NIST, OECD, or OWASP checklist.

Copy this control block:

Proposed action:
Stop gate triggered:
Input source and classification:
Exact destination or target:
Exact payload, command, or diff:
Evidence used:
What is unknown:
Expected effect:
Worst credible effect:
Can it be reversed:
Rollback or manual fallback:
Named reviewer:
Decision: reject / edit / approve once
Decision expires at:
Receipt location:

An “approve all future actions” option defeats the boundary. Approval should apply to the exact preview, destination, and payload shown.

A worked example: customer reply draft

Suppose a workflow receives a fictional customer question and public FAQ text. It proposes a reply but cannot access a real inbox.

The input gate confirms that the question is fictional and the FAQ is an approved source. The exception gate fires if the question does not match a known policy or two FAQ passages conflict. The external-action gate always fires before a real message could be sent.

The reviewer sees the destination, final reply, cited FAQ section, missing facts, and an edit view. Reject leaves the existing manual path untouched. Approve once permits only the displayed message to the displayed destination. Any content change invalidates the decision and requires a new preview.

This design does not prove the reply is correct. It separates drafting from sending and makes the human decision observable.

The approval dialog can be the attack

OWASP describes “HITL dialog forging,” where untrusted content manipulates how an approval request is presented. A model or webpage might claim that tests passed, hide a destination, rename a destructive action, or frame a risky request as routine.

That means the same model proposing an action should not be trusted to summarize why approval is safe.

Use a trusted controller to render:

the literal destination or resource identifier;
the raw command, diff, or final outbound payload;
the permissions involved;
the source of each fact;
a clear irreversible-action warning; and
the exact scope and expiry of approval.

The reviewer still may make a bad decision. The technical stop, least privilege, sandbox, logging, and rollback remain separate controls.

Record overrides, errors, and no-go decisions

NIST Playbook material suggests documenting oversight roles and measuring overrides, errors, complaints, escalations, and go or no-go decisions. The Playbook also says it is voluntary, tailorable, and not a universal ordered checklist.

A small workflow can keep a simple receipt:

Run:
Gate triggered:
Reviewer decision:
Edit made:
Reason:
Action executed:
Result verified:
Rollback used:
Error or complaint:
Rule or source to update:

Review the receipts for repeated edits and exceptions. If reviewers routinely click approve without inspecting the preview, the control is not functioning. If the same exception recurs, update the source or rule before widening authority.

Failure modes and non-fit cases

Human review can fail because the reviewer lacks expertise, is rushed, trusts fluent text, cannot see the true target, or receives too many approvals. A stop gate can also be placed too late, after data exposure or an external write already happened.

Do not treat this article as legal, employment, financial, compliance, or security advice. High-impact decisions and regulated data require context-specific controls and qualified review. Some read-only, low-impact tasks may not need the same approval flow; NIST Appendix C notes that oversight needs vary by system and context.

Related Builderlog field manuals:

Final decision and sources

Put the human before the consequential action, not after it. Stop on sensitive input, external communication, money, exceptions, and privileged changes. Show a trusted preview, bind approval to that exact action, preserve reject and manual fallback, and keep a receipt.

Sources reviewed 2026-07-29:

The sources support defined oversight roles, context-appropriate human agency, approval for consequential actions, previews, audit trails, and the risk of deceptive approval interfaces. They do not validate these five gates or guarantee a safe result.

TL;DR: A human in the loop needs a real stop. Show the exact action from trusted state, permit rejection, and bind approval to one preview.

The useful artifact is the approval receipt and exception log, not the presence of an approve button.

DEV Community