IT-RAT guides/agent governance All guides The stack
a guide · agent governance

AI agent governance, and what it means at runtime.

An AI agent does not answer a question and stop. It calls tools, spends money, touches data and hands work to other agents, on its own schedule and at machine speed. Governance is the set of controls that decide what it is allowed to do while it is doing it: a budget it cannot exceed, a policy it must ask, an identity that records who it acts for, a memory that can say where a belief came from, and evidence somebody else can check afterwards.

the distinction that matters

Observability is a witness. Governance is a brake.

Most AI tooling sold today is observability: traces, dashboards, token counters, evaluation reports. It is genuinely useful and it is not governance. A trace tells you, after the fact, that an agent looped four hundred times against a production API. A budget tells the agent, on call five, that it may not.

The distinction is not academic. Every failure mode teams actually hit with agent fleets is a failure of control, not of visibility: a retry loop that ran overnight, an agent that called a tool nobody meant to expose, a sub-agent inheriting permissions through a delegation chain nobody had drawn, a model quietly getting worse while the dashboard stayed green. In each case the data was there. Nothing was standing in the path.

Runtime governance means the control sits in the request path, and its answer is binding. Anything else is reporting.

the questions to answer

Seven questions, each with an owner.

Governance sounds abstract until it is broken into the questions a fleet has to answer at runtime. Each one is a separate control, and each has an open-source tool in this stack.

money

What may this run spend?

Budgets that nest from company down to the single run, priced before each call and enforced in the path, so a loop is refused rather than reported.

TokenFuse, the money plane →
policy

May it do this at all?

Allow, deny, or hold for a human, decided per action against policy as code, with signed approval tokens for the actions that need a person.

Wardryx, the policy plane →
identity

Who is it acting for?

One graph of humans, service accounts, keys and agents, with delegation chains and the true blast radius of each identity, not the list of grants on its own name.

Idryx, the access plane →
memory

Why does it believe that?

Memory with provenance and two timelines, so you can ask what the agent knew in March and get March's answer, and correct a fact without erasing the reason it once held.

Engram, the knowledge plane →
quality

Is it still any good?

Cost per correctly resolved case rather than cost per token, with statistical drift detection that catches the small consistent regression a threshold misses.

Verdryx, the quality plane →
crypto

What is it holding, and for how long?

An inventory of the keys, certificates and algorithms actually running, graded against the post-quantum migration dates rather than against an architecture document.

Qryx, the crypto plane →
rehearsal

Do the guardrails hold?

Fire drills against a real gateway, so a broken defence fails a build rather than an incident review. A guardrail nobody tests is a guardrail nobody has.

Mockryx, the pre-prod plane →
the contract

How do they agree?

One agent identifier, one event envelope and one Go binding under all of it, so seven independent tools can describe the same agent without a shared runtime or database.

The shared contract →
approaches that survive contact

Five decisions every governed fleet ends up making.

1. Shadow mode before enforcement

Put the control in the path first with its answer recorded and never binding. You learn what would have been blocked, on real traffic, before anything is. A policy set that has never seen production traffic is a hypothesis, and the first day it enforces is the wrong day to discover that.

2. Fail-open or fail-closed, chosen on purpose

Decide now what happens when the control plane is unreachable. Fail-open treats it as allow: availability wins, and an outage silently disables governance. Fail-closed treats it as deny: governance wins, and an outage stops every governed action. There is no clever third answer. The failure is only embarrassing when nobody chose and everybody assumed.

3. The run is the unit, not the key

Per-key rate limits cannot tell one agent's honest afternoon from the same key looping on itself. The unit that means something for an agent fleet is the run: one task, one budget, one identity, one trace, rolled up to the agent, the team and the company. Every control in this stack keys on it, which is what makes an incident, a spend and a policy decision line up on the same id.

4. A human in the loop, without a parked connection

Approval that holds an open connection while somebody sleeps is not a control, it is an outage waiting for a timeout. The workable shape is stateless: the agent is told to hold, a person decides out of band, and the eventual grant is proven by a signed token bound to that exact agent, run and tool set, not by anyone remembering an open request.

5. Evidence produced as a by-product

Governance that has to be reconstructed for an audit will be reconstructed badly. If every decision, kill and approval is journaled as it happens, each record carrying the hash of the one before it, then the audit is an export rather than an archaeology project, and it stays verifiable by someone who does not trust you.

where to start

The order that works.

Nobody governs seven planes on the first day. This is the order we deploy in, and the reasoning behind it.

Meter before you enforce. Put the money plane in the path in shadow mode. Within a week you know what your fleet actually costs per run, which agent is the outlier, and what a cap would have blocked. This is also the step that pays for the rest.
Turn on the ceiling. Budgets per run, nested up to the team. The first runaway it refuses tends to settle the argument about whether runtime control was worth the effort.
Name the actions that need a human. Usually a small list: money above a threshold, anything that writes to a system of record, anything that touches customer data. A hold with a signed approval is enough; a committee is not.
Draw the identities. Most fleets discover here that half their agents have no owner and a third run on a key nobody rotates. The graph is uncomfortable reading and it is the cheapest security work available.
Rehearse the guardrails in CI. Fire drills that assert the breaker returns its refusal and the policy plane denies the forbidden tool. A guardrail regression should fail a pull request, not an incident review.
Then measure quality in money. Cost per resolved case, drift with statistics behind it. By this point you have the outcome tags to do it honestly, which you did not on day one.

All of it is Apache-2.0 and runs on infrastructure you own. One command starts the live services locally if you want to see the shape before you commit to any of it, and the whole corridor is on the stack page. The defensive half of the same job is in AI agent security.

common questions

What people ask about agent governance

What is AI agent governance?

The controls that decide what an AI agent may do while it is running, rather than the reports that describe what it did. In practice that is six things: a budget it cannot exceed, a policy it must ask before acting, an identity that records who it acts for, memory with provenance, quality measured in outcomes, and drills that prove the guardrails still hold.

How is agent governance different from LLM observability?

Observability is a witness; governance is a brake. A trace tells you afterwards that an agent looped four hundred times against a production API. A budget tells the agent on call five that it may not. Both are useful, but only one of them is standing in the path when it matters.

Do I have to adopt all of it at once?

No, and nobody does. The order that works is metering first, then a ceiling, then naming the actions that need a human, then drawing the identities, then rehearsing the guardrails in CI, and only then measuring quality in money. Each step is a separate Apache-2.0 tool and each is useful alone.

Does putting controls in the request path slow agents down?

The enforcement decision itself is in-process and measured in microseconds, and the gateway is fail-open by design, so an unreachable control plane never becomes the thing that stops your fleet. The latency people notice in agent systems comes from models and tools, not from a budget check.

Can this run on our own infrastructure?

It is the only way it runs. Every plane is self-hosted on infrastructure you own, any cloud or on-prem, and nothing is sent to us: we never hold your keys, your traffic or your data.