What governs what
"Agent governance" covers at least four different jobs, and a tool that does one of them well is usually not doing the others at all. This page says which job Tesoro does, which tools do the rest, and how to tell quickly whether you need one, two or all of them.
The short answer. Most agent governance tools decide what an agent may do — which tools it may call, what it may read, whether an action is permitted. Tesoro decides what an agent may pay: irreversible outbound value, on a settlement rail, to a third party. They are different questions and a team running agents that spend money generally needs both.
Four jobs that all get called governance
| Job | The question it answers | Typical tools |
|---|---|---|
| Action governance | May this agent call this tool, reach this host, read this record? | Microsoft Agent Governance Toolkit, OPA/Rego, Cedar, MCP gateways |
| Content guardrails | Is this input or output harmful, off-policy, or an injection attempt? | Guardrails libraries, moderation endpoints, prompt-injection filters |
| Observability | What did this agent do, how long did it take, what did it cost? | LangSmith, Langfuse, OpenTelemetry, tracing platforms |
| Economic governance — an AEGL | May this agent spend this, given everything it has already spent? | Tesoro |
The fourth is the one this project is about, and the reason it is separate is on the stablecoins page: a payment on an irreversible rail cannot be charged back, so the only useful control point is before it happens. Observability tells you what an agent spent. A guardrail tells you whether text was safe. Neither refuses a payment.
Microsoft's Agent Governance Toolkit
Worth addressing directly, because it is the most substantial project in the adjacent space and because the two overlap enough that the difference is a fair question. Agent Governance Toolkit (MIT) is action governance done thoroughly: policy enforcement, zero-trust identity via SPIFFE and DIDs, execution sandboxing, an MCP security gateway, an SRE surface with kill switches, and mappings onto OWASP's Agentic Top 10, NIST AI RMF and the EU AI Act. Five language implementations, its own specification, and a machine-readable conformance suite.
It also has budget controls, and they are not the same kind. Its policy library bounds four host-tracked counters — tool calls, tokens, elapsed seconds, and a cost figure — per run. That is the right model for operational consumption: a resource you are billed for later, by a provider you hold a contract with, on an invoice you can dispute.
| Operational cost tokens, tool calls, seconds | Irreversible payment stablecoin to a third party | |
|---|---|---|
| Money as a float | Fine — an approximate bill reconciles against an invoice | Not fine. 0.1 + 0.2 != 0.3, and there is no invoice to reconcile against |
| Per-run counters | Fine — "did this run cost too much" is the question | Insufficient. The question is what this agent has spent this month, per counterparty, across every run |
| One decision point | Fine — the tool call happens or it does not | Insufficient. What settles may differ from what was authorised |
| Reversibility if wrong | A line item you dispute | A transfer that is gone |
So: neither model is wrong, and they answer different questions. If your agents call tools and burn tokens, action governance is what you need and there is a mature project for it. If your agents send money to counterparties you do not control, you need cumulative envelopes over time windows, an authorise-then-settle split, integer arithmetic, and a record of which control refused — none of which falls out of a per-run cost counter.
Convergent design is the useful signal here. Two independent efforts arrived at the same shape: decide before the action rather than report after it, a specification separate from the implementation, machine-readable conformance cases, deterministic evaluation with no model in the decision path, and a verdict carrying a reason. When a project with Microsoft's resources builds the same architecture, that is evidence the category is real rather than a private coinage.
One place they document a gap, and this project closed it
Their ADR on Merkle-chained audit records states, in its own words, that there is "no external blockchain anchoring — verification is self-contained" and consequently "no protection against a complete chain replacement (requires external anchoring for that threat model)".
That is the same conclusion
AEGS-0.1-EVID-6
reaches: a hash chain cannot detect truncation of its own tail, because any prefix of a valid
chain is itself a valid chain. EVID-6a requires what an external
anchor commits to — length and head — and requires verification to distinguish four
outcomes where an unreadable anchor is never reported as consistent.
Governor.verify_anchored() implements it.
The mechanism is not ours, and it is worth naming. This is
Certificate Transparency's model applied to a
spend journal: a CT Signed Tree Head commits to a tree size and a root hash — the same
(length, head) pair, for the same reason — with consistency proofs detecting
omission and witness networks detecting a split view. Anyone who knows CT should find
EVID-6a familiar.
Two things differ. The adversary is not a log operator with many clients watching but the writer of the journal being governed, and there may be exactly one operator — so peer gossip is unavailable and the anchor has to be a party the writer cannot reach. And the unavailable case is named as its own outcome, with a rule against reporting it as consistency. That is the narrow part.
Their evidence model is stronger than Tesoro's in a different direction, and it is worth saying so: it carries proof artefacts for the decision procedure — SMT-verified gates, Coq or Lean derivations, TEE attestation over the deciding binary. That proves the decision was sound. A hash chain only proves the record was not altered. The two claims are orthogonal and Tesoro makes only the second.
Using both together
The layering is straightforward, because the two intercept different things:
- Action governance decides whether the agent may call the tool. If the tool is a paid API, that decision is about permission, identity and blast radius.
- Economic governance decides whether the payment that call requires may happen — against a daily envelope, a per-counterparty envelope, a declared intent, and everything the agent has already spent this month.
- Both write evidence. Only one of them can tell you the agent has spent 94% of its monthly budget across four hundred approved actions, none of which individually looked unusual.
Tesoro requires no framework and imports none. Its integration contract is three calls, and the governor wraps the agent rather than the agent importing the governor — so it composes with an action-governance layer rather than competing for the same interception point.
When you do not need an AEGL at all
Stated plainly, because a governance layer nobody needs is overhead:
- Your agents do not pay anyone. If the only cost is inference on your own API key, a provider spend cap and observability are honestly enough.
- Every payment goes to one counterparty you have a contract with. That is an invoice with a dispute process. Reconcile it.
- A human approves every payment. Then you already have the control, and its cost is the human's time.
The four kinds of AEGL page is the more precise version of this question: it sets out what each level of control can express and where a per-payment cap is genuinely sufficient.
Where next
Stablecoins & irreversibility
Why the rail is the reason the controls are shaped this way.
the rail →Four kinds of AEGL
Which level of control you actually need, and where a cap is enough.
the four types →