Google API Keys Exposure 2026: How Enabling Gemini Turned Public Maps and Firebase Keys into Secrets

On 25 February 2026, Truffle Security published research showing that Google API keys that developers had embedded in websites and apps for years, often because Google's own documentation told them to, could quietly become credentials for Google's Gemini AI. When the Generative Language API (the Gemini API) was enabled on a Google Cloud project, existing unrestricted keys in that project gained access to it, with no warning to the owner. Scanning the November 2025 Common Crawl, the researchers found 2,863 live keys that worked this way, belonging to financial institutions, security companies, recruiting firms and Google itself. Anyone who copied such a key from a page's source could read files and cached content uploaded to Gemini and run up AI usage charges on the owner's bill. The identity lesson is simple: an API key is a non-human credential whose power depends on what its project can do, and that can change long after the key was published.

At a glance

What happened

For years, Google treated many of its API keys as project identifiers rather than secrets. Truffle Security points out that "Firebase's own security checklist states that API keys are not secrets" and that "Google's Maps JavaScript documentation instructs developers to paste their key directly into HTML." Developers did exactly that, and millions of pages and apps carry keys beginning with AIza.

The problem is that Google uses the same key format for public identification and for sensitive authentication, and that a key's reach depends on which APIs are enabled on its Google Cloud project. According to Truffle, when you enable the Gemini API on a project, "existing API keys can silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification." New keys were also created as "Unrestricted" by default, meaning they worked with every enabled API. Truffle calls this a retroactive privilege expansion: a key published safely in 2023 could become a Gemini credential in 2025 because someone else in the organisation switched on a new service.

To measure the scale, Truffle scanned the November 2025 Common Crawl, a public web archive, and found 2,863 live Google API keys that could reach Gemini. One of them was embedded in the page source of a public-facing Google product website and, according to the researchers, had been deployed since at least February 2023, before the Gemini API existed. A request to the Gemini /models endpoint with that key returned success.

Exploitation needs no access to the victim's systems. Truffle describes an attacker who "visits your website, views the page source, and copies your AIza... key from the Maps embed", then calls the Gemini API directly. With a valid key, the researchers say, "an attacker can access uploaded files, cached data, and charge LLM-usage to your account." The relevant endpoints are /files/ for uploaded documents and datasets and /cachedContents/ for cached context. Truffle also warned of billing attacks worth "thousands of dollars in charges per day" on a single account and of quota exhaustion that could shut down a victim's legitimate Gemini services.

Google's initial response, on 25 November 2025, was that the behaviour was intended. Truffle then supplied examples of Google's own exposed keys, and on 2 December Google reclassified the report from a customer issue to a bug. It shared a remediation plan on 12 December and began restricting the reported keys. A Google spokesperson told BleepingComputer and The Register that the company had "already implemented proactive measures to detect and block leaked API keys that attempt to access the Gemini API."

Later studies showed the same pattern in mobile apps. BleepingComputer reported that Quokka found 35,000 Google API keys in a scan of 250,000 mobile apps, though that figure counts keys, not keys confirmed to reach Gemini. CloudSEK's BeVigil scanned the top 10,000 Android apps by installs and found 32 hardcoded keys with live Gemini access across 22 apps, with a combined user base of more than 500 million installs. In one case, the language app ELSA Speak, CloudSEK says user audio files were accessible through the Gemini Files API.

Timeline

How it happened: the identity attack path

1. Key issued as a public identifier. A developer creates a Google API key for Maps, Firebase or another client-side service and embeds it in a web page or mobile app, as Google's guidance allowed.
2. Unrestricted by default. The key is created without API restrictions, so it is valid for every API enabled on its Google Cloud project, now and in the future.
3. Project scope changes. Someone enables the Generative Language API on the same project, for example to experiment with Gemini. The existing public key inherits Gemini access with no notification.
4. Key harvested. An attacker collects AIza keys from page source, public web archives such as Common Crawl, code repositories or decompiled apps.
5. Key validated against Gemini. A single request to a Gemini endpoint shows whether the key works. Truffle confirmed this for 2,863 keys.
6. Data read and usage billed. The attacker lists and reads uploaded files and cached content, or sends model requests that are billed to the key owner's project until quotas are exhausted.

Impact

• Keys: 2,863 live, Gemini-capable keys in public web data according to Truffle Security; 32 keys in 22 of the top 10,000 Android apps according to CloudSEK.
• Organisations: Truffle says victims included "major financial institutions, security companies, global recruiting firms, and, notably, Google itself." It did not name the companies.
• Data: files and cached content uploaded through the Gemini API on affected projects. CloudSEK confirmed access to user audio files in ELSA Speak, an app with more than 10 million installs.
• Cost: The Register reported a developer who faced $82,314.44 in unauthorised Gemini charges over 48 hours against a normal monthly bill of about $180. The Register did not say how that key was compromised, so it is not tied to this issue, but it shows what billing abuse can cost.

