Model Security

How to Verify an AI Model's Integrity, From Checksums to On-Chain Attestation

You are about to load several gigabytes of numbers into a process with real permissions. Here is the full ladder of checks that tell you those numbers are what they claim to be.

What model integrity verification means

Verifying an AI model's integrity means confirming three progressively stronger claims: that the file you have matches the file that was published (integrity), that it was published by the party you believe (authenticity), and that the claims attached to it, about training, evaluation, and provenance, are vouched for by identifiable parties (attestation). Each claim requires different machinery: cryptographic digests for the first, signatures for the second, provenance frameworks and ideally independent anchoring for the third. The threat model is not hypothetical. Model files are large binaries fetched from public hubs over networks, stored in shared caches, and loaded by frameworks that historically executed arbitrary code from pickle-based formats; a swapped or tampered model can exfiltrate data, produce subtly poisoned outputs, or carry backdoored behaviors that pass casual testing. Model supply chain security is simply behind software supply chain security, where digests, signing, and provenance via Sigstore and SLSA are becoming standard practice. This guide walks the same ladder for models, ending at the strongest currently deployed rung: on-chain quorum attestation of model manifests.

Level 1: checksums, the non-negotiable floor

The floor of model verification is comparing cryptographic digests. Compute the SHA-256 hash of each downloaded file and compare against the publisher's stated digests: on Linux, sha256sum model.safetensors, then verify against the values in the release notes or the hub's file metadata. HuggingFace exposes per-file hashes through its API and git-lfs metadata, which makes this check scriptable in CI so a swapped artifact can never silently reach production. Two practical refinements matter. Prefer safetensors over pickle-based formats: pickle files can execute code on load, converting a tampered model from a data problem into remote code execution, while safetensors is a pure tensor container. And hash the complete artifact set, not just weights: tokenizer files, adapter weights, and configuration all change model behavior, which is why serious systems verify a manifest, a structured list of every component with its digest, and then hash the manifest itself into a single root. That manifest root becomes the model's true name, the content-addressed identity that every higher verification level builds on, and the unit that QBC attests on-chain.

Level 2: signatures, binding artifacts to publishers

A checksum only proves the file matches a published digest; if an attacker can alter the download, they can often alter the digest listing beside it. Signatures close that loop by binding digests to a publisher identity that tampering cannot forge. The maturing standard here is Sigstore: cosign signing of model artifacts using keyless certificates tied to OIDC identities, with signatures recorded in the Rekor transparency log so even the signer cannot quietly rewrite history. Some model hubs and enterprises layer GPG signing or internal PKI instead; the mechanism matters less than the property, which is that verification asks who vouches for this digest, and gets a cryptographically checkable answer. One forward-looking consideration deserves mention: models are long-lived artifacts, and signatures made with classical elliptic-curve keys carry quiet expiry risk in a post-quantum world, since a future adversary who breaks the curve could forge historical publisher identities. Long-horizon signing is an argument for post-quantum signature schemes such as ML-DSA, standardised in FIPS 204, for artifacts whose authenticity must remain provable for a decade or more, which increasingly describes foundation models.

Levels 3 and 4: provenance attestation and on-chain anchoring

Above authenticity sits provenance: structured, signed claims about how the artifact came to exist. The software world formalizes this as SLSA provenance and in-toto attestations, statements like this artifact was built from this source by this process, signed by the builder. Translated to models, useful attestations cover the base model digest, training data references, the training procedure, and evaluation results. The structural weakness of self-attestation is obvious: the publisher vouching for its own claims. The strongest deployed remedy is independent, externally anchored attestation, and this is where QBC is a working reference: its served model, a frozen Qwen2.5-7B base with a 10-expert MoE adapter, has a manifest root that a two-thirds validator quorum attested on-chain at block 1,097,990, on a chain with deterministic finality and post-quantum signatures. The training claims are independently measured too: every accepted epoch's held-out loss was verified by validator quorum before finalization. Anchoring converts a publisher's promise into a public record that multiple parties staked their signatures on, timestamped by infrastructure the publisher does not control.

Runtime binding and a practical checklist

One gap remains after download-time verification: proving that the verified model is the one actually serving your requests, since an operator can attest one artifact and quietly serve another. Closing it requires runtime binding, per-inference records tying each response to a model identity. QBC implements this as Proof-of-Thought commitments: each block carries the serving model's id, a context digest, the RNG seed, and an output hash, signed and finalised, so served behavior is continuously bound to the attested manifest, forming a live audit trail. For your own practice, the checklist compresses to six steps. Verify SHA-256 digests of every artifact against publisher values, in CI, not by hand. Prefer safetensors. Verify publisher signatures where offered, via cosign or equivalent. Record the manifest root of what you deploy in your own verifiable records. Pin exact digests in production configs, never floating tags like latest. And for high-stakes deployments, prefer models with independent attestation over self-declared provenance. Each step is cheap; skipping all of them means trusting several gigabytes of unaudited numbers with your users.

