Signing Models and the MLBOM — Quantum-Safe: AI and Verified Crypto

An artificial intelligence model you cannot verify is not a technical asset so much as a promise. The weights may have come from a public hub, the base model may have been trained by someone else, the fine-tuning data may have passed through several hands, and some of the code around it may have been written by an agent. A hash can tell you whether a file matches a claimed digest. It cannot tell you who made the claim, whether that identity is one you trust, or how the model was built. That is why model provenance needs signatures, attestations, and a machine-learning bill of materials, or MLBOM. It is also why the signature algorithms underneath that provenance must eventually become quantum-safe.

A checksum is not provenance

A cryptographic hash is useful. It turns a file into a fixed-size digest, so even a tiny change in the file produces a different value. If you already trust the place where the digest came from, the hash helps you detect accidental corruption or a swapped file.

But a hash is not an identity. If an attacker controls the download page, the model repository, or the release workflow, the attacker can publish a new digest for the tampered model. The file and the hash will still match. What is missing is a trusted claim: who produced the artifact, under what process, from which inputs, and with what evidence.

Provenance adds that missing claim. In a model supply chain, provenance means a signature that traces to an identity you deliberately trust, plus a record of how the artifact was produced. The practical question becomes simple: should this model be allowed to load in this environment?

⚠️

The trap. A matching hash only proves that a file matches a number; it does not prove that the number came from someone you trust.

A hash detects change; provenance proves who produced the artifact.

Model signing is software supply-chain signing applied to weights

The reassuring part is that model signing does not require a new category of security product. The same supply-chain ideas used for containers, packages, and build artifacts apply to model weights. The artifact is different, but the trust problem is familiar.

Sigstore is an open source signing system, and cosign is the commonly used command-line tool for signing and verifying artifacts. Sigstore can use keyless signing, where a short-lived certificate binds the signature to an identity from a single sign-on, or SSO, provider through OpenID Connect, or OIDC. That avoids handing every build pipeline a long-lived private signing key that must be stored and protected for years.

Fulcio is Sigstore’s certificate authority, and Rekor is its transparency log. The certificate tells a verifier which identity signed the artifact. The log gives auditors a public record that the signing event occurred. That combination is powerful because it makes unauthorized or unexpected signing activity easier to discover after the fact.

Sign the exact model weights, not just a repository name or version label.
Bind the signature to a trusted identity, such as the training pipeline or release service.
Record the signing event in a transparency log when the workflow supports it.
Verify the signature before the model is loaded, fine-tuned, promoted, or deployed.

Attestations describe the build, not just the file

A signed model file says that a trusted identity signed those bytes. That is necessary, but it still leaves important questions unanswered. Which base model was used? Which datasets were included? Which build system produced the artifact? Were the weights created by an approved training job or uploaded by a person from a laptop?

This is where in-toto fits. in-toto is a framework for supply-chain attestations: signed statements about the steps, inputs, outputs, and builders involved in producing an artifact. It aligns with Supply-chain Levels for Software Artifacts, or SLSA, a framework for improving build integrity across software supply chains.

For models, an attestation can say that a specific training pipeline consumed a specific base model and dataset snapshot, produced a specific weights file, and handed that file to a signing step. The point is not to make the process fancy. The point is to make it checkable.

An attestation records inputs through the training job to the signing step.

The MLBOM is the model’s inventory record

A machine-learning bill of materials, or MLBOM, is the model-specific version of a bill of materials. It extends the ideas behind a software bill of materials, or SBOM, and a cryptography bill of materials, or CBOM, into the machine-learning domain. The useful version is deliberately plain: it records the facts someone will need when deciding whether to trust, audit, reproduce, or retire a model.

Common formats such as CycloneDX and Software Package Data Exchange, or SPDX, can represent these records. With machine-learning components, the MLBOM can identify the model, its version, the hash of the exact weights, the base model, the datasets, the model card, and the signature information. Hugging Face already supports signing model repositories with this kind of supply-chain machinery, so many teams are adopting a workflow rather than inventing a standard from scratch.

The MLBOM also becomes a search tool. If a base model is later found to contain a backdoor, or a training dataset is found to include data that should not have been used, teams can query the MLBOMs across their estate and find every affected derivative model. Without that inventory, incident response becomes archaeology.

📌

Boring is good. An MLBOM is most useful when it is complete, queryable, and easy to verify, not when it is clever.

An MLBOM records the facts needed to trust, audit, or retire a model.

Where quantum computing changes the signing model

Every signature in today’s common provenance stack depends on classical public-key algorithms. That includes Rivest-Shamir-Adleman, or RSA, the Elliptic Curve Digital Signature Algorithm, or ECDSA, and Ed25519, a signature scheme based on elliptic-curve cryptography. A large enough fault-tolerant quantum computer running Shor’s algorithm would break those public-key assumptions.

That does not mean model signatures have the same urgency profile as encrypted network traffic. Key exchange has a harvest-now-decrypt-later problem: an attacker can record encrypted traffic today and decrypt it in the future if the key exchange is later broken. A signature is different. There is no hidden plaintext inside a signature to recover later.

The signature risk is future forgery. Once a quantum-capable attacker can forge RSA, ECDSA, or Ed25519 signatures, they may be able to create new artifacts that appear to come from an old trusted identity if that trust anchor is still accepted. The danger is not that someone recorded your 2026 signature. The danger is that someone in 2035 may mint a convincing signature against a trust root you failed to retire or migrate.

