You probably have Google API keys sitting in your codebase right now. Maybe they power your Maps integration. Maybe they connect to Firebase. Maybe they were set up years ago by a developer who has since left, and nobody has touched them since.
Here is the problem: security researchers just discovered that those keys, the ones you thought were scoped to a specific service, may now have silent access to Google's Gemini AI endpoints. And you almost certainly did not authorise that.
This is not a GCP issue. This affects anyone using Google APIs.
What Actually Happened?
When you create a Google API key for any Google service, Maps, Firebase, YouTube, that key lives under a Google Cloud project. Even if you have never opened the GCP console, that project exists in the background.
When the Gemini API gets enabled on a Google Cloud project, all existing keys tied to that project automatically inherit access to Gemini endpoints. No notification. No warning email. No permission prompt.
One day your Maps key has access to Maps. The next day it has access to Google's AI APIs. And you had no say in it.
Security researchers scanned publicly available data and found nearly 3,000 live Google API keys already exposed this way, affecting major financial institutions and security companies. Not small startups. Real organisations with real security teams who had no idea this was happening.
Why Your Keys Are Probably in Scope
You might be thinking: "We are not a GCP shop. This does not apply to us."
That is exactly the wrong conclusion to draw.
Every Google API key is linked to a GCP project, whether you know it or not. You are effectively a GCP user the moment you generate a key for anything Google. So ask yourself: does your team use any of these?
Google Maps
Firebase
Google Analytics API
YouTube Data API
Any other Google service with an API key
If yes, you are in scope. Full stop. The highest-risk keys are the ones sitting in your frontend JavaScript or mobile app bundles. An attacker does not need to breach anything. They just need to look.
What Can an Attacker Do With Your Key?
For starters, they can run queries against Gemini at your expense. AI API calls are not free, and you will foot the bill. They can also access data processed through your GCP project, which could expose sensitive information you had no intention of making accessible. Beyond that, a key with broader-than-intended permissions is a useful foothold for exploring what else they can reach in your environment. And if your keys get abused at scale, expect rate limits, account flags, or outright suspension of your Google services.
What You Need to Do Right Now
Check if Gemini is enabled on your projects
Log into the Google Cloud Console under APIs and Services. If the Generative Language API is enabled on any project and you did not deliberately turn it on, that is your first problem to fix.
Rotate keys that have been sitting unchanged
Especially any keys that live in frontend code or were ever committed to a repository. Assume they have been seen by someone you do not know.
Scope your keys properly
A Maps key has no business touching AI endpoints. Apply API restrictions and referring site or IP restrictions in your key settings.
Search your codebase and repos
Check config files, frontend JavaScript, environment files, and mobile bundles. If you find a key that should not be there, revoke it, rotate it, and find out how long it has been exposed.