Autonomous economic governance
An agent that can pay is an agent that can overpay. This is about the layer that decides whether it may — before it does — and why nothing built for human spending fits the job.
New here? Read this page and the four kinds of AEGL first. They are about the problem, not about any particular software. Tesoro — one implementation — starts at What Tesoro is.
Here to judge whether this is serious? Skip all of it and read Evaluate this in ten minutes instead. It opens with the two attacks that still succeed, the prior art this concedes, and the profile the reference implementation deliberately fails.
The problem, stated precisely
Give an agent a wallet and a task, and you have created something new: an actor that makes economic decisions at machine speed, thousands of times an hour, with no intuition about money and no sense that a number is unusual.
It is not that agents are careless. It is that every control we have was designed around a human being present. Consider what actually happens when a person overspends:
| Control | Assumes | Against an agent |
|---|---|---|
| A monthly statement | somebody reads it, monthly | 30 days late; the run finished in 90 seconds |
| An approval workflow | the requester can wait for a reply | nothing to wait with — the agent is mid-execution |
| A fraud alert | anomalies are rare and worth a phone call | every action is anomalous; alerting on all of them is noise |
| A card limit | one purchase at a time, considered | bounds one payment and nothing about ten thousand |
| Human judgement | “this feels wrong” | the agent has no such feeling, and cannot acquire one |
Every row in that table is a report rather than a control. It tells you what happened. At machine speed, by the time it tells you, the money is gone — and the agent has made four hundred more decisions.
What an AEGL is
An Autonomous Economic Governance Layer is any layer that decides whether an autonomous agent may spend, before it spends.
That is the whole category definition, and the word carrying it is before. A layer that observes, records, alerts or reconciles is doing something useful and is not this. The distinction is not about sophistication — it is about where in time the decision sits.
Why this became a real problem recently
Agents could always burn tokens. What changed is that they can now pay counterparties directly, without a human in the transaction. Machine-payable APIs — HTTP 402 revived by x402, agent payment protocols like AP2, stablecoin rails settling in seconds — remove the last human step that used to act as an accidental control.
So an agent now spends in two directions at once, and they are not the same money:
| Internal channel | External channel | |
|---|---|---|
| What | tokens the agent burns thinking | what it pays out |
| Currency | real money, on your provider key | often stablecoin, on a chain |
| Counterparty | one model provider you chose | anyone the agent decides to buy from |
| Failure | a runaway loop, one enormous context | paying the wrong party, or too often |
| If exhausted | no human is in the loop — must stop | a payout can wait for a person |
That last row is the one people miss, and it is why the two channels are governed separately everywhere in this documentation: the same breach has a different correct response depending on which money it was. It is not tidy bookkeeping.
Why a cap on one payment is not enough
The obvious control is a per-payment limit, and it is genuinely useful — it is also the easiest thing in this space to build, which is why several tools now ship one.
It cannot express a great deal. Here is one cent, six times, against a ten dollar per-payment ceiling none of these comes near:
purchase 1: $0.01 APPROVE
purchase 2: $0.01 APPROVE
purchase 3: $0.01 APPROVE
purchase 4: $0.01 APPROVE
purchase 5: $0.01 APPROVE
purchase 6: $0.01 REVIEW ← a cumulative daily limit, not the per-payment oneThe refused payment is byte-for-byte identical to the five approved before it. A limit with no memory cannot produce that outcome, and tightening the per-payment ceiling does not help — it only makes legitimate purchases fail.
And there is a harder case still. Consider a purchase that is affordable, from a trusted counterparty, well inside every budget, at a completely ordinary price — for something the agent was never asked to buy. No amount of arithmetic about money detects that, because nothing about it is a money problem.
The four questions a governance layer has to answer
1 · May this happen?
The verdict. Approve, refuse, or send it to a human — decided before money moves.
2 · Which control decided?
Not what was decided. Which control — the field you need when an agent stops at 2am and you have to know what to change.
3 · Can I prove it later?
An account of what was decided and why, that resists being quietly edited afterwards.
4 · What is not covered?
The honest one. A layer that cannot tell you where it is weak invites you to assume it is strong everywhere.
Question 2 is the one that separates a governance layer from a limit. A per-payment cap has exactly one rule to blame, so attribution is trivial and useless. Once several controls can each refuse, which one did becomes the only actionable piece of information in the record — and it turns out to be surprisingly hard to get right, which is why the standard devotes a whole section to it.
What an AEGL is not
- Not a wallet. It does not hold keys or custody funds. It decides; something else pays.
- Not a compliance product. It can produce evidence a compliance process might use. It does not make anyone compliant with anything, and a layer that claims to should be read carefully.
- Not a fraud system. Fraud detection asks whether a transaction is fraudulent. This asks whether an agent is authorised — a different question with a different answer even when both say no.
- Not an agent framework. It governs agents; it does not build them. If it needs to be part of your agent, it is a dependency rather than a layer.
- Not a model. A layer that needs an LLM to decide whether a payment may happen has given up its cost and latency guarantees, and acquired a prose-injection surface where its decisions live. There are reasons to consult a model alongside the decision; putting one on the path is a different choice with different consequences.
Where to go from here
Four kinds of AEGL
The types, ordered by what each can express — and where the useful boundary falls.
types →The shared vocabulary
Channels, verdicts, controls, envelopes and the four states — the words the rest of this documentation uses precisely.
vocabulary →