Skip to main content
When an AI agent pays for x402-protected resources, it spends real on-chain value from a Fireblocks vault. This page covers controlling that spend at company scale: how to fund agents, set what each one is allowed to spend, run many of them safely, and reconcile every payment. It builds on the x402 Agent and its Secure deployment controls, and frames them for finance and security teams who need oversight across a fleet. To publish the services that agents pay for, see Build an Agentic Product Catalog. The foundation is that the agent never holds private keys. It asks Fireblocks to sign each payment authorization, so every spend passes through controls you set in Fireblocks, not controls the agent enforces on itself. This gives a company the same oversight over autonomous agent spending that it has over human procurement: a per-purchase limit, a budget, an approved-vendor list, and an approval step for large amounts.
The agent enforces no spending limit of its own. The x402 Agent has no per-call amount cap and no per-period velocity cap in its code. It will optionally refuse a payment when the vault balance is too low, but every real spending limit is enforced by Fireblocks Policy rules. Treat Policy rules as the source of truth, not the agent.

​
The control plane

Controlling agent spend at a company level rests on two decisions you make in Fireblocks, plus the agent’s own guardrails:
  • How much each agent is funded. A vault’s balance is a hard ceiling on what the agent can ever spend.
  • What Policy rules allow. Per-transaction caps, velocity limits, destination allowlists, and human-approval thresholds, enforced at Fireblocks so they hold even if an agent’s host is compromised.
  • Application-layer guardrails. Defense-in-depth settings in the agent: merchant allowlists, confirmation gates, and integrity checks.
The per-agent setup (scoped API user, secret storage, Policy rules, and guardrails) is documented step by step in Secure deployment. This page focuses on what a company layers on top: funding, running a fleet, and auditing spend.

​
Fund an agent

Funding an agent means transferring the spend asset (commonly USDC) into the dedicated vault account that agent’s API user is scoped to, in the Fireblocks Console or through the API, exactly as you would fund any vault. Two practices keep funding safe:
  • Keep the balance small. Fund the vault to the agent’s working budget, not your treasury. Because the balance is a hard ceiling, a small balance caps the worst-case loss if the agent or its host is compromised, independent of any Policy rule.
  • Top up on a schedule. Refill to the working budget periodically rather than pre-loading a large amount. Combined with a Policy velocity cap, this bounds the spend rate even between top-ups.
The agent pays by signing an off-chain EIP-712 authorization, so it spends no gas at signing time. On-chain settlement and its gas are handled by the merchant’s facilitator, not the buyer’s vault. The agent’s vault only needs the spend asset itself.

​
How the balance check bounds a single payment

Before paying, the agent can confirm the vault holds enough of the asset. The x402_get_and_pay tool and the CLI accept a check_balance flag (default true):
  • When true, the agent queries the vault balance for each candidate asset and only selects a funded option. If nothing is funded, it does not sign.
  • When false (optimistic mode), the agent skips the query and attempts the best-matching option regardless.
The balance check is a convenience that avoids signing a payment the vault cannot cover. It is not a spending limit: a funded vault pays whatever the merchant quotes unless a Policy rule says otherwise. Spending limits belong in Policy rules.

​
Set what an agent can spend

Two settings turn a funded vault into a budgeted one, both enforced at Fireblocks rather than in agent code:
  • Per-transaction amount cap. Match a single x402 micropayment, for example 1 USDC or less. Any signing request above the cap is rejected.
  • Per-period velocity cap. An hourly or daily ceiling matched to the agent’s autonomous budget, so total spend is bounded regardless of how many calls the agent makes.
Pair these with a destination allowlist (only expected assets and recipient addresses) and a manual approver above a threshold for high-value actions. Approvals are pushed to the Fireblocks mobile app and enforced cryptographically by the Policy rule, not by trust in the agent code. The full rule set and configuration steps are in Enforce human-in-the-loop signing. For autonomous flows where the target URL or the model’s context cannot be trusted, also enable the agent’s application-layer guardrails: a merchant-host allowlist (ALLOWED_MERCHANT_HOSTS), a confirmation gate (REQUIRE_CONFIRM), integrity enforcement (REQUIRE_INTEGRITY), and a preference for the Permit2 exact scheme over upto.
On-chain transfers authorized by an agent are irreversible. A misconfigured Policy rule, an over-funded vault, or an over-broad destination allowlist can result in permanent loss of funds. Test on testnets, fund vaults conservatively, and review Policy rules before pointing an agent at mainnet.

​
Run a fleet of agents

The per-agent model composes directly into a company-wide setup. Give each agent, or each team’s agent fleet, its own dedicated vault account and scoped API user, then apply a consistent set of Policy rules across them:
  • Per-agent isolation. Separate vaults and API users mean a compromised agent cannot touch another agent’s funds, and you can revoke or rotate one agent’s credentials without affecting the rest.
  • Budgets as funding plus velocity caps. An agent’s effective budget is the combination of how much you fund its vault and the per-period velocity cap in its Policy rules. Set both deliberately, and the two together cap spend even if one is misjudged.
  • Central policy governance. Manage Policy rules centrally and require two approvers for any change to a policy, so spending authority for every agent is governed in one place and cannot be widened silently.
This structure lets a finance team reason about a fleet the way it reasons about a set of corporate cards: each agent has its own limit and its own ledger, and the rules that govern them all are changed under dual control.

​
Monitor and audit spending

Every agent payment leaves two records you can reconcile:
  • On-chain. Each settlement is a token transfer on the network, giving a permanent, independently verifiable audit trail. Vault activity is also visible in the Fireblocks Console.
  • Facilitator-side. The merchant’s facilitator persists every payment with its status, amount, asset, and transaction hash. If your company also operates the facilitator, inspect these with x402 payments list and the management API.
Reconciling the two confirms that what an agent signed matches what settled on-chain, and gives finance a per-agent spend ledger drawn from authoritative sources rather than from the agent’s own reporting.