Pin a Hugging Face model by passing the full commit hash as the revision argument to from_pretrained. A branch name like main can move, but a commit hash points to one exact state of the repository. Record the hash in code review, and treat any change to it like a dependency upgrade.
Why pinning matters
When you load "org/model" with no revision, you get whatever the default branch points to at that moment. Weights can be replaced. Config can change. For custom models, code can change, and the Transformers documentation recommends loading from a specific revision so you avoid model code that may have changed.
This is the same reasoning as pinning a package version. You want the artifact you tested to be the artifact you run.
Steps
- Find the commit. Open the model page on the Hub, go to the commit history, and copy the hash of the version you reviewed.
- Pass it as the revision. Use the full hash, not a short prefix.
- Store it as configuration. Keep it next to your other pinned versions, not buried in a notebook cell.
- Cache deliberately. Know where the local cache lives and who can write to it, so a pinned load is not satisfied by a different file.
- Review changes. When someone bumps the hash, the pull request should say why and what changed.
from transformers import AutoModelForCausalLM, AutoTokenizer
REPO = "org-name/model-name"
REV = "<full commit hash>"
tokenizer = AutoTokenizer.from_pretrained(REPO, revision=REV)
model = AutoModelForCausalLM.from_pretrained(REPO, revision=REV)
Pin the tokenizer too. It is easy to forget, and it is also loaded from the repo.
What a pin does and does not give you
| Pinning gives you | Pinning does not give you |
|---|---|
| The same files on every run | Proof the files were safe in the first place |
| A review point when the model changes | Protection from a malicious file at that commit |
| Reproducible evaluation results | A guarantee about training data or behavior |
A pin freezes a state. You still have to judge that state. Hugging Face notes that GPG signed commits do not guarantee a file is safe, but they do guarantee its origin, so a verified signature from a publisher you know is a useful extra check before you choose which commit to pin.
Pair the pin with a hash of your own
For the files you rely on most, record a SHA-256 of each weight file when you first approve it. Compare on deploy.
shasum -a 256 model.safetensors
This catches a swapped file in your own storage or cache, which a Hub commit hash cannot.
Add it to your checklist
Include the model repo, the pinned commit, the file format and the reviewer name in the same place you track packages. Our guide on a pre-import checklist for third-party models goes through the full list.
Where Safeguard fits
Safeguard's policies and gates can run on pull requests, which is where a change to a pinned revision would show up beside dependency changes. Safeguard also provides SBOM generation and dependency scanning. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Is a tag enough instead of a commit hash?
A tag can usually be moved by the repo owner, so a full commit hash is the stricter choice.
Does pinning protect me from pickle risk?
No. It keeps the files constant. If the pinned commit contains a malicious pickle, you will load it every time.
Sources
Last reviewed: 19 October 2026.
