# AI agent governance > What AI agent governance means in practice: budgets, policy decisions, identity, provenance, quality and drills applied while an agent runs, not after. With the open-source tools for each. 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. ## 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. ## 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. *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. *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. *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. *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. *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. *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. *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. ## 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. ## The order that works. Nobody governs seven planes on the first day. This is the order we deploy in, and the reasoning behind it. All of it is Apache-2.0 and runs on infrastructure you own. [One command starts the live services locally](https://it-rat.com/services/platform.html#run) if you want to see the shape before you commit to any of it, and the whole corridor is [on the stack page](https://it-rat.com/index.html#stack). The defensive half of the same job is in [AI agent security](https://it-rat.com/ai-agent-security.html). ## What people ask about agent governance **Q: 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. **Q: 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. **Q: 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. **Q: 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. **Q: 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.