![HS5oROJXoAEJjRN](/api/storage/objects/uploads/58ca123a-b73e-4489-87c4-945c82875b5a)
## Give AI agents an allowance, not your account.

We are handing AI agents the keys to our accounts and letting them spend. When one goes wrong, two things are true at once: the key it used could spend whatever the account could, and the only record of what it did belongs to the company you are trying to hold to account. In one widely shared case, an agent ran up a $6,531 AWS bill by creating a duplicate CloudFormation stack every time it hit an error.
Agents will keep making expensive mistakes. The question is whether you can stop one fast, and prove what happened afterwards.

Here is my answer. Stop giving agents access to your account. Give each agent its own key and a small allowance, and make it pay for every action out of that allowance. Each payment is then the permission for one action and the permanent receipt for it. The most an agent can ever lose is what is left in its allowance, and you can take that back with one transaction. The record of what it did is written by the settlement itself: not by the provider, not by the agent, and not by you.

The payment is the permission, and the payment is the receipt.
That gives you four things you can't currently get together: a worst case fixed before the agent starts, a record of its actions that no party to a dispute wrote, a pinned account of which model did the work, and a checkable answer to the question you will actually ask afterwards, which is whether it did what you asked.

## One task, end to end

Say I ask an agent to research competitors before a launch. It will call a language model a few hundred times and a search API a few dozen.
I give it an allowance of £15, held on a public ledger in a form the agent's key can spend and my key can always take back. The agent's key is derived from mine, for this task only. It never sees my API keys.

Every call goes through a proxy I run. If the provider accepts machine payments over HTTP 402, the agent pays the provider directly. If it only takes a card, as most model APIs do today, the agent pays my proxy and the proxy makes the call with my real key. Either way, each payment draws on the allowance, returns the change to it, and carries a fingerprint (a hash) of the exact request it paid for. Each response names the model version that served it, and the proxy records that alongside the payment.

At call 212, the agent hits an error and starts retrying the same failing request. With an API key, this is where the $6,531 bill starts. Here, every retry costs a payment. The allowance drains, and when it reaches zero the agent stops, because there is nothing left to spend. No alert has to fire in time. The worst case was £15 from the start.

I see the drain and sweep what's left back to my wallet. One transaction. The agent's key still exists, but it controls nothing.
A week later the provider's invoice arrives. Suppose it says 1,140 calls, and my allowance paid for 412. Then 728 calls came from somewhere other than my agent, and I can show it without asking the provider for its logs: 412 payments, in an order fixed by the ledger, each carrying the fingerprint of the request it paid for, each checkable by anyone without asking the provider or me.

Then the question that matters. Partway through its research, the agent read a web page with instructions hidden in it, and for a while it went off and did something else. Which calls were those? A typed classifier runs over all 412 for a fraction of a penny and returns in scope, out of scope or unclear for each. It finds 31. Those verdicts are recorded along with the classifier version that produced them, so anyone can re-run the check and disagree with it on the record.

The rest of this paper explains why each part of that story holds: the cap, the record, the model, and the verdict.

## 1. The worst case is fixed before the agent starts

An API key is a bearer credential. Whoever holds it can use all of it, and it carries no idea of who authorised a request or up to what amount. Revoking it means noticing the problem, finding the dashboard and rotating the key while the agent keeps spending. The time between a key going wrong and a key being revoked is where the money goes. The Agent Control Protocol, the most thorough agent-governance specification I've found, describes that gap as an irrecoverable exposure interval. That's accurate. No revocation scheme closes it, because it exists wherever standing authority does.

An allowance has no authority beyond its own balance. Revocation stops being a race against an unlimited spender and becomes a sweep of whatever is left. If one of the agent's payments and my sweep reach the network at the same moment, I lose that race by at most one call.
Delegation becomes arithmetic. When an agent needs a sub-agent, it funds one by splitting off part of its own allowance to a new key. The sub-agent's budget comes out of the parent's, so creating a new agent does not create new money.

