Resource Groups let an organization on a Hugging Face Team or Enterprise plan group repositories and decide which members can read or write each group. That limits who can push a changed model file. For an organization publishing models others depend on, it is a basic least privilege control.
Why it matters for supply chain
A model repository is a release channel. Whoever can write to it can change what downstream users download, unless they pin revisions. Limiting write access narrows the set of accounts whose compromise would let someone swap a weight file.
How Resource Groups work
The documentation states the feature is part of the Team and Enterprise plans. Administrators group related repositories, and members must be added to a group to access its repositories. A repository can belong to only one group, and a member can belong to several.
Four roles apply inside a group:
- read: read access to the group's repositories.
- contributor: write access limited to repositories the user created in that group.
- write: write access to all repositories in the group, including create, delete and rename.
- admin: write access plus administering the group and its members.
Organization admins can manage all groups. Resource Groups also affect visibility: a private repository in a group is visible only to its members, while public repositories are visible to anyone.
Designing groups for models
- Put production, published models in their own group, with few writers.
- Keep experiments and personal forks in a separate group with broader access.
- Use read for people who only consume models.
- Prefer contributor over write where people create their own repositories.
- Review membership on a schedule, and remove people who change teams.
The docs also describe auto-join, which adds all organization members to a group at a chosen role. Be careful before enabling it on a group that holds production models, since it grants that role to everyone, including future members.
Pair it with other controls
Access control reduces who can push. It does not tell consumers what changed. Combine it with fine-grained tokens, signed commits for your own releases, and revision pinning on the consuming side.
I read the documentation for the features above, but plan details can change, so confirm availability on your plan before you design around it.
A small example layout
A team with eight people might create three groups. One holds production models, with two writers and everyone else on read. One holds experiments, with all engineers as contributors. One holds partner shared models, visible to a named subset. When someone leaves, removing them from three small groups is quicker and less error prone than hunting through dozens of individual repository settings.
Quick check
Are Resource Groups available to everyone?
The docs say the feature is part of the Team and Enterprise plans. Some related features, such as spend limits, are listed as Enterprise and above.
Does a private repo in a group stay visible to the whole organization?
No. Per the docs, it is visible only to members of that group.
Sources
- Advanced Access Control with Resource Groups, Hugging Face Hub documentation
- Hugging Face Hub security overview
Last reviewed: 19 October 2026.
