Most "AI model risk registries" are just spreadsheets with a model name, an owner, and a status column. That's not a registry — it's a directory. A real registry has to answer the questions a security team, a legal team, and an auditor will each ask under pressure: which weights are actually running in production, where did they come from, what's inside the serialization format, which license governs their use, and when was risk last reassessed.
The gap matters because model sprawl happens fast. One base model becomes a dozen fine-tunes, each fine-tune gets quantized for edge deployment, and each variant gets pushed to a different endpoint by a different team. In February 2024, JFrog's security researchers found roughly 100 malicious models sitting on Hugging Face Hub, several capable of opening reverse shells the moment they were loaded with pickle.load(). No spreadsheet would have caught that. A registry built around the right fields would have.
Here's what an AI model risk registry actually needs to track, and why each field earns its place.
What Actually Counts as a "Model" Worth Registering?
The answer is every distinct artifact that gets executed, not just the named base model. A single Llama or Mistral checkpoint can fork into a LoRA-tuned variant for support tickets, a GGUF-quantized build for a mobile app, and a merged checkpoint fine-tuned on internal data — three artifacts with three different risk profiles running under one name in most inventories. If your registry has one row for "customer-support-llm," you've collapsed three attack surfaces into one line item. Each variant needs its own entry with its own checksum, because a vulnerability found in the base model (a jailbreak, a licensing violation, a poisoned dataset) doesn't automatically apply — or automatically exclude itself — from every downstream fork. Treat each serialized artifact the way you'd treat a container image tag: same name, different digest, different risk state.
Which Provenance Fields Separate a Registry From a Spreadsheet?
The answer is a cryptographic hash of the actual weight file, not the model's marketing name and version string. A registry entry needs the SHA-256 digest of the checkpoint, the training data manifest or a pointer to it, the model card version it shipped with, and its serialization format — safetensors versus pickle is a security-relevant distinction, not a technical footnote, since pickle deserialization is Python code execution by design. It also needs signing status. The OpenSSF's Model Signing project, built on Sigstore and gaining adoption through 2024 and 2025, lets teams attach a verifiable signature to a checkpoint the same way Sigstore does for container images and packages. A registry that records "signed: yes/no" and "signer identity" turns an unverifiable download into an auditable one. Without the hash, "we use Llama 3.1 8B" is a claim, not a fact you can check against what's actually deployed.
How Should a Registry Track Vulnerabilities in Model Files and Frameworks?
The answer is by linking each registered model to the CVE feed of everything that loads it, the same way an SBOM links an application to its dependency vulnerabilities. In January 2025, PyTorch shipped 2.6.0 to fix CVE-2025-32434, a vulnerability that allowed arbitrary code execution via torch.load() even when the supposedly-safe weights_only=True flag was set — a flag thousands of teams had been treating as a guarantee. A registry that only tracks "model name and license" has no way to tell you which of your 40 deployed checkpoints are loaded by a vulnerable PyTorch version and which have been migrated. The fix is a field most registries skip: the serving runtime and exact version (PyTorch, ONNX Runtime, TensorFlow Serving, vLLM) tied to each model entry, refreshed on every framework CVE disclosure the way you'd refresh a container base-image scan.
What Licensing and Usage-Rights Data Prevents Legal Exposure?
The answer is the license family and its field-of-use restrictions, not just a "license: open source" checkbox. Apache-2.0, the Llama Community License, OpenRAIL-M, and CreativeML licenses all impose different constraints — the Llama Community License, for instance, requires a separate commercial license once a downstream product crosses 700 million monthly active users, and several OpenRAIL variants carry use-case restrictions that a generic "open" label hides entirely. A registry needs the license name, a link to its text, any commercial-use threshold, and whether the training data included scraped content with disputed rights. Legal exposure here isn't hypothetical: several ongoing suits against model providers turn on exactly this question of what data trained the model and under what terms it can be redistributed. If your registry can't answer "what license governs this exact checkpoint," you can't answer whether shipping it in a customer-facing product is a breach.
How Often Should a Registered Model's Risk Score Be Revalidated?
The answer is on a fixed cadence tied to retraining and regulatory checkpoints, not once at intake and never again. A model's risk score isn't static — a fine-tune on new data, a framework CVE, or a new regulatory obligation can all invalidate a score that was accurate six months ago. The EU AI Act is a concrete forcing function here: obligations for general-purpose AI models took effect August 2, 2025, and providers now have to maintain up-to-date technical documentation and risk assessments for models already in circulation, not just new releases. A registry entry needs a "last reassessed" timestamp and a trigger list — retraining event, dependency CVE, license change, new deployment context — that forces a re-score rather than letting the field go stale. Registries that only assess risk at model onboarding are measuring a snapshot of a system that keeps moving.
Who Should Own Each Field When a Model Crosses Team Boundaries?
The answer is a named owner per field, not per model, because provenance, licensing, and runtime security rarely sit with the same person. The ML engineer who fine-tuned a checkpoint usually can't speak to its license terms, and the platform team running inference usually didn't choose the training data. A registry that lists a single "model owner" column tends to produce answers like "I think legal reviewed that" — which isn't evidence. Splitting ownership by field (provenance and hash: ML/platform team; license and usage rights: legal; runtime CVEs: security; risk score and revalidation cadence: security or GRC) turns the registry into something an auditor can actually walk through, field by field, with a name attached to each answer.
How Safeguard Helps
Safeguard treats AI models the way it treats every other artifact in the software supply chain: as something that needs a verifiable identity, a provenance trail, and continuous vulnerability tracking, not a one-time intake form. Safeguard's platform ingests model metadata from the repositories, registries, and Hugging Face-style hubs your teams already use, and automatically resolves each entry down to a checksummed artifact rather than a display name — so "customer-support-llm" becomes the specific fine-tune, quantization, and runtime version actually deployed.
From there, Safeguard continuously cross-references each registered model's serving stack against live CVE data, the same engine it uses for container images and open-source dependencies, so a disclosure like CVE-2025-32434 surfaces against every affected deployment automatically instead of waiting for someone to remember which models load with torch.load(). License metadata is captured and flagged against usage context, so a non-commercial or field-of-use-restricted checkpoint deployed into a revenue-generating product raises a finding before legal has to go looking for it.
Because Safeguard is built for SOC 2-grade auditability, every registry field carries change history and an attributed owner — who added the model, who last revalidated its risk score, and when — giving compliance and security teams the evidence trail that frameworks like the EU AI Act's GPAI documentation requirements, and internal audits, actually ask for. The result is a registry that answers "what's running, where did it come from, and is it still safe" on demand, instead of a spreadsheet that answers none of those questions once it's more than a quarter old.