An AI workflow with human approval should stop before a consequential action, present the exact proposed target, scope, changes, permissions, and effects, and accept a decision through a trusted channel. The system must bind approval to the reviewer, proposal version, allowed action, and expiry. Any material change invalidates the approval and requires a new decision.

Microsoft's Work Trend Index frames effective agent use around human judgment and agency rather than passive delegation.［1］ A real approval gate turns that principle into a technical boundary. It does not ask a person to rubber-stamp an opaque result; it gives them enough verified context to accept or reject one specific action.

Key Takeaways

Classify actions by consequence before choosing approval points.

Separate proposal generation from privileged execution.

Show a complete, human-readable approval packet.

Bind approval to identity, version, scope, and expiration.

Reapprove whenever inputs, effects, or permissions change.

Test forged dialogs, stale approvals, and indirect prompt injection.

Use the repetitive-task automation workflow to choose and prototype a bounded task. This guide begins where a proposal may lead to an external side effect.

Which actions need an AI workflow with human approval?

Classify actions by their possible effect, not by how easy they are for the system to call. Consider confidentiality, money, legal rights, safety, external communication, data integrity, account access, reversibility, number of people affected, and recovery time.

A simple tier model is:

Tier	Example effect	Default control
Read	View permitted data without changing it	Logged, least-privilege access
Draft	Produce content with no external delivery	Human review before use
Reversible write	Update a bounded record with reliable rollback	Approval or narrow preauthorization
External or privileged action	Send, publish, pay, grant, delete, or deploy	Explicit approval for exact action
Irreversible/high-impact	Safety, rights, major finance, broad deletion	Independent controls or exclude

The same tool call can belong to different tiers. Drafting an email is not sending it. Creating a proposed access rule is not installing it. Showing a diff is not deploying it. Write the risk class into the workflow definition so the model cannot downgrade an action by changing its description.

OWASP's Excessive Agency guidance recommends limiting functionality, permissions, and autonomy, and requiring user approval for high-impact actions.［2］ Approval is one layer; it does not replace least privilege, validation, rate limits, or rollback.

Step 1: Separate proposal from execution

Run proposal generation in a context that cannot perform the consequential action. The proposal stage may read allowed inputs, produce a structured candidate, validate it, and build a preview. It should not hold execution credentials.

The execution service should accept only a validated proposal ID plus a trustworthy approval artifact. It must reload the canonical proposal, recheck policy and permissions, and execute only the operation encoded there. Do not let the model send arbitrary tool arguments after approval.

This separation provides clear owners:

the model proposes;
deterministic code validates and packages;
an authenticated person decides;
a trusted executor mediates every side effect;
audit storage records the decision and result.

If generated code implements the executor, apply the AI code-review checklist. Permission enforcement, serialization, retries, and failure recovery need the same review as other security-sensitive code.

Step 2: Build a complete AI approval workflow packet

An approval screen should answer “what exactly will happen?” without requiring the reviewer to reconstruct the proposal from chat history. Include:

purpose: why the action was requested and who owns it;
target: exact account, record, recipient, environment, or resource;
scope: included and excluded items, quantity, time range, and destination;
change: a readable diff or before/after representation;
evidence: validated inputs and policy checks supporting the proposal;
permissions: which capability and credential the executor will use;
effects: external messages, writes, costs, access changes, or downstream jobs;
risk and reversibility: likely failure modes and rollback limits;
version and expiry: immutable proposal identity and decision deadline;
alternatives: reject, edit and regenerate, narrow scope, or escalate.

Use progressive detail, but never hide a consequential effect behind a collapsed summary. Highlight uncertainty and missing information. If the proposal includes many records, show both the aggregate and a reviewable sample, and require stronger review when the set exceeds the approved boundary.

Do not show only model-generated prose. Generate critical fields from canonical structured data and deterministic policy checks. The reviewer should be able to tell which statements are verified and which are model explanations.

