Yes. Point the model cache at its own folder with HF_HUB_CACHE, supply the token through HF_TOKEN from your CI secret store, and persist only the cache folder, never HF_HOME as a whole. Restore the cache only for trusted branches so an untrusted job cannot plant model files.
The problem in one sentence
Large models are slow to download, so teams cache them between pipeline runs. The huggingface_hub environment variable reference says HF_HOME is where your token and the cache are stored by default. Caching HF_HOME wholesale therefore caches the token too.
The two variables that fix it
| Variable | Documented purpose |
|---|---|
| HF_HUB_CACHE | Where repositories from the Hub are cached; defaults to HF_HOME plus hub |
| HF_TOKEN | The access token; if set, it overrides the token stored on the machine |
| HF_TOKEN_PATH | Where the token file is stored |
| HF_HOME | Where the token and the cache are stored by default |
Setting HF_TOKEN from a secret means no token file has to be written to disk for authentication. Setting HF_HUB_CACHE to a dedicated path means you can persist exactly that path.
Setup steps
- Create a dedicated cache path in the job, for example under the runner's work folder.
- Export HF_HUB_CACHE to that path. Leave HF_HOME at a throwaway location.
- Inject HF_TOKEN from the secret store, using a read only, fine grained token if your plan supports it. See Hugging Face fine grained tokens for production and CI.
- Configure the CI cache step to save and restore only the HF_HUB_CACHE path.
- Key the cache on the pinned model commit hash, so a changed pin gets a fresh cache.
- Restore the cache only on trusted branches. For forks and untrusted pull requests, start with an empty cache, or restore read only.
- After restore, verify file hashes against your approval record before tests load the model.
What this does and does not protect
It keeps the token out of the saved archive. It does not stop a trusted job from saving a bad file into the cache, which is why the key and the verification step matter. It also does nothing about a token that is already printed in logs, so check that your logging never echoes environment variables.
Cache key tips
A key made of the model name alone will keep serving old files after a change. Include the commit hash. If you pin by hash, the key becomes self explanatory, and a pin change shows up in the pull request diff where reviewers can see it.
Try it yourself
Click through it at your own pace, or open it full screen. See how a pull request check can block a change before it merges, which is where a pin change belongs.
Quick check
Is a read only token enough to make caching safe?
It limits what a leaked token can do, but the cache can still be poisoned, so verify hashes.
Should pull requests from forks restore the cache?
Safer not to, or restore it read only. That is a policy choice for your CI system.
Safeguard's policies and gates can hold a pull request that changes dependency pins until it is reviewed. Try the free scan.
Sources
Last reviewed: 19 October 2026.
