AI Data Security: Verify a Record With Bounded Disclosure

Joe BraidwoodCo-founder & CEO

June 2026 · 6 min read

A signed OVERT record can make a covered AI data-security event more legible without routinely disclosing its protected payload. This guide walks through what a record contains, what may cross the configured trust boundary, and how a third party checks the integrity of reported outcomes such as permit, deny, override, or escalate. The record is tamper-evident and independently checkable; it does not prove that the reported control was effective, that every action was captured, or that no other system path exposed data.

Many AI data-security controls rely on logs stored and administered by the operator. Those logs can be useful, but a reviewer also has to account for editability, retention, and scope. OVERT, the open standard published at overt.is, defines a signed record that configured control paths can emit alongside covered actions. The signature binds reported fields; it does not independently establish that the underlying claim is true.

Why a log is not AI data security evidence

Governance says what ought to be done. Operational records help show what a system reported. Policies, audit narratives, and mutable logs are weaker when an outsider cannot detect later changes or establish their coverage. A signed record adds field integrity and attribution to a key, while its scope and trust basis still need review.

A receipt is structured so that supported cryptographic checks can detect later alteration to covered fields. The signer may be the operator, a separate component, or another party depending on the assurance profile. A valid signature identifies the key used; it does not by itself establish signer independence, control effectiveness, or factual accuracy.

That distinction — unsupported assertion versus checkable record — is OVERT’s first commitment. For a configured, in-scope action, a third party can check the artifact rather than rely only on a narrative.

What actually crosses the boundary

Here is the part that matters most for AI data security: a configured data-minimizing profile can keep protected payloads inside an operator-side boundary while sending hashes, bounded metadata, signatures, and other verification material to a verifier. The actual data path remains deployment-specific. A remote model endpoint may still receive prompts, outputs, documents, or tool payloads, and receipt metadata can itself be sensitive.

Concretely, a receipt carries:

• Fingerprints rather than payloads. A cryptographic hash can commit to exact bytes for later comparison. A hash is not encryption and may still reveal information about low-entropy or guessable inputs, so field selection matters.
• A reported enforcement decision. The record can state permit, deny, override, escalation, or response. The signature protects that statement from undetected alteration; it does not prove the decision was correct or effective.
• Scope and execution fields. The record can identify the component, configuration, and declared scope associated with the covered action. It does not establish coverage of uninstrumented paths.
• A signature. Produced by the configured signing key, binding covered fields so later alteration is detectable. Key ownership and organizational independence must be established separately.

A reviewer can check the artifact’s integrity, signer, reported outcome, and declared scope. That can reduce routine payload disclosure, but the reviewer still has to assess metadata exposure, key trust, coverage completeness, control effectiveness, and the system’s actual data flows.

Walking through a verification

Checking signature integrity can be done with the receipt and applicable public key or trust material. Confirming that a hash corresponds to a specific payload may also require controlled access to that payload or to a trusted source hash. The cryptographic check can run in a browser, a CI step, or 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. Alteration to covered bytes causes supported verification to fail, subject to the disclosed key, trust assumptions, and verification procedure. This is what tamper-evident means in practice: tampering is not impossible, and the check remains bounded by those assumptions.

2. Identify the signer and trust basis

The second question is who controls the signing key and what assurance profile applies. The verifier can confirm that the signature traces to the supplied key or trust chain. Establishing whether that signer is organizationally independent requires evidence outside the receipt, such as key custody, deployment ownership, contractual roles, and trust-root governance.

3. Interpret the reported enforcement claim

Once integrity and signer attribution are checked, the reviewer can read the reported enforcement event, component, configuration, and scope. The result is bounded: it shows what the signed record says and whether covered fields changed after signing. It does not, on its own, prove that the control actually ran, that it was effective, or that all relevant actions were recorded.

In a data-minimizing deployment, that check can occur without giving the verifier the protected payload. Hashes, metadata, signatures, and trust material still cross the chosen boundary, and any remote model data path remains separate.

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 can support a more data-minimizing review. An outside party can check the integrity of signed records for covered events — permit, deny, override, escalation, response — without routinely receiving the underlying payloads. If an investigator holds a source payload, its hash can be compared with the recorded fingerprint. The receipts expose the fields included by the profile, not a complete forensic history.

This is the difference between vague coverage and declared coverage. An implementation should state what was in scope, what was excluded, and how denominators were derived. The records do not prove that this accounting is complete, so reconstruction should combine them with routing, deployment, and other operational evidence.

What changed in OVERT 1.1

The mechanisms available for cross-boundary verification were expanded 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, supporting deployments that keep protected artifacts inside a defined local boundary.
• An HTTP transport binding for cross-boundary attestation — a standardized way a record and its bounded fields can move from operator to verifier.
• Automated auditor discovery via a well-known endpoint protocol that implementations can expose to verification tooling.
• A reference schema for the ControlAction artifact — the record described above — already mandated by the standard and now documented in full.

The takeaway for a security reviewer: OVERT defines an interoperable record shape plus transport and discovery mechanisms that implementations can adopt. Actual discovery, retrieval, and checking availability depends on the deployed implementation.

Measurement, not adjective

A receipt resists the thing AI data security marketing does most: substituting confident words for checkable fields. OVERT’s fourth commitment is measurement, not adjective — coverage claims stated with intervals, sample sizes, scope, and exclusions rather than words such as “robust” or “enterprise-grade.” A record can say that a named component and configuration reported a decision for a fingerprinted payload and bind those fields to a signature. It does not certify safety, compliance, effectiveness, or completeness.

See it for yourself

The fastest way to understand a receipt is to verify one. You can check a signed OVERT record yourself in your browser: inspect the fields the sample discloses, validate the signature, and see which claims the cryptographic check supports. In a real deployment, hashes and metadata still require a disclosure review.

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