Implementation · Model fingerprint attestation
Evidence & limits
On this page
Evidence
- Appendix L.4 describes the design and assumptions, and explicitly leaves construction of a suitable cryptographic challenge to future work 1.
- Footnote 437 calls for public development and incentivized attack testing. Its timing and overhead requirements are proposed criteria 1.
- The separate VRAM-residency challenge tests a block supplied by the verifier 2. This proposal instead targets the declared model or shard already in memory 1.
Limitations
The report's timing argument assumes that an answer needs the model already loaded and that the challenge cannot be made substantially easier by a shortcut 1. Even with a compromised hardware root of trust, it anticipates a prover keeping an equal-or-higher-performance chip ready to answer challenges about the declared model 1. The simultaneous variant addresses declared chips covering for each other 1.
The neutral-cluster checking proposal needs a copy of the model 1. The report leaves both challenge design and validation against attacks open 1.
Blockers
The challenge must require the model or assigned shard in memory and resist shortcuts; the report leaves its construction to future work.
The proposed short deadline and low interference with inference need end-to-end evaluation.
The proposed neutral checking cluster needs a copy of the model.
The report specifies a model-residency goal, a timing-based design and its assumptions, while leaving the challenge itself to future work 1.
Assessed use: checking residency of declared model weights with timed challenges
Development assessment
- R1 met: Appendix L.4 describes fresh challenges, the model-loading timing assumption, later verification with a model copy, and simultaneous challenges across the declared inventory 1.
- R2 not met: the report calls designing a suitable challenge future work. Footnote 437 gives performance and security requirements, without a construction or end-to-end results 1.
The Supporting link to The declared model is the one being served is conditional on a sound challenge. Loaded weights are one part of identifying the serving model. Binding the checked device, time and weights to a delivered response remains a separate requirement. The software-challenge variant is assessed here; the report's TEE and specialized-hardware variants are outside this record. The neutral verifier needs a model copy, so this design is not assessed as weight-confidential.
- A public challenge construction with a security argument covering shortcuts and helper devices.
- Reproducible end-to-end results on realistic models and hardware, with deadlines, error rates and inference overhead.
- A device-binding analysis showing which hardware a timely answer identifies under the stated adversary.
Assessed 2026-10-21 against rubric v1.2.
Security evidence
- Adversarial evaluation
- Published analysis or argument
- Open failures
- 0 critical · 0 significant · 0 minor