Runtime proof · OVERT
AI Governance Tools Need a System of Proof
AI governance tools organize intent: policies, registers, owners, and approvals. Glacis connects that intent to configured control decisions and scoped operational evidence for covered actions — without claiming the record proves safety, compliance, or complete coverage.
AI governance tools have become a system of record for how an organization intends to handle AI. They catalog models, hold policies, route approvals, and assemble material for regulators and boards. By themselves, those records do not establish what a separate control reported for a specific AI action. Governance platforms typically sit above the action boundary: they can record that a control was defined and assigned an owner without independently recording the inference call, tool invocation, or agent action where it was supposed to run.
That gap is not a flaw in the category. It is the category. Operational evidence complements it by recording what a configured control reported for an in-scope action.
What AI governance tools actually do. 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. A policy says a control should run. A questionnaire says a vendor claims it does. A logged approval says a human authorized it. Those artefacts do not by themselves show what the relevant control reported at 2:14 a.m. on a Tuesday, or whether an agent action was denied at the configured boundary.
Three common limitations explain the gap:
- It reads what it is told. A governance platform may ingest model metadata, control statements, and self-reported logs. Its picture of reality depends on the sources and integrations feeding it.
- It may live above the boundary. Decisions such as permit, deny, override, escalate, and respond can happen at inference, tool-call, and agent boundaries that a dashboard does not itself mediate.
- It may emphasize intent over execution. “Control defined” and “control enforced at runtime” are different facts. Many governance platforms emphasize the first; execution visibility and enforcement vary by product and integration.
Governance has always been able to say what ought to be done. Policies, audit narratives, and operator-controlled logs can be evidence of intent or operation, but may not independently establish integrity, signer attribution, completeness, or what a separate control reported for a specific event.
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 sharper question is: can another party check, after the fact, which configured control was invoked and what outcome was recorded for a covered AI action? A governance record alone usually cannot answer that. It needs operational evidence from the action boundary, with scope and limitations attached.
The missing layer: a system of proof at the runtime boundary
That something is an operational evidence layer at the inference, tool-call, or agent boundary. An in-scope event can produce a signed record of the enrolled identity, configured control claim, and reported outcome. In a data-minimizing deployment, protected content can stay inside the operator’s boundary while bounded verification material travels. The record is evidence about the event it covers, not proof that every event was captured or the control was effective.
GLACIS builds that layer and emits records in an open format. OVERT is the royalty-free specification Glacis stewards for portable, signed operational records. The format can support data-minimizing deployments and witness signatures, but the format alone does not establish complete coverage, control effectiveness, signer independence or that protected content stayed local. Those properties depend on the implementation and evidence presented.
- Operational evidence. A receipt binds a covered event claim and reported outcome to an enrolled signing key; it carries more than a policy statement, but remains bounded by what was captured.
- Configured containment. Protected payloads can stay inside the operator’s boundary while hashes, labels, signatures and verification metadata travel.
- Independent verification. Another party can check supported signatures and covered fields. Organisational independence is a separate question about who controls the signing keys and witness service.
- Measurement, not adjective. Scope, exclusions, intervals and sample sizes should replace unsupported words such as “robust” and “comprehensive.”
In a properly instrumented deployment, those properties can support checkable execution metadata, explicit coverage accounting, tamper-evident records of permit, deny, override, escalation or response events, and incident reconstruction without routine disclosure of protected payloads. The evidence still needs to state which paths and fields it covers.
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. The governance platform remains the system for intent, ownership, and review; operational evidence supplies a separate record from the configured action boundary.
Think of it as a layered relationship:
- Governance tools state intent. Policies, the model register, control ownership, framework mappings, and the approval trail live here.
- Operational records carry scoped evidence. They make supported signatures and covered control claims checkable for routed actions.
- Together: intended, configured, recorded, reviewed. The policy statement and the signed event record become two linked parts of an evidence chain, with coverage and limitations stated explicitly.
Concretely, a receipt can link a governance entry to a signed operational claim. The policy says the model must refuse a class of prompt; receipts can record reported refuse outcomes for covered requests and attach the relevant scope. The vendor questionnaire describes the control; the operational record gives a reviewer something specific to verify. The GRC program keeps the system of record and gains a bounded evidence layer beneath it.
That changes what a governance dashboard can index. In-scope controls can point to records of the configured events they cover, while exclusions and unwatched paths remain visible. The result is a more defensible account of what was intended, configured and recorded — not a certificate that the whole system behaved correctly.
What this looks like in practice
A security reviewer or governance lead can start where AI already acts. For actions routed through the configured boundary, an OVERT record can capture the enrolled identity, control claim and reported outcome. Because the format and verifier are open, another party can inspect supported signatures and covered fields without relying on a proprietary reader.
The practical test for a governance stack is simple: show the operational record for this control on this covered request, not only the policy that says it should have run. If the answer is only the policy, the execution-evidence layer is still missing.
Governance tooling and operational evidence aren’t a choice — they layer. Keep the platform that organizes intent; add independently checkable records of what the configured path reported for covered actions.
Want to see the difference between a claim and a receipt? Verify a record and read the open standard at overt.is — then decide what your AI governance tools should be sitting on top of.