# Google API keys and Gemini: how embeddable keys got exposed

URL: https://infro.io/blog/google-api-keys-gemini-exposure
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> Google API keys (the AIza… format) were designed to be embedded in client code for services like Maps. In February 2026 Truffle Security showed that enabling the Generative Language (Gemini) API on a project let existing unrestricted keys in that project call Gemini, and found 2,863 live keys exposed on the public web that could. Google's documentation now says the Gemini API rejects unrestricted standard keys and blocks long-dormant ones. Still: restrict every key to the APIs and callers it needs, keep Gemini in its own project, disable unused APIs, and prefer service accounts or Vertex AI with IAM.

Key takeaways:
- A standard Google API key identifies a project, not a caller; it can call any enabled API that accepts keys unless it is restricted.
- Truffle Security showed in February 2026 that enabling Gemini on a project let existing embeddable keys call Gemini, and found 2,863 live keys on the public web that could.
- Google's Gemini key page now says the Gemini API rejects unrestricted standard keys and, since 7 May 2026, blocks long-dormant unrestricted keys; restricted keys that include Gemini still work.
- Restrict every key by API and by application, keep Gemini in its own project, and disable APIs you do not use.
- Budgets in Google Cloud alert but do not stop spend; Gemini project spend caps are experimental and can overshoot.

**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 Gemini[1].

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 Gemini[1].

| 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 do[1].

## 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 it[1]:

- **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 charges[3]. 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 identity[4]. 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 restrictions[2].

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

```bash
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 public[1].

### 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=SERVICE` replaces 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 apps[4]; [AI API keys in frontend and mobile apps](https://infro.io/blog/ai-api-keys-frontend-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 API[4]. Google Cloud cautions against auth keys in production for APIs that create or manage Google Cloud resources[2], 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 possible[6] |
| Gemini billing-account tier cap | Pauses Gemini for all linked projects at the tier limit | Account-wide, not a per-key limit[6] |

## 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 console[4]. Two additions:

- **Deleting is not instantly final.** A deleted key can be undeleted within 30 days[2]. 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](https://infro.io/blog/ai-api-key-theft-bill-refund) 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 protection[8]. 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](https://infro.io/docs/providers)), 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](https://infro.io/docs/org/spend-controls) 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.

## Questions

### Can a Google Maps API key call Gemini?

It could. Truffle Security showed that enabling the Generative Language API on a project let existing unrestricted keys in that project call Gemini. Google's Gemini key documentation now says the Gemini API rejects unrestricted standard keys, but a key whose API restrictions include the Generative Language API still works, so check each key's restrictions.

### Are Google API keys secret?

Some were designed not to be: Google documented that keys for services like Maps could be embedded in client code. A standard key identifies a project for billing and quota, not a caller, so whatever APIs it is allowed to call, anyone holding it can call. Treat any key that can reach Gemini as a secret.

### How do I restrict a Google API key?

Add API restrictions (the services the key may call) and one application restriction (websites, IP addresses, Android apps or iOS apps). Google says unrestricted API keys are insecure and recommends both. With gcloud, use gcloud services api-keys update with --api-target and, for example, --allowed-referrers or --allowed-ips.

### What should I do if my Gemini API key leaked?

Google's checklist: create a replacement key, deploy it, disable the leaked key once the new one works, and audit billing and API usage in the Cloud console. If the usage is not yours, report it to Cloud Customer Care; Google says it reviews billing adjustments case by case.

## Sources

1. Google API Keys Weren't Secrets. But then Gemini Changed the Rules. — Truffle Security. https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules (accessed 2026-10-21)
2. Manage API keys — Google Cloud. https://docs.cloud.google.com/docs/authentication/api-keys (accessed 2026-10-21)
3. Dev says Google warned him about account hijack – then charged him $11,000 anyway — The Register. https://www.theregister.com/a/5266234 (accessed 2026-10-21)
4. Using Gemini API keys — Google AI for Developers. https://ai.google.dev/gemini-api/docs/api-key (accessed 2026-10-21)
5. Create, edit, or delete budgets and budget alerts — Google Cloud. https://docs.cloud.google.com/billing/docs/how-to/budgets (accessed 2026-10-21)
6. Billing (Gemini API) — Google AI for Developers. https://ai.google.dev/gemini-api/docs/billing (accessed 2026-10-21)
7. Resolve Cloud Billing issues — Google Cloud. https://docs.cloud.google.com/billing/docs/how-to/resolve-issues (accessed 2026-10-21)
8. Supported secret scanning patterns — GitHub. https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns (accessed 2026-10-21)