# Google API Keys Are Now Secrets: How Gemini Changed the Rules > Google API keys were never treated as secrets — until Gemini made them dangerous. Learn how a leaked key can lead to massive bills and illegal AI usage. * URL: * Author: Jean-Yves Pasquier * Published: 2026-03-12 * Tags: cloud security, secret detection, google cloud For over a decade, Google API keys have been treated as "not really secrets." Developers embed them in frontend JavaScript, commit them to public repositories, and leave them in `.env` files that end up in version control. The reasoning: **Google API keys only gate quota, not identity**, so who cares if one leaks? That assumption is now dangerously wrong. ## What Changed: Gemini Google API keys follow a well-known format: `AIzaSy` followed by 33 characters. This format is shared across **every** Google API — Maps, YouTube, Translate — and now **Gemini**. Before Gemini, the worst case was quota abuse on Maps or YouTube. Annoying, but not enough to keep anyone up at night. Now, the same `AIzaSy...` key that powers your embedded Google Map can also call the Gemini API, **if Gemini is enabled on the Google Cloud project** the key belongs to. ### The Two Risks You Need to Worry About #### 1. Billing Abuse at Scale Gemini API calls are orders of magnitude more expensive than Maps or YouTube requests. This is not theoretical: in February 2026, a three-developer startup in Mexico [was hit with an \$82,314 bill in 48 hours](https://www.theregister.com/2026/03/03/gemini_api_key_82314_dollar_charge/) after a stolen `AIza` key was used to call Gemini. Their normal monthly spend was \$180. Google cited their "shared responsibility model" and indicated the charges would stand, despite the fact that the company would face bankruptcy. #### 2. Illegal Content Generation Under Your Identity When an attacker uses your leaked key to call Gemini, every request is logged against **your** Google Cloud project and **your** billing account. If they generate illegal or regulated content — CSAM, sanctions-violating communications — the audit trail points to your organization. You did not generate that content, but your infrastructure did. And explaining that distinction to regulators or law enforcement is a conversation no CISO wants to have. These risks were surfaced publicly by [Truffle Security's research](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github), which found **2,863 live Google API keys exposed across public websites**, and it fundamentally changes how we should classify these credentials. ## The Problem: You Can't Tell From the Key All Google API keys look the same: `AIzaSy...` + 33 characters. Whether a key is restricted to Maps or has full Gemini access depends on the **API restrictions** configured in the Google Cloud Console, not the key itself. **You cannot tell by looking at it.** And here's the catch: - **API restrictions are opt-in**, not default. New keys are unrestricted, meaning they can call any API enabled on the project. - Many organizations have old, unrestricted keys created years before Gemini existed. There was simply no reason to restrict them at the time. - There is no global policy to enforce restrictions across all keys in a project. The result: keys **created for one purpose** (Maps, YouTube) **can now access Gemini**, because the API was enabled on the same project and the key was never locked down. ## What You Should Do If you use Google Cloud, treat this as a priority audit: 1. **Make an inventory all Google API keys**. Check the [Cloud Console Credentials page](https://console.cloud.google.com/apis/credentials) for every project. 2. **Check API restrictions** on each key. Anything showing "Don't restrict key" can call Gemini if the API is enabled. 3. **Apply least-privilege restrictions**. A Maps key should only access Maps APIs. 4. **Rotate exposed unrestricted keys**. If a key has ever appeared in a public repo, client-side code, or CI/CD logs, assume it is compromised. 5. **Treat any unrestricted Google API key as a critical secret.** ## How PanIAM Helps Manual audits work for a handful of projects. For organizations running dozens of AWS workloads that interact with Google services, you need automation. **PanIAM detects Google API keys in your cloud environment automatically**. Once detected, each key is placed in your **security graph** so you can trace which compute resources have access to it and assess the **blast radius** of a potential leak. This is the same graph-based approach we use for [all secret detection in PanIAM](https://blog.paniam.cloud/posts/introducing-secret-detection.md) but extended to a credential class that most tools still treat as low-risk. ## The Bottom Line The security classification of Google API keys has changed. Keys that were harmless two years ago are now potential liabilities, and they are scattered across your infrastructure in places you may not expect. **The question is not whether you have exposed Google API keys. It's whether you know where they are and what they can access.** [Get in touch](mailto:get-secure-now@paniam.cloud) and find out in minutes.