So i almost never use spaces.
I tried using space it asked for my banking asking for me to it access my banking among other things. wtf..?? I canceled request
Now main question is how do i see i my profile that no other spaces have such access - i dont want some random space accessing such thing and randomly making some debt for me.
Maybe some spaces are dangerous newbie traps?
thanks for help
Hmm… without the actual Space code, or at least a screenshot, I can only speak in general terms,
but…:
The first thing I would separate is “billing-related access” from “access to your bank account.” Those are not the same thing in Hugging Face’s OAuth system.
If what you saw was the read-billing permission, Hugging Face currently defines that scope as:
Know whether the user has a payment method set up.
In other words, it is a yes/no-type account capability check, not a permission described as reading your bank account, card number, balance, etc. You can see the current scope definitions in the Hugging Face OAuth documentation and the Spaces OAuth documentation.
However, you said it asked for that “among other things”, and that part matters. Some other HF OAuth scopes can actually let a Space perform actions on your behalf. So without knowing the Space or seeing the permission screen, I would not say either “that Space was definitely safe” or “that Space was malicious.”
For the practical part of your question, I would start with these two places:
Check which apps/Spaces you have authorized:
Hugging Face → Connected Applications
Gradio’s own Hugging Face OAuth guide explicitly points users there to revoke an application’s access.
If your concern is actual money rather than permissions, check billing separately:
Hugging Face Billing
The important distinction is:
Connected Applications tells you who has authorization. Billing/Compute Usage tells you whether paid activity actually happened.
And canceling an authorization request you do not understand is a perfectly sensible default. You do not need to approve it first just to find out what it means.
A useful mental model is:
"Can this app read some account state?"
!=
"Can this app perform actions for me?"
!=
"Can those actions consume paid HF resources?"
!=
"Did any paid usage actually occur?"
read-billing belongs mainly to the first category. Other scopes can belong to the second and sometimes lead to the third.
According to the current HF OAuth scope list, some examples are:
| Scope | Rough meaning |
|---|---|
profile |
Read basic profile information |
email |
Read your email address |
read-billing |
Know whether a payment method is set up |
read-repos |
Read your personal repositories |
gated-repos |
Read public gated repos you have been granted access to |
contribute-repos |
Create repos and access repos created by that app |
write-repos |
Read/write your personal repos |
manage-repos |
Fully manage personal repos, including creating/deleting them |
inference-api |
Make Inference Providers requests on your behalf |
read-endpoints |
View your Inference Endpoints and invoke them |
write-endpoints |
Manage Inference Endpoints, including creating/deleting them |
jobs |
Run Hugging Face Jobs |
webhooks |
Manage webhooks |
write-discussions |
Post/interact with discussions and PRs on your behalf |
So I would not judge a consent screen simply by the number of permissions.
The more useful question is:
Does each consequential permission make sense for what this Space says it does?
For example:
jobs;inference-api;HF now also has narrower permissions such as gated-repos and contribute-repos, so in some situations a broad scope is not the only possible design.
This is an important distinction because there are real Hugging Face Spaces that use these capabilities in different combinations.
For example, one public AutoTrain-related Space, Train FLUX LoRA with Ease, uses the OAuth user’s account information to check canPay before allowing a training workflow to proceed. Its code displays an estimated cost for a paid L40S GPU and checks whether the signed-in account has a payment method.
That is a good example of what a billing-status check can be useful for: the app wants to know whether the user is capable of paying before offering a paid action.
But the check itself is not the action that starts the GPU.
There is an even clearer counterexample in another public Space: Krea 2 LoRA Trainer.
Its README currently declares:
hf_oauth: true
hf_oauth_scopes:
- read-repos
- write-repos
- manage-repos
- jobs
Notice that read-billing is not in that list.
Nevertheless, the Space explicitly says that the training Job runs under the signed-in user’s account and billing, and the implementation submits an HF Job with the user’s OAuth token.
That is a useful demonstration of the boundary:
read-billingis neither “permission to charge my bank” nor necessarily required for an app to initiate billable HF work.
What matters for cost is what actions the granted scopes allow the application to perform.
A few examples make the distinction clearer.
The jobs scope permits an app to run HF Jobs.
HF’s Jobs pricing documentation currently says that Jobs require a positive credit balance and that billing is based on the requested hardware while a Job is starting/running. Billing goes to the user’s namespace by default unless another namespace is explicitly selected.
So jobs is not merely an informational permission.
The inference-api scope lets the application make Inference Providers requests on behalf of the user.
For Hugging Face-routed requests, the current Inference Providers pricing documentation says that billing is handled through the HF account; free/monthly credits can apply, and additional usage can use purchased credits.
Again, that is very different from read-billing.
write-endpoints is stronger still: HF describes it as permission to manage your Inference Endpoints, including creating and deleting them.
So there absolutely are OAuth permissions that deserve attention. The point is just that “billing” in the name of read-billing does not mean “banking access.”
For Spaces using Hugging Face’s built-in OAuth integration, the requested scopes can be declared in the Space’s README.md metadata.
The Spaces OAuth documentation shows the structure:
hf_oauth: true
hf_oauth_scopes:
- ...
openid and profile are always included, and additional permissions can be listed in hf_oauth_scopes.
So for a public Space, one useful inspection path is:
What does this Space claim to do?
↓
What does its README request in `hf_oauth_scopes`?
↓
Do those scopes make sense for those features?
↓
If necessary, does the public code show where they are used?
This is much more informative than simply labeling all authorization prompts dangerous or harmless.
It also means that if you later remember the Space URL, someone can often inspect this without you needing to authorize it first.
There is actually a fairly recent HF Forum example showing why these authorization screens can legitimately make users pause.
In this February/March 2026 discussion, an application only wanted access to gated public repositories, but the available read-repos permission also covered private repos. The poster described the resulting authorization message as understandably “scary.”
HF staff responded by adding a narrower permission, which is now the gated-repos scope, and also mentioned a general OAuth UX improvement.
That is not evidence that your case is the same issue, and it does not mean the Space you saw was unsafe.
It is just a useful reminder that:
a permission screen can look alarming because the permission is broad or poorly matched to the user’s mental model, without that automatically implying malicious intent.
So stopping at the consent screen and checking first is reasonable.
For the request you canceled, I would not assume that you somehow needed to authorize it in order to cancel it safely.
But there is another distinction worth making:
canceling one new authorization request does not prove that you never authorized the same or another application in the past.
That is why the account-level source of truth I would use is Connected Applications, rather than relying on whether a Space currently shows you a login/consent screen.
The Gradio OAuth documentation explicitly says users can revoke access there.
Also, I would not treat merely logging out of a Space as equivalent to revoking that application’s authorization. If your goal is “I want this application to stop having delegated HF access,” removing it from Connected Applications is the clearer action.
I would translate that concern slightly differently.
The scenario suggested by HF’s public OAuth documentation is not:
“A Space can use
read-billingto log into my bank and take out debt.”
I do not see support for that interpretation in the documented permission.
The more technically realistic question is:
“Could an application I authorize perform actions on my HF account that consume paid Hugging Face resources?”
Depending on the scopes and the application’s behavior, yes, that is a legitimate thing to think about.
For example, HF currently has paid/credit-backed usage around Jobs, Inference Providers, Inference Endpoints, upgraded Space compute, and related services. The Billing documentation and product-specific pricing pages explain those separately.
That is why I would check:
If you find an unexplained Job, Endpoint, inference usage entry, repo operation, or actual charge, then it is no longer merely a confusing authorization-screen question; there is a concrete account activity to investigate.
If those pages show nothing unexpected, that is much more useful evidence than trying to infer everything from the word “billing” alone.
One small additional note: some OAuth scopes can also apply to organizations. The HF OAuth docs say that the authorization flow can let the user select which organizations to grant access to. So if you are in HF organizations and the consent screen mentions organization access, that is another part worth reading separately from personal-account access.
So, in short, my default path would be:
Just want to make sure nothing currently has access?
→ Check Connected Applications.
Worried that money was actually spent?
→ Also check Billing / Compute Usage.
Remember the Space?
→ Check its README / `hf_oauth_scopes`
and see whether the requested permissions fit its function.
Have the original permission screenshot?
→ The individual permissions can be interpreted one by one.
Find actual unexplained account/billing activity?
→ Revoke the application and treat that concrete activity
as the thing to investigate.
Based only on the post, I don’t think there is enough information to call the Space a “dangerous newbie trap.” There is also not enough information to certify that particular Space as harmless.
What can be said fairly confidently from the public documentation is narrower:
read-billing, it does not mean what I would normally understand as “access to my bank account”;That is probably the cleanest way to separate the scary wording from the things that are actually worth checking.