Spend Controls

Spend controls are the core of agent capital. Wallets make payment possible; controls make payment bounded. A useful agent-finance system should be able to say, before money moves, whether this agent is allowed to spend this amount, with this counterparty, on this rail, for this purpose, during this session.

The mistake is to treat controls as a dashboard after the wallet is live. For autonomous agents, spend policy should be the primitive. The wallet, API key, virtual card, x402 client, or checkout credential should inherit authority from a policy object that can be tested, revoked, and audited.

The spend-control taxonomy

Amount controls

Amount controls include per-transaction caps, daily budgets, monthly budgets, lifetime task budgets, and dynamic limits based on confidence or account health. They should be enforced before signing or authorization, not only monitored after settlement.

Counterparty controls

Counterparty controls limit where the agent can spend. In crypto this may mean recipient addresses, smart contracts, domains, facilitators, or verified seller identities. In card or commerce systems it may mean merchant IDs, merchant categories, payment processors, or approved seller accounts.

Purpose controls

A payment should be attached to a task. "Buy compute for benchmark run 184" is easier to approve and reconcile than "send 50 USDC." Purpose controls prevent an agent from reusing a valid budget for a different objective after a prompt injection or planning error.

Time controls

Authority should expire. Session keys, temporary cards, checkout mandates, and expiring x402 budgets help constrain delayed or replayed actions. A long-lived agent with a long-lived payment credential is a standing liability.

Human-in-the-loop controls

Human review should be reserved for boundary-crossing events: unusual merchant, new rail, high amount, risky asset, first transaction, refund exception, or a policy conflict. Requiring approval for every small API call defeats autonomy; requiring approval for no exception invites runaway spend.

What good controls record

Spend-control systems should produce an evidence trail, not just a decision. A future reviewer should be able to reconstruct the agent's authority and the exact facts presented at authorization time.

• Policy ID: the versioned rule that allowed or denied the spend.
• Agent ID: model, runtime, tool, session, and delegating user or owner.
• Intent: task, merchant, asset, amount, rail, and expected deliverable.
• Decision: allowed, denied, escalated, expired, or manually approved.
• Settlement evidence: authorization ID, x402 payment response, transaction hash, invoice, receipt, or refund event.

Rail-specific controls

The same policy should compile down to the rail being used. On x402, the policy can evaluate the HTTP resource, payment requirements, wallet, network, recipient, and amount. On card issuing, it can evaluate merchant data, card presence, category, geography, and authorization amount. On ACP-style commerce, it can evaluate merchant identity, cart contents, delegated payment token constraints, and user confirmation.

Visa's Intelligent Commerce framing names spending limits, approval workflows, authentication requirements, and trusted identity signals as confidence-building infrastructure. Mastercard's Agent Pay for Machines similarly presents permissions and spending limits as upfront bounds on authority. Those network-level moves matter because ordinary commerce depends on merchant acceptance and dispute handling, not just wallet signatures.

Approval thresholds that scale

A useful approval model is not binary. It layers thresholds:

• Silent allow: tiny recurring payments to known services inside a task budget.
• Notify: low-risk purchases that should be visible but not blocked.
• Ask: new merchant, high amount, new rail, new asset, or ambiguous purpose.
• Deny: blocked category, unknown destination, expired session, sanctioned geography, or missing receipt path.
• Freeze: repeated denials, prompt-injection evidence, impossible merchant claims, or spend velocity outside historical bounds.

Policy before balance

A wallet balance is not a permission. A card limit is not a purpose. An agent that can see funds may infer it can use funds unless the tool boundary says otherwise. For that reason, the safest agent-finance stacks make the policy engine the only path to payment. The model can propose; the policy decides; the wallet signs only after a typed, logged, bounded intent passes.