If you cannot say which bytes of a model ran, you cannot say what made a decision. That is the whole problem. Model cards, vendor PDFs, and a download link named llama-3-instruct.gguf are not provenance. They are labels. Labels can be copied. Weights can be swapped.
OWASP said this plainly in LLM03:2025 (Supply Chain): “Currently there are no strong provenance assurances in published models. Model Cards and associated documentation provide model information… but they offer no guarantees on the origin of the model.” The same entry tells operators to use models from verifiable sources and to use “third-party model integrity checks with signing and file hashes to compensate for the lack of strong” provenance.
This note is from the work of holding and hashing weights ourselves. It is a method, not a customer story. We do not name clients.
What is a weight hash, and what is it not?
A model’s weights are the parameters. They are a large file, or a set of shards. A weight hash is a cryptographic digest of those bytes — typically SHA-256 or a stronger construction — computed after you have the file and before you load it into an engine. If the bytes change, the digest changes. If the digest matches a value you recorded under your own key, the file is the file you accepted.
That is all. A hash does not prove the model is accurate, unbiased, or licensed. It does not prove who trained it. It proves identity of the artefact at a point in time.
Signing wraps the hash. A vendor or an internal signing key attests “digest D is model M, version V.” You still have to trust the key. You do not have to trust a filename.
A Weight Integrity Seal, as we run it, is that digest plus a record we keep for models whose weights we hold. We hash what we load. We can say, later, which digest ran. That is a narrow claim. It is also the claim most enterprises cannot make about the API they call.
Why should a CISO care now?
Three reasons, all already in public texts.
Supply-chain substitution. LLM03 lists compromised supplier accounts, look-alike repositories, poisoned pre-trained models, and direct tampering of published weights (it names ROME-style edits). If your pull script takes “latest” from a public repo, you are trusting the repo’s access control and your own hash check — or you are trusting neither and hoping.
Incident definition. California’s Transparency in Frontier Artificial Intelligence Act (SB 53, signed 29 September 2025) defines a “critical safety incident” to include “unauthorized access to, modification of, or exfiltration of, the model weights of a frontier model that results in death or bodily injury.” The statute is aimed at frontier developers, not every deployer. The drafters still treated weight integrity as a safety object, not a research nicety.
Deployment guidance. CISA, NSA, and partners published Deploying AI Systems Securely on 15 April 2024, on top of the November 2023 CISA/NCSC Guidelines for secure AI system development. Both tell providers and operators to treat the model as a component with a supply chain: know what you deployed, control updates, log and monitor. A component without an identifier is not a component you can patch.
The EU AI Act does not, as of the 2026 consolidated text, require a SHA-256 of weights. It does require, for high-risk systems when those duties apply, technical documentation, logging, and a risk-management system (Articles 9, 11, 12). You will not fill those files from a vendor’s blog post. You fill them from an artefact you can name.
How do you take custody of a model?
Custody is a sequence. Skip a step and the hash is theatre.
1. Receive. Take the files from a named source: a vendor’s signed release, a foundation’s release page, or your own training run. Record the URL, the date, the account, and the published checksum if one exists.
2. Hash. Compute the digest yourself on your metal. Do not paste a checksum from the download page into the register and call it yours. If the publisher published a checksum, compare. If they did not, your digest is the first authoritative value.
3. Identify. Give the artefact a name that is not the marketing name: family, parameter count, quantisation, fine-tune, revision. Store the digest next to that name. Store the licence.
4. Sign or seal. If you have an internal signing key or a seal process, bind name + digest + date. We bind the digest for models we hold. A private governance sidechain can hold a proof of that bind without publishing the weights. Orachain is built for third parties to verify integrity without seeing the records. Use it when you need a third party to see that a seal existed, not what the model contains.
5. Load only what you hashed. The serving path must refuse a file whose digest is not in the register. “Someone dropped a new GGUF on the box” is the failure. Pin the digest in the deployment manifest. The same rule applies to adapters and LoRA files. An adapter is weights. Hash it.
6. Record what ran. Inference logs should carry the digest, not just “gpt-oss-20b.” When an output is challenged, you retrieve the digest and the register row. If you only have a display name, you have a story.
What about APIs you do not host?
You do not hash a closed API. You cannot. Anyone who tells you they “hash ChatGPT” is confused.
What you can do:
- Contract for a model identifier and a version that the vendor will not silently swap.
- Log the identifier the API returns on every call, if it returns one.
- Treat a silent model swap as a change-management event. Ask the vendor, in writing, how you would know.
- Keep retrieval corpora, tools, and system prompts under the same register. LLM03 is not only about weights. It is about the chain: data, model, libraries, deploy.
If the decision is material — credit, hiring, safety, medical, privileged legal — and the vendor cannot name the artefact, you do not have a defensible stack. You have a service. Price and govern it as a service. Do not file it as if you owned the model.
What does “we hold the weights” change?
It changes who can answer a discovery request.
If the weights are on a vendor GPU and the vendor’s terms forbid download, you cannot independently re-hash, fork, or air-gap. You can ask. You may not receive.
If you hold the weights on hardware you control, you can hash today, hash after every move, and produce the register in a privilege-aware form. That is the operational meaning of a sovereign model stack: open-weight models you hold and hash, running on hardware the customer owns. AI Standards runs that method for the models it serves. The sold stack is built so a customer can do the same on their premises.
Holding weights also changes the threat. SB 53’s incident list is a hint: theft of weights is a safety and a competitive event. Access to the weight store is access to the product. Treat it like a signing-key ceremony, not like a dataset share.
What should be in the CISO register?
One row per artefact, nothing clever:
- internal name and vendor/family name
- digest and algorithm
- signature or seal identifier, if any
- licence and permitted uses
- source (URL, training run id, vendor release id)
- date received, date last verified
- where it is allowed to run
- who may promote a new digest
- linked adapters, tokenisers, and system-prompt hashes
Review the register when you review software bills of materials. A model without a row is unlicensed software, even if the licence file says Apache-2.0.
OWASP’s mitigation language is “BOMs” for software, tools, and datasets, plus “signing and file hashes” for models. Use both. A software SBOM that omits the 40 GB file is incomplete.
What to do next
- List every production model and adapter. If you cannot, you do not have a supply chain; you have a habit.
- Hash what you actually load. Compare to any publisher checksum. Record mismatches as incidents.
- Pin digests in the deploy manifest. Refuse unsigned or unlisted files.
- For API models, contract the identifier and the swap notice. Log what the API claims.
- If you need a third party to verify that a given digest was the one in use, without seeing the weights, that is what a governance overlay and a live sidechain are for. An Architecture Review is the session that maps which models you can take into custody and which must stay vendor services.
Provenance is not a research aesthetic. It is how you name the thing that acted. Hash the weights, or admit you cannot name them.