Your Old Google Maps Key Now Reads Your AI Chats
Here's How to Fix It.
You know that Google Maps embed on your contact page? The one with the API key you pasted in years ago and forgot about?
That key can now read everything you’ve stored in Gemini — your uploaded files, your chat history, your AI conversations.
And you probably never knew.
What Changed
For years, Google told us the same thing: API keys for Maps, YouTube embeds, and Firebase aren’t secrets. They’re just billing identifiers. Safe to put in your website’s code.
Google’s own Firebase security guide says it right now:
“API keys for Firebase services are not secret... you can safely embed them in client code.”
That was true when it was written. It stopped being true when Gemini launched.
Here’s what happened: When Google added Gemini AI to their services, they used the same API key system. Suddenly, that harmless Maps key from 2019 gained a new capability — the ability to read your Gemini data, including files you’ve uploaded and conversations you’ve stored.
Nobody warned you. Nobody sent an email. The key you embedded in your website just... changed what it could do.
How Bad Is It?
Security researchers at Truffle Security scanned the web and found 2,863 live API keys that can access someone’s Gemini data right now. These aren’t just hobby projects — they found keys from financial institutions, security companies, and even Google itself.
A separate study found 35,000 keys in Android apps.
Here’s what an attacker can do with one of those keys:
Read your Gemini files — Anything you’ve uploaded or stored
See your chat history — Cached conversations and context
Drain your credits — Make API calls on your dime (thousands per day)
Lock you out — Exhaust your quota so you can’t use the service
All from a key sitting in your website’s source code that anyone can view.
How to Check If You’re Affected
Did You Ever Embed a Google Map?
If you’ve ever copied code like this into a website:
<script src=”https://maps.googleapis.com/maps/api/js?key=AIza...”></script>That’s an exposed API key. The AIza... prefix is the giveaway.
Did You Enable Gemini on Any Google Cloud Project?
If you’ve used Gemini (Google’s AI) through a Google Cloud project — even just to try it — your old keys might now have access.
Here’s the check:
Go to console.cloud.google.com
Select each of your projects (dropdown in the top bar)
Go to APIs & Services → Enabled APIs
Look for “Generative Language API” (that’s Gemini) in the list
If you see it, that project’s API keys can access Gemini.
Are Your Keys Public?
Check where you embedded them:
Your websites — View page source, search for AIza
GitHub or other repos — Search your code
Old projects — Any site you built years ago that might still be live
If you find a key that’s public AND Gemini is enabled on that project, you’re exposed.
How to Fix It
Option 1: Rotate the Key (Recommended)
Go to APIs & Services → Credentials in Google Cloud Console
Find the exposed key
Click Create Credentials → API Key to make a new one
Copy the new key to your website/app
Delete the old key (not just disable — delete it)
When creating the new key, restrict it:
Application restrictions — Only allow your domain
API restrictions — Only allow the APIs you actually use (Maps, etc.)
Option 2: Disable Gemini Access
If you don’t need Gemini on that project:
Go to APIs & Services → Enabled APIs
Find “Generative Language API”
Click Disable
This removes Gemini access from all keys on that project.
Option 3: Restrict the Existing Key
If you can’t rotate immediately:
Go to APIs & Services → Credentials
Click on the key
Under Application restrictions, add your domain
Under API restrictions, select only the APIs you need (exclude Generative Language API)
This won’t help if the key is already scraped and cached, but it limits future exposure.
The Bigger Problem
Google called it a “privilege escalation” — security jargon for “your key can do more than it should.” Cold comfort if your data got scraped.
The real issue: Google has two different security levels using the same key format, and they never updated their documentation. The Firebase guide still says keys are safe to publish. It’s wrong now, but nobody changed it.
The disclosure timeline tells the story:
Nov 21, 2025 Researchers report to Google
Nov 25, 2025 Google: “this is intended behavior”
Dec 2025 Researchers prove Google’s own keys are exposed
Jan 13, 2026 Google acknowledges the issue
Feb 26, 2026 Public disclosure
Three months from report to disclosure. And the docs still say keys are safe to embed.
What to Watch For
If you use Gemini through Google Cloud:
Check your billing — Look for unexpected spikes in Generative Language API (that’s Gemini) usage
Review your usage — In the console, go to Billing → Reports and filter for “Generative Language”
Set up alerts — Budget alerts can warn you before costs spiral
The Fix
This isn’t your fault. You followed Google’s instructions. They just didn’t tell you when the instructions stopped being true.
Find your old API keys
Check if Gemini is enabled on those projects
Rotate any exposed keys
Restrict new keys to only what you need
And next time a provider says “this credential is safe to publish” — set a reminder to check if that’s still true in a year.
Sources:
Firebase Security Checklist (still unchanged): https://firebase.google.com/support/guides/security-checklist
Truffle Security: “Google API Keys Weren’t Secrets. But then Gemini Changed the Rules”
BleepingComputer: “Previously Harmless Google API Keys Now Expose Gemini AI Data”