Human approval for AI must control the action that actually executes

An approval button is useful only if it can still stop the consequential action. For an enterprise AI lead introducing an agent into purchasing, customer service or account administration, the design question is exactly what a person is approving and what the execution system will do with that decision.

Permission to pursue a goal such as “resolve this invoice” is too broad to authorise every payment or record change the agent might propose. Break the workflow at the point where the business consequence becomes specific, then bind the approval to that proposal.

Freeze the proposal before asking for consent

Consider a hypothetical agent preparing a supplier payment. It proposes £4,800 to a named supplier account against an identified invoice. A finance approver agrees. Before execution, the agent refreshes the source record and obtains a £6,200 amount or a different bank account.

The earlier decision cannot establish approval of the changed proposal. The execution layer should reject the mismatch and request a fresh decision. Otherwise, the interface has recorded consent while the system has performed a different action.

Build the approval record around an immutable proposal or a versioned set of material fields: action type, target, amount and currency where relevant, source-record version, permitted scope and expiry. Bind the approving identity and its authority to that record. At execution, compare the submitted action with the approved version rather than asking the model whether they are “essentially the same”.

This is an application control to design and test. A model instruction to seek permission can help the conversation, but it does not enforce the transaction boundary if the tool can execute independently.

Use the platform’s approval mechanism without assuming it does everything

Amazon Bedrock offers user confirmation for selected action-group functions. AWS documents a flow that returns action details in invocationInputs with an invocationId, and carries the user’s confirmation response through confirmationState. Those are concrete integration points for presenting and tracking a proposed action.

They are not, by themselves, proof that your application verifies finance approval limits, rejects changed bank details or prevents reuse of a previous approval. Demonstrate those behaviours in the complete application. Keep sensitive execution credentials behind a service that checks the policy; do not give the agent an alternative unrestricted route to the same operation.

Approval and access permission should reinforce each other. An agent that can propose a payment does not necessarily need the ability to release it. Where the business already has an effective transaction-authorisation process, integrate the proposal into that process instead of inventing a weaker parallel one.

Give the reviewer enough information to disagree

The screen should show the precise proposed action, its destination, relevant limits and the evidence needed to assess it. For the payment example, that includes the invoice and the source of the supplier account details. A fluent model-written explanation is not a substitute for those records.

Separate retrieved content from the application’s own controls. A supplier document can contain useful evidence, but instructions inside it should not redefine who may approve or which tool is allowed to run. Present source material as evidence to inspect, with changes and missing information made visible.

The NIST AI RMF Playbook recommends documenting requirements, roles and responsibilities for human oversight in the operational context. Put that into practice by identifying who can approve this class of action, what expertise they need, and how a decision is escalated when it exceeds their authority.

Also budget the human work. If a reviewer receives hundreds of indistinguishable requests, the workflow may encourage routine acceptance. Use policy to separate low-impact actions suitable for bounded automation from actions requiring meaningful review, and measure whether the review queue fits the available staffing. Do not silently remove approval because the queue has become slow.

Define what happens when the happy path ends

For high-impact actions requiring consent, no response should leave the action unexecuted. Set expiry and escalation behaviour explicitly. A late approval should not revive a cancelled or superseded proposal.

A stop control also needs an honest boundary. Cancelling a pending action can prevent execution; it cannot necessarily reverse a payment already accepted by another system. Record execution state and provide a separate recovery process where the external effect is reversible. Check the authoritative transaction status before retrying an uncertain result.

Before release, exercise a changed amount, changed target, expired approval, denied request, duplicate callback, unauthorised approver and stop request immediately before execution. Verify both the application response and the downstream system state. A friendly error message is insufficient if the action still happened.

Take one consequential workflow and demonstrate that every execution matches a current authorised proposal. Then extend the assessment to the agent’s permissions and failure recovery. Human oversight becomes credible when the system preserves the reviewer’s decision through to the business outcome.