Your agent cannot overspend what you set.
Set an allowance per period and a per-transaction cap on each agent in the dashboard. The backend enforces it on every outbound payment - the agent's code cannot bypass it.
Autonomous agents make mistakes. They retry. They loop. They get prompt-injected. They occasionally try to spend money you did not authorize.
A Blockchain0x spend permission is owner-set in the dashboard and enforced by the backend, not by the agent's code. Every outbound payment is checked against the active permission before the API accepts it, so the agent cannot exceed the limit even if its logic tries. Your code can read the permission over the API to display it or plan around it, but it cannot raise it.
Four dimensions. Set once. Enforced everywhere.
Allowance over a period
allowance_wei is the total USDC (base units) the agent may send across one period_seconds window. The period is a day (86400), a week (604800), or 30 days (2592000).
Per-transaction cap
per_tx_wei is the largest single outbound payment allowed. It stops one mistaken call from moving more than you intended, independent of the period allowance.
Validity window
start_at and end_at bound when the permission is live. Outside the window it does not authorize spending, so you can pre-stage a budget or let one expire on its own.
Revocation
revoked_at records when a permission was switched off from the dashboard. Revoking takes the allowance to zero immediately for any payment evaluated after it.
The agent's key cannot raise its own limit.
You create, change, and revoke spend permissions in the dashboard. The API exposes them read-only - there is no endpoint and no SDK method that mutates a permission. That is the whole point: if the agent is prompt-injected or stuck in a loop, it cannot widen its own allowance, because the credential it holds was never granted that power.
When a payment would exceed the active permission, the backend rejects it before anything touches the chain. No funds move. Your agent handles that rejection like any other failed call, and you see the attempt in the dashboard so you can widen the permission if it was legitimate.
Fetch the current permission to display or plan around it.
GET /v1/agents/{id}/spend-permissions returns the live values. Use it to show a budget in your UI, or to let the agent check how much room is left before it tries a payment.
curl https://api.blockchain0x.com/v1/agents/agt_123/spend-permissions \
-H "Authorization: Bearer $BLOCKCHAIN0X_API_KEY"{
"allowance_wei": "5000000",
"per_tx_wei": "1000000",
"period_seconds": 86400,
"start_at": "2026-05-15T00:00:00Z",
"end_at": null,
"revoked_at": null
}allowance_weiTotal spend allowed per period, in USDC base units (6 decimals). "5000000" is 5 USDC.
per_tx_weiLargest single payment allowed, in base units. "1000000" is 1 USDC. A payment over this is rejected even if the period allowance has room.
period_secondsThe window the allowance applies to: 86400 (day), 604800 (week), or 2592000 (30 days).
start_at / end_atWhen the permission is active. end_at is null for an open-ended permission.
revoked_atNull while active; a timestamp once revoked from the dashboard. A revoked permission authorizes nothing.
Day, week, or 30 days.
period_seconds takes one of three values. The allowance resets when the period rolls; per_tx_wei applies to every single payment regardless of the period.
864001 day
6048001 week
259200030 days
A spend permission is a hard limit, set once, enforced everywhere - not a per-payment approval workflow and not a human-in-the-loop confirmation. If you need approvals or multi-signature, that is a separate, heavier pattern; the permission is the always-on floor under it.