I work on payments, and I’ve spent the last few months thinking about one specific failure mode: an AI agent that can move money, acting while nobody is watching. The interesting attacks aren’t prompt injection. They’re the three cases below — all of which I’ve now seen in real runs, not just in theory.

  1. The look-alike payee. The agent is told to pay a known provider. The invoice names a payee that differs by one or two characters — same shape, different address. A human reading quickly misses it. A model that compares the payee against a known-recipients list catches it, if it actually checks before signing. In my own test runs this one gets rejected cleanly. In the wild, it’s the oldest trick in payments, and agents fall for it the same way people do.

  2. The reusable approval. The agent signs an approval once — say, an unlimited token approval for a spender — and that approval stays valid. A short expiry doesn’t fix it: the approval can still be reused on a slightly different payment before it expires. What fixes it is binding the approval to the exact payload (amount, payee, currency) and making it single-use. Expiry is the weak version of that control; payload binding is the strong version.

  3. The delegated account. EIP-7702 lets an externally owned account delegate to a smart contract. If the account is already delegated to a contract outside the expected set, the gate is checking the wrong thing — it’s verifying an account that no longer acts alone. The fix is reading the account code first (eth_getCode): if the code is a 0xef0100 delegation to an unexpected delegate, hold. A reader found this gap in my own work in October, and it shipped as a fix — that’s the part of open source that actually works.

The common thread: all three have to be caught before signing. After settlement there is nothing to reverse — stablecoin payments are final. A post-settlement check is an audit trail, not a control. The control has to sit between the agent’s decision and the signature, and it has to be deterministic — a rule that says yes or no for this exact payment — not another judgment call by the same agent that decided to pay.

I’m curious how people here think about this. If you run agents with any ability to act on the world: what actually sits between your agent and the consequential action — a built-in approval step, a human in the loop, or something you built yourself? And when something looks off, should it pause for a human, or refuse outright?

For anyone who wants to see the failure modes with receipts rather than take my word for them — a write-up with a real agent payment, a held unlimited approval, and a rejected look-alike, plus the testnet transaction: https://dev.to/sriram1983007/an-agent-paid-and-a-gate-stopped-two-payments-with-receipts-1ep6 https://huggingface.co/sriram1983007/SRA-RiskGate-4B