A valid model signature tells you the files match what a given identity signed. It does not tell you the model is safe, accurate, fairly trained or properly licensed. A bad model can be signed as easily as a good one, so treat signatures as proof of integrity and origin, nothing more.
What the signature does cover
From the sigstore model-transparency project: verification checks that the signature is valid, then recomputes the model's file hashes and compares them with the signed ones. So a pass supports two claims. The files are unchanged since signing, and the signer controls the identity or key used.
That is valuable. It catches tampering in transit, a swapped file in a registry, and mix-ups between versions.
What it cannot say
Whether the model is good. The signer vouches for the bytes, not the behaviour. Training data poisoning or a backdoor added before signing will verify perfectly.
Whether the signer deserves trust. The project page states you must still check that the signature comes from a known or trusted identity. Anyone can sign their own model with their own identity.
Whether everything is covered. Only files in the manifest are protected. The page notes that git related paths are ignored by default, so know what your manifest includes.
Metadata and claims. The tooling's predicate dictionary is described as intended for model card information in the future. Today it is not a guarantee about training data, license or evaluation.
Whether you will notice problems later. With Sigstore signing, events go in a transparency log, and signers have to monitor it themselves. The page says Sigstore is actively developing a log monitor, which suggests the monitoring is not turnkey yet. Do not assume someone is watching for misuse of your identity.
How to close the gaps
- Behaviour and poisoning: your own evaluations and red team tests before approval.
- Trusting the signer: a reviewed allow list of expected identities.
- Coverage: review the manifest and sign the whole directory.
- Metadata: read the model card, record license and lineage.
- Log misuse: watch the log for your identity if you sign.
Treat signature verification as a gate in a longer intake process. See model intake policy for engineering teams.
A short example
A team signs every model it publishes from CI. A customer verifies the signature, sees the expected identity, and the hashes match. That is a good result. If the team trained on data it should not have used, or a labeller slipped in poisoned examples, the signature is still valid. Integrity controls and quality controls answer different questions, and you need both in the process.
Quick check
If the signature verifies, can I skip testing the model?
No. Verification confirms integrity and signer identity. It says nothing about behaviour, bias or hidden backdoors.
Who should I trust to sign?
Decide in advance. Keep a short allow list of expected identities, such as your own CI and the publishers you have reviewed, and reject others.
Sources
Last reviewed: 19 October 2026.
