Project 42Start learning
Module 3 of 12 · 54 min

Model Artifact Integrity and Safe Promotion

Acquire model artifacts into quarantine, verify identity and provenance, inspect executable surfaces, and promote only an immutable reviewed bundle.

Core concept

By the end

You will be able to

  • Design a quarantined acquisition path that prevents unreviewed artifacts from entering a trusted runtime.
  • Explain what digests, signatures, provenance, scans, and software bills of materials each establish and do not establish.
  • Identify executable serialization, custom-code, dependency, tokenizer, template, and conversion risks.
  • Promote an immutable artifact bundle with reproducible verification evidence, stop conditions, and revocation rules.
01

Acquire into quarantine, not the serving path

Download or copy the exact pinned revision into a non-serving, non-production environment with no learner data, no production credentials, minimal network access, bounded storage and compute, and an operator-approved destination. Preserve repository metadata and original filenames. Do not enable remote code, plugins, post-install hooks, or model loading merely to discover what the package contains.

Capture the source URL, immutable revision, retrieval time, transfer mechanism, expected manifest, observed files, sizes, and cryptographic digests before transformation. A mutable branch, tag, latest alias, cache entry, or friendly model name must not silently replace the approved artifact.

02

Verify distinct evidence without overstating it

A cryptographic digest detects whether bytes differ from the expected bytes; it does not identify a trustworthy publisher or prove safety. A verified signature can bind an identity to signed material under a trust policy; it does not prove that the signer made a safe model. Provenance can describe where and how an artifact was produced; it must be checked against expectations and does not replace evaluation.

Scanners can identify known patterns, malware, secrets, vulnerable dependencies, and suspicious files within their coverage. A software bill of materials inventories components and relationships. Neither a clean scan nor a complete inventory proves the absence of malicious behavior, unsafe deserialization, model-level failures, or unacceptable license terms.

03

Treat model packages as executable supply-chain input

Model repositories may include serialized objects, Python modules, native extensions, build scripts, package metadata, custom operators, tokenizer code, templates, conversion tools, or runtime plugins. PyTorch documentation warns never to load data from an untrusted source because its loading path uses unpickling; restricted weight-only loading narrows but does not eliminate denial-of-service or memory-corruption risks.

Prefer non-executable tensor formats where the selected runtime supports them, but verify the entire path rather than trusting a file extension. Inspect archive traversal, symbolic links, oversized or malformed tensors, unexpected files, dependency installers, custom code flags, dynamic imports, network calls, and conversion steps. Run any unavoidable parser or conversion in a disposable, least-privileged sandbox with strict resource and network limits.

04

Bind conversions and quantization to new identities

Conversion, merging, pruning, quantization, sharding, repackaging, or changing a tokenizer or template produces a materially different deployment artifact. Record the input digests, tool and dependency versions, configuration, command or workflow, environment, output manifest, output digests, operator or automation identity, and resulting evaluation target.

Use provenance and verification expectations to connect each output to its inputs and approved process. Re-run license, integrity, compatibility, and evaluation gates for the transformed artifact. Never inherit an approval solely because the new file began from approved weights.

05

Promote an immutable bundle and preserve revocation

The promoted bundle should contain or reference exact weight, tokenizer, template, configuration, runtime, dependency, and policy identities; their digests; verified signatures or documented absence; provenance; scans; license disposition; compatibility results; evaluation target; reviewer decisions; and expiry triggers. Move or copy by digest into a read-only trusted store and configure serving by immutable identity.

Fail closed when expected files, digests, signer identity, provenance predicates, lineage, terms, scans, dependency review, or sandbox checks do not match policy. Preserve evidence, block serving, revoke the candidate from caches and mirrors under your control, investigate affected environments, restore the last verified bundle, and repeat the full gate before promotion.

Practice activity

Design a safe artifact promotion packet

  1. Use a synthetic manifest rather than downloading or loading a real model.
  2. Define a quarantined acquisition environment, immutable source revision, expected file inventory, digest algorithm, signature policy, provenance expectations, scan plan, dependency inventory, and executable-surface review.
  3. Add one quantization transformation and record its input identity, toolchain, configuration, output identity, and new evaluation boundary.
  4. Write pass, hold, and fail-closed rules for every evidence type. Include resource-exhaustion and unsafe-deserialization stop conditions.
  5. Produce the promoted-bundle manifest and a revocation procedure that restores the last verified bundle without deleting investigation evidence.

What to produce

  • A synthetic acquisition and quarantine plan with no production data, credentials, or automatic execution.
  • An evidence matrix that states what each digest, signature, provenance record, scan, and inventory proves and does not prove.
  • A transformed-artifact provenance record, immutable promotion manifest, and tested-paper revocation procedure.

Reflect before continuing

Which control in your packet prevents trusted but wrong bytes, and which different control addresses correctly signed but unsafe behavior?

Evidence

Sources and verification

Knowledge check

Make it stick.

Pass at 80%

Choose the strongest answer for each question. Your attempts become part of your device-local transcript.

01Where should an unreviewed model artifact first be acquired?
02What does a matching cryptographic digest establish?
03Why should model loading be treated as a supply-chain execution boundary?
04A model is quantized from approved weights. What is the correct next step?
05What does a clean scanner result prove?
06What is the safest response to a provenance or digest mismatch during promotion?