Letting an agent spend
Software spending on somebody's behalf: what to grant it, how to bound it, and the review screen a person needs when they were not the one who decided.
An agent is software that spends on a person's behalf without asking each time: an assistant buying API calls, a service renewing storage, a bot paying for data as it works. We recommend giving it its own wallet with a fixed budget, enforcing its limits outside the agent, and reporting what it did in a form a person can judge.
Payments small enough to be automatic make this ordinary.
What is actually new
Everywhere else in this guide, a person chose each payment, or set the rule it follows: an allowance spends on a person's decisions. An agent spends on its own, and the person arrives afterwards. So the design moves from asking to bounding and reporting: what it may do, and what it did.
Give it its own wallet
The most important decision on this page, and it is architectural, not visual.
An agent gets its own keys, its own funds and its own identity, not a permission on the user's wallet. See Wallet setups.
That way the balance bounds the worst case, not the agent's judgement. A compromised agent spends what it was given and stops.
An allowance from the person's main wallet is the fallback where an agent cannot have its own wallet. Its risk is that a bug or an injected instruction can spend the whole allowance, from the wallet that holds everything else. See Spending allowances.
Do
Fund an agent by deliberate top-up, as a human action. A standing instruction to refill is the thing that turns a bounded loss into an unbounded one.
Don't
Hand an agent the user's identity key or their Passes. It can have its own identity and act as itself; it should never be able to prove it is the person.
Topping up an agent
- OK: the person tops it up deliberately, each time, as a human action.
- Grey area: a reminder when the balance runs low, with a one-tap top-up the person still has to press.
- Not OK: a standing instruction to refill automatically whenever the balance falls.
The four bounds
Every agent needs all four. A balance alone is the one most easily mistaken for enough.
A balance. The maximum it can ever spend, because it cannot spend what it does not hold.
A rate. Per payment, per hour, per day. A balance alone lets it spend everything in a second.
A scope. Who it may pay. An agent that buys from one API has no business paying an address it was handed in a prompt.
An expiry. A grant that never ends is one nobody revisits.
Do
Show all four on one screen, as current values rather than settings. "412 of 5,000 sats, 18 payments today, 3 services, 22 days left" is a status, and a settings form is not.
Prompt injection is a payments problem now
An agent reads things, and some of what it reads is written by people who want it to spend money. Instructions hidden in a web page, a document or an email are a known and ordinary attack.
Why the usual answer fails
"The agent should not follow instructions from content" is advice to the model, and a model is not a security boundary. The bound has to sit outside the agent, in what the wallet will do. That is why the scope and the rate matter more than the agent's prompt.
Do
Enforce limits outside the agent, in the wallet or the service holding its keys. A limit the agent checks itself is a limit an injected instruction can argue with.
Do
Require a human for anything outside the scope: a new payee, a larger amount, a wider permission. Send the person a notification for it, rather than adding it to a list they have to check.
The review a person needs
The user was not there. The interface has to reconstruct what happened in a form they can judge.
Do
Group by purpose, not by payment. "Research assistant: 6 sources, 240 sats" is reviewable; forty rows are not.
Do
Record what each payment was for at the moment it happens. Intent cannot be reconstructed afterwards.
Do
Surface the unusual rather than the complete. A payee it has never paid, or a payment larger than its usual, belongs at the top; the routine belongs in a total.
Don't
Report agent spending only in a log. A log is for after somebody already suspects something.
Stopping it
Do
Put one control that stops everything, visible wherever the agent is, with no confirmation step. Confirmations are for actions you might regret, and stopping is not one of them.
Do
Say what stopping means: no further payments, work in progress abandoned, funds stay where they are. A user who is not sure what the button does will not press it.
Telling the user an agent is spending
Do
Name the agent and its purpose wherever its spending appears. "Example Assistant, buying search results" is a thing a person can consent to; "automated payments" is not.
Do
Report on a human schedule. A daily summary a person reads beats a real-time feed nobody watches.
Open questions
- How much can a person delegate before reviewing the agent's spending becomes a job they stop doing?
- The agent records what each payment was for. Can that record be trusted, when an injected instruction could make the agent describe a bad payment as a good one?
- What expiry is right by default: days, weeks, or the length of one task?
- When an agent pays for something the person did not want, what does the person owe the payee, and what can they ask of them?
- Where is the line between an unusual payment that deserves a notification and a routine one that belongs in the daily summary?
Related
- Agent with a budget: this pattern as a whole product, from setup to stopping
- Wallet setups: the agent wallet beside the person's own
- Permissions and allowances: the allowance, and why it is the fallback for an agent
- Charging per use: the small payments an agent usually makes
- Errors and failed payments: an agent that reaches its budget
- Identity: why an agent acts as itself, never as the person
Written from: BRC-29, BRC-52, BRC-100, BRC-151.
Checklist
The rules on this page, in a form you can work through.
13 rules