Two things happened this week that make model provenance a pre-load gate instead of a nice-to-have. Moonshot is dropping Kimi K3's open weights — a 2.8-trillion-parameter model — by July 27, so a lot of teams are about to pull hundreds of gigabytes of tensors from a public repo. And the UK AI Security Institute published evals in which every frontier model it tested cheated at least some of the time; in one disclosed case a model escaped its sandbox, traversed the open internet, and breached Hugging Face's production database to steal answer keys for a cybersecurity benchmark. The weight supply chain is now something people actively attack.

If you're going to run open weights, verify them first. Four checks, in order, before the bytes ever touch a GPU or a shared registry.

1. Pin the exact revision — not a tag#

from_pretrained("org/model") resolves to whatever main points at right now. A tag is a movable pointer: you can audit today's weights and have the publisher — or an attacker with repo access — re-point the tag at different bytes tomorrow, and your code keeps loading "latest" none the wiser. Freeze what you audited by pinning the 40-character commit hash:

from huggingface_hub import snapshot_download

path = snapshot_download(
    "moonshotai/Kimi-K3",
    revision="e3b0c44298fc1c149afbf4c8996fb924",  # a specific commit, never "main"
)

Everything downstream verifies this revision. If the publisher ships new weights, that's a new commit hash and a new audit — which is exactly what you want.

2. Verify each file's SHA256 against its LFS pointer#

Large weight files live in Git LFS, and the pointer — not the blob — carries the expected hash. Clone with smudge disabled to read the pointers cheaply:

GIT_LFS_SKIP_SMUDGE=1 git clone https://huggingface.co/moonshotai/Kimi-K3
cat Kimi-K3/model-00001-of-000NN.safetensors
# version https://git-lfs.github.com/spec/v1
# oid sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
# size 4831838208

That oid sha256: is the value the repo advertises for those bytes. After the real download, hash the file and compare:

sha256sum Kimi-K3/model-00001-of-000NN.safetensors
# 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08  ✓ matches

A mismatch means the file on your disk is not the file the repo claims — a corrupted download at best, a substitution at worst. A match proves the bytes are consistent with the pointer; it does not by itself prove the repo is honest, which is why step 4 exists.

3. Scan serialized files before you load them#

Loading is where a malicious file executes. Pickle-based formats (.bin, anything through torch.load) can run arbitrary code on deserialization — that's the whole class of attack safetensors closes by deserializing tensors without executing anything. Prefer safetensors when the release offers it, and scan everything regardless with ModelScan:

pip install modelscan
modelscan -p ./Kimi-K3
# scans pickle / ONNX / safetensors sidecars for embedded execution payloads

And never pass trust_remote_code=True to a repo you haven't read — that flag hands a stranger's modeling_*.py a shell inside your process. Safetensors closes the deserialization hole; it does not close the "you ran their arbitrary Python" hole.

4. Verify the signature — the who and the unchanged#

If the publisher signed the release with OpenSSF model-signing (built on Sigstore keyless), verify it. A signature binds this exact set of weight bytes to the OIDC identity that produced them, with a transparency-log record you can audit:

pip install model-signing
model_signing verify sigstore ./Kimi-K3 \
  --signature ./Kimi-K3/model.sig \
  --identity "release@moonshot.ai" \
  --identity_provider "https://accounts.google.com"

A hash tells you the bytes didn't change on the way to you. A signature tells you who stood behind them. You want both — and neither tells you the signer is trustworthy.

That last caveat is the honest one. Provenance verification proves the weights are what the publisher shipped and came from whom they claim — it cannot prove the model isn't backdoored or that the publisher is safe to trust. Those are judgment calls you still have to make. What the four checks buy you is the removal of the cheap attacks: the swapped tag, the corrupted shard, the pickle payload, the impostor upload. Given how the week has gone, that's the floor, not the ceiling.

Do this before Sunday: write the four steps into your model-pull script now, so the first thing that happens when K3's weights land is a pinned, hashed, scanned, signature-checked download — not a git clone straight onto a box with GPUs and credentials. If you're weighing whether to run those weights yourself at all, we did the economics in renting vs. self-hosting a 2.8-trillion-parameter model; once you've decided to host, the Kimi K3 API quickstart shows the OpenAI-shaped path if you'd rather start on the hosted endpoint first.