Has anyone figured out a workaround for this? I’ve seen a couple other threads with the same error this week (140734, 141396) but no resolutions yet, so I figured another data point might help.
Every Gemini API call from my Workspace domain returns:
HTTP 403
{
"error": {
"code": 403,
"message": "Your project has been denied access. Please contact support.",
"status": "PERMISSION_DENIED"
}
}
The header includes x-gemini-service-tier: standard, so the key is being recognized but blocked at the entitlement layer.
What I’ve ruled out:
-
Not IAM: super admin has Org Administrator, Project Creator, and API Keys Admin at the org level
-
Not org policies: disabled the usual suspects including
iam.managed.disableServiceAccountApiKeyCreation -
Not the API not being enabled: verified
generativelanguage.googleapis.comis active -
Not key type: same failure with plain keys and service-account-bound keys
-
Not org-level config: I spun up a brand new project with no organization parent via
gcloud projects create(no --organization flag), enabled the API, generated a fresh unbound key, and got the exact same 403. This is the one that convinced me it’s not something I can fix on my end.
Control test: An identical curl from the same network using a key from a personal @gmail.com account returns 200 with valid content. Same endpoint, same payload… only the key differs. So this is scoped to keys from my domain, not to anything about the request or the account doing the calling.
Has anyone:
-
Seen this clear up on its own after N days?
-
Found a trick for generating keys through a path that isn’t affected?
-
Had luck getting a human at Google to look at a domain-level block? (I don’t have paid Cloud support.)
For now I’m working around it with a personal key, but that’s obviously not viable long-term for an org-owned project.