AI Model Weight Signing: Verify Artifacts

AI model weight signing should answer more than whether one enormous file kept its checksum; it should identify the complete release the runtime is about to execute. This guide builds a canonical manifest for shards, configuration, tokenizer, adapters, provenance, policy, rotation, and a loader that refuses partial verification.

AI model weight signing covers a release graph

A deployable model is rarely one blob. It may include dozens of weight shards, an index, architecture configuration, tokenizer files, special-token mappings, generation defaults, quantization metadata, adapters, custom code, licenses, and evaluation receipts. Signing only the largest file leaves many behavior-changing inputs outside the trust boundary.

Model the release as a directed graph. A release manifest points to immutable artifacts by digest and declares the role of each node. The runtime verifies the manifest signature, resolves exactly those nodes, checks every byte digest, and confirms that the selected loader policy supports their formats. AI model weight signing therefore authenticates one coherent graph, not a filename in a mutable registry.

Draw a replacement attack for each artifact. A changed tokenizer can remap tokens; a modified config can select remote code; a swapped adapter can alter behavior; a stale index can omit a shard. The signed model manifest must make every substitution detectable before deserialization. This threat model prevents the project from celebrating cryptography while still trusting mutable neighboring files.

Define identity before choosing a signing tool

Separate artifact identity, release identity, signer identity, and deployment approval. A SHA-256 digest identifies bytes; a manifest version identifies a set; a certificate or key identifies the signer under a trust policy; an environment approval says that this verified release may run here. Collapsing these concepts creates brittle exceptions later.

Sigstore documentation describes identity-bound signing and transparency patterns. The Update Framework explains threshold roles, expiration, rollback, and key compromise, while the Safetensors documentation defines a safer tensor container rather than a provenance system. Use each source for its own layer instead of claiming one solves the entire model supply chain.

Write the verification policy in plain language. For example: production accepts manifests signed by two current release identities, logged in the transparency service, younger than ninety days, and referencing only approved formats. Model artifact integrity becomes an operational rule that can be reviewed independently from how signatures are produced.

Treat the release name as a human label; only the digest-bound identity is safe for loaders, rollbacks, and incident queries.

Canonicalize a manifest humans can inspect

The manifest needs deterministic bytes. Choose a canonical JSON representation, a signed envelope standard, or another format with unambiguous serialization. Define Unicode handling, number representation, object ordering, duplicate-key rejection, and the exact bytes that enter the signing operation. Never sign “whatever JSON.stringify produced” across several languages without a compatibility corpus.

Include release name, revision, created time, producer, source commit, training or conversion job, model architecture, artifact roles, relative paths, sizes, cryptographic digests, formats, dependencies, policy hints, and provenance references. Keep volatile download URLs outside artifact identity; mirrors may change while bytes remain the same.

AI model weight signing should fail closed on unknown critical fields, not silently ignore future semantics. Version the manifest schema and provide fixtures for accepted, deprecated, and rejected versions. A small human-readable summary can show signer, model, shard count, total size, and provenance, but the verifier must always use canonical signed bytes rather than reserializing the summary view.

Sign with scoped identities and retained evidence

Release keys should not live inside training containers or developer laptops by default. Use a protected signing service or short-lived workload identity after the build has produced immutable artifacts and evaluation has approved them. Scope authorization to repository, workflow, environment, and manifest type, then retain the identity evidence that justified issuance.

If offline keys are required, document storage, access ceremony, backup, rotation, and revocation. Threshold signing can separate model ownership from security approval for high-impact releases. AI model weight signing is stronger when no single compromised job can replace artifacts and authorize its own deployment.

The artifact below uses a local Ed25519 key only as an executable teaching fixture. It signs canonical manifest bytes and proves that a changed config digest fails verification. Production design must additionally validate signer identity, certificate chain or trust root, signature time, transparency inclusion where used, policy version, and expiration. Cryptographic validity is necessary, but acceptance remains a product decision.

The dependency-free Ed25519 fixture signs a manifest that contains two shard digests and a configuration digest, then demonstrates that changing the configuration invalidates the release signature.

Runnable artifact — model-weight-signing.test.mjs

