Can an AI Agent Pay Your Bills While You Sleep?

The question behind the headline

The seed is an interview with Ivan Soto-Wright, MoonPay's CEO and founder. Nothing here summarises what he said in it. The question is worth answering on its own terms: can an agent pay recurring bills without a person approving each one, and what has to be true for that to be safe?

It is a narrower problem than general agent spending. Bills are recurring, the payees are known, and the amounts are mostly predictable. That makes them one of the easier things to automate, and also a place where small design mistakes compound every month.

There are two families of mechanism. In a pull model, the payee or a contract takes the money under a standing authorisation. In a push model, the agent sends each payment from funds it controls. Most real systems mix them.

Pull: card on file and token allowances

Card on file. The oldest recurring rail. The biller stores a card credential, often a network token, and initiates each charge. An agent adds nothing to this flow except deciding whether to keep it active. The limits sit with the issuer and the biller; the agent cannot cap a charge it does not initiate.

ERC-20 allowance. The onchain equivalent. The owner calls approve for a spender, and the spender later calls transferFrom. The weakness is well known: a plain allowance has no period and no expiry, so an approval for a large or unlimited amount stays live until revoked, and a compromised spender can drain it at once.

Expiring allowances. Uniswap's Permit2 adds an amount and an expiration to each allowance, so a standing approval ends on its own. That bounds time but still not rate.

Periodic permissions. MetaMask documents an ERC-7715 permission type, erc20-token-periodic, with a periodAmount and a periodDuration: the grantee can transfer up to the amount each period, and the allowance resets at the start of the next. Their documentation's example is a dapp allowed 10 USDC per day. That is the shape a subscription actually needs: a per-period ceiling, enforced by the account rather than by the biller's goodwill.

Push: the agent pays from a bounded float

In a push model the agent holds a session key on a smart account, scoped to a spending cap, allowed assets, allowed recipients, and an expiry. On the due date, the agent fetches the bill, checks it, and signs a transfer. The account contract rejects anything outside scope.

Push gives the agent a decision point every cycle, which pull does not. That is the advantage: the agent can check the amount against history before paying. It is also the cost, because a missed run means a missed bill.

A reasonable split: pull where the biller only supports pull and the amount is fixed, with a periodic cap rather than an open allowance; push where amounts vary or the payee is paid in USDC directly.

Approval design

Autonomy for bills is not all or nothing. Approval should depend on how much the current payment differs from what has been seen before.

First payment to any payee needs a person. There is no history to validate against, and payee setup is where invoice fraud lives.

Known payee, expected amount, pays automatically. Same recipient address, amount within a band of recent cycles, on schedule.

Known payee, unusual amount, escalates. A utility bill three times normal may be correct. It should still surface rather than pay.

Changed payment details always escalate. A new account number or address on a familiar bill is the classic fraud pattern, and an agent will not notice it unless the check is in code.

MoonPay's published PayBox documentation is a useful reference for the shape of this. It describes three modes, Always approve, Approve above limit, and Autonomous within policy, and states that an approval request which gets no response times out, and that changed operation details require a new request. Approve above limit is the mode that maps to bills.

Failure modes

Insufficient float. The session key's cap or balance is lower than the month's bills. Check coverage at the start of the cycle and alert before the first due date, not on it.

Duplicate payment. The agent retries after an RPC timeout and pays twice. Key every payment to the bill identifier and cycle, and check for an existing transfer before sending.

Wrong payee. An invoice arrives with new details, or an address that resembles a known one. Compare full addresses against the stored payee, never a prefix and suffix.

Silent pull. A biller charges more under an existing allowance and nothing notices, because no one signed anything. Reconcile pulls against expected amounts as if they were pushes.

Expired authority. A session key or permit expires mid-cycle and payments start failing. Track expiries as part of the schedule.

Prompt injection from the bill. The bill is a document from the payee. Text in it should never be able to change the amount or recipient the agent pays.