Human approval is a system boundary

A decision must survive execution

An agent proposes an action. A person approves it. The system executes. On a diagram, this looks like a complete oversight mechanism. In implementation, each transition can change the meaning of the decision.

The resource may have changed between review and execution. A tool may use a different recipient. A retry may duplicate an operation that already succeeded. The reviewer may have approved an explanation while the system executed parameters the person never saw.

My design rule is to treat approval as a structured authorization object. It should identify the action, the actor, the resource, the exact consequential parameters and the period for which the decision remains valid. Execution checks that object independently of the model.

Make the consequence inspectable

A review interface should show the effect the person is being asked to authorize. For a message, show the recipient and final text. For a record update, show the fields and proposed changes. For a transaction, show the amount, destination and relevant constraints.

Present supporting evidence in a way the reviewer can inspect without trusting a generated summary alone. Make uncertainty and missing information visible. If the reviewer cannot understand the action within the available time, the organization has not established effective oversight simply by adding a mandatory click.

OWASP identifies excessive functionality, permissions and autonomy as contributors to excessive agency. Binding approval to execution is one proposed implementation response. It does not remove the need to minimize permissions and restrict the tool interface itself.

Prevent authority from drifting

The approval should expire. A changed action should invalidate it. A different actor should not inherit it automatically. The execution service should deny an operation when the approval is missing, stale, already consumed or inconsistent with the request.

This requires an explicit state machine: proposed, awaiting review, approved, executing, completed, rejected or uncertain. Store transitions and their actors. Use an idempotency identifier for a business operation where the downstream service supports one.

An uncertain result deserves its own state. A timeout after a write may mean the operation failed, or that it succeeded and the response was lost. Retrying without reconciliation can create a second effect that the reviewer never approved.

Design for reviewer absence

Human review is an operating dependency. Specify who is available, what they are trained to decide and how long a work item may wait. Test a queue with unavailable reviewers and a sudden increase in exceptions. Decide which actions stop rather than route to a less qualified person.

Human-on-the-loop supervision needs similar scrutiny. If an action becomes irreversible before a person can detect and stop it, a dashboard does not provide a meaningful intervention boundary. Match the oversight mechanism to the speed and consequence of the action.

Retain evidence without creating a second data problem

An audit record should connect the proposal, evidence references, decision, approved parameters and observed outcome. It should identify relevant versions and policy decisions. It need not contain private model chain-of-thought, and it should not indiscriminately copy sensitive records.

Define retention and access rules for the evidence store. Test whether an investigator can reconstruct a failed action using the permitted records. If the answer depends on screenshots from an operator's laptop, improve the system before expanding its authority.

The reference architecture turns these principles into an execution and governance design. They are engineering recommendations for review in context, not a claim that a particular implementation satisfies a legal requirement.