# Choose Agent Spending Authority

Start with the action a creator wants to authorize. An agent that prepares a payment does not need custody. An agent that must pay while the creator is away needs explicit spending authority and a clearly bounded exposure.

## Choose the Smallest Authority

| Creator's need | Existing flow | Enforcement and limit |
| --- | --- | --- |
| Approve each purchase from my wallet | [Main-Wallet Payment Requests](https://docs.bitbadges.io/agents/main-wallet-payments) | Human reviews and signs each exact transaction; no standing allowance is needed |
| Let an agent operate unattended with a small amount | Separate agent-owned wallet, funded explicitly | Key can spend the wallet's balance and exercise any other authority granted to it; funding is an exposure decision |
| Delegate specific collection-token transfers | [Outgoing spending approval](https://docs.bitbadges.io/agents/spending-authorization) | Chain checks the permitted token, recipient, initiator, time and tracker; inspect alternative approval paths |
| Limit how quickly backing coins leave a vault | Existing [Smart Token / Vault](https://docs.bitbadges.io/guides/smart-tokens-and-vaults) | Collection redemption rules constrain withdrawal; redeemed coins are outside those rules |
| Pay a known provider repeatedly | [Subscriptions](https://docs.bitbadges.io/standards/subscriptions) | Explicit recurring terms and consent, with separate cancellation and already-purchased access |

The first flow is the default. The agent resolves the invoice or recipient, prepares unsigned messages, and opens the existing browser review. The creator sees the network, asset, amount, recipient and fees before signing. This is already an end-to-end workflow; it does not require an Agent Vault collection.

## Unattended Wallets

A separate funded wallet is often enough for a small autonomous experiment. Budget for fees, keep the main wallet key out of the agent's environment, and give the agent only the funds and roles needed for its task. Do not grant it a collection manager role or unrelated approvals merely because it is called an “agent wallet.”

A 10 USDC balance is not a 10 USDC lifetime policy: future deposits, refunds, incoming transfers and other delegated permissions can increase its authority. Automatic top-ups can make total exposure much larger. Reconcile confirmed payments before replenishing, and decide explicitly whether the agent may retain refunds or receive more funds.

Skills, prompts and shell hooks help an agent follow the intended process. They are not a security boundary against a compromised process that can read the signing key. A separate signer that independently validates a policy is a different architecture; it must control key access, validate every signing path and define recovery. Do not promise those guarantees from an agent prompt.

## Existing Vaults Have a Specific Job

Use a vault when on-chain redemption limits are themselves valuable, such as controlling the release cadence of a larger operating reserve. Inspect the exact approval configuration: tracker scope, reset boundary, permitted initiators, alternative withdrawal paths, account approvals and recovery authority. A fixed daily interval can allow one budget immediately before reset and another immediately after it; it is not a rolling 24-hour cap.

A withdrawal cap is not a purchase cap. The agent may accumulate withdrawn coins over several periods, then spend them together. Neither a receipt-transfer recipient restriction nor a multisig activation vote binds a later native bank payment to a merchant. Once coins are withdrawn, a vault cannot claw them back.

Recovery is not automatically a pause, refund or revocation. Read the actual recovery approvals: moving receipts to a recovery address is different from redeeming them, and may still require withdrawal conditions. Revocation or recovery becomes effective when included on-chain; a competing spend ordered first can succeed. Do not assume the manager can change an immutable vault after creation.

## Payment Completion and Service Delivery

For every model, store the business operation reference and transaction hash, confirm execution on the intended network, and reconcile indexed invoice state before retrying. A browser timeout or missing callback is an unknown outcome, not evidence that no payment occurred. See [request recovery](https://docs.bitbadges.io/agents/main-wallet-payments#recover-a-request).

A payment proves a transfer, not service delivery. A merchant refund is a separate payment unless an explicit refund mechanism was agreed. Agents and providers must agree how to identify the original payment and who receives the refund. Replenishing a vault does not erase consumed withdrawal trackers or establish a safe retry.

## Why There Is No Additional Agent Vault Standard Here

A new label would not improve the human-reviewed payment flow. The proposed combination of designated agent, withdrawal cap, activation votes and recovery uses existing approval primitives and creates additional custody and maintenance obligations. It also does not enforce where withdrawn native coins are spent.

Use the existing flows above. A future design should begin with a concrete unmet guarantee—such as independently enforced native-coin recipient and lifetime limits—and demonstrate that every signing and withdrawal path preserves it. A more elaborate vault UI or an “agent” label is not such a guarantee.