# Spending controls for an agent's wallet

An agent's spending limits are enforced either by a provider's policy engine, which is flexible and depends on that infrastructure, or by on-chain permission grants, which are rigid and depend on nothing. The controls worth having are a per-transaction cap, a rolling budget, a counterparty allowlist, a short expiry and a kill switch.

Published: 2026-10-14
Last reviewed: 2026-10-14
Publisher: Roundhouse AI Ltd.
Source: https://roundhouseai.io/resources/agent-wallet-spending-controls

---

## Why will the payment protocol not do this for you?

None of the agent payment standards provides a budget. x402 settles whatever was signed. Mandate schemes prove what was agreed, and a mandate is not a cap on cumulative spend. Card-rail protocols complete whatever checkout was initiated.

So the limit lives in the wallet, and the wallet is the thing to choose carefully. This is the most commonly skipped step in agent payment architecture, usually because two protocols are in the stack and it feels like spending must be handled somewhere in there.

## Which enforcement model should you use?

| | Policy engine | On-chain permissions |
| --- | --- | --- |
| Where enforced | The provider's infrastructure | The contract |
| Adjustable | In real time | Requires a new grant |
| Depends on | A server behaving correctly | Nothing off-chain |
| Typical form | A custodial or server wallet with rules | Account abstraction plus a permission grant |
| Fails if | The provider is compromised or buggy | The grant was written too permissively |

**Policy engines** are what most managed agent wallet products use. Coinbase's agentic wallets, launched in February 2026, apply per-session and per-transaction caps configured at wallet creation and tightenable on the fly. Other providers use similar models, some inside trusted execution environments.

**On-chain permissions** use account abstraction with permission grants, so the cap is enforced by the contract. Nothing has to behave correctly at runtime for the limit to hold.

The choice is a real trade. A policy engine is more flexible and more operable; an on-chain grant is more robust and more rigid. For an agent spending small amounts constantly, flexibility usually wins. For an agent holding meaningful value, the enforcement that does not depend on a server is worth the rigidity.

> [!IMPORTANT]
> Check what your wallet product actually enforces before assuming it enforces anything. Some agent toolkits ship with no built-in spending limits at all, and a product's wallet features and its agent features are not always the same product.

## The five controls

**1. Per-transaction cap.** The largest single loss, bounded. Set it to the largest legitimate single purchase, not to the budget.

**2. Rolling budget, per session and per day.** Caps cumulative loss from a sequence of individually plausible payments. This is the control that catches the attack shape where each payment is small enough to pass the per-transaction cap. The two together are much stronger than either.

**3. Counterparty allowlist.** For anything high value. An agent that may only pay listed addresses cannot be redirected. The cost is that it also cannot discover new sellers, so the usual shape is an allowlist above a threshold and open spending below it.

**4. Short expiry.** A permission that lapses in a day limits a leaked session key to a day. The cheapest control here and the most consistently omitted, because nothing visibly breaks when you omit it.

**5. A kill switch.** Something a human can trigger that stops spending immediately without a redeploy. Test it, since an untested kill switch is a plan rather than a control.

## How do you set the numbers?

Start from what the agent is for, not from what feels safe.

Work out the largest legitimate single payment, and set the per-transaction cap just above it. Work out expected daily spend at the high end, and set the daily budget to a small multiple of it, not ten times. A budget set far above real usage is a budget that will never trigger, which makes it decoration.

Then watch the actuals. An agent whose spend sits at five percent of its budget is over-provisioned, and tightening costs you nothing. An agent that trips its cap weekly has a cap that is wrong or a problem that is real, and both are worth knowing.

## What to do about the first payment to a new payee

The one rule that holds when everything else fails.

**Cap the first payment to any new counterparty, hard, regardless of how good its history looks.** This is the control that works when your screening data is incomplete, which it often is, and when the counterparty is new rather than bad.

A reasonable policy: a low fixed ceiling on the first payment to an address you have never paid, rising with the number of successful interactions. It costs almost nothing when the counterparty is legitimate and bounds the loss when it is not. [Screening a counterparty](https://roundhouseai.io/resources/screen-an-agent-counterparty-before-paying) covers the checks you can run beforehand.

## Frequently asked questions

### Should the agent know its own limits?

Telling it is useful, since an agent that knows its budget plans better. Relying on it is not, because anything an attacker can talk it out of is not a control. [Prompt injection](https://roundhouseai.io/resources/prompt-injection-and-agent-payments) covers why.

### How many wallets should an agent have?

At least two: an operating wallet with a small balance and a funding source that tops it up. The operating wallet's balance is then the real cap, enforced by arithmetic rather than by policy.

### Does holding only a stablecoin help?

Yes, more than people expect. An x402 buyer needs no native token, so the operating wallet can hold exactly one asset and nothing else of value. A compromised wallet with one stablecoin and a small balance is a bounded loss.

### What about gas for other operations?

If the agent only pays over x402, it needs none. The facilitator pays it. [Who pays the gas](https://roundhouseai.io/resources/who-pays-gas-in-x402) covers the mechanism and where that cost lands.

### How do I audit what an agent actually spent?

From the settlement record, which is public. Every payment the agent made is visible against its address, by counterparty and amount and time, without depending on the agent's own logs.

## Where to check this yourself

[/wallets](https://roundhouseai.io/wallets) resolves an address to its full settlement history, which is how you review an agent's spending independently of anything the agent reports. [Setting up an agent](https://roundhouseai.io/docs/guides/set-up-an-agent) covers the wallet side of getting one running.

---

Roundhouse indexes x402 settlements and ERC-8004 identities into one public record.

- Every article: https://roundhouseai.io/resources.md
- Every surface on this site: https://roundhouseai.io/llms.txt
- The index, endpoints and schema: https://api.roundhouseai.io/v0
- A key of your own, $0.01 over x402, no account: https://api.roundhouseai.io/v0/test/x402
- Limits and the SQL surface: https://roundhouseai.io/docs/api