That matters because the alternative, per-agent limits kept by an enforcer, grows with the number of identities. In the Agent Control Protocol's own evaluation, N coordinated agents acting on a shared resource each receive two approved actions before escalation, so the total is 2N. The authors present linear growth as a success, since it rules out anything worse, and within their model it is. But it means every new identity buys two more actions, and identities cost nothing to create. Separate counters don't add up. One shared balance can't be exceeded however many keys draw on it, and none of those keys needs to know the others exist.

This holds across organisations too. Two services that have never heard of each other can both take payment from the same allowance without a registry, a trust agreement or a shared database. The ledger is the only thing they need to agree on.

## 2. The record is written by the settlement

Today, when you dispute an agent's charges, the record you consult was produced, stored and served by the party you are disputing with. Well-built systems hash-chain their logs, so that altering one entry breaks every entry after it. That stops an outsider. It does nothing against the log's owner, who holds the whole chain and can recompute it from the beginning. And no amount of chaining reveals an entry that was never written.
Paying per action removes both problems for the thing people actually fight about, which is money. The agent can't make a paid call without a payment, and a payment can't happen without a transaction on a public ledger. There is nothing for anyone to leave out. Each payment carries the fingerprint of the request it paid for, so the settlement record is also a record of what was asked. The order comes from the ledger rather than anyone's database, and any entry can be checked against the chain's block headers without trusting the provider, the agent or me.

For providers that don't take machine payments, the proxy does the work. The agent pays my proxy, and the proxy spends my real key. The money never leaves my control, but the metering happens on a public ledger, it can't exceed the allowance, and every charge is recorded where I can't quietly edit it either. The provider's invoice can then be reconciled against a record the provider didn't write.

That is the reversal this design is for. At the moment, the provider's log is the evidence and the user's recollection is the complaint. Here, the user holds evidence the provider has to answer.

Not every action costs money. Reading a local file or calling a free tool has no payment attached. For those, the proxy signs a record of each action, gathers a batch of records into a Merkle tree (a structure that reduces the whole batch to one fingerprint), and writes that fingerprint to the same ledger. That fixes the order and integrity of every record in the batch, cheaply, because one ledger entry covers thousands of actions. It does not prove completeness the way payment does, and it shouldn't be described as if it did.

## 3. You know which model did the work, and what you were told about it

At the moment you can't prove which model served a request, or what its provider said about how it was trained at the time you used it. Model names are aliases that get repointed to new versions, and published model cards get revised.

Nothing can yet prove that a model was trained on the data its card describes. There is no cryptographic link between a dataset and a set of weights, and I won't pretend there is. What the proxy can do is pin down exactly what you were told.
The major model APIs name the model version in every response. The proxy records that name alongside the payment. When a provider publishes a model card or system card, the proxy records a fingerprint of the card as it stood when you used the model.

So for every action, the record says: this model version, as named by its provider, served this request, and on that date the provider's published description of that model was this exact document. If the provider later puts a different model behind the same name, the recorded versions show where it changed. If the card is quietly rewritten, the fingerprint shows that it changed and when.

That doesn't verify training. It turns what a provider says about training from something they can revise into something they're on the record for.

## 4. The question you'll ask afterwards has a checkable answer

A complete, ordered, public record of four hundred calls is still four hundred calls. The question anyone actually asks is about meaning: did the agent do what I asked, and if not, where did it go wrong?

Until recently, answering that with a model created a new problem. A language model's free-text judgement can't usefully be put on the record. Its possible outputs are unlimited, the same input can produce different text on different runs, and a fingerprint of one particular paragraph proves only that a paragraph was produced. Nobody can reproduce it and check.
A new kind of model changes that. TypeSafe AI's Jev, released this month, doesn't generate text at all. It returns typed decisions over labels you declare in advance (one of N options, a position on a scale, or a yes/no probability). It costs $0.042 per million input tokens with output free, and it cannot return a value outside the schema you gave it. It can still pick the wrong label from inside that schema.

