Spend governance
Give your agent a wallet. And a leash.
An agent with a funded wallet can spend all of it. A spend mandate is a signed, scope-limited authorization that caps what it may spend — per call, per day, per month, in total — and the gateway refuses over-budget calls before any money moves.
Free to create · No account · No API key
The failure mode nobody prices in
Autonomous agents are given wallets so they can pay for things without a human in the loop. That is the point. It is also the risk: a retry loop, a prompt injection or a mis-parsed instruction turns an unbounded wallet into an unbounded invoice — and on-chain settlement is final.
No ceiling
A funded wallet has exactly one limit: its balance. Nothing between an agent's intent and a 15,500 USDC company formation.
No scope
A key that can send a 1 USDC fax can also file a VAT return and open a bank account. Payment rails do not distinguish.
No record
Reconstructing what an agent spent, on what, and under whose authority means reading a block explorer by hand.
A mandate is four questions, signed
AP2 — the agent payments protocol backed by Google and the card networks — frames agent authority as a cryptographically verifiable mandate: what scope, what limits, which actor, under what conditions. AgentBureau implements the same four questions natively on x402 and Base, so you get the guarantee without leaving the rail your agent already pays on.
Which actor?
A controller wallet signs; a spender wallet is governed. When they differ, the spender must co-sign — delegation is explicit, never assumed.
What scope?
An allowlist of services. A mandate for faxes and letters cannot be spent on a notarized power of attorney.
What limits?
Per-call, daily, monthly and lifetime USDC caps. Any combination; omit one to leave that dimension unlimited.
Under what conditions?
A validity window with a hard expiry, and revocation at any time with a single signature from either party.
Denied before you pay, not after
This is the part that matters. Attach X-MANDATE-ID to a priced call and the gateway evaluates your caps before it issues the x402 payment challenge. An over-budget agent gets a 403 and an X-POLICY-DENIED header naming the breached limit — it never receives a payment request, so it never spends.
With a mandate
- POST /v1/invoices · X-MANDATE-ID: 0x58…
- 403 Forbidden · X-POLICY-DENIED: per_call_cap_exceeded
- 0.00 USDC spent. Agent reads the reason and adapts.
Without one
- POST /v1/invoices
- 402 Payment Required → agent pays 5.00 USDC
- Action executes. Nothing was checked.
Caps are still enforced after payment verification if you omit the header — but by then the funds have moved, so the call is refused and the payment is queued for refund. Send the header.
Build one now
Set your caps and scope below. The canonical document and its mandate ID update as you type; simulate a call to see the policy verdict. Switch to testnet to sign a real mandate against Base Sepolia — creating one is free and needs no account.
The agent wallet this mandate governs. Defaults to your connected wallet.
Spending caps (USDC)
Leave a field empty to leave that dimension uncapped.
Permitted services
3 service(s) permitted. Everything else is denied.
Simulation mode — nothing is sent to the gateway. Switch to testnet to create a real mandate.
Canonical mandate
{
"controller_address": "0x00000000000000000000000000000000000000A9",
"spender_address": "0x00000000000000000000000000000000000000A9",
"chain": "testnet",
"per_call_cap_usdc": 5,
"daily_cap_usdc": 25,
"monthly_cap_usdc": 200,
"total_cap_usdc": null,
"allowed_paths": [
"/v1/fax",
"/v1/invoices",
"/v1/letters"
],
"nonce": "",
"not_before": "1970-01-01T00:00:00",
"expires_at": "1970-01-31T00:00:00",
"controller_signature": "0x…"
}Mandate ID: 0x24ad826b9b8dfbc7ad05517bcad67289895711ad5294122284c7f16f4aaf9e98
Policy simulator
An audit trail you can hand to finance
Every paid call is booked against the spending wallet with its amount, timestamp, service, on-chain transaction hash and intent ID. Export the ledger as JSON or CSV, authorized by a signature from the spending wallet itself and bound to a short-lived deadline — no dashboard login, no support ticket.
- ✓ Signed export — only the spending wallet can pull its own ledger.
- ✓ Never includes request payloads, so customer PII stays out of the audit path.
- ✓ Every row carries a Basescan-verifiable transaction hash.
- ✓ check_spend_budget is exposed as a read-only MCP tool, so an agent can check its remaining budget mid-run.
$ curl "$API/v1/mandates/$ID/audit?format=csv&deadline=$D&signature=$SIG" task_id,created_at,type,amount_usdc,status,payment_tx_hash,chain 6f2a…,2026-08-10T09:12:04,fax,1.0,pending_hitl,0x7c1e…,mainnet 9b04…,2026-08-10T09:41:55,letter,3.0,pending_hitl,0x2fa8…,mainnet c771…,2026-08-10T11:03:18,invoice,5.0,pending_hitl,0x91bd…,mainnet
AP2 and AgentBureau, side by side
| Concept | AP2 | AgentBureau today |
|---|---|---|
| Authorization artifact | Signed mandate (scope, limits, actor, conditions) | Signed mandate — EIP-191 over a canonical document |
| Settlement rail | Cards, bank transfer, stablecoins | USDC on Base L2 via x402 |
| Identity | Issuer-attested actor identity | Controller and spender wallet addresses, co-signed on delegation |
| Enforcement point | At the payment network | At the API gateway, before the 402 is issued |
| Audit | Network-level records | Per-call ledger, signed CSV/JSON export |
| Interop | Cross-network by design | x402 only — AP2 rail support not shipped |
Operated from Germany, under German law
The mandates, the ledger and the services they govern are operated by DataFortress.cloud GmbH — a German limited company. The same entity that signs your agent's Vollmacht and files its VAT return holds the spend record. Jurisdiction is not a marketing line here; it is who is liable.
AgentBureau implements the AP2 mandate model on the x402 rail. It does not yet accept AP2 mandates issued on card or bank rails — that is on the roadmap, not shipped.
Questions a reviewer will ask
Does this require an account? +
No. Creating, reading, revoking and auditing a mandate are all free and authorized purely by wallet signature. AgentBureau has no API keys, no OAuth and no user accounts — the x402 payment is the authentication, and a mandate is a signature.
What stops someone creating a mandate over my wallet? +
A mandate naming a spender other than the controller is rejected unless the spender co-signs the identical message. A stranger cannot bind your wallet, and cannot read its spend totals or ledger.
Can a mandate be revoked? +
Yes, immediately, by either the controller or the spender signing 'AgentBureau Mandate Revoke: {mandate_id}'. The next call under it is denied.
What happens at the daily reset? +
Windows are UTC calendar day and calendar month, not rolling — so a daily cap resets at 00:00 UTC. The status endpoint returns the exact reset timestamp.
Is the enforcement in the payment layer or the application? +
The gateway middleware, evaluated before the payment challenge is generated. It is not advisory — an over-budget call cannot obtain a 402, and therefore cannot produce a valid payment for that intent.
Cap your agent before it caps you
Mandates are free, take one signature, and work with every AgentBureau service. Start on testnet.