Cloudflare launched Wallets for AI agents this week, giving them stablecoin balances with programmable per-payment limits and merchant whitelists, running on the x402 protocol, which now sits under Linux Foundation stewardship rather than any single vendor. More than 20 companies are already participating in agent-initiated payment flows, moving the concept from demo to production infrastructure. The design gives an agent a capped, whitelisted way to pay: it can only spend up to a set amount, only with approved merchants. That's a real constraint, and it's the right instinct — bound the blast radius before you let an autonomous process touch money. But the reporting on this launch flags the actual gap plainly: current controls cap individual payments, not sequences of them. An agent that's limited to $50 per transaction can still make that $50 payment two hundred times in an afternoon if nothing is watching the pattern across calls. This is a familiar failure mode from the identity and permissions world, just showing up in a new place. A single scoped credential looks safe in isolation. The risk lives in the aggregate — in what an agent can accomplish by chaining permitted actions rather than exceeding any one of them. Rate limits, budget windows, and anomaly detection across a session are a different control surface than a per-transaction cap, and right now the tooling around x402 wallets addresses the latter, not the former. The stakes are concrete: agents paying vendors, usage-metered APIs, or contractors within defined allowances is exactly the kind of automation procurement and ops teams have wanted for years. It's also exactly the kind of automation that turns a misconfigured limit or a prompt-injected merchant substitution into instant financial loss, not a slow-burning compliance finding. What's missing isn't a new protocol — x402 and its Linux Foundation home give this a credible standards path. What's missing is the session-level accounting layer: something that treats a burst of small, individually-compliant payments as a single event to evaluate, the way fraud detection treats a card that's suddenly making rapid small charges across many merchants. Until that layer exists and is standard practice, the operational advice for anyone adopting agent wallets is to start with very small, capped limits tied to specific workflows and require human approval for any new merchant or limit change, treating every agent-initiated transaction as something to log with a clear business justification. Payment rails for agents are arriving faster than the accounting discipline to watch what agents do with them across time, not just per call.