Bitcoin SV Wallet Standard Sets Owner-Signed Limits on AI Agent Spending
BRC-181 would have wallets check each transaction request against spending rules while agents draw from separate accounts with capped balances.

Bitcoin SV (BSV) standard BRC-181 sets out owner-signed limits for AI agents’ transaction requests, a framework for autonomous spending that keeps enforcement in the wallet.
A wallet implementing the standard checks a request against the owner’s policy before signing and broadcasting a transaction. Each agent draws funds from its own account with a capped balance, separate from the owner’s main wallet. That balance limits the funds available to the agent even if it requests a transaction outside the owner’s intended use.
An owner can cap the total payout across all outputs in a single createAction transaction request. The policy can also set rolling-period and lifetime spending budgets, restrict recipients and limit how frequently the agent makes requests. The owner can freeze the agent’s spending allowance or revoke its access token.
The checks address the risk that an AI agent could be manipulated into requesting a transfer its owner did not intend. “The agent is untrusted,” BRC-181 author RexStarBSV wrote. The wallet applies the signed rules to each autonomous transaction request before deciding whether to sign it.
An existing BSV wallet permission, BRC-116, lets applications request a monthly spending allowance. BRC-181 adds checks on each autonomous transaction request, including its destination and the agent’s accumulated spending. The distinction matters when an agent makes multiple requests under an allowance: each request still has to meet the owner’s policy.
One constraint concerns payments to web services using BRC-166. That standard requires a new receiving address for every invoice, while BRC-181 checks destinations against a list the owner has signed. Future invoice addresses cannot appear on that list in advance, so this version does not support unattended payments to services using that method.
Fee handling has a separate exception. When a transaction builder does not track fees and reports none, the wallet can pay the fee from the agent’s account without counting it against the policy’s fee cap or spending budgets. If a builder tracks fees but cannot determine the amount, the wallet must reject the request. The agent’s account balance still limits the funds available for payments and fees.
BRC-181 describes unit tests and a testnet transaction check for signing and broadcast, but its reference implementation is private. Its practical reach will depend on wallets implementing the standard.