Spend policy & approvals

How auto-approval and human review work in the dashboard and Agent Bank API.

This guide is for teams using the dashboard and developers calling Agent Bank (/v1). It explains when spend is auto-approved, when it goes to human review, and how that applies to direct spend and checkout intents.

#In the dashboard

Each budget (policy profile) drives policy for its cards and spending keys.

  • Set “Ask me above ($)” to require operator approval for amounts above that threshold.
  • Leave it empty for autonomous mode: no amount-based approval gate (other limits still apply: budget, max purchase, merchant rules, pauses).

Configure this under Treasury → Cards → View policy or Budgets.

#For API users

There is no per-request “auto vs human” switch. The budget attached to the spending key defines policy.

A request is auto-approved (status: "approved") in one response when all of the following hold:

  • Key, budget, and funding are active
  • Amount is valid and within max purchase
  • Merchant passes allow / deny rules
  • Request fits the period budget
  • Either no approval threshold is set, or amount ≤ threshold

If the amount is above the threshold, the result is needs_approval (pending operator). Policy violations yield declined.

#Direct spend vs checkout intents

  • POST /v1/spend-requests — governed decision and ledger; does not issue a card by itself.
  • Checkout intents — POST /v1/checkout/intents, then /authorize, then /issue-credential. Authorize uses the same policy engine. After approved, issue-credential can mint a JIT card (subject to wallet funds at issuance time).

#When you see needs_approval

  1. An operator approves or declines in Treasury → Approvals.
  2. Integrations should use webhooks or polling to continue—see Agent spend webhooks.
  3. For checkout intents, call issue-credential only when the intent is approved (poll GET /v1/checkout/intents/:id or wait for purchase_intent.authorized / lifecycle events).

#JIT note

Wallet reservation for checkout typically happens when the payment credential is issued, not at the first policy approval. Handle insufficient wallet balance at credential issuance by funding the workspace wallet and retrying.