Runtime proof · OVERT
AI security controls are stronger when the evidence can be checked
Alerting, detection, correlation, and dashboards alone may not produce a portable, independently checkable artifact. Signed OVERT records add checkable integrity, signer, scope, and reported-outcome fields for configured runtime paths.
Alerting, detection, correlation, and dashboards alone may not produce a portable, independently checkable artifact. That work matters — but when a regulator, an auditor, or your own general counsel asks the harder question, they also need to inspect what the configured control path reported, which fields were signed, and what was outside scope. A receipt can strengthen that record. It does not prove control effectiveness or complete coverage.
This is the line between monitoring alone and a bounded evidence layer. Detection tells you what might have happened. A signed record can give an outside party checkable integrity and attribution for reported outcomes. As AI systems move from suggesting text to taking actions — calling tools, moving money, touching patient records — that distinction matters.
Why detection and dashboards run out of road
A dashboard is a story your own system tells about itself. That is useful for operating an estate day to day, but a screenshot does not establish which configuration was associated with a specific agent decision three weeks ago. Logs can be edited and retention can lapse; reviewers need to understand those limits.
Self-reported telemetry has a structural limitation: the operator often controls the record. A signed artifact can make later alteration detectable and attribute covered fields to a key. The signature alone does not establish that the signer is organizationally independent or that the reported event is accurate.
There is a second cost, and it is the one security teams feel most. Many tools achieve visibility by pulling sensitive content out of the environment — prompts, outputs, documents — into someone else’s pipeline to inspect. You buy insight and inherit a new data-exfiltration surface. The thing meant to reduce risk becomes a place risk now lives.
Detection, correlation, and alerts do not necessarily produce something portable that procurement, legal, or an external auditor can check directly. That additional artifact and its trust basis have to be designed explicitly.
What evidence-first AI security solutions change
Reframe the category around one demand: an in-scope governed action should leave behind a record an outsider can check. In a configured data-minimizing deployment, protected payloads can remain inside the operator-side boundary while hashes, metadata, signatures, and other verification material travel. Remote model endpoints and other paths may still receive payloads.
Governance says what ought to be done. Policies, audit narratives, and self-reported logs remain useful, but they may not provide field-level integrity, signer attribution, or explicit scope. A signed record supplements them with a tamper-evident, independently checkable artifact whose disclosed fields can be bounded by profile and deployment.
Concretely, that artifact has a few properties worth naming, because they are what an auditor can actually reproduce:
- Execution and configuration fields — the component and configuration associated with a covered action, as reported in the signed record. The signature protects the report; it does not prove effectiveness.
- Coverage accounting — what was declared in scope, what was excluded, and how denominators were derived. The records do not prove that the accounting is complete.
- Independent verification of cryptographic properties — a verifier with the applicable record and key material can check signatures and covered fields. That does not establish signer organizational independence.
- Post-incident review with less routine payload disclosure — selected event fields can be checked without automatically sending the underlying content to the reviewer.
That last point is the discipline that keeps the cure from becoming the disease.
Runtime security is where the proof has to be made
Intent lives in documents. Action lives at runtime. So useful records should be produced on the configured path where a relevant decision is made: at an inference boundary, a tool call, or an agent’s decision to act. Paths that are not instrumented remain outside that evidence boundary.
The motion is runtime coverage. For configured, in-scope events, a control path can emit a signed record of the decision and reported outcome. Teams still need routing and denominator evidence to show which actions entered that path; receipts alone do not prove complete capture or prevent instrumentation from being bypassed or disabled.
This is also where data minimization is decided. A deployment can keep protected payloads local to the operator-side instrumentation while sending fingerprints, bounded metadata, signatures, and trust material to a verifier. That is not zero egress: verification material crosses the boundary, and a remote model or tool endpoint may still receive the payload according to the wider system design.
Evidence you can hand to security, legal, and procurement
Here is the practical test of an AI security solution: when three different people ask the same system the same question, do they all get an answer they can independently trust?
- Security wants to know an enforcement event happened the way the policy says it should — and wants to confirm it without taking the operator’s word for it.
- Legal wants an artifact that survives scrutiny: tamper-evident, attributable, reconstructable, and defensible if it is ever contested.
- Procurement and external auditors want to verify a vendor’s claims against something real, not re-read the vendor’s own marketing in a longer questionnaire.
A receipt can serve all three from one bounded source because a reviewer can check supported cryptographic properties without asking the operator to declare a pass. The signer may still be the operator or an operator-controlled component. Organizational independence, key custody, and the truth of the reported event require separate evidence.
This is where an open AI security standard earns its keep. If the record format and verification method are open, anyone with the applicable artifact and key material can run the same supported checks. They should get the same cryptographic result, while still applying judgment to scope, trust roots, accuracy, effectiveness, and completeness.
From alerts to artifacts
None of this retires detection. You still want the alert feed, anomaly scoring, and a live view of your AI estate. The argument is narrower: detection alone is not the finished evidence set. A signed runtime artifact can add checkable integrity and attribution for covered fields, and a data-minimizing profile can avoid routine disclosure of protected payloads to the verifier.
Measure your tooling against that bar. Can it identify the control and configuration reported for a covered action? Can it state scope, exclusions, and coverage denominators? Can an outsider check the signed fields, and can you explain every payload, metadata, and verification-material path? If the answer is only “it can show you a dashboard,” you have monitoring but not yet the bounded operational evidence described here.
The strongest AI security solutions are the ones that leave something behind worth checking — and let anyone who matters do the checking.
See what a verifiable control-execution record looks like, or start where AI already acts and discuss where the evidence boundary sits. Verify a record — or Talk to us.