A worked verification, end to end

The ladder is easiest to internalize by climbing it once against a real release, and QBC's attested model works as the exercise because every rung is public. Step one: fetch the artifact set from HuggingFace and compute SHA-256 digests locally, comparing against the hub's per-file metadata. Step two: confirm the format is safetensors and assemble the manifest, the structured digest list covering base weights, the MoE adapter, tokenizer, and configuration. Step three: compare your computed manifest root against the on-chain attestation at block 1,097,990, using the explorer or your own node. Step four: check the attestation's quality rather than taking it as a boolean: it carries validator quorum signatures and sits under GRANDPA finality, and you can verify inclusion without a full node via BEEFY and MMR proofs, whose deployment is documented in the finality proofs post. Step five: read the release's claims against its evidence, starting from the v7.1 unification post and the audit walkthrough. The whole exercise takes minutes, and having done it once, the difference between attested and merely open releases stops being abstract.

Verifying training claims, not just files

File integrity is necessary but says nothing about the most consequential claims attached to a model: that it was trained as described and improved as advertised. Verifying those requires a different kind of evidence: measurement series produced by parties other than the claimant. QBC's training pipeline is the deployed example: contributions arrive as DiLoCo-pattern pseudo-gradients, and each aggregated epoch is accepted only after a two-thirds validator quorum independently measures reduced loss on held-out data, making the training run itself an audited process rather than a narrative. The resulting series is public and long: held-out loss down more than 75 percent across attested epochs, with the run having crossed step 1,000,000, and capability deltas reported with honest nulls in the benchmarks post. The research frontier pushes further: zero-knowledge proofs that an inference or training step was computed correctly, sketched for QBC's stack in the masked-trace STARK roadmap, would let verification reach inside computation itself. Until such proofs mature, quorum-measured evaluation anchored on-chain is the strongest deployed answer, and it is checkable today.

Model integrity assurance levels
Conventional approachQuantumAI Blockchain
SHA-256 checksumThe file matches a published digestWhether the digest listing itself was tampered with
Safetensors formatLoading cannot execute embedded codeNothing about where the tensors came from
Publisher signature (Sigstore, GPG)An identifiable party released this exact artifactWhether that party's claims about it are true
Provenance attestation (SLSA, in-toto)Structured claims about how it was builtIndependence: the builder vouches for itself
On-chain quorum attestation (QBC)Multiple validators bound the manifest at a public block, timestampedRuntime behavior, unless paired with per-inference commitments

Frequently asked questions

How do I verify an AI model's checksum?

Compute SHA-256 over each downloaded file, for example sha256sum model.safetensors, and compare against the publisher's stated digests or the hub's file metadata. Automate the comparison in CI so unverified artifacts cannot reach production.

Why should I use safetensors instead of pickle?

Pickle-based model formats can execute arbitrary code when loaded, so a tampered file becomes remote code execution. Safetensors is a pure tensor container: tampering can corrupt the model but cannot run code.

What is model provenance?

The documented, ideally signed, history of how a model came to exist: base model, training data references, procedure, and evaluations. Frameworks like SLSA and in-toto structure these claims; independent attestation makes them trustworthy.

What does on-chain model attestation add?

Independence and permanence: multiple validators sign the model manifest root, and the record is timestamped on a public chain the publisher does not control. QBC's served model is attested this way at block 1,097,990.

How do I know the API I am calling runs the model it claims?

Without runtime binding, you cannot. Per-inference commitments, recording model id, input digest, seed, and output hash, are what tie served responses to an attested artifact; QBC emits these every block.

Can model signatures become invalid over time?

Effectively yes: signatures made with classical elliptic-curve keys could be forged by future quantum computers, undermining historical authenticity. Post-quantum schemes like ML-DSA (FIPS 204) protect long-lived model artifacts.

How do I verify a model's training claims, not just its files?

Look for measurement series produced by parties other than the publisher: independent evaluations keyed to manifest digests, ideally anchored externally. QBC's epoch series, quorum-measured held-out loss finalised on-chain, is the deployed reference for this.

Verify it yourself.

QBC is live. Explore the network, read the on-chain proofs, and see a decentralised AI being trained and finalised in real time.

Enter qbc.network →