Consortium forVerified Computing

K-0019

Evidence binding

Tying verification evidence to the specific device, workload, data and time it describes, so it cannot be substituted, replayed or misattributed.

Source reviewed 2026-09-25

01 / The mechanism and its boundary

What is being described

Evidence binding ties a piece of verification evidence to the device, workload, data and time it describes, so that it cannot be replayed, substituted or attributed to something else S-1603 S-0018.

The IETF remote-attestation architecture states the requirement for devices: evidence must be securely associated with the environment it describes, so that a verifier cannot be tricked into accepting claims that originate elsewhere S-1603. Binding has several dimensions:

  • Device. Evidence is signed with key material held by the attesting device, as in TEE remote attestation S-1603. Scher and Thiergart note that if the private key a chip uses to attest its location were extracted, the chip's location could be spoofed S-0005.
  • Time. A nonce from the appraising party, signed into the evidence, shows that it is fresh rather than replayed S-1603, and network taps hash and timestamp the traffic they capture S-0031.
  • Workload. Shavit's design has chip firmware hash weight snapshots taken at random times, then store the hash where only the firmware can write it or sign it with the chip's private key S-0029. One low-trust system aims to identify each forward pass uniquely and attribute it to the hardware and time that processed it S-0018.
  • Model and data. PAL*M tracks dataset integrity with incremental multiset hashing inside confidential virtual machines, so that attested properties refer to the model and data actually used S-0012.

Binding also constrains when evidence is fixed: for sampled checks, the prover must commit to its records before it learns which ones will be audited S-0017.

Connections in the research map

Related research

mechanism / R3

Model identity attestation

Establishes that responses come from a specific, committed set of model weights, using enclave measurements or recomputation of sampled outputs.

mechanism / R1

Network taps and certifiers

Devices on a cluster's network links that copy and hash all traffic, so a verifier can later check sampled records against declared work.

mechanism / R2

Safeguard attestation

Hardware-signed evidence that an AI service ran its declared safeguards, such as a guardrail classifier or monitor, when producing a given response.

mechanism / R3

TEE remote attestation for AI workloads

Trusted execution environments (TEEs) in CPUs and GPUs sign reports of loaded software, so a remote party can check which code ran an AI workload.

implementation / R3

Apple Private Cloud Compute

Apple's cloud AI inference service, in which user devices send requests only to servers that attest to running software published in a public transparency log.

implementation / R2

Attestable Audits

A research prototype that runs AI safety benchmarks inside a trusted execution environment and publishes attestations binding the model, the audit and the results.

implementation / R3

Tinfoil model identity (Modelwrap)

Tinfoil's method for proving which model weights its enclave-hosted inference service runs, by binding a dm-verity hash of the weights into remote attestation.

Sources and provenance

  1. S-1603 / Tier B

    Remote ATtestation procedureS (RATS) Architecture (RFC 9334) ↗

    H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan · 2023 · Internet Engineering Task Force (RATS Working Group)

    Supports: evidence must be securely associated with its target environment so a verifier cannot be tricked into accepting claims from a different environment; evidence generated with the attester's key material; signed nonces for freshness

    Locator: §3.1; §8.1; §10.2

    Version and catalogue details
  2. S-0018 / Tier B

    A System Overview for Near-Term, Low-Trust AI Compute Verification ↗

    N. Cankaya · 2026 · Machine Intelligence Research Institute

    Supports: evidence can identify each forward pass uniquely and attribute it to the hardware and time it was processed on

    Locator: verification goals

    Version and catalogue details
  3. S-0005 / Tier B

    Mechanisms to Verify International Agreements About AI Development ↗

    A. Scher, L. Thiergart · 2025 · arXiv

    Supports: if a chip's location-attestation private key were extracted, its location could be spoofed

    Locator: On-chip mechanisms for location verification

    Version and catalogue details
  4. S-0031 / Tier C

    The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use ↗

    N. Cankaya · 2026 · The Datacenter Lie Detector

    Supports: taps hash and timestamp captured traffic

    Locator: tap functions

    Version and catalogue details
  5. S-0029 / Tier B

    What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring ↗

    Y. Shavit · 2023 · arXiv

    Supports: chip firmware hashes weight snapshots taken at random times; the hash is stored in firmware-only memory or signed with the chip's private key

    Locator: §4

    Version and catalogue details
  6. S-0012 / Tier B

    PAL*M: Property Attestation for Large Generative Models ↗

    P. Chantasantitam, A. I. Caulfield, V. Duddu, L. J. Gunn, N. Asokan · 2026 · arXiv

    Supports: confidential VMs with GPUs and incremental multiset hashing to track dataset integrity for property attestation

    Locator: abstract

    Version and catalogue details
  7. S-0017 / Tier C

    Example Schemes for Verifying High-Stakes AI Agreements ↗

    Amodo Design · 2026 · Amodo Design

    Supports: prover commits a hash of sampled weights before it learns whether a step will be audited

    Locator: pre-training scheme

    Version and catalogue details
Source review date
2026-09-25
Drafted by (source map)
ai
Review handles (source map)
codex-review