Verifiable Model Identity: How Cryptographic Attestations Make AI Outputs Auditable

You call the API. You pass model: “claude-fable-5”. You get back a completion, a token count, and a field that reads “model”: “claude-opus-4-8”.

That one-sentence mismatch stands for a practical problem: in multi-tenant hosted runtimes the human-readable model name you send increasingly acts as a label, not a cryptographic proof of the exact artifact that produced the response. Verifiable model identity matters when outputs are used for contracts, compliance, audits, or litigation. If routing, quantization, or alias-style redeployments swap in a different architecture, weights set, or numeric precision at runtime, the thing you tested or bought might not be the thing that produced the output.

“Routing is good engineering. It is also, right now, an unlogged, signed, unverifiable substitution of the thing you bargained for. The model ID has quietly become a legal identifier. It is time somebody decided what it identifies.”

How the mismatch happens

Three common operational patterns create the gap between the model name you request and the artifact that actually serves the response.

Routing / substitution: A routing classifier looks at a query’s context and dispatches it to a cheaper, safer, or faster model. Cursor announced Cursor Router on 22 July 2026, saying the classifier was trained on “600, 000-plus live requests” (vendor-reported) and that three early-access accounts reported “30-50% savings” when they routed selectively instead of sending everything to a single model (vendor-reported). Routing saves cost and latency, but it can deliver a different served model than the caller requested unless the runtime records and proves the assignment.
Degradation via quantization: Providers sometimes serve lower-precision (quantized) weights to reduce memory and cost. OpenRouter’s documentation (June 2026) warns some providers serve quantized endpoints at lower prices, that outputs can differ from full-precision weights, and that logs won’t always reveal when quantization happened.
Drift / silent weight updates: Vendors redeploy or swap fallbacks, so an alias can point to different artifacts over time. Anthropic documented this behavior in “Redeploying Claude Fable 5” (30 June 2026): blocked requests were routed to Opus 4.8 and users were notified, and Anthropic’s response metadata can show which model served the request. That disclosure is a useful counterexample to total opacity, but vendor practices vary widely.

Why this matters to business and law

When model names don’t reliably identify the served artifact, three concrete risks follow.

Contract and warranty exposure: A model name in an SLA or purchase order can function as a description that creates an express warranty. For example, UCC §2-313(1)(b) (express warranty by description) supports the idea that asking for “claude-fable-5” could create an expectation that the named model’s behavior will be delivered. If a different model or a quantized variant produced the output, a buyer could allege breach of an express description-based warranty. (Analogous sale-by-description doctrines exist in other jurisdictions, e.g., India’s Sale of Goods Act, 1930 §15.)
Consumer-protection / deception risk: The FTC’s deception doctrine targets material misrepresentations likely to mislead reasonable consumers. If a provider advertises a capability tied to a specific model and runtime routing or quantization undermines that representation without disclosure, the FTC or state regulators could view that as actionable deception, especially where customers rely materially on the claimed capability.
Evidentiary and auditability problems: Admitting machine-generated content or logs in court requires authentication. Under FRE 901(b)(9) the provenance can be shown by describing a system or process; FRE 902(13)/(14) permits certain self-authenticating electronic records accompanied by certified hashes. India’s Bharatiya Sakshya Adhiniyam, 2023 §63 similarly conditions admissibility of electronic records on a certificate describing the record and manner of production. Those pathways exist, but they require verifiable, tamper-resistant artifacts from the producing system, something opaque routing and unlogged quantization do not provide today.

Cryptographic attestations: the proposed technical fix

Contracts and auditing rules can only go so far if the runtime cannot prove what actually executed. A more durable and verifiable approach is per-response cryptographic attestations that bind a completion to the artifact and runtime context that produced it.

An attestation should at minimum bind a completion to an auditable tuple and a signed timestamp. Practically useful fields include:

