Place Human Approval Between AI Proposals and Execution

Human approval belongs after an AI system has assembled a concrete proposal, but before it sends, spends, deletes, grants access or makes another consequential change. Add an earlier pause when the request’s scope or authority is unclear. The implementation challenge is not simply deciding which tasks need review: it is ensuring that the action executed is exactly the action a qualified person approved.

Separate preparation from permission to act

Map the workflow into three parts: preparation, authorization and execution. Preparation includes permitted information retrieval, extraction, calculation and drafting. Authorization determines whether a specific proposal may proceed. Execution changes a business system or communicates externally.

This separation lets people review a complete decision rather than approve an abstract instruction such as “resolve this request.” It also avoids interrupting every harmless intermediate step.

Use these placement rules as a starting recommendation:

• Before preparation: resolve unclear authority or scope, particularly where accessing information itself requires permission.
• Before consequential execution: require the designated owner to approve commitments, sensitive disclosures, destructive changes and policy exceptions.
• After execution: sample low-risk, reversible actions for quality monitoring. Retrospective review is not a substitute for required advance authorization.

Keep the architecture simple. Microsoft’s orchestration guidance recommends using the least complex approach that meets requirements and notes that multiple agents introduce coordination overhead and failure modes. A conventional workflow with one model-assisted preparation step and an enforced approval gate may be sufficient.

Make approval a versioned authorization record

A chat message saying “looks good” is a weak control unless the system can establish what it authorized. Implement approval as a stored record tied to an immutable version of the proposed action.

Recommended fields include:

• The target record, recipient, amount and other execution parameters.
• Supporting evidence and the policy version used.
• Reviewer identity and required business authority.
• Approval time, expiry and decision reason.
• The proposal version and execution result.

Give reviewers a compact decision view: what will change, why it is proposed, which evidence supports it and what remains uncertain. Show source records alongside the generated summary. Offer approve, reject and request-correction options; material edits should create a new proposal version.

Enforce the gate in application code, not merely in model instructions. The component performing the action should verify approval, current permissions and unchanged parameters immediately before execution. Approval must not grant privileges the reviewer or workflow otherwise lacks.

This matters because prompt injection—malicious instructions embedded in content processed by a model—can redirect its behavior. OWASP’s prevention guidance identifies external documents and emails as attack surfaces and recommends human oversight for high-risk operations, tool-parameter validation and least privilege: granting only the permissions necessary. Human review complements those controls; it does not replace them.

Worked example: approving a customer credit

Illustrative example: A business uses AI to prepare service credits. Its hypothetical policy requires a finance reviewer for credits above $500 and a finance manager for exceptions.

A customer requests a $780 credit. The workflow reads the permitted invoice and service records, checks for existing credits and prepares a proposal:

• Invoice: INV-2048; proposed credit: $780.
• Reason: documented service interruption.
• Evidence: the relevant service record and policy provision.
• Action: create the credit against the named invoice.
• Separate draft: a customer notification, not yet authorized to send.

The finance reviewer sees the original invoice, evidence and proposed change. Approval authorizes only that credit, not an unrestricted instruction to resolve the account. The execution service rechecks the invoice balance and duplicate-credit status before posting it.

Suppose another employee issues a $300 credit while approval is pending. The original proposal is now stale. Rather than silently reducing the amount or executing the old decision, the workflow pauses, recalculates and requests approval of a new version.

The notification is then updated with the confirmed result. If external messages require review, that is a separate gate. Bundling the credit and message is reasonable only when the reviewer explicitly approves both exact actions and the workflow handles partial completion.

Design the path when approval cannot complete

Assign each queue an owner, backup reviewer and response deadline. An expired or unanswered request should remain blocked, escalate or return to manual handling—not become implicitly approved. For staffing and handoff planning, see preparing operations teams for AI-assisted workflows.

Distinguish rejection from technical failure. Rejection closes or revises a proposal. A failed network call may leave execution status unknown. Before retrying, reconcile against the destination system and use an idempotency key, a unique operation identifier that prevents repeated requests from creating duplicate actions where supported.

Missing evidence, suspected injected instructions or repeated unsuccessful revisions should route to an exception owner. Preserve the decision record and unresolved questions without presenting an unverified action as complete.

Evaluate the gate, not just the AI output

Before launch, test these concrete acceptance criteria:

• Bypass resistance: no tested protected action executes without valid approval, including direct tool-call attempts.
• Approval integrity: changed parameters, expired decisions and unauthorized reviewers are rejected in every relevant test.
• Recovery safety: retries and interrupted runs produce no duplicate business action in the recovery test suite.
• Reviewer effectiveness: measure detection of deliberately seeded errors, separately from approval speed.
• Operational capacity: track median and 95th-percentile queue age, correction rate and review time against agreed service targets.

Zero failures in a test suite is a release criterion, not proof of universal safety. Continue sampling decisions and investigating misses after launch.

AIoverflow’s automation services connect AI preparation with human decisions and controlled actions. To define the approval records, exception owners and release tests for your workflow, contact AIoverflow.