Step 3: Bind approval to identity, version, scope, and expiry

The approval artifact should identify the authenticated reviewer, role or authority, proposal ID, content version, permitted action, exact scope, destination, expiry, decision, and decision time. Protect it using the identity and integrity controls appropriate to your system.

At execution time, compare the artifact with the canonical proposal. Reject when:

the proposal hash or version changed;
the action type, target, destination, or record set changed;
requested permissions are broader;
the approval expired or was revoked;
the reviewer no longer has authority;
policy or relevant state changed;
the artifact was already used where one-time use is required.

Approval of “send the weekly summary” is not approval to send a later draft, add recipients, attach files, or change the account. A prior general preference can guide low-risk drafting, but it should not be interpreted as perpetual authorization for consequential actions.

Keep approval lifetime short enough for the underlying state. If inventory, account access, recipients, prices, or deployment targets can change quickly, revalidate immediately before execution and request reapproval when the material effect differs.

Step 4: Define rejection, timeout, edit, and retry behavior

Rejection is a normal outcome, not an error to route around. Record a reason when useful, stop the proposal, and prevent automatic resubmission of the same action. A revised proposal needs a new identity and approval.

Timeout should fail closed. Do not translate silence into consent. Notify the owner or place the request in an expired state according to policy. If urgent action is needed, use a separately governed escalation path rather than lowering the gate.

Editing inside an approval interface can be dangerous if the displayed change and executed change diverge. Prefer “reject and regenerate” or create a new canonical proposal from the edit, then display its new version for approval.

Retries must preserve action identity. For a timeout or ambiguous network response, first query the target system to determine whether the action happened. Blindly replaying a payment, message, permission change, or deployment can duplicate the effect. Use idempotency where the downstream system supports it and design explicit recovery where it does not.

Step 5: Mediate every action after approval

OWASP calls for complete mediation of agent tool calls rather than trusting the model's plan.［2］ The executor should independently check the requested operation, arguments, target, authorization, approval binding, rate limits, and current policy.

Use a narrow operation allowlist. The executor should not accept shell commands or free-form API calls merely because the approval packet displayed a safe summary. Translate the approved proposal into a typed internal command with bounded fields.

Apply least privilege:

separate read, proposal, and execution identities;
grant access only to the target resource and operation;
avoid long-lived credentials in the model context;
cap action volume and affected records;
prevent destination changes after approval;
log denials as well as executions;
keep the kill switch outside the model's control.

Review AI privacy risks when approval packets contain sensitive source data. Show enough evidence for a decision without copying unrelated personal or confidential information into the interface or logs.

Step 6: Defend the “human in the loop AI” control from manipulation

OWASP's AI Agent Security guidance treats prompt injection, tool abuse, memory poisoning, excessive autonomy, and inadequate human oversight as connected risks.［3］ External content must not be able to create, style, or submit a trusted approval.

The Lies-in-the-Loop attack describes forged or misleading human-in-the-loop interactions that trick a user into approving an action.［4］ Treat any dialog rendered from untrusted page content, email, document, or model output as untrusted. A real approval surface should have a clear origin, authenticated session, stable proposal identity, and verified action details.

Defenses include:

render untrusted content in a clearly separated data region;
never execute links, forms, or instructions contained in that content;
keep approve and reject controls in trusted application chrome;
show the target and diff again at the final decision point;
require reauthentication for higher-risk tiers;
prevent the model from marking its own proposal approved;
send independent notifications for unusually sensitive actions;
detect framing, overlay, or origin confusion in web interfaces.

Do not rely on wording such as “this action is safe.” The decision must be grounded in independently derived fields and policy results.

Step 7: Test approvals, audit execution, and roll back

Test the happy path, then attempt to break the binding. Include:

modified proposal after approval;
changed recipient, environment, or destination;
expanded record set or permission;
expired, revoked, duplicated, or already-used approval;
approval by an authenticated but unauthorized role;
forged UI or content claiming approval;
indirect prompt injection inside retrieved material;
downstream timeout with an unknown execution result;
partial execution and rollback failure;
audit-store or notification failure.

