Model Security: Protecting Weights, Adapters, and Artifacts

Model artifacts are the files that make a model deployable: weights, checkpoints, adapter deltas such as LoRA, tokenizer files, configuration, and sometimes runtime packages. They are not ordinary documents. A substituted or tampered artifact can change predictions, leak protected capability, evade evaluation, or execute unsafe deserialization code during loading. Model security therefore protects confidentiality, integrity, provenance, and availability across the artifact lifecycle. The practical rule is to make every artifact pass an evidence-bearing promotion path before production. This is narrower than the broader AI supply-chain program in AI Supply Chain Security and complements the application boundaries in LLM Security Risks.

What must be protected

Weights may encode proprietary training data, expensive research, or a capability that should not be downloadable. A checkpoint is a versioned training state; an adapter changes a base model without replacing it; a tokenizer and configuration determine how bytes are interpreted. Treating only the largest file as sensitive creates gaps: a public base plus a private adapter may recreate a restricted model, while a changed tokenizer can alter behavior without changing weight hashes. Inventory the complete load set, including manifests, preprocessing code, license terms, and runtime dependencies.

Threats include theft from registries or build storage, substitution by a compromised mirror, tampering during promotion, malicious or unsafe serialization, accidental exposure in notebooks, and untracked copies in caches. Availability matters too: deleting the only known checkpoint can prevent rollback after a bad release.

The Model Artifact Trust Chain

Use this PermsAI trust chain as a release control: SOURCE → VERIFY → QUARANTINE → SCAN/INSPECT → APPROVE → REGISTER → DEPLOY → MONITOR → REVOKE. Each arrow should produce evidence and a responsible owner.

Source records where the artifact came from, its upstream identity, version, license, and expected files. Verify checks cryptographic digests or signatures against an independently obtained manifest. A hash proves that bytes match a value; it does not prove that the value came from a trustworthy publisher. A signature adds origin evidence only when the signing key and trust root are managed correctly.

Quarantine means new or changed artifacts cannot be imported directly into a production registry. Store them in an isolated location with restricted network and runtime access. Scan and inspect checks file types, archive paths, serialization formats, embedded code, dependency metadata, size anomalies, and known advisories. Loading an untrusted serialized object in a developer environment can be risky; prefer safer formats and documented loaders, and inspect before deserialization.

Approve is a human or policy decision that records evaluation results, license review, security findings, and intended environments. Register creates an immutable, versioned record with digest, source, component relationships, owner, and status. Deploy promotes the exact registered digest, not a mutable tag. Monitor watches access, drift, unusual downloads, loading errors, and behavior changes. Revoke removes a compromised digest from promotion and tells deployment systems to stop accepting it.

Provenance and integrity

Maintain a manifest for every release. Include base model, adapters, tokenizer and config digests, build or conversion job, dataset and code revisions, toolchain versions, evaluator, approval ticket, and deployment locations. Sign the manifest or use a transparency-oriented signing workflow where it fits your platform. OpenSSF and Sigstore materials are useful examples of provenance and signing practice, but no tool removes the need to secure keys, verify identity, and review metadata.

Verify at multiple boundaries: on download, after conversion or quantization, before registry import, during promotion, and immediately before deployment. Pin digests in automation. A mutable name such as latest is convenient for experimentation but is not a release identity. Record failed verification instead of silently retrying from an untrusted mirror.

Artifact-control matrix

Artifact	Owner and storage	Integrity evidence	Access boundary	Promotion and response
Base weights	Research owner; encrypted registry	Signed manifest and digest	Read only to approved builders	Evaluation gate; revoke digest
Checkpoint	Training pipeline; versioned store	Job lineage and checksum	Training service role	Retain rollback set; expire stale copies
LoRA adapter	Product or team namespace	Base-plus-adapter compatibility record	Tenant/project scoped	Disable adapter without deleting base
Tokenizer/config	Release owner; immutable bundle	Digest and schema validation	Deploy service only	Roll back bundle with model
Converted/quantized file	Build service quarantine	Reproducible build evidence	No direct upload to prod	Rebuild from trusted source

Access, storage, and theft

Separate read, write, approve, and deploy roles. A training job may write checkpoints but should not publish to production. A serving identity may read an approved bundle but not enumerate every research artifact. Use private registries, tenant-aware namespaces, network restrictions, and audit logs. Encrypt at rest when model theft would create material harm, and protect keys separately from the registry. Encryption does not correct a malicious file or an overbroad reader.

Limit copies in local caches, CI workspaces, notebooks, and debug bundles. Mark exports and downloads with an owner and expiry. Alert on unusual volume, access from a new workload, repeated failed signature checks, or attempts to fetch revoked versions.

Promotion, inventory, and rollback

Promote through development, evaluation, staging, and production with explicit gates. Keep the exact digest and dependency set in deployment inventory so an incident responder can answer what is running where. Canary behavior and evaluation slices can detect a regression, but they do not replace provenance checks. Keep at least one known-good rollback artifact protected from the same failure domain as the current release.

Revocation must be operational: a registry status, deployment denylist, cache invalidation plan, and owner notification. If a base model is revoked, identify dependent adapters and bundles. If only an adapter is compromised, disable that component while preserving evidence.

Incident response

When an artifact is suspect, freeze promotion, preserve manifests and access logs, identify all digests and derived files, and isolate affected workloads. Determine whether the issue is theft, substitution, unsafe loading, license violation, or behavioral poisoning. Rotate registry credentials and signing keys when exposure is possible. Compare deployed bytes with registered digests, inspect downstream outputs, and notify owners of dependent adapters. Restore from a verified rollback and document the decision.

Checklist

1. Inventory every file required to load and serve a model.
2. Assign an owner, sensitivity, license, and retention rule.
3. Require provenance and independent digest or signature verification.
4. Quarantine before inspection; avoid unsafe deserialization of untrusted files.
5. Store immutable, versioned manifests with component relationships.
6. Separate registry read, write, approve, and deploy permissions.
7. Pin digests and verify after every transformation and promotion.
8. Encrypt high-value artifacts and reduce caches and exports.
9. Maintain deployment inventory, monitoring, revocation, and rollback.
10. Exercise an incident drill that traces a model from source to every running copy.

Sources

• NIST AI Risk Management Framework
• NIST Secure Software Development Framework
• MITRE ATLAS
• OpenSSF
• Sigstore documentation
• Hugging Face security policy

What good evidence looks like

A trustworthy release can be reconstructed by an independent reviewer. The record links an upstream reference to downloaded bytes, quarantine findings, scan versions, evaluation results, approval, registry digest, deployment target, and later observations. If any link is missing, label the artifact accordingly instead of inferring trust from a familiar name. This discipline also makes supplier changes visible: a new conversion tool, tokenizer revision, adapter base, or serving runtime is a new release candidate. Keep the decision record with the artifact so a future responder does not need tribal knowledge to determine whether the running model is approved.