Skip to main content
Every agent runs against its spend limits before a payment is signed. The limits are simple on purpose — they are the contract between the builder and the agent, and they are enforced server-side before anything is signed.

​
What a builder sets

  • Per-request maximum — the largest single payment the agent can make. Leave it empty for no per-request ceiling.
  • Daily spending cap — the most the agent can spend in a day. Defaults to 10 USDC when an agent is created, and resets each day. Leave it empty for no daily ceiling.
More controls will arrive over time. Today these two are the dials, and they cover the common case: keep any single payment small, and keep the day bounded.

​
The check, in order

1

Is the amount within the per-request maximum?

PerTxLimitExceeded if not.
2

Would this keep today's total under the daily cap?

SpendingLimitExceeded if it would push the agent over. The remaining budget is returned in the error so the agent can report it cleanly.
If both pass, SAULT confirms the vault’s signer is still authorised, then signs.

​
What agents can and cannot do

An agent can:
  • Make paid requests through SAULT within its limits
  • Read its own identity, balance, today’s spend, and history
  • Check whether a URL needs payment, without paying
  • Discover and run published skills
An agent cannot:
  • Read or export vault keys
  • Edit its own limits
  • Create, edit, or delete other agents
  • Authorise or revoke the vault’s signer
  • Send funds from the vault — that is a builder action in the console

​
Error codes the agent sees

The CLI and MCP surface these as structured errors. An agent reading its SKILL.md reports them to the user instead of looping.

​
Rotation and deactivation

A builder can deactivate an agent (immediately blocks all requests) or rotate its key (invalidates the old key) from the console. Limits are mutable — edits take effect on the agent’s next request.