{
  "schema_version": "1.8.0",
  "rubric_version": "1.2",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "I-0027",
    "slug": "model-fingerprint-attestation",
    "title": "Model fingerprint attestation",
    "aliases": [
      "Timed model residency",
      "Model-weight residency challenge"
    ],
    "status": "published",
    "last_reviewed": "2026-10-21",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": [
        "codex-review"
      ]
    },
    "risk_flags": [],
    "flags": [],
    "one_liner": "A proposed timed challenge that tests whether declared model weights are already in a chip's memory.",
    "summary": "Model fingerprint attestation is a proposal to check that a declared model is loaded in a chip's memory. The Oxford Martin AI Governance Initiative's verification report describes fresh challenges that would need the model or an assigned shard already in memory to answer before a deadline. Loading the model after receiving the challenge would take too long. A neutral cluster holding a copy of the model could check answers later. The report proposes challenging all declared inference chips simultaneously to prevent them covering for one another. It leaves the challenge construction to future work. Its roughly 50 ms ceiling is a design target, without a measured implementation [[S-0004]].",
    "category": "cryptographic-computational",
    "secondary_categories": [],
    "verifies": [
      {
        "claim": "C-0005",
        "role": "supporting",
        "note": "A sound timed challenge over declared weights would support model identity by checking their residency (S-0004). Residency alone does not bind a particular delivered response to those weights. The report leaves the challenge construction to future work."
      }
    ],
    "threat_model": "adversarial",
    "adversarial_evaluation": "analysis",
    "hardware_requirement": "none",
    "prover_cooperation": "required",
    "confidentiality": "revealing",
    "depends_on": [],
    "readiness": {
      "assessment": true,
      "level": "R1",
      "scope": "checking residency of declared model weights with timed challenges",
      "rubric_version": "1.2",
      "rationale": "The report specifies a model-residency goal, a timing-based design and its assumptions, while leaving the challenge itself to future work [[S-0004]].\n\n- **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 [[S-0004]].\n- **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 [[S-0004]].\n\nThe Supporting link to [[C-0005]] 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.",
      "evidence": [
        "S-0004"
      ],
      "next_level_gaps": [
        "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."
      ],
      "gap_annotations": [
        {
          "gap": 1,
          "gap_type": "technical",
          "gap_group": "model-residency-challenge"
        },
        {
          "gap": 2,
          "gap_type": "evaluation"
        },
        {
          "gap": 3,
          "gap_type": "technical",
          "gap_group": "device-identity-binding"
        }
      ],
      "confidence": "medium",
      "assessed_by": [
        "codex-review"
      ],
      "assessed_on": "2026-10-21",
      "status": "current",
      "dispute": null
    },
    "flaws": [],
    "blockers": [
      {
        "text": "The challenge must require the model or assigned shard in memory and resist shortcuts; the report leaves its construction to future work.",
        "historical": false,
        "gap_type": "technical",
        "gap_group": "model-residency-challenge",
        "theme": "protocol-soundness",
        "blocked_by": null,
        "sources": [
          "S-0004"
        ]
      },
      {
        "text": "The proposed short deadline and low interference with inference need end-to-end evaluation.",
        "historical": false,
        "gap_type": "evaluation",
        "theme": "performance-compatibility",
        "blocked_by": null,
        "sources": [
          "S-0004"
        ]
      },
      {
        "text": "The proposed neutral checking cluster needs a copy of the model.",
        "historical": false,
        "gap_type": "engineering",
        "theme": "access-governance",
        "blocked_by": null,
        "sources": [
          "S-0004"
        ]
      }
    ],
    "challenge_themes": [
      "evidence-binding",
      "protocol-soundness",
      "adversarial-validation",
      "performance-compatibility",
      "access-governance"
    ],
    "organizations": [
      "O-0205"
    ],
    "people": [],
    "sources": [
      {
        "source": "S-0004",
        "supports": "loaded-model goal; timed software variant; model-loading assumption; unpredictable challenges; neutral batch checking; simultaneous inventory challenges; whole-model or shard requirement; random-weight variant; roughly 50 ms target; construction and attack testing left open",
        "locator": "Appendix L.4, pp. 159–160, especially footnote 437",
        "essential": true,
        "reading_note": "Appendix L.4 describes the timed model-residency proposal. Footnote 437 sets the desired timing, memory dependence and low overhead, and suggests challenges over random portions of weights if a whole-model challenge is too costly.",
        "reading_order": 1
      },
      {
        "source": "S-0033",
        "supports": "the separate VRAM-residency experiment challenges verifier-supplied data",
        "locator": "§3; §4.3"
      }
    ],
    "concepts": [
      "K-0001",
      "K-0002"
    ],
    "kind": "proposed-architecture",
    "developer": [
      "O-0205"
    ],
    "realises": [
      "M-0016"
    ],
    "homepage": "https://aigi.ox.ac.uk/wp-content/uploads/2025/07/Verification-for-International-AI-Governance.pdf#page=160",
    "type": "implementation",
    "url": "https://trustbutveri.fyi/implementations/model-fingerprint-attestation/",
    "source_file": "content/implementations/model-fingerprint-attestation.md",
    "flags_all": [],
    "body_markdown": "## What it is\n\nModel fingerprint attestation is a proposal in the Oxford Martin AI Governance Initiative's *Verification for International AI Governance* report to show that a specified model is loaded in memory on specified hardware [[S-0004]]. Its timed variant applies [[M-0016|timed challenge-response]] to the model's weights [[S-0004]]. The report also describes remote attestation and confidential computing as simpler ways to establish model residency [[S-0004]]. TEE-based weight binding is covered in [[M-0012]].\n\n## How it works\n\n1. The verifier generates an unpredictable challenge immediately before sending it. The proposed computation would need the declared model or an assigned shard already in memory [[S-0004]].\n2. The prover answers within a short deadline. The report assumes loading a different model would take seconds or longer. The deadline is intended to rule out loading it after the challenge [[S-0004]].\n3. A neutral cluster with a copy of the model checks the answers later, potentially in batches. The verifier need not know the expected answer when sending the challenge [[S-0004]].\n\nAn expanded design challenges all declared inference chips simultaneously to prevent declared chips covering for one another [[S-0004]]. Footnote 437 proposes a maximum of about 50 ms with little interruption to ongoing inference. If using the whole model is too costly, it suggests selecting a random portion of the weights from the challenge, with a tighter deadline [[S-0004]].\n\n## Evidence\n\n- Appendix L.4 describes the design and assumptions, and explicitly leaves construction of a suitable cryptographic challenge to future work [[S-0004]].\n- Footnote 437 calls for public development and incentivized attack testing. Its timing and overhead requirements are proposed criteria [[S-0004]].\n- The separate [[I-0019|VRAM-residency challenge]] tests a block supplied by the verifier [[S-0033]]. This proposal instead targets the declared model or shard already in memory [[S-0004]].\n\n## Limitations\n\nThe 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 [[S-0004]]. 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 [[S-0004]]. The simultaneous variant addresses declared chips covering for each other [[S-0004]].\n\nThe neutral-cluster checking proposal needs a copy of the model [[S-0004]]. The report leaves both challenge design and validation against attacks open [[S-0004]].",
    "body_text": "What it is Model fingerprint attestation is a proposal in the Oxford Martin AI Governance Initiative's Verification for International AI Governance report to show that a specified model is loaded in memory on specified hardware [S-0004]. Its timed variant applies timed challenge-response to the model's weights [S-0004]. The report also describes remote attestation and confidential computing as simpler ways to establish model residency [S-0004]. TEE-based weight binding is covered in Hardware-attested weight binding. How it works 1. The verifier generates an unpredictable challenge immediately before sending it. The proposed computation would need the declared model or an assigned shard already in memory [S-0004]. 2. The prover answers within a short deadline. The report assumes loading a different model would take seconds or longer. The deadline is intended to rule out loading it after the challenge [S-0004]. 3. A neutral cluster with a copy of the model checks the answers later, potentially in batches. The verifier need not know the expected answer when sending the challenge [S-0004]. An expanded design challenges all declared inference chips simultaneously to prevent declared chips covering for one another [S-0004]. Footnote 437 proposes a maximum of about 50 ms with little interruption to ongoing inference. If using the whole model is too costly, it suggests selecting a random portion of the weights from the challenge, with a tighter deadline [S-0004]. Evidence - Appendix L.4 describes the design and assumptions, and explicitly leaves construction of a suitable cryptographic challenge to future work [S-0004]. - Footnote 437 calls for public development and incentivized attack testing. Its timing and overhead requirements are proposed criteria [S-0004]. - The separate VRAM-residency challenge tests a block supplied by the verifier [S-0033]. This proposal instead targets the declared model or shard already in memory [S-0004]. 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 [S-0004]. 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 [S-0004]. The simultaneous variant addresses declared chips covering for each other [S-0004]. The neutral-cluster checking proposal needs a copy of the model [S-0004]. The report leaves both challenge design and validation against attacks open [S-0004].",
    "development_status": {
      "code": "R1",
      "label": "Proposed",
      "short": "Proposed",
      "rank": 1,
      "legacy_code": "R1"
    },
    "security_evidence": {
      "attack_testing": {
        "status": "analysis",
        "label": "Published analysis or argument",
        "kind": "analysis"
      },
      "independent_evaluation": {
        "status": "unassessed"
      },
      "formal_proof": {
        "status": "unassessed"
      },
      "deployment_assurance": {
        "status": "unassessed"
      },
      "legacy_evaluation_code": null,
      "scoped_findings": [],
      "open_failures": {
        "critical": 0,
        "significant": 0,
        "minor": 0
      }
    },
    "finding_counts": {
      "failure": 0,
      "scope_limitation": 0,
      "open_question": 0,
      "open_failures": {
        "critical": 0,
        "significant": 0,
        "minor": 0
      }
    },
    "referenced_by": [
      {
        "id": "M-0012",
        "title": "Hardware-attested weight binding",
        "url": "https://trustbutveri.fyi/mechanisms/model-identity-attestation/"
      },
      {
        "id": "M-0016",
        "title": "Timed challenge-response and memory-occupation challenges",
        "url": "https://trustbutveri.fyi/mechanisms/timed-challenge-response/"
      },
      {
        "id": "I-0019",
        "title": "VRAM-residency challenge",
        "url": "https://trustbutveri.fyi/implementations/vram-residency-challenge/"
      },
      {
        "id": "C-0005",
        "title": "The declared model is the one being served",
        "url": "https://trustbutveri.fyi/claims/declared-model-is-served/"
      },
      {
        "id": "O-0205",
        "title": "Oxford Martin AI Governance Initiative",
        "url": "https://aigi.ox.ac.uk/"
      }
    ]
  }
}