Runtime proof · OVERT
AI Agent Governance: Policy at the Action Boundary
AI agent governance is policy enforced at the action boundary — permit, deny, or require approval per tool call — plus signed evidence of every decision.
AI agent governance is usually sold as paperwork. A charter, a model card, a review board, a slide in the board deck — artifacts that describe what an organization intends its agents to do. Intent is not governance. An agent holds credentials, calls tools, writes to systems of record, and chains those actions together faster than any human can review. The question a governing institution has to answer is not “did we write down what the agent should do?” It is “what actually decided what the agent did, and can we prove it?”
Properly, governance is three things at once. Declared policy: what agents are allowed to do, written down. Enforced policy: a mechanism that permits, denies, or escalates each action as it happens. Proven policy: evidence of those decisions that someone outside your organization can check without taking your word for it. Most AI governance programs have the first. Many assume the second. Almost none produce the third.
This piece is about closing that distance: what AI agent governance actually requires, why the declared-versus-enforced gap is the governing failure, and how to evaluate governance tooling by what it can prove rather than what it promises.
What AI agent governance actually means
To govern is to constrain and direct by authority. For software that only responds, that authority can live in documents, because a human is always in the loop to apply it. For software that acts — that sends the email, runs the query, moves the money — authority has to exist where the action happens. AI agent governance, then, is not the set of things written about the agent. It is the combination of policy applied to the agent's actions and a trustworthy record of how that policy was applied.
This is a narrower definition than the market uses. AI governance broadly covers model risk, data usage, organizational accountability — much of it necessarily documentary. Agent governance is the runtime subset: the part concerned with what an autonomous system does through tools, moment by moment, under authority that either exists at that moment or does not exist at all.
Two consequences follow. First, governance of agents is a property of the deployment, not of the documentation set — you can inherit policies, templates, and frameworks, but you cannot inherit enforcement. Second, the unit of governance is the individual action. An agent is governed to the extent that each of its actions passes through a decision point where policy is applied, and the resulting decisions are attributable and preserved. Everything else is context.
None of this makes the documents worthless. Charters and policies are the input to enforcement — the boundary control has to get its rules from somewhere, and that somewhere should be the written policy the organization has actually ratified. The failure is not writing policy; it is stopping there. A governance program is the whole chain — declared, enforced, proven — and breaking any link turns the rest into assertion.
The declared-vs-enforced gap
Consider a mid-size financial services firm — call it nimbus. Its AI policy states that customer-facing agents may draft emails but never send them without human approval. The policy is real: reviewed by counsel, signed by the CTO, circulated to the team. But the agent's send tool is reachable in its tool chain, and nothing sits between the model's output and the API call. The rule holds only because the model usually follows its instructions. “Usually” is the entire control.
That distance — between what the charter says and what the machinery enforces — is the declared-vs-enforced gap, and it is the governing failure. Not a gap in an otherwise sound program; the gap is the program. When the incident comes, the postmortem will compare the charter against whatever the operator's own software chose to log, and both documents will have been written by the parties being audited.
The gap persists for structural reasons. Prompt instructions are advisory — the model can drift from them across versions, and injected content can redirect an agent mid-task; a prompt injection is precisely an attempt to widen the gap on demand. Tool connectors get added without re-review. Agents acquire new credentials as integrations grow. None of these changes update the charter, because the charter was never connected to the machinery in the first place.
The diagnostic is short. Pick any rule in your AI policy and ask: where, mechanically, is this enforced, and what artifact shows it held for a specific action last Tuesday at 14:03? If the answer is the policy document itself, you have a declaration. You do not have governance.
Governance at the action boundary
For an agent, the decisive event is the tool call — the instant it tries to send, spend, write, or invoke. That is the action boundary, and it is the only place governance can live. A control at that boundary evaluates each call against policy and decides: permit, deny, or require approval. Per tool call, per agent, every time. Enforcement that happens anywhere else — a weekly review, a dashboard, a sampling audit — is advisory, because the action has already occurred.
GLACIS implements this as a proxy that sits in the execution path and applies policy inline to AI actions. Three properties have to hold for that enforcement to count as governance:
- Enforcement is in the path, not beside it. The control mediates the action. Observation after the fact is monitoring — useful, but a different discipline.
- Every decision is an event. Permit, deny, approval requested, approval granted, approval refused — each is recorded as a discrete, attributable decision, not a line buried in application logs.
- Approval is a governed action too. When policy requires a human, the human's decision is captured with the same rigor as the agent's request, so “approved by whom, when, on what basis” is answerable later.
This is the layer most governance tooling assumes exists but does not produce. It is also what makes the security framing in AI agent security and the governance framing here the same problem seen from two sides: controls that act at the boundary, and proof that they did.
Evidence, not dashboards
A dashboard is the operator's account of itself. It asserts. Evidence is different: an artifact that a third party can check independently, whose integrity does not depend on trusting the party that produced it. Governance needs the second. If your record of enforcement is reducible to logs your own systems wrote, then a compromised agent — or a compromised operator — rewrites history along with everything else.
This is what signed receipts are for. Each enforcement decision at the boundary mints a receipt: Ed25519-signed, hash-chained to the receipts before it, anchored in an RFC 6962 transparency log. The receipt is content-free by construction — it carries hashes, counters, and labels, never prompts or personal data — so it can cross trust boundaries the underlying content cannot. Anyone can verify a receipt offline, against a pinned key, at /verify, without trusting GLACIS. The receipt format is an open, royalty-free standard, OVERT, and the independence properties behind it are laid out in what makes AI attestation independent.
Two disciplines matter here, and we hold to them in our own claims. First, receipts do not prove completeness. A receipt proves faithful recording of what passed the boundary — not that every action everywhere was captured. Coverage is a scope question, answered with denominators and exclusions, not adjectives. Second, receipts do not prevent the next incident. We can't stop the next one either, and governance tooling that promises prevention is overpromising. What evidence does is make what happened provable — which changes what you can do afterward: reconstruct the incident, attribute the decision, answer a regulator or a customer with artifacts instead of narratives. A sample evidence pack shows what that looks like assembled.
The chain and the log do the quiet work. Hash-chaining means each receipt commits to the one before it, so removing or reordering decisions breaks the sequence. Anchoring in a transparency log means the history cannot later be swapped for a different one without detection. None of this requires the verifier to see any content — the fingerprints are enough.
Evaluating governance tools honestly
The practical test for any governance tool is what it can prove, not what it promises. Five questions cut through most of the marketing:
- Where is policy enforced? In the execution path, or beside it? If the tool observes actions and files reports, it is monitoring, not governing.
- What does a decision produce? A log line the vendor wrote about itself, or a signed artifact you can verify without the vendor's cooperation?
- What crosses the trust boundary? Content, or fingerprints? Content-free evidence travels further — to auditors, regulators, counterparties — because it does not expose the thing it describes.
- What is claimed about coverage? Treat “complete” and “prevent” as red flags. Ask for scope, exclusions, and the denominators behind any percentage.
- What is live versus designed? Governance roadmaps routinely describe enforcement that has not shipped. Ask what you can run against your own tool calls this week.
Tools that answer these well are rare, and the honest ones answer them narrowly. That narrowness is the point. Governance that survives contact with an incident is governance that was specific about where it enforced and disciplined about what it claims to prove.
The declared-vs-enforced gap closes in exactly one way: policy where the agent acts, and evidence of every decision. If you're deploying agents into regulated or high-stakes environments, get runtime coverage and see what signed enforcement looks like against your own tool calls. You can also verify a receipt yourself, or read the standard at overt.is.