served model identifier (the canonical name the serving runtime recognizes)
weights hash (a cryptographic digest of the served artifact: the quantized file or canonical serialized weights)
numeric precision (e.g., float16, int8-quantized)
system-prompt hash (digest of the system prompt and any hidden context injected by the runtime)
request nonce and timestamp

Signed by a hardware-rooted key from a trusted enclave (TEEs / confidential-computing platforms), that attestation lets an outside verifier check that a particular enclave with a particular measurement produced the response. Remote attestation patterns are established (see edera.dev’s explainer on attestation). But important caveats apply:

Measurement scope: Remote attestation proves the signed measurement of what loaded into the enclave. It proves the runtime saw the artifact whose hash is in the attestation only if the model artifact itself is included in the enclave’s measurement process. Simply running a model inside a TEE without measuring the loaded weights into the attestation value does not prove the weights used.
Serialization and fingerprinting complexity: Large models and multiple precision variants multiply artifacts. A hash of an int8 quantized file differs from a float16 weight hash even when behavior is similar. Canonical serialization, meaning exact bytes and agreed metadata, is necessary to make weights hashes meaningful and robust across providers.
Attestation does not automatically prove absence of upstream substitution: If a router or proxy reassigned a request before the attested enclave received it, the attestation speaks only for the final enclave’s inputs. Either the final enclave must attest to the full request history or upstream components must produce chained attestations.

Why not just sign logs with TLS keys or a vendor certificate? Network or application-layer signatures protect transport integrity but do not stop the host from rewriting logs or substituting artifacts before signing. Hardware-rooted keys (TPMs, Nitro-style attestation) tie the signature to a measured runtime state, making post-hoc tampering far harder to conceal.

Trade-offs and pragmatic designs

Per-response attestations are technically feasible but they add cost and sensitivity. Here are common trade-offs and lower-friction alternatives that keep verifiability while reducing overhead.

Cost and latency: Signing every response increases CPU/GPU and storage costs, and can add latency. Practical deployments may use batching or sampling to balance cost and evidentiary value.
IP and confidentiality: Publishing weights hashes is less revealing than publishing weights, but companies legitimately worry about what fingerprints leak. One compromise is to sign manifests internally and disclose them only under contract, audit, or subpoena.
Signed run manifests: For each serving run or time window, publish a signed manifest mapping request IDs (or deterministic request hashes) to the served model artifact. Retain manifests for a contractual discovery window so request-level verification is possible without per-response signing.
Batched attestations and on-demand verification: Vendors can sign batches or periodic snapshots of the serving configuration and produce request-level attestations on demand (e.g., during an audit or litigation), balancing discoverability and IP protection.
Chained attestations: If routers make decisions, each hop can produce an attestation; the final proof is a chain that documents the route and final serving artifact.

What success looks like

A practical, adoptable ecosystem needs three foundations:

Canonical artifact fingerprints: agreed serialization rules for weights, quantized artifacts, hyperparameters, and system-prompt canonicalization so a weights hash means the same thing across vendors.
Verifiable trust roots and attestation chains: a public PKI or trust root for verifying hardware attestation chains (cloud provider or device manufacturer roots, with clear mapping to the attestation statements).
Retention and discoverability rules: clear contractual retention windows for manifests and attestations and policies for on-demand disclosure that balance discovery needs and trade-secret protection.

Policy frameworks should also address conflicts of interest: router owners that also sell models present self-preferencing risks. Antitrust-oriented proposals (QoS parity, FRAND-style non-discrimination) have been floated in working papers as behavioral remedies, but regulators have not adopted a single, uniform approach yet.

What business leaders should do now

Prioritize verifiability in procurement and risk management. Here’s a short, prioritized checklist you can act on immediately.

