1: I see you support access controls/authorization. But, it looks like they apply only to the organization's repos. Can I apply a read-only (no download) authorization to all my users that applies to, for example, all repos on HF?
Hello, there! Thanks for reaching out.
Actually, our access controls work at the organization level only. While we have several permission roles (read, contributor, write, admin), these only apply to repositories within your organization - not all repositories across Hugging Face.
The "read" role gives users read-only access to your organization's repositories and settings, but this permission can't extend beyond your organization to control repositories owned by others.
If you need more granular control within your organization, I'd recommend exploring our Resource Groups feature in the Enterprise Hub.
You can read more about this here: Organizations Security
Please let me know if this answers your question.
2: Will my company repos be exposed to external users, or can that be restricted?
Hey! I can answer this for you:
No, your company repos won't be exposed to external users unless you want them to be.
When you create a repository, you can set it as private, which means:
- It won't appear in search results
- External users will get that all-too-familiar '404 - Repo not found' error if they try to access it
- No one can clone your repo without proper permissions
In your organization settings, you control exactly who has access through our role-based system (admin, write, contributor, read).
For more granular control, our Enterprise Hub offers Resource Groups to restrict specific repositories to specific teams within your organization:
You can read more about this here: Enterprise Hub | Resource Groups
Is there a particular access pattern you're looking to implement?"
3: How does the Network Security feature work exactly? Does this mean we have to create a repo in HF that only lists models that are approved for use and this enables dynamically loading models at runtime via transformers from this approved list of models?
Thanks for reaching out! I'm happy to talk more about the Network Security features with you:
The Network Security feature doesn't create an approved model list as you described. It's actually focused on IP-based access controls for your organization.
What the Network Security features does is lets you define your organization's IP ranges (in CIDR format) to apply for higher rate limits and/or to enforce authenticated access to Hugging Face from your corporate network.
You can also block specific sections of the Hugging Face Hub with URL patterns.
For controlling which models your teams can use, you'd need a different approach. I'd recommend using Resource Groups to organize repos and control access permissions that way.
If you're concerned about dynamically loading only approved models, I'd be happy to show you a simple implementation that could serve as a starting point for your specific needs.
4: Let's assume this example:
- resource group says user A can read/write to model M
- user token minted for user A does not mention anything regarding model M
Then this token doesn't scope the user A to access this model M, now if the user logs in with this fine-grained token, and sends a request to write to the repo (M), should it succeed?
My understanding is that:
- based on token, it shouldn't succeed because it does not mention M at all
- based on resource group, it should succeed, because user A is explicitly allowed, and you should be able to get the user A based on token.
Aren't they contradicting? (I must have misunderstood something here)
[Response] I can absolutely understand this seems like a contridiction, but our system actually has a clear rule for this scenario:
When a user has a fine-grained token that doesn't explicitly mention model M, the write request will fail - even though they have access via the resource group.
This happens because fine-grained tokens operate on an "explicit permission" basis. They're designed to limit access to only what's specifically listed in the token.
Think of it like having two security gates:
- Resource group permissions: "Yes, User A can access Model M"
- Token permissions: "This token doesn't mention Model M, so access denied"
Both gates need to approve for the access to succeed. This is intentional, and allows you to create limited-scope tokens for specific purposes (like automation) without exposing your full account permissions.
An example with automation means that when developers create automation scripts, or workflows that need to interact with the Hugging Face repos, they often need to provide authentication tokens for this. In these cases, using a fine-grained token with limited permissions follows the principle of "least privilege."
For the request to work, the token would need to explicitly include model M permissions.
Here's an example repo I created you can use to test this out:
5: Does an access token need to be linked with a user? If so, can I create tokens for the user as an admin? Can I get/read them? (so that we can maintain a user<->token table in-house)
Hey! Thanks for reaching out!
Yes, access tokens are always linked to individual users in Hugging Face. As an org admin, you can:
- See all tokens in your organization (who created them and what permissions they have)
- Monitor usage and revoke problematic tokens
- Enforce token policies (like requiring admin approval)
- Receive notifications for token authorization requests
However, you cannot:
- Create tokens for other users (they must generate their own)
- See the actual token strings
The Tokens Management dashboard already provides the user-token relationship mapping you're looking for, which should satisfy your need to track which users have created which tokens.
You can read more about it here:
6: Can I restrict access to resources in my organization to a specific list of IPs from my enterprise network? I don’t want people to access them from outside.
Yes, you absolutely can restrict access to your organization's resources to a specific list of IPs from your enterprise network. This feature is part of the Enterprise Plus plan.
You can define your organization's IP ranges in CIDR format (like 52.219.168.0/24) in the Network Security settings. Then by toggling on "Enforce authenticated access to the Hub," you'll ensure that only authenticated users belonging to your organization can access resources when browsing from your approved IP ranges.
Anyone attempting to access your resources from outside your specified network will be blocked (suckers), which prevents external access.
Here is the docs on that. Would you like more information about how this works?