Human-in-the-Loop (AI)

Human-in-the-loop is frequently invoked as a general assurance ('there's always a human in the loop') without specifying which actions actually require approval, who the approver is, or what happens if approval is bypassed. As a security control, it only functions when each of those is defined and enforced outside the model's own reasoning.

A useful human-in-the-loop boundary names: the specific action classes that require approval (irreversible financial actions, external communications, data deletion, permission changes — not a blanket 'anything the agent does'); the approver (a named role, not 'a human'); the enforcement point (the tool or gateway layer, which blocks the action pending approval — not a prompt instruction the model is expected to honour); and the fallback if approval is not obtained (the action does not execute, by default).

Prompt-layer human-in-the-loop is a weak control. An instruction telling the model 'ask for approval before sending an email' can be displaced by injected content that convinces the model approval was already given, or that the specific action doesn't fall under the rule. A human-in-the-loop boundary that lives only in the system prompt is the same category of weakness as any other prompt-layer-only control.

The durable version enforces the approval gate in infrastructure: the tool itself refuses to execute the flagged action class without an approval token issued through an out-of-band channel, regardless of what the model's reasoning concluded. This makes the boundary hold even when the model has been successfully manipulated.

Human-in-the-loop scope should track blast radius, not be uniform across an agent's entire action surface. Low-blast-radius actions (drafting, summarising, read-only lookups) rarely justify approval friction; high-blast-radius actions (irreversible writes, financial transactions, external-facing communications) are exactly where the control earns its cost.