Table of Contents
Write the USDC spend policy on the agent wallet before you fund it, then enforce per-transaction and rolling-window caps at signing time, outside the model. The LLM does not get to raise its own limit.
How to set up an AI agent wallet creates the wallet and funds a budget. This page is the policy that stops that budget becoming a hot wallet with a chatbot on top.
Key Takeaways
- Write the USDC policy before the first mainnet fund; the model is not the policy engine.
- Caps nest: per-transaction must be less than or equal to daily, then weekly, then monthly.
- Remaining budget is EVM-wide, not chain-specific, so a Base cap also binds the same wallet on Arbitrum.
- Recipient allowlists beat blocklists, because prompt injection invents addresses you have never seen.
- Policy changes need a second email OTP; the agent cannot confirm its own raise.
- Circle spending policies are mainnet-only; testnet will not refuse an over-limit transfer.
- A hit cap is a successful control, not an error for the agent to retry.
- Logout the agent session to stop the next 402; settled USDC does not reverse.
What a spend policy is
A spend policy is a signing-time gate on how much USDC the agent can move, and to whom. It lives in the wallet product, not in the system prompt.
If the rule lives in instructions, prompt injection can rewrite it. If it lives in the wallet layer, the transfer is refused before it is submitted.
Circle's spending policies are the current reference: transfer limits plus recipient and contract allowlists, applied to outbound USDC and x402 payments. Local imported keys skip that layer, which is why they are not an agent wallet.
Write the policy before you fund
Do not fund first and "add limits later." A funded wallet with no policy is an unconstrained spender that happens to have a chatbot on top.
Circle spending policies apply to mainnet agent wallets only. Testnet will accept transfers that production would refuse, so a testnet dry run is not a policy test.
Keep the prepaid USDC small until the caps and the allowlist hold. The balance is inventory; the policy is the control.
The four velocity caps
Circle's default rule type is transfer-limit. You set per-transaction, daily, weekly, and monthly caps in USDC.
They must nest: per-transaction ≤ daily ≤ weekly ≤ monthly. A $100 per-transaction cap with a $50 daily cap is rejected at set time.
Start tighter than the prepaid budget. If the wallet holds $500, a $50 daily cap is the control and the $500 is only what could leak if the policy is missing.
Rolling windows are not calendar days. Headroom you spent this morning is still gone this evening until the window rolls.
Pick the rule that matches the failure
Velocity caps stop a drain; destination rules stop a new beneficiary. You want both, and you want the destination rule to be an allowlist.
| Rule type | What it gates | When to use it |
|---|---|---|
| transfer-limit | USDC amount per transaction and over rolling windows | Always; this is the velocity ceiling |
| recipient-allowlist | USDC only to named addresses | Default for the two or three x402 services the agent is hired to buy |
| recipient-blocklist | USDC not to named addresses | Known-bad destinations; weaker than an allowlist |
| contract-allowlist | Calls only to named contracts | Agents that must execute one specific contract |
| contract-blocklist | Calls not to named contracts | Block DEX and router drain paths |
A blocklist only stops addresses you already fear. Prompt injection invents new ones, so an allowlist of two or three services is the working default.
Coinbase opened USDC agent payments via x402 on the merchant side. Your allowlist is who the paying agent is allowed to answer.
How to set it
Authenticate the human session, then run circle wallet limit set against the mainnet address. Circle's CLI reference is the syntax source; do not let the model invent flags.
A typical first policy on Base looks like this: --policy-type stablecoin --per-tx 10 --daily 50 --weekly 200 --monthly 500, then a recipient-allowlist of the service addresses you already named. Confirm with circle wallet limit on the same address and chain.
Circle emails a second OTP to the agent-session address to confirm the change. Confirm that OTP yourself; do not let the agent poll the inbox to raise its own cap.
Do not re-run limit set while you wait for the code. Each invocation invalidates the previous OTP.
Then check remaining headroom with circle wallet limit budget. Those remaining daily, weekly, and monthly amounts are EVM-wide, not per chain, so spend on Base reduces the same budget the wallet has on Arbitrum.
What happens when a cap is hit
The wallet refuses to sign. The 402 never gets a PAYMENT-SIGNATURE, so the service is not paid.
Log that refusal the same way you log a successful spend. How to reconcile AI agent USDC spend is where those refusals become the audit trail of prompt-injection probes.
Do not retry a refused payment with a higher amount. That is the agent arguing with the policy.
x402 payments still count
Limits apply to outbound USDC transfers and to x402 payments. A sub-cent nanopayment is still spend.
x402 is only the HTTP challenge. Circle Nanopayments can batch many of those authorizations, but the wallet policy still has to allow each one before the signature is produced.
Use --max-amount on circle services pay as a second ceiling per call. That is a per-request fuse on top of the wallet policy, not a replacement for it.
Kill spend without waiting on a ticket
If the agent is compromised, tighten the transfer limits under a human OTP, then run circle wallet logout --type agent. The next 402 should fail closed.
That stops new spend. It does not recall USDC already settled; on-chain transfers do not reverse once they confirm.
circle wallet limit reset restores defaults and also needs a second OTP. Do not reset under incident; tighten first, logout second, reconcile third.
When not to raise the cap
Skip a raise if you cannot name the new beneficiary. A higher daily cap with an open destination list is more inventory for the same attack.
Skip it if the books do not close. Reconcile the prepaid USDC first, then raise.
Skip it if only the agent is asking. Policy changes require a human OTP for a reason.
FAQs
Do spend limits work on testnet?
No. Circle spending policies are mainnet-only, so a testnet transfer is not a policy test.
Are remaining budgets per chain?
No. Remaining daily, weekly, and monthly amounts are EVM-wide, so spend on one supported chain reduces the same rolling windows on the others.
Can the agent raise its own limit?
No. Setting or resetting a policy sends a second email OTP that the human principal must confirm, and if the agent can read that inbox the OTP is no longer a control.
Does an allowlist apply to x402 nanopayments?
Yes. Wallet policy gates outbound USDC, including x402 payments, before the signature is produced, so a batched settlement still started as an authorization the policy had to allow.
How do I kill spend right now?
Tighten the transfer limits under a human OTP, then log out the agent session. Do not run limit reset during an incident, and do not wait for a refund; settled USDC is already gone.
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy, sell, or hold any financial instrument, and readers should conduct their own independent research or consult a qualified professional.
){kind=link}