K
Kenneth Onyebuchi
Guest
Model signing became real infrastructure this year. NVIDIA has been cryptographically signing every model it publishes to its NGC Catalog since March 2025, using a specification called OMS, and it's the first major model hub to do so. Google is prototyping the same approach on Kaggle.
The OpenSSF model-signing project reached version 1.0 in April 2025, and the work was subsequently formalized as the OpenSSF Model Signing (OMS) specification. That's a real, verifiable milestone, and it solves a real problem. It also solves a narrower problem than a lot of people assume it does, and the gap it leaves open is already showing up in serious accountability research.
OMS works by producing a detached signature bundle, built on the same Sigstore Bundle Format that secures a large share of the software supply chain already. That bundle contains a manifest listing every file in the model: weights, configuration, and tokenizer, each referenced by cryptographic hash, plus a signature over the whole thing. NVIDIA's own technical write-up is direct about what this buys you. Model weights, configuration files, tokenizers, and related assets get verified together as a single unit, without needing to modify or repackage the original content. Signing can happen through enterprise PKI, a self-signed certificate, or keyless signing through Sigstore, whichever fits an organization's existing key management.
What that gives a downstream consumer is a clean answer to one specific question: Does this model match exactly what was signed, and does the signature trace back to a specific key? For a supply chain where models get pulled from public hubs, repackaged, and redistributed, that's genuinely useful. It's the same reason unsigned software in production has been considered bad practice for years.
Here's what that verification doesn't cover. OMS confirms the bytes weren't altered after signing and that a specific key signed them. It does not confirm that the entity holding that key was authorized to train and release that particular model, what data went into it, or which pipeline actually produced it. The specification does support optional metadata, such as fields for training data sources and hardware used, but those fields are self-reported by whoever creates the bundle, not independently verified against anything. A compromised or misused signing key still produces a technically valid signature. So does a legitimate key used to sign a model nobody with actual authority approved for release.
That's not a flaw in OMS specifically. It's the same limitation every code-signing system has always had. A signature proves the artifact matches the key. It doesn't prove the key was used the way it should have been. For AI models, that gap decides how the system actually behaves in production.
This distinction isn't just something I noticed reading a spec. The International AI Safety Report, the expert-authored report chaired by Yoshua Bengio and backed by dozens of countries, covers this ground directly under post-deployment monitoring. It describes techniques for tracing which model produced a given output, watermarking model weights, and inferring the lineage of open-weight models that were never watermarked at all, work aimed specifically at establishing accountability when something goes wrong, separate from whether a file was tampered with. The same report is honest about the tradeoff. Tracking models too precisely creates real surveillance and privacy concerns, so this isn't a problem with an obviously clean solution.
A separate academic survey on AI agent identity standards makes a related point about where SLSA and Sigstore-style attestation is actually heading next, extending beyond a single signed artifact toward verifiable records of the training pipeline itself, fine-tuning steps, and deployment lineage. That's a meaningfully bigger claim than what OMS verifies today. It's provenance of the entire process, a different and harder guarantee than provenance of a single file, and it's still an open research direction rather than a shipped standard.
The gap is closer to getting a real answer than I expected though. The same OpenSSF working group behind OMS has already stood up a follow-on effort, a pipeline-agnostic framework for end-to-end model lifecycle provenance, built to complement OMS rather than replace it. The project description names the goal directly, attesting and validating the full model lifecycle, well beyond the final signed artifact, building on an existing framework called Atlas plus hardware-backed attestation. It's early, but it comes from the same standards body and the same working group that shipped OMS itself, which makes it a meaningfully more credible next step than a random third-party tool claiming to solve the same problem.
A few things follow if you're evaluating model signing today.
OMS answers one real question well, whether this is the exact model that was signed, and it's now backed by companies with production deployments to prove it. It was never built to answer a harder question: who trained this model and whether they were allowed to. Serious accountability research already treats that as its own separate, unsolved layer. Know which of these two questions your tooling actually answers before you tell anyone the problem is solved.
The OpenSSF model-signing project reached version 1.0 in April 2025, and the work was subsequently formalized as the OpenSSF Model Signing (OMS) specification. That's a real, verifiable milestone, and it solves a real problem. It also solves a narrower problem than a lot of people assume it does, and the gap it leaves open is already showing up in serious accountability research.
What OMS Actually Verifies
OMS works by producing a detached signature bundle, built on the same Sigstore Bundle Format that secures a large share of the software supply chain already. That bundle contains a manifest listing every file in the model: weights, configuration, and tokenizer, each referenced by cryptographic hash, plus a signature over the whole thing. NVIDIA's own technical write-up is direct about what this buys you. Model weights, configuration files, tokenizers, and related assets get verified together as a single unit, without needing to modify or repackage the original content. Signing can happen through enterprise PKI, a self-signed certificate, or keyless signing through Sigstore, whichever fits an organization's existing key management.
What that gives a downstream consumer is a clean answer to one specific question: Does this model match exactly what was signed, and does the signature trace back to a specific key? For a supply chain where models get pulled from public hubs, repackaged, and redistributed, that's genuinely useful. It's the same reason unsigned software in production has been considered bad practice for years.
A Valid Signature Isn't the Same as a Trustworthy Signer
Here's what that verification doesn't cover. OMS confirms the bytes weren't altered after signing and that a specific key signed them. It does not confirm that the entity holding that key was authorized to train and release that particular model, what data went into it, or which pipeline actually produced it. The specification does support optional metadata, such as fields for training data sources and hardware used, but those fields are self-reported by whoever creates the bundle, not independently verified against anything. A compromised or misused signing key still produces a technically valid signature. So does a legitimate key used to sign a model nobody with actual authority approved for release.
That's not a flaw in OMS specifically. It's the same limitation every code-signing system has always had. A signature proves the artifact matches the key. It doesn't prove the key was used the way it should have been. For AI models, that gap decides how the system actually behaves in production.
Researchers Are Already Naming This as a Separate Problem
This distinction isn't just something I noticed reading a spec. The International AI Safety Report, the expert-authored report chaired by Yoshua Bengio and backed by dozens of countries, covers this ground directly under post-deployment monitoring. It describes techniques for tracing which model produced a given output, watermarking model weights, and inferring the lineage of open-weight models that were never watermarked at all, work aimed specifically at establishing accountability when something goes wrong, separate from whether a file was tampered with. The same report is honest about the tradeoff. Tracking models too precisely creates real surveillance and privacy concerns, so this isn't a problem with an obviously clean solution.
A separate academic survey on AI agent identity standards makes a related point about where SLSA and Sigstore-style attestation is actually heading next, extending beyond a single signed artifact toward verifiable records of the training pipeline itself, fine-tuning steps, and deployment lineage. That's a meaningfully bigger claim than what OMS verifies today. It's provenance of the entire process, a different and harder guarantee than provenance of a single file, and it's still an open research direction rather than a shipped standard.
The gap is closer to getting a real answer than I expected though. The same OpenSSF working group behind OMS has already stood up a follow-on effort, a pipeline-agnostic framework for end-to-end model lifecycle provenance, built to complement OMS rather than replace it. The project description names the goal directly, attesting and validating the full model lifecycle, well beyond the final signed artifact, building on an existing framework called Atlas plus hardware-backed attestation. It's early, but it comes from the same standards body and the same working group that shipped OMS itself, which makes it a meaningfully more credible next step than a random third-party tool claiming to solve the same problem.
What This Means for Builders
A few things follow if you're evaluating model signing today.
- Don't treat a signed model as a trusted model. A signature tells you the file matches what was signed. It doesn't tell you the training process behind it was legitimate or that the signer had authority to release it.
- Read the optional metadata fields skeptically. Training data sources and hardware information in an OMS bundle are self-declared by whoever signs the model, not independently checked, so treat them as a claim worth verifying separately.
- Watch the lineage and provenance-inference research as closely as you watch the signing tooling itself. The accountability layer researchers are describing, tracing a model back to who actually trained it and under what authority, is where this space is heading, and it's not solved by signing alone.
Conclusion
OMS answers one real question well, whether this is the exact model that was signed, and it's now backed by companies with production deployments to prove it. It was never built to answer a harder question: who trained this model and whether they were allowed to. Serious accountability research already treats that as its own separate, unsolved layer. Know which of these two questions your tooling actually answers before you tell anyone the problem is solved.