A model signature verifies who published which exact bytes and that nobody changed them since — nothing about training data, behavior, or safety. And it breaks the moment you quantize, fine-tune, or merge, so the signature on the hub is not one on the artifact you serve.
A team adopts model signing as its supply-chain control. It pulls a model whose publisher signed it with the 2025 tooling — an OpenSSF Model Signing bundle, backed by Sigstore, with the signing event in a public transparency log. The verifier runs, the signature checks out, the inclusion proof checks out, the pipeline shows a green checkmark. The team reads that checkmark as “this model is trustworthy” and moves on.
Then the pipeline does what every serving pipeline does. The full-precision weights do not fit the GPU at the batch size the team needs, so it quantizes to INT4. Maybe it fine-tunes on in-house data first, or merges in a task adapter. The model answering production traffic is the quantized, fine-tuned, merged artifact, and when the team re-runs verification on it the signature fails — not because anyone tampered with anything, but because the bytes changed, and the signature was a signature over the bytes.
“This model is signed” and “this model is trustworthy” are different claims, and the gap between them is the subject of this post. A second gap stacks on the first: the signature that verified on the hub does not verify on the artifact the team serves, because the transforms a deployer applies are exactly the byte changes a content signature is built to reject.
This post is about what an OpenSSF Model Signing signature actually asserts — integrity of specific bytes and authenticity of a publisher, and, by the spec’s own words, nothing about quality, fairness, or behavior — and why, because the signature is computed over a manifest of per-file content hashes, it cannot survive the quantize, fine-tune, or merge step between the hub and your serving node.
Start with what the standard says it does, because the words are precise and the whole argument lives inside them.
The OpenSSF Model Signing specification enumerates exactly two guarantees: “Integrity: The model files have not been modified since signing. Authenticity: The model was created by the claimed organization or individual.” That is the entire positive claim. Integrity is a statement about bytes — these files, unchanged since signing; authenticity is a statement about a publisher — a named party stands behind those bytes. Together, a verified signature answers one question: did these exact bytes come, untampered, from the party who claims to have shipped them.
What it does not answer, the spec also says — as an explicit list, not a footnote. Model signing “is not: A replacement for secure model development practices; A guarantee of model quality, fairness, or ethical behavior; A solution for model privacy or confidentiality; A comprehensive security solution on its own; A mechanism to prevent all forms of model misuse; A substitute for proper access controls.” Read the second item again, because it is the one a team conflates away: signing is not a guarantee of model quality, fairness, or ethical behavior. The standard draws the boundary itself, in the document a verifier is implementing.
OpenSSF’s own introduction frames the claim the same narrow way. Model signing “is a cryptographic process that creates a verifiable record of the origin and integrity of machine learning models” — origin and integrity, not contents. And what a verifier learns is just as plain: “Recipients can verify that a model was published by the expected source, and has not subsequently been tampered with.” Who shipped the bytes, not what is in them.
The boundary is not immaturity the next release will close, either. The work to attest more is tracked separately: OpenSSF notes its AI/ML working group “is engaging with the Coalition for Secure AI to incorporate other AI metadata into the OMS Signature Format, such as embedding rich metadata such as training data sources, model version, hardware used, and compliance attributes.” Training-data sources, hardware, compliance — the very things a team imagines a “verified” model has vouched for — are named as future enhancements, absent from today’s signature by design.
To see why the signature cannot survive a transform, look at what it covers. Not a fingerprint of behavior or a summary of architecture — a signature over a manifest, and the manifest is a list of content hashes.
The spec describes the signed object directly: “A list of all files in the bundle, each referenced by its cryptographic hash (e.g., SHA256) … A digital signature that covers the entire manifest, ensuring tamper-evidence.” Red Hat’s write-up of the Sigstore approach puts it the same way: “a cryptographic hash of the model and all its files and metadata is generated and written to a serialized manifest.” The signature’s subject, in the reference implementation’s terms, “is a list of (file path, digest) pairs,” produced by code “responsible with generating a list of hashes for every component of the model.”
A SHA256 digest has the property that is its entire point: change one bit of the input and the output is a different, unrelated value. So the signature is not approximately tied to the model — it is tied to the exact bytes, file by file. Verification makes that concrete. The reference implementation does not trust the manifest it was handed; it recomputes: “the verification part reads the sigstore bundle file and firstly verifies that the signature is valid and secondly compute the model’s file hashes again to compare against the signed ones.” Re-hash the local files, compare digest to digest. If any file differs by one bit, the recomputed hash does not match and verification fails. No tolerance, no “close enough.” That is correct for tamper detection — and it is also why the mechanism cannot tell malicious tampering from the legitimate transform your own pipeline performs.
Now combine the two facts: the signature covers per-file content hashes, and verification fails on any byte difference. A deployment pipeline’s job is to produce byte differences. Quantization rewrites every weight tensor from one numeric representation to another; fine-tuning updates the weights by gradient descent; merging combines them arithmetically with another model’s. Each is routine and intended, and each alters exactly the bytes the manifest hashed, so the recomputed digests will not match and the verifier reports failure — not because the model is compromised, but because it is no longer the bytes that were signed.
Red Hat’s analysis states the consequence in a sentence that could have been written for this post: because the signature is over a hash of the whole blob, “if a minor update is needed e.g. modifying a configuration file or retraining a small part of the model, the entire blob needs to be resigned and redistributed even if most files remain unchanged.” Even a single config-file edit forces a full re-sign. Quantizing every weight is a wholesale rewrite of the largest files in the bundle. There is no version of this where the publisher’s signature carries across the transform.
The production case studies confirm the scope rather than widening it. OpenSSF’s case study on Google’s rollout describes the strongest claim a production signer makes: “Each model is cryptographically signed and tied to the author’s identity … Users know that what they download hasn’t been tampered with or misattributed.” The reference implementation is just as careful about the temporal edge: the signature establishes “that the signature comes from a known or trusted identity and thus that the model hasn’t been tampered with after training.” After training — so the instant you transform the artifact, you are outside the window the signature covers, in both directions: it never spoke to what is in the model, and it no longer matches the bytes you hold.
So the green checkmark a team wants to read as “trustworthy model” does two narrower jobs and stops doing even those the moment the pipeline runs. On the hub it certifies origin and integrity of the published bytes; after quantization it certifies nothing, because it fails to verify at all. A verification gate before the transform passes a model the team does not serve; after the transform it fails the model the team does serve.
A team that has internalized “signing means trustworthy” often points to the transparency log as the part that closes the gap. It does not — and being precise about what the log adds keeps the argument honest, because the log is real, deployed infrastructure doing a genuine job, just not this one.
Sigstore writes every signing event to Rekor, an append-only public log, and a verifier can confirm a signature is in it: “transparency logs make signing events discoverable … Model verifiers can validate that the models they are looking at exist in the transparency log by checking a proof of inclusion.” Red Hat describes the same component as a way to “record signing events, enabling anyone to verify the model’s signature against the log,” and Google’s deployment logs “all signing events … in the sigstore transparency log, providing a complete audit trail.”
What the log buys is discoverability and tamper-evidence of the signing record itself: a publisher cannot quietly sign a second, different model for one audience and hide it from another, because every event is visible to all in the same log — which defeats a split-view attack on the signature. It says nothing about contents. An inclusion proof answers “was this exact artifact signed by this identity, and is that fact publicly logged” — a stronger statement of the same narrow thing. The supply-chain literature names the analogue exactly: the protection “is analogous to the one offered by Certificate Transparency and allows users to be sure that, when they download a given version of a model, they are seeing the canonical model at that version.” The canonical model at that version — not a good one. Certificate Transparency tells you a certificate is the real one for a domain, not that the site is honest. Model transparency is the same shape.
Three qualifications, because the version of this argument that overstates loses the reader who knows the field.
First, none of this makes model signing useless or even weak at its job. It does its job — integrity and authenticity — and does it well, and that job is worth doing: without it a team cannot tell whether the bytes on the hub are the publisher’s or a hub-side swap; with it, they can. The argument is not “do not sign,” it is “do not read the signature as a claim it explicitly disclaims.” This is the same discipline the weights provenance problem demands: a signature makes a model accountable to its origin, which is the most you can ask of a signature and the least you should accept — it does not make the model good.
Second, the standard stops at origin because the thing a team wishes it asserted is genuinely hard, not merely unbuilt. Proving what is in a model — that it was trained on the data its card claims — is a separate, harder problem, and the literature is candid the tools do not yet scale. Machine Learning Models Have a Supply Chain Problem (arXiv 2505.22778) proposes extending signing toward proofs about datasets, then states the limit: “there is thus currently no proof system that has demonstrated the ability to scale to large models while maintaining reasonable proof sizes and prover and verifier runtimes.” The same paper defines the integrity guarantee narrowly and on purpose — signing gives “some assurance that the models published on model hubs are the ones that the model owner intended to publish, and in particular have not been tampered with by the model hub or some other malicious party.” That is origin assurance, stated as origin assurance — a research frontier away from a claim about contents, not an oversight.
Third, the usual stand-in for “what’s in it” — the model card — does not fill the gap either, and is weakest exactly where signing is silent. The same paper observes model cards “are often more vague about the training data, preprocessing, and training hardware.” So you cannot recover the missing assurance by reading the card next to the signature: the signature does not assert contents, and the card is vaguest about the contents that matter.
The origin-versus-contents line is not peculiar to model signing. It is the same line the broader software supply-chain standards draw — the strongest evidence that the boundary is principled, not a gap to be patched.
SLSA, the build-provenance standard for software, defines provenance as “the verifiable information about software artifacts describing where, when and how something was produced,” then states the limit in one sentence: “SLSA does not tell you whether the developers writing the source code followed secure coding practices.” It even draws the line at malice: “SLSA does not address organizations that intentionally produce malicious software, but it can reduce insider risks within an organization you trust.” Authenticity of origin is orthogonal to trustworthiness of what is produced.
That is, line for line, the boundary OMS draws for models. A signed software artifact tells you who built it and that it is unchanged, not that the code is secure; a signed model tells you who shipped the weights and that they are unchanged, not that the model is safe. Reading either as a safety verdict is the same category error — and on the model side, the backdoor that survives the deployment pipeline is what walks through the gap: a quantization-conditioned backdoor is invisible in the bytes you scan and alive in the bytes you serve, while the signature, having broken at the same transform, is not even watching.
The fix is not a new standard. It is reading the signature as the claim it makes, and putting verification where the bytes you serve actually are.
Read a verified signature as “known publisher, untampered bytes” — not “trustworthy model.” Write down what your green checkmark asserts: origin and integrity of a specific artifact, and by the spec’s own enumeration, nothing about quality, fairness, or behavior. It is a true statement about provenance, not a safety sign-off.
Verify the artifact you serve, not the one you downloaded — and expect the publisher’s signature to fail after a transform. A signature that verified on the hub will not verify on the quantized, fine-tuned, or merged bytes, because verification re-hashes the files and the files changed. That failure is correct, which means the publisher’s signature cannot be your serving-side integrity control: if you need integrity on the deployed artifact, re-sign it after the transform, under your own identity, and verify that.
Do not let “signed” stand in for the behavioral checks signing disclaims. A model can carry a valid signature and a backdoor at once, and after quantization the signature is gone while the backdoor remains. Quality, safety, and backdoor evaluation are separate controls that run on the deployed bytes — their own gate, not a thing the checkmark covered.
Use the transparency log for what it is — auditable origin, not a contents claim. An inclusion proof confirms the signing event is public and append-only, defeating a hidden second-version attack. Keep relying on it for that, and not for a behavioral guarantee it does not make.
Know that “what’s in it” is unsolved, and do not paper over it with the card. Training-data and behavior attestation is a frontier the literature says does not yet scale, and the model card is vaguest exactly there. If a policy or filing commits you to vouch for what a model contains, that needs evidence the signature does not provide — say the smaller true thing the signature proves, and do not let it be read as the larger one.
A signature on a model is a true sentence, and the team reading it as trustworthiness is reading a different, longer sentence that was never written. What the signature says is: these exact bytes came from this named publisher and nobody changed them since — origin and integrity, the two things the spec promises and the only two. It does not say the model is good, safe, or fairly trained, and the spec lists those exclusions itself. Then the team quantizes to fit its GPU, and even the small true sentence stops verifying, because the bytes are no longer the bytes that were signed. The checkmark on the hub belonged to an artifact the team took apart and rebuilt before serving; the one in memory on the serving node is unsigned, unattested as to behavior, and the only model the users ever meet. Sign it again if you want integrity on it, and evaluate it separately if you want to know it is safe. The publisher’s signature answered who shipped the original bytes — and that stopped being the question that mattered the moment you changed them.
GRPO's group-relative advantage looks like a clean normalized policy gradient. Two of its normalizers aren't neutral: dividing by response length rewards longer wrong answers, dividing by reward std overweights easy and hard questions. The trainer optimizes both, faithfully.
16 min →
A big pass@1 jump after a GRPO run reads as the model having learned to reason better. Often it has not — it has learned to pick, more reliably, a solution path it already had. RLVR re-weights the base model's existing reasoning rather than creating new reasoning, and whether any RL budget escapes that is genuinely disputed.
14 min →
Chinchilla's twenty-to-one was fit on unique data, one pass. Teams now repeat scarce corpora at tens of times that ratio, where the law breaks — and past a repetition threshold the re-derivations reverse its verdict: spend compute on capacity, not more epochs.
14 min →