AI Data Security: Verify a Receipt Without Exposing the Data

Joe BraidwoodCo-founder & CEO

June 2026 · 6 min read

A signed OVERT receipt makes AI data security legible without ever exposing the data it is about. That is the move this guide makes tangible. You will walk through what a receipt actually contains, what crosses the trust boundary, and how a third party confirms that a runtime control did what it claims — permit, deny, override, escalate — without the protected content ever leaving the operator’s environment. The point is not a prettier audit log. The point is evidence: tamper-evident, independently checkable, and silent about everything it need not disclose.

Most AI data security controls fail at the same seam. A control runs inside your environment, sees sensitive input and output, makes a decision — and then the only record of that decision is a log you wrote, that you store, and that you alone can edit. A reviewer who wants assurance is asked to trust the operator’s word. OVERT, the open standard published at overt.is, closes that gap: a governed action produces its own proof as a by-product of running.

Why a log is not AI data security evidence

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. A log lives inside the system it describes, under the control of the party being asked to demonstrate good behaviour. It can be edited, backfilled, or quietly truncated, and nothing in the artifact itself lets an outsider tell.

A receipt is the opposite kind of object. It is produced at the moment of enforcement, signed by a component separate from the thing being governed, and structured so that any tampering is detectable after the fact. You don’t trust the operator — you check the math.

That distinction — assertion versus evidence — is OVERT’s first commitment: a governed action yields a receipt a third party can check, not a claim it is asked to trust. Everything below is what it takes to honour that in practice.

What actually crosses the boundary

Here is the part that matters most for AI data security: when a control produces a receipt, the protected content stays home. This is containment by construction — only cryptographic fingerprints and signatures cross the boundary. The prompt, the document, the patient record, the trade instruction, the model output — none of it travels. What leaves is a small, structured artifact that says, in effect, a thing of this exact shape passed through this control under this configuration, and here is the proof.

Concretely, a receipt carries:

• Fingerprints, not content. A cryptographic hash stands in for each input and output. The hash commits to the exact bytes — change one character and the fingerprint no longer matches — but it cannot be reversed to recover the data. This is what makes zero data egress real rather than aspirational.
• An enforcement decision. Which event occurred: permit, deny, override, escalation, or response. This is the substantive claim the receipt exists to make verifiable.
• Execution evidence. Which enforcing component, in which configuration, was active when the governed action occurred. A receipt that proved something ran but could not say what would not be worth much to a reviewer.
• A signature. Produced by the attesting party, binding the above together so any later alteration is detectable.

A reviewer holding that artifact learns what they need — that the control fired, in the stated configuration, on data of a specific fingerprint — and nothing they do not. The receipt stays silent about everything it need not disclose. That silence is a feature: it lets you hand proof to an auditor, a regulator, or a customer’s security team without opening a new path for sensitive data to leak.

Walking through a verification

Verification does not require access to the operator’s systems, their logs, or their data. It requires the receipt and the public means to check a signature. The shape of the check is the same wherever it runs — in your browser, in a CI step, in an auditor’s tooling.

1. Check the signature

The first question is integrity: has this artifact been altered since it was signed? The verifier recomputes the signature over the receipt’s contents and compares. If a single field has been touched — a decision flipped from deny to permit, a configuration edited, a timestamp nudged — the signature no longer validates and the receipt is rejected. This is what tamper-evident means in practice: not that tampering is impossible, but that it cannot pass unnoticed.

2. Confirm independence

The second question is who signed it. A receipt signed by the same party that operates the control is self-attestation, and self-attestation is not independent attestation. OVERT’s third commitment is independence by structure: whoever attests is separate from whoever is governed. The verifier confirms the signature traces to that independent attesting party — not to the operator’s own key. Assurance comes from the structure of who-vouches-for-whom, not from a promise in a policy document.

3. Read the enforcement claim

With integrity and independence established, the substantive content is now trustworthy to read. The receipt states which enforcement event occurred and which component and configuration produced it. A reviewer can now answer, with evidence rather than narrative, the question that actually matters: did the control that was supposed to fire, fire — in the configuration it was supposed to be in?

That is the entire trust transfer. No content changed hands. The operator proved a property of their runtime; the reviewer verified it; the protected data never moved.

Reconstructing an incident without opening a data channel

The harder test for any AI data security mechanism is what happens after something goes wrong. When a reviewer needs to reconstruct an incident — what did the system do, in what order, and which controls held — the usual answer is to pull the logs, which means exposing exactly the sensitive content the incident is already about. Post-incident review quietly becomes a second data-exposure event.

OVERT is built to avoid that. Post-incident reconstruction works against the receipts, not the content: an outside party verifies the history of enforcement events — permit, deny, override, escalation, response — without turning attestation into a new protected-data egress channel. The fingerprints let an investigator confirm that the artifact referencing a given input genuinely corresponds to that input, if they hold it, while the receipts themselves reveal only the sequence and outcome of control actions.

This is the difference between coverage you can describe and coverage you can prove. OVERT accounts for what was in scope, what was excluded, and how the denominators were derived — so the reconstruction rests on tamper-evident telemetry that is not reducible to operator-controlled logs. You get the forensic picture without paying for it in fresh exposure.

What changed in OVERT 1.1

The mechanics that make cross-boundary verification routine were strengthened in version 1.1.0, released 11 June 2026 as an additive, backward-compatible minor release. An implementation conformant to 1.0 stays conformant to 1.1 unmodified. The relevant additions live in a new normative Annex G:

• Local content-addressed storage for evidence retrieval and retention integrity, so a receipt’s fingerprints can be resolved against stored artifacts without compromising containment.
• An HTTP transport binding for cross-boundary attestation — the standardised way a receipt moves from operator to verifier.
• Automated auditor discovery via a well-known endpoint protocol, so verification tooling can locate the right attestation surface without bespoke wiring.
• A reference schema for the ControlAction artifact — the receipt described above — already mandated by the standard and now documented in full.

The takeaway for a security reviewer: the receipt is no longer a bespoke object you have to learn one integration at a time. It has a defined shape, a defined way to travel, and a defined way to be found and checked.

Measurement, not adjective

A receipt resists the thing AI data security marketing does most: substituting confident words for checkable facts. OVERT’s fourth commitment is measurement, not adjective — safety stated in intervals and sample sizes an auditor can reproduce, not in prose. A receipt does not say a control is “robust” or “enterprise-grade.” It says this component, in this configuration, produced this decision on data of this fingerprint, and here is the signature. Reproducible, or rejected. That is the standard verifiable AI should be held to.

See it for yourself

The fastest way to understand a receipt is to verify one. You can check a signed OVERT receipt yourself, in your browser — watch the signature validate, see that only fingerprints and metadata are present, and confirm that nothing in the artifact could expose the data it attests to.

When you are ready to put signed receipts under your own inference, tool-call, and agent boundaries, get runtime coverage — or read the open standard at overt.is and /standard. Verify a receipt to start.