Your Google Maps API Key Can Now Drain Your Bank Account

In February 2026, a developer posted on Reddit that their Google Cloud API key had been compromised, racking up $82,314 in Gemini AI charges in 48 hours against a normal monthly spend of $180. They were facing bankruptcy.

The post went viral. But the real story isn’t about one stolen key — it’s about a silent change Google made to how API keys work, one that turned millions of previously harmless keys into potential financial liabilities overnight.

🚨 Google told devs: API keys aren’t secrets. Gemini changed that.

😱 We found ~3,000 public keys silently authenticating to Gemini - exposing private files, cached data & charging for LLM usage

💥Even Google’s own keys were vulnerable.

🔗 https://t.co/UYRE9uCozc pic.twitter.com/PYQrwn2oe9

— Truffle Security (@trufflesec) February 25, 2026

What Changed

For over a decade, Google told developers that API keys are not secrets. Their documentation explicitly said so. The reasoning was sound: API keys for services like Google Maps were designed to be embedded in client-side JavaScript, shipped in mobile apps, and checked into public repositories. They identified your project for quota and billing purposes, but they couldn’t access sensitive data or perform privileged operations.

Then Google launched Gemini and changed the rules.

Google Cloud uses a single API key format — strings starting with AIza — for all services. The same key that authenticates a Maps JavaScript request can authenticate a Gemini API call. The only thing that controls which APIs a key can access is its API target restrictions — and many keys, created when restrictions weren’t necessary, have none.

The Gemini API (generativelanguage.googleapis.com) can be enabled on any GCP project. Once enabled, every unrestricted API key in that project can call it. If your Maps key is unrestricted and Gemini is enabled on the same project, anyone with that key can run Gemini queries and bill them to your account.

Why This Is Dangerous

The Gemini API is expensive at scale. A compromised key can generate thousands of dollars in charges per hour. Unlike Maps API abuse, which is rate-limited and relatively cheap per request, LLM inference is compute-intensive and priced accordingly.

The $82,000 Reddit incident isn’t an outlier — it’s the predictable consequence of making a billable AI service accessible through keys that were designed to be public. The attacker doesn’t need to steal credentials from a server. They just need to find one of the thousands of API keys already sitting in public GitHub repos, client-side JavaScript bundles, or decompiled mobile apps.

Google has since responded by defaulting new AI Studio keys to Gemini-only access and blocking leaked keys discovered being used with the Gemini API. But the fundamental issue remains: existing keys created before this change have no restrictions, and Google can’t retroactively restrict them without breaking legitimate integrations.

How to Check If You’re Exposed

The risk depends on two factors: whether the Gemini API is enabled on your GCP project, and whether your API keys have API target restrictions. You can check both with the gcloud CLI.

Manual Check for a Single Project

List all API keys and their restrictions:

gcloud services api-keys list --project=YOUR_PROJECT_ID

Get details for a specific key — look for restrictions.apiTargets :

gcloud services api-keys describe KEY_ID --project=YOUR_PROJECT_ID

Check if Gemini is enabled:

gcloud services list --enabled --project=YOUR_PROJECT_ID \
| grep -i generativelanguage

If the key has no apiTargets and Gemini is enabled, that key can call Gemini.

Automated Audit Across All Projects

If you manage more than a handful of GCP projects, checking them one by one isn’t practical. I wrote a script that scans every project in your account, checks both API target restrictions and application restrictions (IP, referrer, Android/iOS), and classifies each unrestricted key by risk level:

• CRITICAL — Key can call Gemini AND is publicly accessible (no restrictions, or client-side restrictions like referrer/Android/iOS which are easily bypassed)

• HIGH — Key can call Gemini but is IP-restricted (server key — lower risk since only authorized IPs can use it)

• MEDIUM — Key has no API restrictions but Gemini isn’t enabled on the project yet (one click away from risk)

The script opens with a clear verdict — YOU ARE AT RISK, NOT AT RISK TODAY, or YOU ARE NOT AT RISK — so you know immediately whether you need to act. It checks projects in parallel (20 at a time by default) and includes the gcloud command to fix each flagged key.

Grab it from the gist and run it:

curl -sL https://gist.githubusercontent.com/laurentgoudet/8cd3956be4c594bd9f88c9a16dc2f46b/raw/check_gemini_exposure.sh -o check_gemini_exposure.sh
chmod +x check_gemini_exposure.sh

# Scan all projects
./check_gemini_exposure.sh

# Scan only specific projects
./check_gemini_exposure.sh "freelancer|escrow"

# Increase parallelism
MAX_PARALLEL=40 ./check_gemini_exposure.sh

You need the gcloud CLI authenticated and python3 available. The script automatically detects whether stdout is a terminal and disables color codes when piped to a file.

The full script is available as a

.

How to Fix It

Once you’ve identified exposed keys, there are two complementary fixes.

Restrict API Keys to Specific Services

Every API key should be restricted to only the APIs it actually needs. A Maps key should only be able to call Maps APIs:

gcloud services api-keys update KEY_ID \
--project=YOUR_PROJECT_ID \
--api-target=service=maps-backend.googleapis.com \
--api-target=service=geocoding-backend.googleapis.com \
--api-target=service=places-backend.googleapis.com

This is the correct long-term fix. Even if Gemini isn’t enabled today, restricting keys protects you against any future API that Google adds to the platform.

Disable the Gemini API

If no one in your organization is using Gemini through a particular project, disable it:

gcloud services disable generativelanguage.googleapis.com \
--project=YOUR_PROJECT_ID

This removes the immediate risk but doesn’t address the underlying problem of unrestricted keys. Do both.

Set Billing Alerts and Budget Caps

Billing alerts notify you when spending exceeds a threshold, but they don’t stop charges. Budget caps can actually halt API usage. For any project with API keys exposed to the internet — which includes every project with a Maps key in client-side code — configure both.

The Bigger Problem

Google’s response — defaulting new keys to Gemini-only access and blocking discovered leaked keys — addresses the symptoms. The root cause is a design decision made years ago: using a single credential format for both “public identifier” and “sensitive authentication token” use cases.

When Google Maps API keys were introduced, treating them as non-secret was reasonable. They identified a project for billing and could be scoped by HTTP referrer or IP address. The security model assumed these keys would only ever access low-sensitivity, rate-limited, cheap-per-request APIs.

That assumption broke the moment the same key format gained access to Gemini — a service where a single compromised key can generate tens of thousands of dollars in charges in hours. Google essentially changed the threat model for every existing API key without notifying the key owners.

If you manage GCP projects, run the audit. The five minutes it takes to restrict your keys is considerably cheaper than an $82,000 surprise.