The safe result is a visible stop, not a guessed success. Verify that the action does not occur, the attempt is recorded without leaking secrets, and an authorized operator can understand the reason.

NIST's Generative AI Profile emphasizes governance, documentation, measurement, and management across the AI lifecycle.［5］ Keep the test evidence with the workflow version and rerun it after changes to models, prompts, schemas, policies, identity systems, tools, or user interfaces.

Audit execution and make rollback real

Record proposal ID, workflow version, reviewer identity, decision, approval scope, timestamps, validation results, executor identity, downstream request identity, outcome, and rollback status. Minimize sensitive content in logs and protect them against unauthorized change.

An audit record must distinguish:

proposed but never approved;
rejected or expired;
approved but not executed;
executed successfully;
execution result unknown;
partially executed;
rolled back or corrected.

Test rollback using realistic permissions and dependencies. A button labeled “undo” is not a recovery plan if downstream messages cannot be recalled or external users already acted on them. For irreversible effects, strengthen pre-execution review or remove the action from the workflow.

Keep a manual operating procedure for outages and disputed approvals. A cold-run SOP review can expose missing ownership, credentials, or recovery steps before an incident.

How do you measure a human-in-the-loop AI gate?

Measure more than approval rate. Track proposals by risk tier, review time, rejection and regeneration reasons, changed-scope attempts, expired approvals, executor denials, critical errors, rollback success, and reviewer disagreement. A very high approval rate may indicate excellent proposals, but it may also indicate fatigue or an uninformative packet.

Sample approved actions and compare the displayed packet with the canonical proposal and actual side effect. Interview reviewers about which fields they used, what they could not verify, and when they felt pressured. Improve clarity without removing material detail.

The general AI-use guide provides a broader framework for bounded tasks and verification; an approval gate is one specialized control within that larger system.

FAQ

Is clicking Approve enough for human oversight?

No. The reviewer needs a trustworthy, complete packet and authority to reject. The system must bind the decision to one exact proposal and independently mediate execution.

Which actions always need approval?

The answer depends on your risk policy, but external communication, money movement, access changes, deletion, publication, deployment, and high-impact decisions usually need explicit controls. Some should remain outside AI execution entirely.

Can one approval cover a batch?

Only when the batch membership, scope, destination, limits, and effects are visible and fixed. Any added item or changed target should invalidate the approval or enter a separately authorized rule.

What if the proposal changes after approval?

Reject the stale approval and create a new proposal version. Do not patch the approved payload in place or assume the reviewer would accept a similar change.

How long should an approval remain valid?

Set expiry according to how quickly relevant state and risk can change. Revalidate immediately before execution and require a new decision when the effect is materially different.

Can the AI explain why an action is safe?

It can provide a clearly labeled explanation, but critical fields and policy results should come from canonical data and deterministic checks. The model's confidence is not approval evidence.

How do I prevent a fake approval dialog?

Use a trusted application origin, authenticated session, stable proposal identity, separated untrusted content, verified target details, and protected controls. Test overlays, embedded content, and indirect prompt injection.

What should happen when execution times out?

Treat the result as unknown until the target system is checked. Do not automatically replay a consequential action. Use idempotency or an explicit reconciliation process.

Related articles

Disclaimer: This article provides general security and workflow guidance. Approval requirements depend on your systems, risks, laws, and policies. Use qualified security, privacy, legal, and operational reviewers for consequential deployments.

Sources:

Microsoft WorkLab — Work Trend Index: Agents, human agency, and the opportunity for every organization — https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization
OWASP GenAI Security Project — LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
OWASP Cheat Sheet Series — AI Agent Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
OWASP — Lies-in-the-Loop — https://owasp.org/www-community/attacks/Lies_in_the_Loop
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 24 August 2026.

How to Build an AI Workflow with Human Approval