Require per-response metadata in SLAs: demand that response objects include served-model-id, numeric precision, request ID, and a manifest hash. If per-response attestations are unavailable, require signed run manifests covering your requests.
Contractual retention: require vendors to retain routing logs and signed manifests for a defined discovery window (typical starting points: 12-24 months) and to provide attestations or manifests on demand under contract or legal process.
Benchmark capability, not just name: include an agreed benchmark suite and pass/fail thresholds for the behavior you care about (e.g., top-1 classification agreement, safety filters). Require remediation if routing or quantization materially degrades agreed performance.
Ask about attestation roadmaps: require vendors to disclose whether they support confidential-computing attestations, what they will commit to signing, and how they treat quantized vs full-precision artifacts.
Sample SLA clause (one-line starter): “Vendor must retain a signed manifest mapping request IDs to served-model artifacts for at least 18 months and must provide, upon written request or lawful process, the signed manifest and any associated hardware attestation for any covered request.”

Key takeaways, questions you should ask (and short answers)

Can the model name in an API call be trusted as the thing that produced the response?

No. Routing, quantization, and alias-style redeployments can cause the served artifact to differ from the requested model name. Vendor practices differ: some return the served model in response metadata (Anthropic documented fallback behavior in “Redeploying Claude Fable 5”, 30 June 2026), while others publish routing rules without per-request assignment disclosures.
Which vendors disclose runtime substitutions or fallbacks?

Practices vary. Anthropic documented that blocked requests were routed to Opus 4.8 and that users were notified (Anthropic, 30 June 2026) and can return the served model in response metadata; Cursor published Cursor Router (22 July 2026) along with vendor-reported training and savings claims; OpenRouter’s docs (June 2026) warn that some providers serve quantized weights at lower prices and that logs may not show it. Treat vendor-reported performance or savings numbers as claims, not independently audited facts.
Is there a legal path to demand proof of which model produced an output?

Yes, plausible routes exist. Evidence rules like FRE 901(b)(9) and FRE 902(13)/(14) permit authentication via system descriptions and certified hashes; India’s Bharatiya Sakshya Adhiniyam, 2023 §63 has analogous requirements for electronic records. But courts will require foundation, and outcomes are fact- and jurisdiction-specific rather than settled law.
What technical fix would make model identity verifiable?

Cryptographic attestations, signed statements, ideally rooted in hardware attestation, that include served-model-id, weights hash, numeric precision, and system-prompt hash, would let third parties verify which artifact produced a completion. Practical deployments will need canonical serialization, attestation trust roots, and retention policies.
Are attestations a silver bullet?

No. They introduce cost, latency, IP disclosure concerns, and complexity around quantization and intermediary routing. Attestations are necessary for high-assurance provenance, but practical systems will blend per-response attestations, signed manifests, batched attestations, and on-demand disclosure.

Routing and other production optimizations respond to real constraints: cost, latency, and safety. But the current mix of opaque routing, invisible quantization, and alias-style drift turns a human-readable model name into an unreliable legal hook. Contracts should start requiring verifiable artifacts and vendors should publish attestation roadmaps. Technical controls, signed manifests and hardware-rooted attestations, are the most durable way to make model identity provable. In short: insist on verifiable evidence, not just a name.

Sources

Anthropic, “Redeploying Claude Fable 5” (30 June 2026), vendor documentation describing fallback behavior and response metadata.
Cursor, “Introducing Cursor Router” (22 July 2026), vendor product announcement claiming “600, 000-plus live requests” training and early-access “30-50% savings” (vendor-reported figures).
OpenRouter, Provider Routing and Lowest-Cost LLM Inference (June 2026), docs and guides describing provider selection, quantization risks, and routing limitations.
Edera.dev, “Understanding Remote Attestation in Confidential Computing” (Dec 3, 2025), technical explainer on TEEs and remote attestation patterns.
Legal authorities referenced: U.S. Uniform Commercial Code §2-313(1)(b) (express warranty by description); India Sale of Goods Act, 1930 §15 (sale by description); Federal Rules of Evidence 901(b)(9), 902(13), 902(14); Bharatiya Sakshya Adhiniyam, 2023 §63 (electronic evidence certificate requirements).