tl;dr: Following our February disclosure that public Google API keys could silently gain access to the Gemini API, Google is replacing standard API keys with new service-account-backed "auth keys." Gemini now rejects unrestricted API keys and by September 2026 will reject standard API keys entirely. The change fixes the core issue we identified: public keys intended for services like Maps or Firebase could unexpectedly become AI credentials, exposing organizations to data access, quota abuse, and unauthorized billing.
When we published our research in February, we documented a fundamental flaw in Google's API key architecture. Nearly 3,000 Google API keys - many deployed years earlier for benign services like Google Map - had silently gained access to the Gemini API, exposing organizations to data leakage, quota exhaustion, and unauthorized billing. Google was using a single credential type for two fundamentally different purposes: public project identification and sensitive authentication.
In the months between our disclosure and this fix, we heard directly from developers who faced real consequences. Reports piled up of unexpectedly large bills with no warning until the charges arrived: like one developer in our community slack saying an attacker racked up a 1 million dollar bill:
Or this canadian small business owner who emailed us saying the received a 10,000 dollar bill:
Or on public reddit where this developer was hit with $82,000 in charges within 48 hours of their Gemini API key being stolen. The attacks required no sophistication: just scraping a key from a public webpage and calling the Gemini API.
Source: Reddit
Four months later, Google has announced the architectural change we had highlighted in our previous post. Starting June 19, 2026, the Gemini API began rejecting requests from unrestricted standard API keys. By September 2026, Google plans to remove support for standard API keys entirely in favor of a new credential type called "auth keys,” service-account-backed credentials restricted to the Gemini API by default, with fast-acting leaked key enforcement built in. All new keys created in Google AI Studio are automatically auth keys.
This addresses the core issue. A standard API key originally created for Maps or Firebase can no longer silently become a Gemini credential simply because someone enables an additional API in the same project. Google also made earlier changes leading up to this, including blocking dormant keys starting May 7 and requiring at least one API restriction when creating a new key in the Cloud Console.
What you still need to do
Google's changes in September will protect you going forward, until then it is important to audit exposure now. Here's what you can do:
Check every GCP project for the Generative Language API under APIs & Services > Enabled APIs & Services. If it's not enabled, you're not affected.
Audit your credentials. Look for unrestricted API keys or keys that explicitly allow the Generative Language API. Rotate anything exposed immediately.
Migrate to auth keys. Create them through AI Studio or Google Cloud Console and update your integrations. Don't wait for September.
Scan your codebase for keys embedded in frontend code, repositories, or CI/CD pipelines:
trufflehog filesystem /path/to/your/code --only-verified
The broader lesson applies beyond Google: when AI capabilities are layered onto existing platforms, legacy credentials can quietly inherit permissions their owners never intended. For more information on Google Cloud’s changes to prevent “unauthorized use of keys that might be shared publicly or linked to other services,” check out their updated documentation.
