TL;DR
- Generating content with Gemini API using misconfigured API keys is all the rage. Read on before it's your turn.
- We're releasing a free open source scanning tool to help identify problematic API keys, check it out here: https://github.com/doitintl/gcp-apikey-check
What's happening
Here at DoiT, we see a lot when it comes to the cloud. Lately reports keep surfacing from the community about unwanted billing surprises with Gemini. The user may or may not be using Gemini in their applications but they wake up to huge bill from content generation, much of the time image or video contnent which drives up bills faster than billing alerts can get out to you. If you're using Google API keys anywhere, read on, your keys may be at risk.
How It Happens
Google Cloud, like all other cloud providers, works on a system of shared responsibility -- Google is responsible for the underlying infrastructure, users are responsible for securing their use of that infrastructure. Google uses a single API key format (AIza...) for two very different purposes: public project identifiers and sensitive authentication credentials.
Google Maps and Firebase API key issues have been problematic for awhile as when generating API keys, the default was to have no restrictions on the API -- it was up to the developer to scope APIs and restrict the APIs to specific web sites, IP addresses or SDKs; this didn't always happen. For Google Maps and Firebase API keys, these keys are often found in the frontend client code so they're not particularly private and really used more as billing identifiers.
Problems started once the Gemini API was enabled in the same project with an unrestricted Maps or Firebase API key. Once a malcicious actors found these keys, they quickly learned to exploit them.
When the Gemini API gets enabled on a Google Cloud project, every existing API key that is not scoped to specific APIs in that project can silently gain access to Gemini endpoints. No warning. No email. No confirmation. A Maps key you embedded in your website years ago may now be a live Gemini credential sitting in your page source for anyone to find.
Another vector for key leakage is accidentally committing API keys or static Service Account keys to public GitHub repos. In times past, these would be quickly picked up by bad actors and used to spin up crypto mining, however, Google has gotten better at detecting this sort of fraud.
What an Attacker Does With It
The attack is trivial. A malicious actor views your page source, copies the AIza... key, and calls the Gemini image generation API. That's it. No access to your infrastructure, no credentials to steal, no sophisticated exploit. Just your key and one HTTP request — repeated many times in quick succession, all billed to your account.
Are You Exposed?
Can you answer these questions:
- Are the Generative Language API or Gemini Agent Platform APIs (formerly Vertex AI) enabled in any of your GCP projects?
- Do any API keys have no API restriction or no application restriction?
- Are Maps or Firebase keys on the same key as AI APIs?
- Do you have Service Account keys that are old, unused, or holding owner or editor roles?
If you have more than a handful of projects, checking this manually across your organization is not realistic.
Scan Your Organization in Minutes
At DoiT, we work with Google Cloud customers every day. We built gcp-apikey-check to give the broader community the same visibility our customers get — free and open source.
git clone https://github.com/doitintl/gcp-apikey-checkcd gcp-apikey-checkuv sync
# Scan an entire organizationuv run gcpkeyscan.py --org-id YOUR_ORG_ID
# Or scan a single projectuv run gcpkeyscan.py --project-id YOUR_PROJECT_IDThe tool checks API keys for the exact misconfigurations that lead to these billing spikes: unrestricted keys, Maps and AI APIs on the same key, Firebase keys without application restrictions, and broad wildcard referrer rules. It also surfaces Service Account keys that are old, unused, or carrying excessive permissions, and checks whether your organization policies allow SA key creation at all. Findings are severity-tagged (CRITICAL / HIGH / MED) and output to JSON and CSV so you can act on them immediately.
Fix It — and Rethink Whether You Need Keys at All
The most important thing to understand: the best API key is no API key.
Google's own best practice guidance is clear; avoid API keys and Service Account keys wherever possible. API keys have no identity, no expiry by default, and no fine-grained audit trail. For backend services and GCP workloads, there is almost always a better option:
- Use Workload Identity Federation instead of Service Account keys for server-to-server authentication
- Use Application Default Credentials with IAM roles for workloads running on GCP
- Call Gemini server-side with proper IAM — never expose a key in client-side code
If you must use API keys — for Maps embeds, Firebase client SDKs, or other legitimate client-side use cases — restrict them properly:
- Restrict each key to the specific APIs it needs
- Add application restrictions: HTTP referrer for web, bundle ID for mobile, IP range for server
- Never put Maps or Firebase keys on the same key as Gemini or any other AI API
- Disable APIs you are not actively using
- Set billing alerts so a spike does not go unnoticed for days
For Service Account keys you cannot eliminate yet: rotate anything older than 90 days, remove owner and editor roles, and delete keys that have not been used recently.
Fortunately, Google has made making new API keys by default more restricted; you can no longer create an unresticted key. Google AI Studio also creates new API keys that are restricted to Gemini API only. This doesn't resolve all problems, but saner defaults helps.
Don't Wait for the Bill
Google is moving to make stronger defaults, but how soon and if the changes will help protect keys already deployed in your projects is still a question. The developers posting about surprise charges did not know they were exposed until it was too late.
Run the scan today. Find what you have. Fix the worst offenders, then work toward eliminating keys entirely where you can.