If you load a Hugging Face model by name alone, you get whatever is on the main branch today. Pin the revision to a full commit hash and the same bytes come back every time, until you choose to update. Store the hash in your code or config and change it through review.
Why a name is not a version
The huggingface_hub download guide states that by default the latest version from the main branch is downloaded. The transformers documentation for from_pretrained describes revision the same way: it defaults to main, and can be a branch name, a tag name or a commit id, since the Hub is git based.
So a plain model name is a moving target. A maintainer can push a new commit, and so can anyone who gains write access to the repository. Your next deploy or a fresh CI runner picks up the change without any pull request on your side.
What you can pass as a revision
From the download guide, revision can be a branch, a tag, a pull request reference such as refs/pr/3, or a commit hash. Only the commit hash is immutable in practice, since branches move and tags can be reassigned in git generally.
The guide also notes that a commit hash must be the full length hash rather than a seven character one.
from transformers import AutoModel
MODEL = "org/model-name"
REVISION = "FULL_40_CHARACTER_COMMIT_HASH"
model = AutoModel.from_pretrained(MODEL, revision=REVISION)
How to adopt it
- Open the repository on the Hub and review the files at the commit you want to use.
- Copy the full commit hash from the history.
- Put the repository name and hash in one config file, not scattered through code.
- Make updates a pull request, with a short note on what changed and who reviewed it.
- Apply the same pin in notebooks, Dockerfiles and CI jobs that download the model.
Pin the code too
Revision applies to the files you download. If a model needs custom code, that code also lives in the repository. The transformers docs say trust_remote_code should only be enabled for repositories you trust and in which you have read the code. Pin first, review that exact code, then decide. More in the trust_remote_code post.
What pinning does not fix
A pin stops silent change. It does not prove the pinned commit was good. If the author's account was compromised before the commit you reviewed, you will faithfully pin a bad file. Review matters, as do scans and source checks.
Safeguard's policies and gates can enforce rules in CI, and its SBOM and dependency scanning covers the packages around the model. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is pinning to a tag enough?
A commit hash is safer. The docs list tags as valid revisions, but a full commit hash identifies one exact state of the repository.
Does a pinned hash mean the model is vetted?
No. It only means the files will not change. Vetting is a separate step you do before you pin.
Sources
Last reviewed: 19 October 2026.
