Set payment budgets and authorization controls for an AI agent

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

The model should request; policy should authorize

An agent that can compose a payment should not automatically control the rule that approves it. Put a deterministic enforcement layer between model output and signing. Coinbase's AgentKit repository makes the risk unusually explicit: text reaching the model can influence transfers, while AgentKit itself does not enforce human approval, spend caps or destination allowlists. Prompt instructions such as 'never spend more than $20' are therefore not a budget control.

Define the authorization envelope

1. Funds: use a dedicated account with only the operating balance required. Never expose a treasury key to the model or its tools.
2. Assets and chains: allowlist exact chain IDs and token contracts, not symbols.
3. Counterparties: allowlist merchant or contract addresses and permitted function selectors. Reject arbitrary calls by default.
4. Amounts: set per-transaction, per-session and rolling-period caps. Count approvals as exposure, not only completed transfers.
5. Time: expire sessions and signed authorizations; bind signatures to chain, account, nonce and intended verifier.
6. Escalation: require independent human or quorum approval for a new destination, contract upgrade, token approval or amount above threshold.
7. Revocation: provide a pause path that does not depend on the agent, plus credential rotation and allowance revocation.

CDP Wallet policy documentation provides examples of destination and value filters, per-address limits and USD spend limits. Safe's agent quickstart demonstrates a smart-account allowance module. ERC-4337 explains how a smart account can supply its own validation logic. These are implementation options, not proof that a configured system is safe.

Hypothetical control sheet

Hypothetical: an agent buys data from two vendors. Its wallet holds 150 USDC, may call only each vendor's purchase(bytes32,uint256), may spend at most 5 USDC per call, 25 USDC per session and 60 USDC per day, and expires after one hour. Adding a vendor or granting any ERC-20 allowance requires a two-person approval. A separate monitor totals confirmed payments and pending authorizations. If the model is manipulated into requesting 40 USDC or a transfer to a new address, the policy rejects the transaction even if the prompt says it is urgent.

Test controls without claiming production safety

Before funding, use a test environment to exercise boundary cases: amount just below and above each cap, repeated small payments, a wrong chain, an unlisted address, an unknown selector, stale nonce, expired session and emergency pause. Log the requested action, policy decision, signed payload, transaction hash and reconciliation result without storing secrets. Review who can change policy itself; an admin that can silently raise limits is part of the authorization surface, as the quorum guide makes clear.

Limits

A bounded wallet limits loss but does not validate the quality of what the agent buys, prevent every prompt injection or resolve disputes with merchants. Fiat-value caps depend on price data; token caps avoid that oracle but change economic exposure. Paymasters can sponsor gas without controlling purchase value. This workflow is about operational authorization, not whether agents need a token—the separate token-necessity essay addresses that claim—and it is not investment advice.