import assert from "node:assert/strict";import {generateKeyPairSync,sign,verify,createHash} from "node:crypto";
const {privateKey,publicKey}=generateKeyPairSync("ed25519");const digest=x=>createHash("sha256").update(x).digest("hex");
const manifest={model:"jp-small",format:"safetensors",shards:[{name:"model-01",sha256:digest("weights-a")},{name:"model-02",sha256:digest("weights-b")}],config:digest("config-v1")};
const bytes=Buffer.from(JSON.stringify(manifest));const signature=sign(null,bytes,privateKey);assert.equal(verify(null,bytes,publicKey,signature),true);
const changed=Buffer.from(JSON.stringify({...manifest,config:digest("config-v2")}));assert.equal(verify(null,changed,publicKey,signature),false);
console.log("PASS: signed weight manifest rejects mutation");

Run node model-weight-signing.test.mjs. Expected receipt: PASS: signed weight manifest rejects mutation.

Bind conversions, quantization, and adapters

Derived models need new release identities. Quantization changes weights and may add scales, kernels, or calibration metadata; format conversion changes containers; adapter merging changes parameter values; adapter stacking changes runtime composition. Do not inherit the upstream signature as though transformed bytes were identical.

Record parent release digest, transformation code, parameters, environment, output artifacts, evaluation receipt, and responsible signer. This lineage permits a verifier to say “quantized from verified base R12 by job J44” while still checking the new bytes independently. A Safetensors checksum is one node in that chain, not the chain itself.

For AI model weight signing, decide whether loose adapters may attach at runtime. A strict environment might require a signed composition manifest naming base model and ordered adapters. An experimental environment may allow unsigned local adapters but display an unmistakable unverified state and block external actions. The policy should make composition visible rather than letting a command-line flag silently redefine the model.

Verify before mapping a single tensor

The loader begins with policy and manifest verification, then checks every referenced artifact before parsing or memory mapping it. Stream digests for large shards and compare sizes early, but do not treat size as integrity. Resolve paths within an approved root, reject traversal and unexpected symlinks, and disable remote code unless the manifest and environment policy explicitly authorize it.

Verification output should name manifest digest, signer identities, trust-root version, transparency result, artifact count, mismatches, unsupported formats, and final decision. Keep successful receipts too; otherwise incident response cannot prove which release a host accepted. The loader must never downgrade a failed signature into a warning in production.

AI model weight signing also needs time and rollback defenses. A valid old manifest may contain a vulnerable model. Enforce minimum release epochs, expiration, revocation, and environment pins so a registry attacker cannot replay a previously trusted artifact. The table distinguishes bytes, release, signer, and deployment authority because each uses different evidence.

Connect verified bytes to runtime identity

After loading, expose the manifest digest as the model's runtime identity in logs, traces, health endpoints, and generated output metadata where appropriate. A friendly model name is mutable and insufficient during an incident. The serving process should attest which verified release it mapped and which policy accepted it.

Related controls continue after verification. Confidential AI inference protects execution evidence, memory-mapped model loading handles shard residency, AI agent workload identity scopes the serving principal, and an LLM quantization quality budget tests the behavioral consequence of derived weights.

Join metrics by manifest digest: latency, error rate, evaluation cohort, user feedback, and rollback events. This allows a canary to compare actual releases instead of aliases that may move between requests. Supply chain attestation becomes useful to product operations when the same identity survives from registry verification to behavior monitoring.

AI model weight signing emits that verified identity into traces and serving receipts before traffic arrives, otherwise later telemetry cannot prove which artifact answered a request.

Drill key compromise and partial download failure

A release process is incomplete until it practices failure. Revoke one fixture signer, expire a role, present a valid signature from an unauthorized identity, swap one shard, truncate a tokenizer, replay an older manifest, and interrupt download before the final artifact. Every case should produce a stable denial reason and leave no loadable partial release.

Key rotation needs overlapping trust windows and an explicit end. Publish new trust roots through a separately protected channel, sign with both identities during transition if policy requires it, verify fleet adoption, then remove the old key. AI model weight signing should reveal stragglers before the old signer is revoked, not after production stops loading.

Archive the release manifest, envelope, identity certificate or key reference, transparency evidence, policy, artifact verification receipt, transformation lineage, evaluations, and rollback target. Revisit the contract whenever formats, registry behavior, or deployment composition changes. The objective is simple to state and demanding to maintain: the exact bytes that passed review are the only bytes the runtime may execute.

Make verified identity the loading boundary

Signed weights are meaningful only when the signature covers the entire executable release and the loader enforces a current identity policy before parsing it. Preserve that identity through serving and monitoring so a cryptographic receipt becomes operational evidence rather than a badge on a registry page. A release is complete when an operator can start from a running process, recover its manifest digest, verify every artifact, and explain which current policy admitted it without relying on a mutable registry label.