Two different jobs
When a team first lets an agent spend, the question sounds like one question: how do we let it pay without losing control? It is really two. One is about money: where it comes from, how the agent reaches it, and the hard ceiling on how much it can move. The other is about permission: whether a particular spend is something the agent was delegated to do.
Agent wallets — balances, virtual cards and accounts built for software to hold — answer the first. Spend authority answers the second. They are different layers, and most setups that go wrong treat one as if it were the other.
MCP / tool protocol
Can the agent call it?
Mandates / agent identity
Was the agent authorized to act?
Payment rail
Can the payment settle?
Spend limit
Is it within the number?
Neltava
Should this agent do this — under this delegated authority, for this purpose, right now?
What a wallet decides
A wallet is excellent at the things a balance can know:
- whether there is enough money;
- whether a payment is under a card or wallet limit;
- whether a merchant or address is on the card’s allowed list;
- how much has moved this period.
These are hard limits on the money itself, and they are valuable precisely because they don’t depend on the agent behaving. A $500 prepaid balance can never lose $5,000.
What authority decides
A balance cannot know what the money was for. Authority adds the questions that need the agent’s mandate:
- Purpose. Is this spend for the reason the budget was delegated? A B2B lead-generation budget buying a consumer campaign is within every limit and still wrong — see purpose-aware spending.
- Sequences. Five small payments to one payee that add up to what a person should have approved.
- People. Which spends need a person, who that person is, and the guarantee that the requester can’t approve itself — see human review.
- Evidence. For every spend: what the agent asked, why, under which version of its authority, what was decided and what happened.
- One policy across rails. Agents rarely spend from one place. Authority applies the same rules whether the payment goes through a card, an invoice, an API top-up or a wallet.
Side by side
| Agent wallet | Spend authority | |
|---|---|---|
| Core question | Can this agent pay, and from what balance? | Should this agent make this payment? |
| Holds money | Yes — a balance, card or account | No — never moves or holds funds |
| Limits | Balance, card limit, per-transaction and period caps | Per-transaction, daily/monthly, windowed totals per payee or category, velocity |
| Who may be paid | Often an allow/block list per card or wallet | Allow/block lists, trusted categories, payee identity |
| What it's for | — | A written purpose, checked on every spend; doubt goes to a person |
| People in the loop | Sometimes approval for large payments | Review for doubtful spends, separation of duties, labels |
| Evidence | Transaction history | Every decision with its authority version, trace and outcome, hash-chained |
| Rails | Its own | Any — cards, invoices, APIs, prepaid balances, wallets |
| Testing a policy safely | Usually live | Shadow Mode: decided and recorded, nothing blocked |
Using both
The strongest setup uses each for what it is good at:
- The wallet holds a bounded amount. Its balance and limits are the last line: whatever else fails, the agent can’t move more than is in it.
- The agent asks Neltava before every payment. The spend is checked against the agent’s authority and purpose, and doubtful ones go to a person.
- The wallet pays only with a capability. In Enforce, an allowed spend carries a single-use capability bound to its payee, amount and currency. Whatever controls the wallet — your payment service, a signing service — consumes it before it pays. That is the payment adapter pattern.
- What the wallet reports becomes the outcome. Failed payments give their budget back; executed ones count at the amount that really moved.
Which one you need
A wallet alone is enough when…
the agent pays one kind of vendor, for one kind of thing, from a balance small enough that its limit is the whole policy.
You need authority when…
the agent chooses what to buy, from many payees, with a budget that belongs to someone else — and “under the limit” is not the same as “what we wanted”.
You need both when…
real money moves at volume. The wallet caps the worst case; authority decides the ordinary case, keeps people on the doubtful ones, and leaves a record you can defend.
