Agent Payment Security: 20 Checks Before You Ship

TL;DR

• AI agent payments rarely break in the model. In the agent payment designs we went through in October 2026, each gap was in something the payment path accepted without checking: a payout address set by a weaker key, a contract address taken from the API being checked, a payment not bound to its token or network, a signature type the guard didn't know.
• Bind every payment to amount, recipient, resource, token contract and network, and pin every contract address per chain in your own config.
• List every kind of signature the agent's key can produce. On 29 October 2026 an attacker pointed Binance's "Binance 14" hot wallet at a sweeper contract with 50 EIP-7702 authorizations signed by its key, and about $2.5 billion left the wallet in under four minutes.
• Watch your own wallets' code. A delegated account's code reads 0xef0100 plus the delegate's address, and Binance 14 stayed delegated for nearly four hours while deposits kept arriving.

Who this is for

Where the checks come from

The Binance 14 drain

1. Where the money goes (4 checks)

1. The strongest control sets the payout first. In one x402 facilitator, a merchant had to sign to change where their vault pays. But the operator deployed each vault, and its first payout address came from a dashboard setting. A leaked operator key could create vaults that pay someone else before any merchant signs anything. Find every path that writes a payout address and check which one decides first. If the payout is written once when a contract is created, a fix in the factory only covers new contracts, so go back through the creation events and have those merchants confirm.
2. Every contract address is pinned per chain in your config. Routers, bridge deposit contracts, token contracts, facilitators. A swap API for agents added recipient and minimum-output checks, but took the bridge's deposit contract address from the same bridge API it was checking. A compromised API could name its own contract and every order check would still pass, because the funds never reach the real one. An address that comes from the service you are validating is not a check. Alert when the API and your config disagree.
3. Calldata is decoded before anyone signs it. If an API returns calldata and the agent signs it, that API is part of the agent's wallet. Decode it on your server first: the target contract is on an allowlist, the recipient is the user, and the minimum output matches the quote the user saw.
4. A smart wallet address means nothing on another chain. The same contract address can have a different owner on a different chain. In June 2022, 20 million OP sent to Wintermute's address on Optimism went to someone else, because Wintermute's Safe existed on Ethereum mainnet but had not been deployed on Optimism yet, and an attacker deployed one at that address first. Verify ERC-1271 signatures and smart wallet payouts on the chain where the money lands, and reject messages that name any other chain ID.

2. What a payment is bound to (4 checks)

5. Each payment is bound to amount, recipient, resource, token contract and network. A server that only checks that a settled payment exists will serve whatever route the proof is presented to.
6. Substitution tests run in CI. A valid payment made for a cheaper route, to another recipient, in another token or on a testnet must fail when replayed against your most expensive mainnet route. The author of an open-source x402 fault-injection suite added amount, recipient, resource, token and network substitution as checks after we raised them.
7. One payment buys one response. Mark a payment as used atomically, before the response goes out. In our x402 demo, one signed payment sent 20 times at once bought 20 premium responses (replay).
8. The client's spend limit pins the token and the network, not only the number. In x402 the server's 402 response tells the client which token contract and which network to pay on. A limit that checks the recipient and the amount can be walked around by an endpoint that keeps the number the same and changes the token.

3. What the agent's key can sign (4 checks)

