Evidence binding
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 1 2.
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 1. Binding has several dimensions:
- Device. Evidence is signed with key material held by the attesting device, as in TEE remote attestation 1. 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 3.
- Time. A nonce from the appraising party, signed into the evidence, shows that it is fresh rather than replayed 1, and network taps hash and timestamp the traffic they capture 4.
- 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 5. One low-trust system aims to identify each forward pass uniquely and attribute it to the hardware and time that processed it 2.
- 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 6.
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 7.
Related
Used in
- R3Model identity attestation⚠
- R1Network taps and certifiers
- R2Safeguard attestation
- R3TEE remote attestation for AI workloads⚠
- R3Apple Private Cloud Compute
- R2Attestable Audits
- R3Tinfoil model identity (Modelwrap)⚠
- Chips are where they are declared to be
- The declared model is the one being served
- Declared safeguards were applied during inference
Sources
- BH. Birkholz et al. (2023). Remote ATtestation procedureS (RATS) Architecture (RFC 9334). Internet Engineering Task Force (RATS Working Group). Source recordSupports: 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 · §3.1; §8.1; §10.2
- BN. Cankaya (2026). A System Overview for Near-Term, Low-Trust AI Compute Verification. Machine Intelligence Research Institute. Source recordSupports: evidence can identify each forward pass uniquely and attribute it to the hardware and time it was processed on · verification goals
- BA. Scher & L. Thiergart (2025). Mechanisms to Verify International Agreements About AI Development. arXiv. Source recordSupports: if a chip's location-attestation private key were extracted, its location could be spoofed · On-chip mechanisms for location verification
- CN. Cankaya (2026). The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use. The Datacenter Lie Detector. Source recordSupports: taps hash and timestamp captured traffic · tap functions
- BY. Shavit (2023). What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring. arXiv. Source recordSupports: 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 · §4
- BP. Chantasantitam et al. (2026). PAL*M: Property Attestation for Large Generative Models. arXiv. Source recordSupports: confidential VMs with GPUs and incremental multiset hashing to track dataset integrity for property attestation · abstract
- CAmodo Design (2026). Example Schemes for Verifying High-Stakes AI Agreements. Amodo Design. Source recordSupports: prover commits a hash of sampled weights before it learns whether a step will be audited · pre-training scheme