Google API Keys Were Never Meant to Be Secrets — Until Gemini Changed Everything For over a decade, Google told developers that API keys — like those used for Maps, Firebase, and other public services — were not secrets and could safely be embedded in client-side code. But with the launch of Gemini, that long-standing assumption has been shattered. A new security flaw reveals that these same keys, originally intended only for billing and project identification, now grant full access to sensitive Gemini AI endpoints — even if they were never meant to be secure. Truffle Security uncovered a critical vulnerability: when the Generative Language API (Gemini) is enabled in a Google Cloud project, every existing API key in that project — including those publicly exposed in websites, apps, and repositories — automatically gains access to Gemini’s private functions. No warnings. No confirmations. No notifications. The implications are severe. An attacker who scrapes a public-facing Google Maps key from a website can use it to access uploaded files, cached data, and even run expensive AI queries — all charged to the original project’s account. In one alarming test, researchers used an old public API key from a Google product’s website — deployed in 2023 before Gemini existed — to successfully access Gemini’s model list, proving that legacy keys were silently upgraded to powerful credentials. Truffle Security scanned the November 2025 Common Crawl dataset and found 2,863 live Google API keys exposed on the public internet that now have access to Gemini. These keys belong to major financial institutions, global recruiting firms, security companies — and even Google itself. The root of the problem lies in Google’s single API key format (AIza...) being used for two entirely different purposes: public project identifiers and sensitive authentication. While Google long encouraged developers to treat API keys as non-secret, the introduction of Gemini changed the rules without changing the defaults. New keys are created with unrestricted access by default, and old keys gain new powers retroactively when Gemini is enabled — a dangerous combination of insecure defaults and privilege escalation. Despite initial resistance from Google, which initially dismissed the issue as “intended behavior,” the report gained traction after researchers provided proof using Google’s own infrastructure. Google eventually reclassified the flaw as a Tier 1 vulnerability — “Single-Service Privilege Escalation, READ” — and began restricting exposed keys from accessing Gemini. They’ve also committed to fixing the underlying architecture, though a full solution remains pending. The takeaway for developers and organizations: if you use Google Cloud, check every project for the Generative Language API. Audit all API keys for public exposure, especially older ones. Rotate any keys that are accessible in client-side code or public repositories. Use tools like TruffleHog to scan for live, vulnerable keys. This isn’t just a Google issue — it’s a warning for the entire tech industry. As AI features are layered onto legacy systems, old assumptions about security no longer hold. What was once a harmless identifier can now be a backdoor into sensitive data. The era of treating API keys as public has ended — and the cost of ignoring this shift could be catastrophic.