Runtime proof · OVERT
AI Governance Tools Need a System of Proof
AI governance tools state intent — policies, registers, approvals. None proves a control ran. OVERT receipts add the runtime proof: asserted, then proven.
AI governance tools have become the system of record for how an organization intends to handle AI. They catalogue models, hold policies, route approvals, and assemble the audit narratives that satisfy a regulator or a board. What they cannot do — by their position in the stack — is prove that any of it executed. A governance platform sits above the runtime. It records that a control was defined and assigned an owner. It does not observe the inference call, the tool invocation, or the agent action where that control either fired or did not.
That gap is not a flaw in the category. It is the category. And it is exactly the gap that a system of proof is built to close.
What AI governance tools actually do — and where they stop
An AI governance platform is an inventory and a workflow engine. It answers questions that matter: Which models are in production? Who owns this one? What policy applies? Has it been risk-assessed against NIST AI RMF or ISO 42001? Has someone signed off? Enterprise AI governance software organizes the intent of the program — the model register, the policy library, the approval trail, the AI governance documentation an auditor will ask to see.
This is real work, and it is necessary. The limitation is structural. Everything a governance tool holds is an assertion. A policy says a control should run. A questionnaire says a vendor claims it does. A logged approval says a human authorized it. None of these is evidence that, at 2:14 a.m. on a Tuesday, the model actually refused the prompt it was supposed to refuse, or that the agent was actually denied the tool it was not supposed to call.
Three properties make this true of every governance dashboard:
- It reads what it is told. A governance platform ingests model metadata, control statements, and self-reported logs. Its picture of reality is only as good as what the operator pipes into it.
- It lives above the boundary. The decisions that matter — permit, deny, override, escalate, respond — happen at the inference, tool-call, and agent boundary. The dashboard is not there when they fire.
- It records intent, not execution. “Control defined” and “control enforced at runtime” are different facts. Governance tooling is fluent in the first and silent on the second.
Governance has always been able to say what ought to be done. It has rarely been able to prove what was. Policies, audit narratives, and self-reported logs record intentions and recollections — they are not evidence.
Assertion versus evidence: the distinction GRC for AI keeps blurring
GRC for AI inherited a comfortable assumption from a decade of software compliance: that a documented, owned, periodically reviewed control is, for practical purposes, a working control. For deterministic software, that assumption mostly held — the same code path ran the same way every time.
AI breaks the assumption. A model’s behavior is probabilistic. A jailbreak that didn’t work last week works today. An agent composes a tool chain no one wrote a policy for. The distance between “we have a control for that” and “the control held on that specific request” is now wide enough to drive an incident through. When a frontier model can be pulled from deployment over a single discovered jailbreak, capability and security stop being separable — and neither is asserted from proven.
So the question every regulated and agentic deployment now faces is not “do we have governance?” It is sharper: can you prove, independently and after the fact, what your AI did and which controls actually held? An AI governance platform, on its own, cannot answer that. It was never built to. It needs something underneath it.
The missing layer: a system of proof at the runtime boundary
That something is a runtime proof layer. Controls enforce at the inference, tool-call, and agent boundary. Each enforcement event produces a signed, tamper-evident receipt of what ran. No protected content leaves the operator’s environment — only fingerprints and signatures cross the boundary. The result is not a prettier log. It is evidence.
GLACIS builds that layer, and it emits its receipts in the open. OVERT is GLACIS’s open standard — a royalty-free patent covenant — for independent, tamper-evident proof that runtime controls executed without protected content leaving the operator’s environment. OVERT rests on four commitments, and each one answers a place where governance tooling goes quiet:
- Evidence, not assertion. A receipt records that an event happened, not that a policy said it should.
- Containment by construction. Only fingerprints and signatures cross the boundary; content stays home. Proof does not require exfiltration.
- Independence by structure. The attester is separate from the system it observes — so the evidence is not the operator vouching for the operator.
- Measurement, not adjective. Intervals and sample sizes an auditor can reproduce, instead of “robust” and “comprehensive.”
Those commitments express themselves as concrete, checkable properties: trusted execution evidence; coverage accounting that states scope, exclusions, and denominators; tamper-evident telemetry that is not reducible to the operator’s own logs; independent verification of enforcement events — permit, deny, override, escalation, response; and post-incident reconstruction without routine content disclosure. When the board or the regulator asks what happened, the answer is a replay of the receipts, not a narrated recollection.
Position your AI governance tools above proof, not against it
This is not a teardown of the governance category, and it is not a migration plan away from it. Your AI governance platform stays exactly where it is — and gets better at the one thing it could never finish.
Think of it as a layered relationship:
- Governance tools state intent. Policies, the model register, control ownership, AI governance framework mappings, the approval trail — the structure of the program lives here.
- OVERT receipts prove execution. They supply the runtime evidence the governance layer was always asking for and could only collect by assertion.
- Together: asserted, then proven. The control statement in your AI governance software and the signed receipt of that control firing at runtime become two halves of one record.
Concretely, the receipt is the artifact that turns a governance entry from a claim into a fact. The policy says the model must refuse a class of prompt; the receipt shows the refusals firing, with reproducible coverage numbers. The vendor questionnaire asserts an AI-for-risk-and-compliance control; the receipt is the independently verifiable evidence that it ran in your environment. Your GRC for AI program keeps the system of record. It gains a system of proof underneath it. Asserted becomes proven, and the audit narrative finally has something behind it an auditor can check.
That changes what your governance dashboard is worth. Instead of being the place where unverifiable claims accumulate, it becomes the index over a body of evidence. Every assigned control can point to the receipts that show it executing. The program stops being a description of what should be happening and starts being a verifiable account of what did.
What this looks like in practice
A security reviewer or a governance lead does not need to rip anything out to start. The runtime proof layer attaches where decisions are made — the inference call, the tool invocation, the agent action — and emits OVERT receipts as those controls enforce. The supporting machinery, scanners and local classifiers, feeds the boundary; the receipts come out the other side as portable, signed evidence. Because the standard is open, the receipts you collect are not locked to one vendor’s reader: anyone can verify one.
The litmus test for any AI governance platform you already run is simple. Ask it one question: show me the proof this control ran on this request, not the policy that says it should have. If the honest answer is the policy, you have found the layer that is missing. Governance tools were never going to produce that proof on their own — they sit above the runtime, and proof is made at the runtime.
Governance tooling and evidence aren’t a choice — they layer. Keep the platform that organizes intent; add the proof layer that settles what actually ran.
Want to see the difference between a claim and a receipt? Verify a receipt and read the open standard at overt.is — then decide what your AI governance tools should be sitting on top of.