ML-DSA and SLH-DSA are the likely destinations

The practical post-quantum migration target for most signing is the Module-Lattice-Based Digital Signature Algorithm, or ML-DSA. It is designed as a general-purpose digital signature algorithm for the post-quantum era and is the natural replacement for many ordinary signing use cases once libraries, hardware security modules, policy engines, and transparency logs support it well.

For the longest-lived roots of trust, the more conservative option is the Stateless Hash-Based Digital Signature Algorithm, or SLH-DSA. It is hash-based rather than lattice-based, and it rests on different assumptions. Its signatures are large and it is not the right answer for every high-volume leaf signature, but it is attractive for roots that may need to remain trusted for a decade or more.

This is why signature migration should be planned by lifetime. A short-lived model release that will be re-signed next quarter is not the same as a model-signing root, certificate authority root, or firmware signing key that may still be accepted ten to fifteen years from now. The older and longer-lived the trust anchor, the sooner it should be made quantum-safe or placed on a clear retirement path.

Use ML-DSA as the expected general-purpose destination for model and artifact signing as ecosystem support matures.
Consider SLH-DSA for the longest-lived roots of trust where conservative assumptions matter more than signature size.
Inventory which signing keys are roots, intermediates, and leaves; do not treat them as one risk class.
Make the signature algorithm a policy choice, not a hard-coded assumption in build or deployment systems.

Long-lived roots favor SLH-DSA; ordinary signing uses ML-DSA.

Generated code needs the same discipline

Model provenance is not only about weights. If an artificial intelligence agent proposes a database migration, updates an infrastructure configuration, writes a function, or changes a policy file, that output enters the software supply chain. The fact that an agent produced it is itself a provenance claim.

The right pattern is not to trust agent output because the agent is useful. The pattern is to gate it. Record which tool, prompt context, source inputs, reviewer, and pipeline produced the change where that information is available. Sign the resulting artifact or commit through the same release process used for human-authored code. Verify before the change runs in production.

This does not make generated code safe by magic. Signatures do not prove code is correct. They prove that a particular identity approved a particular artifact under a particular process. That is exactly the kind of evidence auditors, incident responders, and deployment gates can use.

The real decisions for leaders and practitioners

The hard part is rarely the cryptographic concept. The hard part is deciding where verification becomes mandatory, which identities are allowed to sign, how exceptions are handled, and when old algorithms are no longer acceptable. Those are architecture and governance decisions, not just security-tooling decisions.

A practical program starts with one enforceable path. For example: no model may be promoted from experimentation to production unless its weights are signed, its build attestation is present, and its MLBOM names the base model and datasets. That gate can begin with today’s signing algorithms while the organization prepares for post-quantum signatures underneath.

The most important design choice is agility. Do not wire the business process to one signature algorithm. Wire it to a verification policy that can accept, prefer, require, or retire algorithms over time. Then the move from RSA, ECDSA, or Ed25519 to ML-DSA or SLH-DSA becomes a controlled migration rather than a rebuild of the model platform.

Choose the identities that are allowed to sign production models, such as approved training pipelines rather than individual laptops.
Require verification before model loading, deployment, or fine-tuning on sensitive systems.
Store MLBOMs where security, legal, platform, and incident response teams can query them.
Classify signing keys by lifetime and business impact, then migrate the longest-lived trust roots first.
Track ecosystem readiness for ML-DSA and SLH-DSA in signing tools, registries, hardware security modules, and policy engines.

✅

Practical rule. Sign models and generated code now, but design the workflow so the signing algorithm can change without changing the whole pipeline.

Key takeaways

A hash proves that bytes match a claimed digest; provenance proves who made the claim and how the artifact was produced.
The model supply chain can use existing tools such as Sigstore, cosign, Rekor, in-toto, CycloneDX, and SPDX rather than inventing a new trust stack.
An MLBOM records the model’s exact weights, base model, datasets, model card, hashes, and signature information so models can be audited and traced.
Quantum risk for signatures is future forgery, not harvest-now-decrypt-later exposure, so long-lived roots of trust migrate first.
ML-DSA is the expected general-purpose post-quantum signing destination, while SLH-DSA is attractive for conservative long-lived roots.
Generated code should be signed, attested, and gated like any other artifact that can affect production.

Glossary

MLBOM: A machine-learning bill of materials is an inventory record for a model that lists items such as weights, base model, datasets, hashes, model card, and signatures.
Provenance: Provenance is verifiable evidence about where an artifact came from, who produced or approved it, and how it was built.
Sigstore: Sigstore is an open source system for signing software artifacts and recording signing activity in a transparency log.
cosign: cosign is a tool commonly used with Sigstore to sign and verify containers, packages, model artifacts, and related attestations.
in-toto: in-toto is a framework for creating signed attestations about the steps and inputs used to build an artifact.
Transparency log: A transparency log is an append-only public record that lets others audit when signing events or certificates were created.
ML-DSA: The Module-Lattice-Based Digital Signature Algorithm is a post-quantum digital signature algorithm intended for general-purpose signing.
SLH-DSA: The Stateless Hash-Based Digital Signature Algorithm is a post-quantum signature algorithm based on hash functions and suited to conservative long-lived trust anchors.
Harvest now, decrypt later: Harvest now, decrypt later is the risk that encrypted traffic recorded today may be decrypted in the future when stronger computing attacks become available.