Definition

A spend permission is the readable record of how much an AI agent is allowed to spend: the per-transaction cap, the period allowance, and the validity window that express its enforced spend policy. On Blockchain0x it is read through a GET to the agent's spend-permissions endpoint, with fields like per_tx_wei, allowance_wei, and period_seconds. It is read-only via the API and set by a human in the dashboard.

In short, a spend permission is the concrete, queryable form of an agent's spending limits. Where a spend policy is the idea of the rules bounding the agent, the spend permission is the actual record you can fetch to see those rules, the numbers and the window. It is what an agent or your code reads to know the current budget, and it is the object the enforcement is based on, which is why it is worth defining as its own term alongside the broader policy concept.

Spend permission versus spend policy

Spend permission and spend policy describe the same underlying thing from different angles, and distinguishing them helps. A spend policy is the concept, the rules that bound how much an agent can spend, discussed at the level of intent and design. A spend permission is the concrete record of those rules as the system holds and exposes them, the actual fields you can read.

So when you decide an agent may spend up to a certain amount per transaction and per period, you are setting a spend policy; the readable record of that decision, the fields an agent can fetch, is the spend permission. The terms overlap in everyday use, and you will see both, but spend permission tends to emphasize the queryable object, while spend policy emphasizes the rules. For practical purposes, reading an agent's spend permission is how you see its spend policy in concrete form. The policy concept is covered in what-is-an-agent-spend-policy.

The fields

A spend permission is made of a few fields that define the spending envelope. On Blockchain0x, the readable fields include per_tx_wei, the maximum a single transaction may spend; allowance_wei, the total that may be spent over a period; and period_seconds, the length of that period, with common windows being a day, a week, or a month. Amounts are expressed in USDC base units, the smallest unit of the stablecoin.

Alongside the limits are validity fields: start_at and end_at describe when the permission is in effect, and revoked_at indicates if it has been revoked. Together, these tell you not just how much the agent may spend but also whether the permission is currently valid. So a spend permission is, concretely, this small set of fields: two amount caps, a period, and the timestamps that bound its validity. Reading them gives the full picture of what the agent is allowed to do with money right now.

How it is read

On Blockchain0x, a spend permission is read through a GET to the agent's spend-permissions endpoint, and it is read-only through the API. An agent or your code can fetch the current permission to see the limits, which is useful for planning, but cannot change it. Creating, editing, or revoking the permission is done by a human in the dashboard, not through the API the agent can reach.

This read-but-not-write design is deliberate and important. It means the spend permission is a control held by the human: the agent can be aware of its limits but cannot raise them, so it cannot grant itself more authority. The enforcement of the limits also happens server-side, independent of whether the agent reads them, so the permission bounds the agent regardless. The read access exists purely so an agent can plan around its budget, not so it can manage it. How a human sets the limits is covered in how-to-set-up-agent-spending-limits.

How an agent uses it

An agent uses its spend permission to plan, not to spend. By fetching the permission, an agent learns its per-transaction cap and how much of its period allowance remains, and it can use that to make better decisions: avoid attempting a payment larger than the cap, choose a cheaper option when the allowance is low, or stop before failing on an over-limit payment. This is planning awareness, letting the agent reason about budget the way it reasons about any other constraint.

Crucially, this awareness is a convenience, not the safeguard. The limits are enforced server-side whether or not the agent reads them, so an agent that ignores its spend permission is still bounded by it; a payment over the limit is refused regardless. So reading the permission makes an agent smarter about budget, but the protection comes from enforcement, not from the agent's good behavior. The two work together: enforcement guarantees the bound, and the readable permission lets the agent plan within it rather than discover the bound by hitting it.

Validity and revocation

The validity fields are worth understanding, because a spend permission is not necessarily permanent. The start_at and end_at timestamps describe the window during which the permission is in effect, so a permission can be scoped to a period rather than open-ended, and revoked_at records if it has been revoked before its natural end. Reading these tells you not only the limits but whether the permission applies right now.

This matters for control. A human can revoke a permission to cut off an agent's spending, and the revoked_at field reflects that, so a misbehaving agent can be stopped without deleting anything. It also means a spend permission should be read as a current state, not a fixed fact: an agent or your code checking the permission sees whether it is valid and within its window, not just the limit numbers. Treating the permission as a living, revocable record rather than a static setting is part of using it correctly, and it is what makes the limits a control a human keeps rather than a one-time grant.

The broader meaning

Beyond a specific platform, spend permission is a general idea in the wallet world: a permission granted to a spender to spend up to certain limits from a wallet, sometimes implemented on chain in smart wallets. The common thread with the agent case is the same, a bounded authorization to spend, recorded so it can be checked and enforced. Different systems implement it differently, on chain via smart-wallet rules, or server-side as with a managed agent wallet, but the concept is consistent.

So when you encounter spend permission outside the agent context, read it as the same core idea: a record of how much a spender may spend, under what limits. The agent-payment case is one prominent application, where the spender is an autonomous agent and the permission bounds its wallet. Recognizing the general concept helps connect agent spend permissions to the broader wallet-permission landscape, while the specifics, the fields and how they are read and enforced, depend on the platform.

Related terms

A spend permission connects to several concepts. An agent spend policy is the rules it records. An AI agent wallet is what it bounds. A payment mandate is the broader notion of delegated, bounded authority it expresses. And a session key is an alternative, key-level way to scope spending authority.

Understanding spend permissions is understanding how an agent's budget is recorded and read, the concrete side of the spend-policy concept. For the policy it expresses, see what-is-an-agent-spend-policy; for setting the limits, see how-to-set-up-agent-spending-limits. Pricing is on the pricing page.