What this means for NHI governance

This research is about a non-human identity whose privileges changed underneath it. The API keys did not leak in the usual sense: they were published on purpose, under guidance that said this was safe. What changed was the scope of the project they belonged to. Most secrets programmes assess risk when a credential is created or found. Here, the risk arrived later, through an unrelated decision to enable a new AI service, and nobody who owned the key was told.

Three governance gaps stand out. First, unrestricted defaults: a credential that is valid for every current and future API on a project is the opposite of least privilege. Second, one format for two jobs: when public identifiers and sensitive credentials look identical, scanners, reviewers and developers cannot tell which exposed keys matter. Third, shared projects: when Maps, Firebase and AI experiments live in the same Google Cloud project, turning on one service quietly widens the reach of every key in it.

The AI angle makes this sharper. LLM APIs hold uploaded data and are expensive to run, so an exposed key is both a data access path and a billing weapon. Google's fix, moving Gemini to service-account-backed auth keys restricted to the Gemini API by default, is a move from project-level bearer keys towards credentials tied to a specific identity. Organisations should apply the same thinking to every API key they hold, not only Google's.

Recommendations

• Find every project with Gemini enabled. Check each Google Cloud project for the Generative Language API under APIs and Services, and disable it where it is not needed.
• Restrict every API key. Apply API restrictions so each key can call only the services it was created for, and add application restrictions such as HTTP referrers or app signatures for client-side keys. The API Key Management Guide covers scoping and ownership across the key lifecycle.
• Treat exposed keys as secrets and rotate them. Search websites, JavaScript bundles, mobile apps and repositories for AIza keys, test whether they reach Gemini, and replace any that do.
• Separate public and sensitive workloads. Keep client-side keys and AI workloads in different projects so enabling a new API does not widen existing keys.
• Move Gemini to auth keys. Use Google's service-account-backed auth keys, keep them server-side and store them in a secrets manager. The LLM Provider API Key Security and LLMjacking Guide explains how stolen AI keys are abused.
• Set billing alerts and quotas. Google's own guidance recommends billing alerts; per-key quotas limit how much damage a leaked key can do in a day.
• Review scope changes as identity changes. Treat enabling a new API as a change to the permissions of every credential in that project, following the Secrets Management Guide.

Frequently asked questions

What was the Google API keys and Gemini exposure?

Truffle Security found that Google API keys embedded publicly for services such as Maps or Firebase could access the Gemini API once it was enabled on the same Google Cloud project. It found 2,863 live keys like this and published the research on 25 February 2026.

Are Google Maps and Firebase API keys secret?

Google's documentation long described them as safe to embed in client code. Truffle's research showed that an unrestricted key becomes sensitive as soon as an API such as Gemini is enabled on its project, so keys should be restricted to the services they need and treated as secrets where they are not.

How did Google fix the Gemini API key issue?

Google began blocking leaked keys, stopped accepting dormant unrestricted keys from 7 May 2026 and unrestricted standard keys from 19 June 2026, issues new Google AI Studio keys as auth keys restricted to Gemini, and plans to end standard key support for Gemini in September 2026.

Related NHI Mgmt Group resources

Google Firebase breach · iOS apps leaking secrets · AI LLM hijack breach · Secrets in a public LLM training dataset · The secret sprawl challenge

How NHI Mgmt Group can help

API keys are non-human identities whose power can grow without anyone touching them, and AI services make that growth costly. Our NHI Foundation Level Training Course helps teams inventory, scope and rotate keys and other machine credentials before an attacker finds them.

References

• Truffle Security: Google API Keys Weren't Secrets. But then Gemini Changed the Rules. (25 February 2026)
• Truffle Security: Google Fixes the Gemini API Key Privilege Escalation Issue (29 June 2026)
• BleepingComputer: Previously harmless Google API keys now expose Gemini AI data (26 February 2026, updated 28 February 2026)
• The Register: Dev stunned by $82K Gemini bill after unknown API key thief goes to town (3 March 2026)
• CloudSEK: Hardcoded Google API Keys in Top Android Apps Now Expose Gemini AI (7 April 2026)
• Cybernews: Google ends unrestricted API keys to prevent Gemini abuse (18 June 2026)
• Google AI for Developers: Using Gemini API keys (25 September 2026)
• Google AI for Developers: Troubleshooting guide, security measures for leaked keys (20 September 2026)