Runtime proof · OVERT
AI Agent Governance: Policy at the Action Boundary
AI agent governance connects intended policy to configured permit, deny, and approval controls at the action boundary, then leaves signed records for actions routed through that boundary.
AI agent governance is often presented 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. An agent can also hold credentials, call tools, write to systems of record, and chain actions faster than a human can review. A governing institution therefore needs to ask not only “did we write down what the agent should do?” but “what decided this covered action, and what record supports that account?”
Operational governance connects three things. Declared policy: what agents are allowed to do. Configured enforcement: a mechanism that permits, denies, or escalates actions on identified routes. Operational evidence: records of those covered decisions that another party can check. A signed record can support integrity and key attribution for its covered fields; it does not by itself establish that the claim is true, the control was effective, or all action paths were included.
This piece is about closing that distance: what AI agent governance requires at a defined action boundary, why the declared-versus-enforced gap matters, and how to evaluate governance tooling by the claims its records can actually support.
What AI agent governance actually means
To govern is to constrain and direct by authority. For software used only as decision support with a genuine human decision-maker, some authority may remain in documented human process. 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 scoped record of what the configured control reported.
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 a particular deployment, not only of its documentation set — policies, templates, and frameworks do not establish that enforcement is present on a route. Second, the useful unit of analysis is the individual covered action. A deployment can apply policy at identified decision points and preserve the reported outcomes, while separately naming routes outside that scope.
None of this makes the documents worthless. Charters and policies are inputs to enforcement — the boundary control has to get its rules from somewhere, and that source should be the policy the organization has ratified. The failure is stopping at documentation. A defensible program connects declared policy, configured enforcement, and scoped evidence, while being explicit about what the evidence cannot establish.
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 many agents, a decisive event is the tool call — the instant the system tries to send, spend, write, or invoke. A configured control at that action boundary can evaluate routed calls against policy and decide: permit, deny, or require approval. Weekly reviews, dashboards, and sampling audits remain useful, but they do not mediate an action that 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 covered path. The control mediates a routed action. Observation after the fact is monitoring — useful, but a different discipline.
- Each covered decision can produce an event. Permit, deny, approval requested, approval granted, and approval refused can be recorded as discrete, attributable decisions.
- Approval is a governed action too. When policy requires a human, the human’s decision can be captured alongside the agent’s request, subject to the identity and context available to the integration.
This is the layer between governance intent and agent execution. It also makes the security framing in AI agent security and the governance framing here the same problem seen from two sides: configured controls at the boundary and scoped records of their reported decisions.
Evidence, not dashboards
A dashboard is generally the operator’s presentation of system state. A signed artifact adds a different capability: a third party can check whether covered fields remain intact and whether the signature validates against a disclosed key. Those checks do not establish that the signer was truthful, that its key was uncompromised, or that the signer was organizationally independent from the operator.
This is what signed receipts are for. A configured enforcement decision can emit an Ed25519-signed receipt and link it to prior receipts. Depending on the deployment, the record may carry hashes, counters, labels, and selected metadata instead of raw prompts or payloads. Payload locality is a deployment property: it must be established from routing, configuration, and egress controls, not inferred from a signature. A verifier can check a supported receipt offline against a pinned key at /verify. The receipt format is published through the open OVERT standard; the relevant verification limits are described in what makes AI attestation independently verifiable.
Two disciplines matter here. First, a receipt does not prove completeness. It supports integrity and key attribution for the claim recorded on a covered path; it does not establish that every action was captured, that the reported event occurred exactly as claimed, or that the control was effective. Coverage is a scope question, answered with inventories, denominators, and exclusions. Second, receipts do not prevent the next incident or certify safety or compliance. They can make a bounded operational account easier to reconstruct and challenge. A sample evidence pack shows how those records can be assembled.
Hash links can reveal alteration or reordering within the chain presented for verification. A separately published anchor can add evidence that a committed chain existed by a particular point. Neither mechanism detects an event that never entered the covered path, and neither removes the need to assess signer provenance, keys, scope, and source-system truth.
Evaluating governance tools honestly
The practical test for any governance tool is which claims its evidence can support. Five questions cut through much 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? An operator-controlled log, a signed record, or both — and what can each artifact actually establish?
- What crosses the trust boundary? Content, selected metadata, or commitments? A data-minimizing record may reduce exposure, but hashes are not confidentiality and field choice still matters.
- 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 is currently available on the named path.
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 narrows when intended policy is connected to configured controls and scoped records on named action paths. If you’re deploying agents into regulated or high-stakes environments, Talk to us about the action path that matters most. You can also Verify a record yourself, or read the standard at overt.is.