That combination is what makes its verdicts recordable. A judgement drawn from a fixed set of labels, about inputs identified by their fingerprints, produced by a named model version, is a small and exact object. Record it, and a third party can run the same schema over the same inputs with the same model version and compare. Judgement about an audit trail becomes something you put on the record and others can challenge, instead of something one party asserts. At these prices it runs over every entry, not a sample picked after someone complains.

One rule is absolute: verdicts never decide spending. A probability is not a permission. Letting "87% likely in scope" approve a payment would rebuild the problem this paper is about. Everything that can be computed (amount, endpoint, rate, remaining balance) is enforced exactly, at the proxy. Judgement happens afterwards, where a wrong answer produces a flag for someone to look at rather than a loss.

## What already exists, and what's missing

![HS5k8eSWEAAwAtG](/api/storage/objects/uploads/4ab2dea2-7a23-4ee4-b0b0-802fd7890f7e)

The Agent Control Protocol deserves specific credit. It shows, formally and with a model-checked implementation, that limits over an agent's history need stored state and can't be enforced one request at a time. This paper starts from that result. The difference is where the state lives. In ACP it is held by the institution that enforces it. Here it is held by a ledger that no party to a dispute controls. That one change is what lets the limit hold across services, sub-agents and organisations, and lets the record stand up when the institution is the one being questioned.

## Why a ledger, and which one

The design needs three things from wherever the payments settle. Fees have to be small enough to pay for every action at agent volumes; otherwise allowances get coarser and the worst case grows. The allowance has to be something the user can reclaim alone, without anyone's permission. And the order of payments has to be checkable by anyone from public data, without trusting a server.
Other chains can do versions of this, and the architecture doesn't belong to any one of them. In practice, fees are what separate the options: they decide whether you can meter every call or only settle in batches.

I build on Bitcoin SV because it meets all three with the most room to spare. Fees are measured in single satoshis, so metering every call is affordable. Its output model makes an allowance a discrete spendable object, which is what makes the sweep a single transaction. And verification runs offline from block headers. HTTP 402 payments on BSV are standardised as BRC-105.
Where it stops

This records what an agent did and caps what it can spend. It doesn't make the agent's choices good. It doesn't stop prompt injection; it limits what an injected instruction can cost and makes the damage findable afterwards. It pins what a provider told you about its model, but it can't prove the weights match the data. Actions that cost nothing get records that prove order and integrity but not completeness. And a counterparty that serves a request before the payment settles has given up the guarantee, which is why the proxy only forwards calls that are already paid.
Build it

None of this needs a provider to change anything. It needs four pieces: a proxy that holds the real keys and forwards only paid calls, an allowance the user can sweep, a batcher that writes action records to the ledger, and a verdict runner that records what it finds.
Half of that already runs. I've built the provenance side three times, for publishing, for patient-owned medical records, and for a notary that anchors content batches at one satoshi each. The payment side ships as open-source middleware for 402 flows. The allowance and the verdict runner are next.

We are already giving agents real money and real authority, because they're useful. What's left to decide is whether that authority has a ceiling, and whether their actions leave a record that nobody can rewrite.
The payment is the permission, and the payment is the receipt.

## References

Birgisson, A., Politz, J. G., Erlingsson, Ú., Taly, A., Vrable, M., & Lentczner, M. (2014). Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud. NDSS.

Fernandez, M. (2026). Agent Control Protocol v1.30: Admission Control for Agent Actions. arXiv:2603.18829.

Jones, M., Nadalin, A., Campbell, B., Bradley, J., & Mortimore, C. (2020). OAuth 2.0 Token Exchange. RFC 8693.

TypeSafe AI (2026). Introducing System One Models & Jev.

Wright, C. S. (2026). Order On-Chain, Content Off-Chain, Judgement in the Overlay. Singular Grit, 11 August.
x402 Foundation (2026). x402: HTTP 402 payments. Linux Foundation.