Set USDC Spend Limits Before Funding AI Agent Wallets

Operators must write a USDC spend policy for an AI agent wallet before adding significant funds on mainnet. Per-transaction and rolling-window caps are enforced at signing time in the wallet layer, outside the language model, and the model cannot increase its own limits. Policy changes require a human one-time passcode (OTP) to confirm.

A spend policy is a signing-time gate built into the wallet product, not a system prompt or instruction set. If rules live only in the agent’s prompts, a prompt-injection attack can overwrite them. Wallet-level controls evaluate transfer limits, recipient and contract allowlists, and blocklists when preparing a signature. Keys imported locally bypass that signing layer and do not receive these protections.

Operators must set limits on mainnet before funding. Wallet command-line interfaces offer limit-setting commands; for example, administrators run a wallet limit set command against the mainnet address and then confirm a second OTP sent to the human session address. The human principal must confirm that OTP; if the agent can read the inbox, the OTP no longer functions as a human control. Each limit-set request invalidates the previous OTP until confirmation is complete.

Velocity caps include per-transaction, daily, weekly and monthly ceilings. Those caps must nest: per-transaction must be less than or equal to daily, daily less than or equal to weekly, and weekly less than or equal to monthly. A configuration that has a higher per-transaction cap than its daily cap will be rejected at signing time. Rolling windows are measured as rolling intervals rather than calendar days, so spent headroom remains consumed until the window rolls.

Recipient allowlists provide stronger protection than blocklists because prompt injection can invent new addresses. For agents expected to pay a small set of services, operators typically limit outbound USDC to two or three named recipient addresses. For agents that must call specific smart contracts, contract allowlists can restrict calls to named contracts.

Outbound-USDC rules apply to small authorization flows and nanopayments. Sub-cent authorizations and batched nanopayment settlements still require each authorization to pass the wallet gate. Wallet-side per-request limits, such as a max-amount flag on service pay calls, act as a second ceiling in addition to the wallet policy.

When a cap is hit, the wallet refuses to sign and the payment flow does not produce a PAYMENT-SIGNATURE. That refusal prevents the transfer and should be logged alongside successful spends to create an audit trail of attempted prompt-injection probes. Operators should not retry a refused payment with a higher amount.

If an agent is suspected compromised, operators can tighten transfer limits under a human OTP and then terminate the agent session with a logout command to stop further signed payments. Do not run a limit reset during an incident, because a reset restores default values and also requires a second OTP. Tighten limits, log out the agent session, then reconcile balances. On-chain USDC transfers that have settled do not reverse.

Circle-style spending policies apply only to mainnet agent wallets; testnet environments will accept transfers that production policies would refuse and therefore do not validate mainnet policy settings. Remaining daily, weekly and monthly budgets are measured EVM-wide rather than per chain, so spend on one supported chain reduces the same rolling windows available on others.

Operators are advised to document the policy before any mainnet funding, confirm the OTP themselves, enforce nested velocity caps and maintain recipient allowlists. These measures place authority over USDC movement in the wallet layer rather than in the agent’s prompts.