If Google AI Studio says “Failed to generate API key: Permission denied,” it did not create a usable key. The first permission boundary is the Google account and Cloud project selected in AI Studio—not your application code.
Before you change the browser, role, project, or tool, record the signed-in account and the selected project ID. Then find the first gate that fails:
| Gate | What must be true | Who usually owns the fix |
|---|---|---|
| AI Studio access | The account can use AI Studio and meets Workspace, region, and age requirements | Workspace administrator or account owner |
| Project visible | The intended Cloud project is selected or imported for the same account | Project owner or organization administrator |
| Create permission | The account has the current permissions needed to create the authorization key | Project IAM administrator |
| First request | A created key is stored privately and one small server-side request succeeds | Developer, after the key exists |
Stop rule: if no key was created, do not debug an SDK, model name, quota, billing path, or request-time 403 yet. Those belong after key creation.
If the create-permission gate is blocked, send the project administrator the exact current list from Google's AI Studio key documentation, checked July 15, 2026: resourcemanager.projects.get, apikeys.keys.create, serviceusage.services.enable, iam.serviceAccounts.create, and iam.serviceAccountApiKeyBindings.create. Ask for the needed permissions on the intended project; do not assume one broad role name covers the whole chain.
Retry creation once after an authorized change. Success means the key exists, remains outside browser code and support messages, and one minimal private server-side request succeeds.
Start with the signed-in account and selected Cloud project
Open Google AI Studio API Keys in the account that is supposed to own the integration. Before pressing Create API key again, write down two things:
- the email address shown in the account selector;
- the project ID, not only the project display name.
Every Gemini API key belongs to a Google Cloud project. The project is therefore the owner of IAM, service enablement, the service account behind a new authorization key, restrictions, usage, and later recovery. A browser tab can look correct while still holding a different Google identity or a different Cloud project from the one your team expects.
If the intended project already exists in Google Cloud but is missing from AI Studio, use AI Studio's project import flow instead of creating a look-alike project. Google's current API-key guide tells existing Google Cloud users to import their projects into AI Studio before managing keys there.
A clean session can help diagnose identity confusion. Sign out of unrelated Google accounts or open a private browser window, sign in with exactly one account, select the same intended project, and try once. This does not grant IAM permissions or bypass an organization policy. It only tells you whether a mixed browser session was pointing AI Studio at the wrong identity.
If a personal account works but a work account fails
That difference is useful evidence, but it is not proof of one specific cause. The personal account may be using a personally controlled project with fewer organization boundaries. The work account may be subject to Workspace service access, project visibility, IAM, age or region eligibility, or an organization policy.
Do not move a production integration to a personal project merely because it creates a key. Keep the intended identity and project, then ask the owner of that boundary to correct access.
Use this interpretation:
| Observation | What it suggests | What it does not prove |
|---|---|---|
| Personal account creates a key | A different identity/project path can pass | The work account is missing one particular role |
| Work account cannot see the project | Project visibility or organization access is blocked | The Gemini API itself is down |
| Work account sees the project but create fails | Creation permissions, service enablement, service-account creation, binding, or policy may be blocked | Clearing the browser will fix IAM |
| Both accounts fail in the same supported setup | The problem may sit at project, eligibility, or policy level | Creating more projects is the safest next step |
Ask for the five permissions AI Studio currently uses
Google's API-key guide now documents a five-permission creation path for new AI Studio authorization keys. This is broader than the single apikeys.keys.create permission that many older answers mention.
| Permission | Why AI Studio needs it during creation |
|---|---|
| resourcemanager.projects.get | Read and confirm the selected project |
| apikeys.keys.create | Create the API-key resource |
| serviceusage.services.enable | Enable the required service when needed |
| iam.serviceAccounts.create | Create the backing service account |
| iam.serviceAccountApiKeyBindings.create | Bind the new API key to that service account |
Source: Google's Gemini API key documentation, checked July 15, 2026.
The Cloud IAM API Keys role reference shows that API Keys Admin includes API-key operations such as apikeys.keys.create. That does not make it a complete answer to the current AI Studio flow: the service-usage and service-account operations belong to other permission families.
The least-privilege request is therefore not “make me Owner.” Ask the administrator to grant the five named permissions on the intended project through roles or a custom role that fit the organization's policy. The administrator should decide the approved implementation; the developer should make the required operations explicit.
Copy this administrator request
I cannot create a Google AI Studio authorization key in project PROJECT_ID while signed in as ACCOUNT_EMAIL. AI Studio shows “Failed to generate API key: Permission denied” at TIMESTAMP_WITH_TIME_ZONE.
Please confirm that this account can access AI Studio and see the intended project, then check whether it has these current creation permissions on that project: resourcemanager.projects.get apikeys.keys.create serviceusage.services.enable iam.serviceAccounts.create iam.serviceAccountApiKeyBindings.create
No key was created, and no credential is attached to this message.
Include the exact project ID, account, timestamp, and visible error. Do not include a key string, browser cookie, access token, or secret.
Separate Workspace access from Cloud project IAM
A Workspace administrator and a Cloud project IAM administrator control different gates.
Workspace service access answers whether the managed account may use AI Studio at all. Project IAM answers what that identity may do inside a particular Cloud project. Passing one gate does not imply passing the other.
Google's Workspace access guide for AI Studio says administrators can control AI Studio access for managed users. It also documents special restrictions for some education users under 18. Google's available regions page separately describes region and age eligibility. These are access gates, not project-role substitutes.
Use the visible symptom to route the request:
| What you can do | Likely owner | Ask them to check |
|---|---|---|
| Cannot open AI Studio with the work account | Workspace administrator | AI Studio service access, organizational unit, age/education restrictions |
| Can open AI Studio but cannot see the intended project | Project owner or organization administrator | Project membership, project import, account identity |
| Can see the project but cannot create the key | Project IAM administrator | The five current creation permissions and organization policy |
| Can create the key but the API later returns 403 | Developer plus project owner | Key/project match, restriction, route, region, and request authentication |
If an administrator-owned gate fails, stop there. Repeatedly switching browsers, making new projects, or requesting broad roles makes the incident harder to audit without changing the owner of the failure.
Retry creation once in the same intended project
After one authorized access or IAM change, return to the same account and same project. Refresh AI Studio or start one clean session, confirm the project ID again, and retry Create API key once.
Do not change the account, project, browser, and role at the same time. A controlled retest tells you whether the approved change fixed the denied operation. If it still fails, preserve the new timestamp and exact message for escalation.
When creation succeeds, note the key type before leaving the page. Google's current guide says newly created AI Studio keys are authorization keys backed by a Google Cloud service account and restricted to the Gemini API by default. Google's Cloud API-key authentication guide explains the service-account binding behind authorization keys.
This lifecycle matters because an old tutorial may describe a standard API key instead. Google currently says the Gemini API will reject standard API keys starting in September 2026. Treat that date as a migration boundary and recheck the official key guide before relying on a long-lived setup.
The key value should be copied into a trusted server-side secret store. Do not save it in a screenshot, frontend bundle, mobile application, public repository, issue, or chat. If the intended application runs in a browser, put the Gemini call behind your backend rather than exposing the key to the client.
Verify one private request after the key exists
A successful create operation proves that the key resource exists. It does not yet prove that your runtime reads the correct secret or that the key reaches the Gemini API.
Store it in a server-side environment variable:
hljs bashexport GEMINI_API_KEY="replace this only in your private shell or secret store"
Then make a small authentication check from that private environment:
hljs bashcurl "https://generativelanguage.googleapis.com/v1beta/models" \
-H "x-goog-api-key: $GEMINI_API_KEY"
A successful response shows that the credential reaches the Gemini API. It does not promise that every model, quota, billing state, or later request will work. Choose a current model and test your real request only after this smallest check is clean.
Keep four safety rules:
- copy the key only into an approved secret location;
- never put it in client-side environment variables such as NEXT_PUBLIC_*;
- never paste it into a support ticket, screenshot, or chat;
- rotate it if it was exposed, even if the first request still works.
If creation is still denied, escalate the boundary instead of guessing
A good escalation packet lets an administrator reproduce the failed operation without receiving your secret. Send:
- the exact Cloud project ID;
- the signed-in Google account;
- the exact visible error text;
- the timestamp with time zone;
- the action attempted: create an AI Studio authorization key;
- whether AI Studio opens and whether the project is visible;
- whether a clean single-account session changed the result.
Do not send a key because no key should exist in this failure state. If a key appeared during a later attempt, keep it private and report only that creation succeeded or failed.
The following stop conditions belong to an administrator:
- AI Studio is disabled for the managed Workspace account;
- the intended project is hidden by organization or membership settings;
- the organization disallows one of the service-account or key operations;
- the user cannot meet region, age, verification, or education-account eligibility;
- security policy requires a different approved credential route.
At that point, “try another personal account” is not a production fix. The administrator must either authorize the intended AI Studio route or name the organization's supported alternative.
Do not confuse creation-time denial with a later API 403
The two failures can share the words “permission denied,” but they happen on different sides of key creation.
| State | What exists | Where the failure appears | First checks |
|---|---|---|---|
| AI Studio says it failed to generate the key | No usable key | AI Studio create operation | Account, project visibility, five creation permissions, Workspace/organization policy |
| API returns 403 PERMISSION_DENIED | A key already exists | HTTP response to an API request | Key/project match, API restriction, endpoint/auth shape, region and resource access |
| API returns 429 RESOURCE_EXHAUSTED | A key exists and authentication may already work | HTTP response after request admission | Project limits, request rate, tokens, retry behavior |
Do not solve the first row by editing application code, and do not solve the second row by repeatedly creating keys. Preserve the state transition: create first, store privately, make one small request, then diagnose the response you actually received.
For request-time capacity and Free Tier questions after the key works, use the focused Gemini API Free Tier limits guide. For a location-specific API failure, use the Gemini region availability guide. Those branches should not delay the key-creation fix.
Recovery checklist
The incident is closed only when each answer is concrete:
| Question | Passing answer |
|---|---|
| Which account is signed in? | The intended work or personal identity is recorded |
| Which project owns the key? | The exact Cloud project ID is confirmed in AI Studio |
| Can the account use AI Studio? | Workspace, region, and age gates pass |
| Can it see the project? | The intended existing project is selected or imported |
| Can it create the authorization key? | The five current operations are allowed |
| What changed before the retest? | One authorized access or IAM change is recorded |
| Where is the key stored? | A server-side secret or environment variable |
| How was it verified? | One minimal private request succeeded |
| What was shared with support? | Project context and error evidence, never the key |
If creation still fails, send the evidence packet to the owner of the failing gate. If creation succeeds but the request fails, move to the request-time branch without rewriting the history as a creation problem.
FAQ
Why can my personal Google account create a key when my work account cannot?
The accounts usually point to different identity and project boundaries. The work account may be subject to Workspace access controls, project membership, IAM, service-account operations, or organization policy. Personal-account success is a clue that the route differs; it does not identify the exact missing permission or authorize a production workaround.
What does apikeys.keys.create do?
It permits creation of an API-key resource. The current AI Studio authorization-key flow also documents project-read, service-enable, service-account-create, and API-key-binding permissions, so this one permission may not finish the full operation.
Why might API Keys Admin be insufficient?
API Keys Admin covers API-key operations, but the current AI Studio flow can also enable a service, create a service account, and bind the key to that account. Those actions belong to other permission families. Ask for the five named permissions instead of guessing a broad role.
Can clearing browser cache fix “Failed to generate API key: Permission denied”?
A clean single-account session can fix or reveal an account-selection problem. It cannot grant project IAM, enable AI Studio for Workspace, or override an organization policy. Use it once as a diagnostic, then escalate the owning boundary.
Can I create the key directly in Google Cloud Console?
AI Studio is the documented creation and management surface for Gemini API keys, and existing Cloud projects can be imported there. Cloud Console remains important for IAM, API-key restrictions, service accounts, and organization controls. If your organization mandates another credential workflow, follow its approved route rather than treating Console as a bypass.
What if the key was created but my request returns 403?
That is a request-time failure, not the creation-time error covered by the denied button. Confirm the runtime uses the new key, the key belongs to the intended project, its restriction fits the Gemini API, the endpoint and authentication shape are correct, and the requested resource is available for that route.
Should an administrator create the key and send it to me?
Prefer granting the approved developer or service identity the minimum required access and storing the key through the team's secret-management process. If an administrator must create it, they should deliver it through an approved secret channel—not email, chat, screenshots, or tickets—and keep ownership and rotation documented.
What should I send Google or my administrator if creation still fails?
Send the project ID, signed-in account, exact error, timestamp, attempted action, project-visibility state, and the result of one clean-session retest. Never include a key, access token, cookie, or other credential.
Will standard Gemini API keys keep working?
Google currently says the Gemini API will reject standard API keys starting in September 2026. Newly created AI Studio keys use the authorization-key path backed by a service account. Recheck the official API-key guide before the cutoff because lifecycle dates and migration instructions can change.
