Runtime guardrails for AI · OVERT
Put an operating boundary around the agents you already use
Your rules apply as agents use tools, credentials and infrastructure. Routine work goes through untouched. The risky exceptions get held, narrowed or denied, and either way there’s a signed record someone outside your company can check.
An agent is not a chatbot. It can hold credentials, call tools, move money, write to systems of record, and chain actions faster than a human can review. That changes what AI agent security has to mean. A CTO or security reviewer needs to connect the permission they intended to the control that ran where the agent acted, and to the record that came out of it.
Governance platforms describe intended behavior. Posture tools score configuration, and observability records system events after the fact. Glacis adds a signed record of what the control reported for each action that passed through its boundary. What that record does and doesn’t establish is set out below.
The gap between intent and what happened is where signed records sit in agentic AI security: underneath the governance tools you already run, at the boundary where the agent acts.
Why agent security is a runtime problem, not a document problem
The model layer is now a live attack surface. On 12 June 2026, the US government directed Anthropic to restrict Fable 5 and Mythos 5 access by foreign nationals. Anthropic suspended both models for all users because it said it could not verify nationality in real time. The company said the directive followed a reported method for bypassing Fable 5 safeguards, while disputing the government’s assessment of the finding.
The restriction was temporary. The government lifted the export controls on 30 June, and Anthropic restored Fable 5 globally on 1 July after describing an updated classifier and further safeguard work. The operational lesson has little to do with whether the model is available today. Access and controls can change quickly, and teams downstream still need a current account of what their own systems reported.
When that happens, a policy document tells you what was supposed to occur. It can’t tell you what did, and for an agent acting through tools that is the question a reviewer is asking.
Intent versus evidence
Governance states what ought to be done. An operational record adds an account of what the control reported where the agent acted. A log written by the agent or operator is still a claim from that system; a signature makes later alteration detectable, but it doesn’t make the claim true.
AI agent security turns on keeping those questions apart. Dashboards, policies and signed records each answer a different one, and a deployment that blurs them can’t support the account it gives after an incident.
The action boundary is where security has to live
For an agent, the decisive event can be the tool call: the instant it tries to send the email, run the query, hit the payment API, or invoke another agent. Tool-call security means a control sits at that boundary and decides whether to allow, constrain, hold or deny. Observation after the action is advisory; enforcement can also sit at other system boundaries that mediate the action.
Three things need defining at that boundary before a runtime-security claim can be reviewed:
- Enforcement sits in the path. The control mediates the action rather than observing it after the fact.
- Each decision produces a named event. Allow, constrain, hold and deny are recorded as discrete events, with whatever attribution the integration can supply.
- The record is tamper-evident. Signature and chain checks can show whether the signed fields were changed later.
This is the layer between governance intent and tool execution. Governance tooling defines the policy; the boundary control applies it and writes a record of what it reported.
A signed record anyone can check
This is where OVERT comes in. OVERT is Glacis’s open standard for signed, tamper-evident operational records, released royalty-free under a patent covenant. Version 1.1.0 shipped on 11 June 2026 as a backward-compatible, additive minor over 1.0.
OVERT records are built around four disciplines:
- The record says what it covers. It names the control, the reported outcome, the signer and the fields it signs.
- Data minimization. A deployment can put hashes, labels and selected metadata in the record instead of raw prompts or tool payloads.
- Disclosed provenance. The record says who signed or witnessed it.
- Coverage is measured. A coverage claim states the inventory, interval, exclusions and denominators, so a reviewer can redo the arithmetic.
In practice, each decision the control makes at the boundary emits a signed record in an open format. Someone outside your company can verify it in a browser, with no Glacis account, and it stays readable whether or not you’re still a customer. The verifier confirms the record is intact, shows which key signed it and what it links to, and reads back the decision it recorded. It doesn’t tell you whether the action was the right one, whether every tool call passed through the boundary, or whether the system is safe or compliant, and it can’t confirm that events happened the way the record says.
What changed in OVERT 1.1
Version 1.1 adds a normative Annex G, with G.4 explicitly informative. G.1 defines local content-addressed evidence retrieval and retention-integrity requirements. G.2 binds cross-boundary attestation context to HTTP using trace and parent-attestation references. G.3 defines a well-known discovery document and artifact-retrieval flow for supported verification. G.4 documents an informative reference schema for the ControlAction artifact already mandated by Section 10.
The official changelog also records refreshed Colorado and EU references, framework crosswalks moved to an informative companion, the Attestation Boundary Declaration renumbered from 29.4 to 22.10, and scanner and local-classifier components clarified. Section 22.11 defines versioning and errata and keeps identifiers such as ATT-3.5 and GOV-5.6 stable within a major version. OVERT classifies 1.1 as a minor release: existing 1.0 implementations remain conformant without modification, while new obligations apply to claims citing 1.1 or later.
How this sits with your governance stack
None of this displaces the governance, risk and compliance tools you run. A GRC platform states what the agent should do. OVERT records add a signed account of what the control decided. The policy layer declares the control; the record lets someone outside your company check what it reported.
For agentic AI security specifically, that pairing helps when a model shifts, an input slips past, or a regulator or customer asks what happened. You answer from the signed records for that path, each with the event time it reported, rather than from a log you’d have to take on trust.
That is the shape of AI agent security worth building: a control where the agent acts, and a signed record of what it decided.
If you’re deploying agents into regulated or high-stakes environments, Talk to us and see what signed enforcement looks like against your own tool calls. You can also Verify a record yourself, or read the standard at overt.is.