Human approval for AI agent transactions is a workflow where an agent can propose a transaction but a person must review and authorize the exact transaction before it is signed and sent. The OWASP AI Agent Security Cheat Sheet recommends human-in-the-loop controls for high-risk actions and says approval should be bound to the exact action, including the tool, target, parameters, timestamp, and expiry. A payment that moves stablecoins onchain is one of the clearest high-risk actions an agent can take.
​

The weak version of this workflow is a chat message asking whether to pay the vendor and a one-word reply approving it. The strong version shows the reviewer the decoded transaction, the simulated balance changes, and the destination, then binds the approval to those exact bytes so a different transaction cannot ride on it. This article lays out the strong version step by step and compares four approval patterns: wallet confirmation, multisig thresholds, unsigned-transaction handoff, and policy-based auto-approval below a limit.
​

Key facts at a glance:

Humans should approve the exact transaction, not the agent's description of it. The agent proposes, a simulator shows the outcome, the reviewer checks recipient, amount, approvals, and bounds against the decoded transaction, and the approval is bound to those parameters with a short expiry. Signing happens outside the agent, and every decision is logged.
​

The gap between description and transaction is where most approval workflows fail. An agent hijacked by prompt injection, or simply mistaken about decimals, can describe a correct payment while building an incorrect one. A reviewer who reads only the summary approves the summary. OWASP's guidance to separate decision-making from execution addresses this directly: the agent proposes an action, and an independent component validates scope, privilege, and approval state before execution.
​

For the injection side of this risk, see Prompt Injection Attacks on AI Agents That Hold Funds.
​

A sound approval workflow has six steps: propose, simulate, present, approve with binding, sign outside the agent, and log. Each step has a specific failure it prevents, from wrong units at simulation to replayed approvals at binding. Skipping any step leaves a path for a bad transaction to reach the chain.

The cheat sheet also says to block the action when approval validation, policy lookup, or audit logging fails. In practice: if the logging service is down, the payment waits.
​

Teams use four patterns: confirming in a wallet, requiring a multisig threshold, handing an unsigned transaction to a separate signer, and auto-approving below a policy limit. They differ in who signs, how strongly the approval binds to the exact transaction, and how much friction they add. Many teams combine two patterns by amount tier.
​

The agent builds the transaction and the person signs it in a wallet they already use. The Sauce agent docs describe this as the first signing path: transaction-building tools return unsigned transactions, which are signed in the user's own wallet and broadcast there.
​

A Safe smart account defines a list of owners and a threshold number required to confirm a transaction before execution. An agent can be one proposer while humans hold the confirming keys. Adding or removing a module also requires the threshold, which keeps an agent from quietly granting itself new execution paths.
​

The agent passes an unsigned transaction to a signer it cannot control, such as a wallet's own MCP server. The Sauce docs note that a wallet's MCP server keeps its key away from the agent.
​

Below a set amount, a policy approves without a person. The Sauce wallet policy limits a wallet per transaction and per 24 hours, by chain, recipient, native currency, and token, and the security notes state the policy is checked against a simulation before signing. That is a limit, not a review of intent.
​

The reviewer should check five things against the decoded transaction: the recipient address in full, the amount in the token's base units, every allowance the transaction leaves behind, the minimum output or price bound on swaps, and the chain. A reviewer who checks only the agent's summary is approving the agent's claim, not the transaction.

Eco's article on what happens when an AI agent sends crypto by mistake covers recovery options when review fails.
​

Batches and delegated accounts change what one approval covers. A wallet batch can bundle several calls behind a single confirmation, and a delegated account can run code that executes many operations. The reviewer must see every call in the batch and know what the delegated code is allowed to do before approving.
​

EIP-5792 lets an app ask a wallet to process a batch of onchain calls. When the app sets atomicRequired to true, the wallet must execute all calls atomically or none; when it is false, the wallet may run them sequentially with no atomicity guarantee. For an approval workflow, that flag matters: a reviewer approving a non-atomic batch is approving each call to land even if a later one fails.
​

EIP-7702 lets an ordinary account delegate to contract code, and its motivation section lists batching and privilege de-escalation, such as a sub-key limited to spending up to 1% of the total balance per day. Approving the delegation is a one-time decision with lasting effect, so it deserves the multisig-level review that a large single transfer gets. Eco's explainers on EIP-7702 and ERC-7715 wallet permissions cover the account mechanics.
​

A simple rule follows: the approval screen should list every call, its target, and its value, and the reviewer should be able to reject one call without approving the rest.
​

Eco's Sauce SDK fits the unsigned-handoff and wallet-confirmation patterns. An agent compiles and simulates a transaction program, the MCP server returns the unsigned transaction, and a human reviews the program, the simulation, and the transaction before signing in their own wallet. The program can also carry minimum-output and destination checks that hold at execution.
​

The Sauce agent docs state the review step explicitly: the user reviews the program, simulation, and transaction before sending funds. Starting the server with sauce mcp --no-wallets removes local wallet tools so the agent cannot sign at all; the HTTP server never signs.
​

Sauce also supports a pattern where the human signs and someone else submits. The security notes call a signed cook "a cheque": whoever holds it can cash it once until it expires. The recommended binding matches OWASP's advice: name the submitter, sign short deadlines, sign a fee ceiling, and cancel signatures no longer wanted. Sauce sends on Ethereum, Base, Arc, and Solana; other networks are preview.
​

Human approval fails through fatigue, poor presentation, and loose binding. Reviewers who see dozens of requests a day stop reading. Approvals shown as summaries hide what is signed. Approvals not bound to exact parameters or expiry can be reused. Approval also does not scale to high-frequency payments, which need policy limits instead.

These are short answers to the questions developers and operators ask most often about human approval workflows for AI agent transactions. Each answer stands on its own and points to the primary documentation used in this article, retrieved in November 2026, for readers who need the full detail.
​

No. Tier by risk. Small, frequent payments to allowlisted recipients can run under policy limits; large or new-recipient transfers should need a person, and treasury moves a multisig threshold.
​

No. A tool prompt approves a call, not the transaction's contents. Review the decoded transaction and simulated outcome.
​

Safe owners can be EOAs, other smart contract accounts, or passkeys, per the Safe docs. Keep the agent's key below the threshold so it can propose but not execute alone.
​

The OWASP cheat sheet lists the actor, tool name, target resource, normalized parameters, timestamp, and expiry. For an onchain payment, add the chain, the token contract, the amount in base units, and the transaction hash once it lands, so the record ties a person to the exact bytes that settled.
​

As short as practical. OWASP recommends short-lived authorization artifacts with replay protection for irreversible operations.
​

Approvals review individual transactions; spend controls cap totals. Eco's AI Agent Spend Controls covers the second.
​

Retrieved November 9 2026: OWASP AI Agent Security Cheat Sheet, OWASP LLM01:2025, Safe docs, Revoke, Claude Code permissions, Cursor MCP docs, and Eco's Sauce agent docs, wallet policy docs, and security considerations.
​

Related reading: AI Agent Spend Controls, Prompt Injection Attacks on AI Agents, AI Agent Security Checklist, AI Agent Kill Switch, Security Risks of Autonomous AI Agents, Best Smart Wallets 2026, DAO Treasury Management, AI Agents for Stablecoin Treasury.
​