Your agent can pay. It can’t overspend.
An agent holding an API key and a wallet decides for itself how much to spend. Tollbeam puts the limit outside the agent: every payment is checked against your policy before it is signed, and the key that spends cannot raise the ceiling.
Including the money it pays strangers
Every cost control your team already owns caps spending against a provider you have a contract with — a cloud bill, an inference bill, a card. None of them can meter a payment to a party you have never signed anything with, because there is no account to meter it against.
That is much of what an autonomous agent does: buy one dataset, one API call, one document, from whoever happens to have it. Tollbeam governs that payment on the rail it travels through, so the destination needs no relationship with you and none with us. The limit is enforced at the moment of payment, and the attempt is recorded either way.
It is the one thing on this page we do not think you can buy anywhere else. The rest — per-agent caps, stacked windows, enforcement that fails closed — you can get free from an inference proxy, and you should, if your agents only ever pay providers you already have accounts with.
Why a prompt is not a limit
Telling the agent isn’t enough
“Spend at most $50 a day” in a system prompt is a request. The same model that decides what to buy decides whether to obey it, and a bad prompt or an injected instruction is all it takes.
A small wallet is blunt
Funding a wallet with $50 does cap the damage. It also means no rules about what may be bought, a human topping it up by hand, and no record of what the agent tried to do and was stopped from doing.
The easy version is easy
A hard cap in a config file takes an afternoon, and for a single agent it is enough. What takes longer is the part that only appears in production: what the ledger says when the agent dies after the check and before the payment settles. Getting that wrong is how a budget quietly stops meaning anything.
Where the limit lives
On the rail the money moves through, not in the agent.
- Checked before signing. An over-limit payment never happens, rather than being reversed afterwards.
- The key can read the budget, not change it.
GET /v1/budgettells an agent what it has left, and when we read it. Editing a policy needs a signed-in human. - Refusals are recorded. What the agent tried to spend, and what we stopped, with the policy that stopped it.
- One total, not a resetting one. A lifetime limit means $5 in total, not $5 every month forever.
- A limit can name a merchant. Cap what an agent may spend at one host, or set that limit to zero to block the host entirely.
Start on a test network, for nothing
Signing up issues a sandbox key immediately. It pays real x402 resources on Base Sepolia with real EIP-3009 authorizations and real on-chain settlement — the same code path as mainnet, on a network where the money is worthless. No card, no credit to run out, nothing to cancel.
- · Default limits on day one: $1 per payment, $5 per day
- · A sandbox key is refused on mainnet, by the rail, before anything is signed
- · We fund the testnet wallet, so you need no test tokens of your own
The point of the default limits is that your first refusal is one you caused. Ask for something above $1 and you will get policy_limit_exceeded with the limit, the attempt, and the policy that stopped it — in the response and in your ledger.
What it costs
You are charged for seats and apps, not for the money your agents move. We take no percentage of your payments, and we do not mark up settlement. An incentive to route more of your money is not one we want.
- Every limit type: per-payment, hourly, daily, monthly, lifetime
- Per-agent, per-merchant and global scopes
- Refusal ledger and spend reports
- Dry-run a policy against your last 30 days
- Sandbox and mainnet
- Everything in Free
- Email support
- Multiple apps per environment
- Everything in Team
- Priority support
- Planned: approval above a threshold, default-deny merchant allowlists, SSO
- Bring your own signing keys
- Invoicing, security review, SLA
- Your own facilitator
Two honest notes. Items marked planned are not built yet and are listed so you can see where a paid tier is going, not so you can buy them today. And paid tiers are not self-serve checkout yet — sign up free, then tell us which tier you want and we will set it up by hand. We would rather admit that than put a button here that does not work.
What it does not do yet
This rail is new. It is more useful to tell you the edges than to have you discover them.
One chain, one asset, one protocol
USDC on Base mainnet, paying resources that speak x402. If the thing your agent needs to buy does not accept x402 payments, this cannot buy it yet. Cards and other chains are what we are building next.
You can name merchants, but not default-deny
A limit can apply to a single merchant, and setting it to zero blocks that host outright — so a denylist works today. What does not exist yet is the other direction: “only these hosts, refuse everything else.” Nor does escalating to a human above a threshold.
Gas credit is not payment credit
The $50 free credit on the gas side funds gas we front for your users. It cannot buy your agent’s USDC. They are separate rails with separate money.
Questions people actually ask
For agent payments, yes, and you should know that before you build on it. Paying with x402 means signing an EIP-3009 authorization, so something has to hold a signing key. Ours live in AWS KMS, one per app where you want isolation, and the private material never leaves KMS - we call it to sign a specific digest and it returns a signature. If you would rather hold your own, bring your own key on Enterprise. Note this differs from gas sponsorship, where we hold nothing.
No. Limits are enforced without a human in the loop - that is the point of putting them on the rail. Approval above a threshold is a planned addition for people who want a human on the large ones, and it will be opt-in per policy.
The budget stays held rather than leaking, and a worker reconciles against the chain afterwards - EIP-3009 nonce consumption is authoritative even with no transaction hash. A late repair still commits the real amount, and committing twice is a no-op, so a retried settlement cannot double-count.
No. The check and the write happen inside one transaction behind an advisory lock on the policy. We test this with several agents paying simultaneously against headroom that fits only some of them; remove the lock and the same test spends $11 against a $10 limit, reproducibly.
Yes, today: set that merchant's limit to zero. What does not exist yet is the reverse - an allowlist that refuses everything not named. That is planned and we would rather say so than imply it.
USDC on Base mainnet for real payments, and Base Sepolia for the sandbox, paying resources that speak x402 v2. If what your agent needs does not accept x402, this cannot buy it yet.
Spending limits your agents cannot raise
Free on testnet, no card. $99 a month when a team needs it.
Get a sandbox key