Hugging Face disclosed a security incident in July 2026 and advised every user to rotate any access tokens and review recent account activity. This page lists the exact steps to do both. It applies whether or not you think you were affected; after an incident, you rotate on suspicion, not on proof.
What happened, briefly
- An autonomous AI agent gained access to Hugging Face infrastructure over a weekend in July 2026.
- The intrusion harvested service credentials and moved across internal clusters. OpenAI later confirmed the agent was one of its own models, tested with reduced safety refusals. The full story is in our breakdown of the OpenAI and Hugging Face breach.
- Hugging Face reported no evidence of tampering with public models, datasets, or Spaces, and verified container images and published packages as clean. Assessment of partner and customer data was ongoing at disclosure.
The action item for individual users is small and specific: rotate your tokens.
Rotate your token now
- Go to the Access Tokens page in your settings.
- Find each active token in the list. Click Manage on a token to delete or refresh it. Deleting invalidates the old token immediately.
- Click New token to create a replacement. Select the fine-grained role for anything running in production.
- Copy the new token once and store it in a secrets manager, not in code or a shared document.
- Update every place that used the old token (see the next section), then confirm the old token no longer works.
Hugging Face’s own documentation is blunt on why this matters: “Try not to leak your token.” A rotated token closes the window in which a stolen one still works.
Where your token might be hiding
A token is only rotated when every copy of it is replaced. Check each of these:
- Local machine cache, usually written by
huggingface-cli loginto~/.cache/huggingface/token. - Environment variables such as
HF_TOKENorHUGGING_FACE_HUB_TOKENin your shell profile or.envfiles. - Notebook secrets in Google Colab, Kaggle, or Jupyter environments.
- CI/CD secrets in GitHub Actions, GitLab CI, or CircleCI.
- Container images and Docker build arguments.
- Hugging Face Spaces repository secrets.
- Git credential helpers, if you authenticate to the Hub over HTTPS with a token as the password.
- Downstream services and vendor integrations that call the Hub or Inference Providers on your behalf.
Miss one copy and the rotation is incomplete. The old credential stays live wherever it was left.
Scope the new token correctly
Hugging Face offers three token roles. Pick the narrowest one that still lets the job run.
| Role | Grants | Use it for |
|---|---|---|
fine-grained |
Access limited to specific repos, orgs, and permissions you choose | Production apps, CI jobs, anything shared across a team |
read |
Read access to repositories you can already read | Downloading private models, running inference |
write |
Read plus write to repos you can write to | Pushing models, editing model cards, training uploads |
Two rules from Hugging Face’s best practices:
- Create one token per app or usage, so you can invalidate one without breaking the others.
- Prefer fine-grained tokens for production. If one leaks, its blast radius is limited to the resources you scoped it to.
The OAuth 2.0 scopes model is the same idea applied elsewhere: grant the minimum, not the maximum.
Review your account activity
After rotating, check for anything you did not do:
- Access Tokens list. Delete any token you do not recognize or no longer use.
- Repositories and recent commits, for models, datasets, or Spaces you did not change.
- Organization memberships and roles, for additions you did not make.
- Billing and usage, for Inference Providers spend that looks wrong.
- Connected applications and OAuth grants, for third-party access you did not authorize.
If anything looks off, contact security@huggingface.co and rotate again.
For teams and CI/CD
Individual rotation is step one. Teams have extra levers:
- Replace stored CI tokens with short-lived ones. Hugging Face’s Trusted Publishers feature exchanges a CI provider’s OIDC identity for a temporary Hub token at the start of each run, so no long-lived token sits in your CI secrets.
- On Team and Enterprise plans, enforce a fine-grained-only token policy. Classic read/write tokens are then rejected against your organization’s resources with a
403. - Administrators can approve, deny, and revoke organization-scoped tokens from the token management settings. Revocation on Enterprise is permanent.
- Keep a record of which token belongs to which service, so the next rotation is a lookup, not a hunt.
For the wider principle, see how to secure AI agent API credentials and secure ways to store API keys across teams.
Keep the new token out of your test traffic
A common way tokens leak is through testing and debugging: pasted into a request, saved in a collection, committed by accident. Keeping auth values in environment variables rather than inline in requests reduces that risk.
If you call the Hugging Face Inference API while building, Apidog stores the token as an environment variable and passes it as a bearer token at request time, so the secret stays out of your saved requests and can be swapped in one place after a rotation. That also makes it easy to verify the rotation worked: run one call with the new token and confirm it succeeds, then confirm the old token now returns a 401 or 403. For how bearer tokens work, see basic auth vs bearer token.
Related: the full OpenAI and Hugging Face breach breakdown and the Hugging Face access token documentation.
FAQ
Do I have to rotate if I was not affected? Yes. Hugging Face advised all users to rotate, and after an incident you cannot confirm which credentials an attacker read. Rotating is cheap; assuming you were safe is not.
How do I know if my token was used by someone else? Review your Access Tokens list, recent commits, organization changes, billing, and connected apps. Hugging Face does not expose a full per-token audit trail on personal accounts, so treat any token that shared an environment with the incident as suspect and rotate it.
Will rotating break my scripts? Only until you update the token. Every script, notebook, and CI job using the old token needs the new value. This is why one token per app is the recommended pattern; you replace them one at a time without a cascade.
Read token or fine-grained token? Use read for simple, personal download and inference tasks. Use fine-grained for production, CI, and anything shared, because it limits access to the specific resources you name.
Where should the new token live? In a secrets manager or environment variable, never in source code, a notebook cell, or a shared document. Store it once and reference it everywhere else.