9. You have a list of every signature the key can produce. Transactions, EIP-712 typed data, Permit and Permit2, plain messages and EIP-7702 authorizations. A guard that knows some of them isn't a guard for the rest. One open-source agent wallet guard held unlimited approvals, Permit signatures and long expiries by default, and still approved a type 4 transaction whose authorization list delegated the whole account. Its author fixed and published it within three hours of the report. Approvals themselves should be exact, never unlimited (attack 5 in our agent wallet article).
10. Keys that should never delegate refuse the authorization payload. An EIP-7702 authorization is a signature over keccak256(0x05 || rlp([chain_id, address, nonce])). It names no recipient and no amount, and a chain_id of 0 makes it valid on every chain. Hot wallets, treasury keys and most agent keys have no reason to sign one, so the signer should refuse to build or sign anything with the 0x05 prefix, and refuse chain_id 0 everywhere. A rule that only blocks type 4 transactions sent from your hot wallet would not have fired at Binance, because the attacker sent the transaction and only the signatures came from the hot wallet's key. More on what to check in EIP-7702 wallet security.
11. The signer decodes what it signs. A signing service, MPC policy engine or HSM that signs whatever 32-byte hash it is handed cannot apply a policy, because the hash says nothing about what it authorizes. Have the signer build the hash itself from the decoded request, and reject request types it doesn't know. How Binance 14's authorizations were produced is still under investigation (checked 31 Oct 2026), and this is the first place we would look.
12. The guard is the only way to the key. A client-side guard only sees what goes through the client it wraps. If the agent, a plugin or another service can reach the raw key, or a wallet can upgrade the account on its own, the guard never sees the signature. Keep the key in a separate signer process the agent can only ask.

4. Watching the account after it signs (3 checks)

13. The wallet checks its own code before each send. Once an account is delegated, eth_getCode on it returns 0xef0100 followed by the delegate's address, the delegation designator. Read it before every send or signature and stop if it points to a delegate you didn't expect. The guard from check 9 shipped this two days after we suggested it, with a list of expected delegates so that teams who delegate on purpose don't have to turn the check off.
14. Funds stop flowing into a wallet whose code changed. Whatever already watches your hot wallets' balances can also call eth_getCode on them every block. A monitor would not have stopped Binance 14's first sweep, three and a half minutes after the delegation, but it could have stopped Binance's own systems from routing deposits into the wallet before the sweeps at 21:04 and 21:44.
15. The revoke is ready, and so is the nonce math. An authorization to address(0) clears a delegation. Authorizations signed for later nonces stay valid until the account's nonce passes them, though, and the Binance 14 transaction carried 50 of them for consecutive nonces, of which Ethereum used one. After a revoke, push the account's nonce past the highest one an attacker could hold. If the signer itself is compromised, move the funds and retire the key, because it can sign new ones.

5. What the model and the human see (2 checks)

16. The model writes no free text that leaves your system. Transfer notes, payment memos, email bodies, metadata. A banking agent we looked at kept the payee and the amount out of the model's hands, with a confirm screen outside the chat, but the model still wrote the transfer note, which lands with someone outside the bank. A model that read a malicious message can put a balance or another account number in that note. Let the customer fill the note on the confirm screen. More in outbound authority checks.
17. The human approves what gets signed, rendered by code. The approval screen shows the exact values that get signed (token contract, network, amount, recipient, expiry), built from the payload itself rather than the agent's summary, and it sits outside the chat.

6. Operators, tools and logs (3 checks)

18. Operator keys that can set payouts are treated as treasury keys. Kept separate from deploy keys, monitored and rotated, and every payout they set raises an alert. In check 1 the operator key was the weak path to every merchant's money.
19. Read-only is enforced by the database role. A September 2026 advisory for dbhub, an MCP server for databases, showed that its read-only setting never reached the connection, so the only thing left was a check on each statement's first keyword, and a SELECT that calls a function with side effects could still write (GHSA-mwwr-p57h-56pf). Give agent tools a database role that can only read. A read tool next to a tool that sends anything out is still a way to leak what it reads (check 12 in our MCP checklist).
20. Every payment decision is logged with its inputs. Which payment requirements, which quote, which upstream answer, which approval, which signature. When something goes wrong, "the agent paid" is not an incident report.

Before you ship

• Draw the payment path from the agent's decision to the money landing, and mark every value that comes from outside your own code.
• Run the substitution tests from check 6 against your real routes on a testnet.
• Send your signer one EIP-7702 authorization request and see whether it signs.
• Write down who can revoke a delegation, rotate a key and stop routing funds, and how long each takes.

FAQ

Glossary