Can a Google API key expose Gemini? Yes, if it is allowed to call the Generative Language API. Google API keys in the AIza… format were designed so that some of them, such as Maps keys, could sit in a web page. A standard key identifies a project, not a caller, and can call any enabled API that accepts keys unless it is restricted. In February 2026 Truffle Security showed that enabling the Gemini API on a project silently gave the existing keys in that project access to it, and found 2,863 live keys on the public web that could call Gemini1.
Google has changed its defaults since. This guide sets out what the research found, what Google's documentation says today, and the fix, which is the same whatever the defaults: restrict every key, keep Gemini in its own project, and prefer identity over keys.
Why a public key became a Gemini key
Google's own definition explains the exposure. A standard API key associates a request with a project "for billing and quota purposes"; it does not identify a principal, so IAM cannot check whether the caller is allowed to make the request. A standard key can be used with any API that accepts API keys "unless API restrictions have been added to the key"2.
For a Maps key in a web page, that was acceptable: the worst a stranger could do was load maps on your quota. Truffle's finding was that the set of APIs a key could reach was not fixed. Enabling the Generative Language API on a project gave existing keys in it access to Gemini endpoints, with no warning, and new keys defaulted to unrestricted, so they worked with every enabled API including Gemini1.
| What the key was created for | What it could do after Gemini was enabled |
|---|---|
| Load maps or another client-side API, on the project's quota | Call Gemini models billed to the project |
| Nothing secret; embedded in public JavaScript | Reach files and cached content through Gemini's /files/ and /cachedContents/ endpoints |
| Visible to every visitor | Exhaust the project's Gemini quota for its legitimate users |
The right column is Truffle's list of what an attacker with one valid key could do1.
What the research found
Truffle scanned the November 2025 Common Crawl and found 2,863 live keys vulnerable to the escalation, belonging to organizations it described as including financial institutions, security companies, recruiting firms and Google itself. Its disclosure timeline, as Truffle tells it1:
- 21 November 2025: reported through Google's vulnerability disclosure program.
- 25 November: Google initially said the behaviour was intended.
- 2 December: reclassified as a bug with upgraded severity.
- 12 December: Google shared a remediation plan, including restricting exposed keys from Gemini.
- 2 February 2026: the root-cause fix was still in progress; the 90-day window closed on 19 February.
Truffle reports that Google's published roadmap included Gemini-only defaults for new AI Studio keys, blocking of leaked keys and proactive notification, and that it had not yet seen a root-cause outcome when it published.
The cost of a key in the wrong hands is not theoretical. In July 2026 The Register reported a developer whose Google Cloud account recorded $11,089.77 over two days, mostly on Gemini image models; Google suspended the account for "abusive activity consistent with hijacked resources", attributed the root cause to a compromised Firebase service account key, and the developer said Google's billing team had refused to waive the charges3. That case was a service account key, not an embedded API key, which is the point: any credential that can reach Gemini is a billing credential.
What Google's documentation says now
Google's Gemini API key page, last updated in October 2026, describes a move from standard keys to authorization ("auth") keys, which are bound to a service account so that requests run under that account's identity4. It states:
- "The Gemini API rejects requests from unrestricted standard keys." The page gives no date for this change. Standard keys with explicit restrictions continue to work.
- Since 7 May 2026, the Gemini API blocks unrestricted keys that have been dormant for an extended period; they show a Blocked tag in AI Studio.
- Since 28 May 2026, new keys created in Google AI Studio are auth keys by default, restricted to the Gemini API.
- Auth keys get "fast-acting leaked key enforcement" for leaks Google's systems detect.
Google Cloud's general documentation adds that "Unrestricted API keys are insecure", that the console and gcloud require at least one API restriction when you create a key, and that a key created through the REST API is unrestricted unless you add restrictions2.
These changes close the original path for an unrestricted Maps key. They do not cover a key whose API restrictions include the Generative Language API alongside Maps, a Gemini key deliberately shipped in client code, or a key created through the API without restrictions. Check your keys rather than relying on the default.
The fix
1. Find every project where Gemini is enabled
gcloud services list --enabled --project="$PROJECT" | grep generativelanguage
gcloud services api-keys list --project="$PROJECT"
gcloud services api-keys describe "$KEY_ID" --project="$PROJECT"Truffle's checklist starts the same way: look for the Generative Language API under Enabled APIs & Services, then review keys that are unrestricted or explicitly allow it, oldest first, and confirm none of them are public1.
2. Restrict every key twice
Google recommends "both API restrictions and application restrictions"2:
- API restrictions list the services a key may call. A Maps key should list Maps APIs and nothing else;
gcloud services api-keys update KEY_ID --api-target=service=SERVICEreplaces the whole list, so name every service the key needs. - Application restrictions say who may use the key: websites (HTTP referrers), IP addresses, Android apps or iOS apps. A key can carry one type. A server-side Gemini key should be limited to your egress addresses with
--allowed-ips.
Keep in mind what a referrer restriction is: a header a browser sends, which a script outside a browser can set to anything. It narrows casual abuse of a key that has to be public; it does not make a powerful key safe to publish. A key that can reach Gemini should never be in client code. Google's guidance is to run a backend proxy for client apps and not to hardcode keys in web or mobile apps4; AI API keys in frontend and mobile apps covers the patterns.
3. Keep Gemini in its own project
Put Gemini traffic in a project that holds no client-side keys, and keep browser and mobile keys in projects where the Generative Language API is not enabled. A key cannot call an API its project has not enabled. Disable APIs a project no longer uses (gcloud services disable generativelanguage.googleapis.com) so that a forgotten key has less to reach.
4. Prefer identity over keys
A standard key cannot be checked by IAM; a service account can. Where you can, call Gemini through Vertex AI with a service account and IAM roles, or use auth keys bound to a service account through the Gemini API4. Google Cloud cautions against auth keys in production for APIs that create or manage Google Cloud resources2, and a service account's own key file is still a long-lived secret, as The Register's case shows. Workload identity, where the platform issues short-lived tokens, removes the file.
5. Put a ceiling on the project
Know what each billing control does before you rely on it:
| Control | What it does | Limit |
|---|---|---|
| Cloud Billing budget | Alerts at thresholds | Doesn't "automatically cap Google Cloud or Google Maps Platform usage or spending"5 |
| Budget notification that disables billing | Stops billing on the project programmatically | Stops every paid service on the project; Google warns resources "might be irretrievably deleted"3 |
| Gemini project spend cap (AI Studio) | Monthly cap per project | Experimental; billing data can lag around 10 minutes and overages are possible6 |
| Gemini billing-account tier cap | Pauses Gemini for all linked projects at the tier limit | Account-wide, not a per-key limit6 |
If a key has already leaked
Google's leak checklist: generate a replacement, deploy it, disable the compromised key once the new one is verified, and audit billing and API usage in the Cloud console4. Two additions:
- Deleting is not instantly final. A deleted key can be undeleted within 30 days2. If someone else may hold project permissions, check that nobody restores it.
- Report the usage. Google's billing documentation says to secure the account, stop resources you do not recognise, and contact Cloud Customer Care to discuss billing adjustments, which it reviews "on an individual basis"7. Stolen API key charges covers what the terms say.
GitHub's secret scanning reports Google API keys to Google as a partner pattern, but its separate Gemini API key pattern is user-alert only, and neither Google pattern is blocked by push protection8. Turn on push protection and run a scanner of your own.
How INFRO handles Google keys
INFRO runs on provider accounts you connect, including Google's. A Gemini credential you connect is sealed with AES-256-GCM and never shown again (see Connect a provider), so it does not need to live in client code or in each service. Your applications call INFRO with gateway keys that can be limited to chosen providers and IP ranges, belong to one environment, expire, and are capped by budgets checked before Google is called.
INFRO's controls govern traffic that goes through INFRO. A Google key or service account credential leaked from anywhere, including from a platform like INFRO that holds it, can be used directly against Google, and no INFRO budget or allowlist sees it. The restrictions, project separation and billing controls in this guide are the backstop, and they live in your Google Cloud project.
Summary
A Google API key is a project's billing handle, not an identity, and it can call whatever its project has enabled unless you restrict it. Gemini turned that from a quota concern into a cost and data concern. Google now rejects unrestricted standard keys on the Gemini API, but restricted keys that include Gemini still work. Restrict every key by API and by caller, keep Gemini in a project with no public keys, disable what you do not use, and move server traffic to service accounts and IAM.