Google API Keys and Gemini: Audit Your Exposure with gcloud

For over a decade, Google explicitly told developers to embed their API keys directly in client-side JavaScript. The Firebase documentation still states that API keys are not secrets. The Google Maps documentation instructs developers to paste the key into the page HTML. That advice was correct — until Gemini arrived.

What Changed with the Gemini API

Google Cloud uses a single key format (AIza...) for two fundamentally different purposes: public project identification and authentication to sensitive services. For years, these keys served only to identify a project for billing and to call public APIs like Maps or YouTube. They were not authentication credentials in the strict sense.

When you enable the Gemini API (Generative Language API) in a Google Cloud project, all existing API keys in that project silently inherit access to Gemini endpoints. No warning. No email notification. No confirmation dialog. A key created three years ago to display a map on your website can now query Gemini, access files uploaded to your project, and generate usage charges.

This is a retroactive privilege escalation. The key did not change. Your website code did not change. But its permissions changed — without your knowledge.

The Scale of the Problem

Security researchers analyzed the November 2025 Common Crawl archive, a snapshot of hundreds of terabytes of public web pages. They identified 2,863 active Google API keys vulnerable to this privilege escalation. Affected organizations included financial institutions, international recruiting firms, and Google itself. Some of Google’s own keys had been publicly deployed since at least February 2023, well before the Gemini API existed.

The problem is not limited to already-exposed keys. By default, any new key created in the Google Cloud console is “unrestricted,” meaning it grants access to all APIs enabled in the project — including Gemini if it is enabled. A developer who creates a key for a Maps widget unknowingly generates a credential capable of AI calls.

What an Attacker Can Do

The attack is straightforward. An attacker visits your site, inspects the page source, copies the AIza... key from the Google Maps embed, then runs:

curl "https://generativelanguage.googleapis.com/v1beta/models?key=AIzaSy..."

If the response is a 200 OK with a list of available models rather than a 403 Forbidden, the key has Gemini access. The attacker can then read files uploaded to your project via the /files/ endpoint, access cached content via /cachedContents/, and generate AI calls billed to your account. They never touched your infrastructure.

Auditing Your Exposure with gcloud

The good news: the audit is fast with the gcloud CLI. Here is the complete procedure.

Step 1: List your projects

gcloud projects list --format="value(projectId)"

This command lists all Google Cloud projects your account can access. Note the project IDs — you will need them in the following steps.

Step 2: Check whether the Gemini API is enabled

For each project, check whether the Generative Language API is enabled:

gcloud services list --enabled \
  --project=MY_PROJECT \
  --filter="name:generativelanguage.googleapis.com"

If the command returns nothing, your project is not affected by this vulnerability. If it returns generativelanguage.googleapis.com, proceed to the next step.

Step 3: Inspect the project’s API keys

List all API keys in the project:

gcloud services api-keys list --project=MY_PROJECT

For each key, examine its restrictions:

gcloud services api-keys describe \
  projects/PROJECT_NUMBER/locations/global/keys/KEY_ID \
  --project=MY_PROJECT

Look for the restrictions field in the response. A key with no restrictions (restrictions: {}) or with generativelanguage.googleapis.com in its allowed API list can access Gemini.

Multi-project audit script

If you manage several projects, this script automates the full audit:

#!/bin/bash
echo "=== Google Cloud API Keys / Gemini Audit ==="
for project in $(gcloud projects list --format="value(projectId)"); do
  result=$(gcloud services list --enabled --project="$project" \
    --filter="name:generativelanguage.googleapis.com" \
    --format="value(name)" 2>/dev/null)
  if [ -n "$result" ]; then
    echo ""
    echo "⚠️  Exposed project: $project"
    echo "   API keys present:"
    gcloud services api-keys list --project="$project" \
      --format="table(displayName,uid,createTime)" 2>/dev/null
  fi
done
echo ""
echo "=== Audit complete ==="

This script identifies all projects where the Gemini API is enabled and lists the associated keys. For each key listed, check whether it appears in public code — Git repositories, client-side JavaScript, or documentation.

API Keys vs. Service Accounts: Do Not Confuse Them

An important clarification: AIza... API keys are different from Service Account JSON files. Service Account JSON files are authentication credentials for server-side applications — they have always been treated as secrets. API keys were historically designed to be public in certain contexts. That distinction is what the arrival of Gemini made obsolete for projects where the API is enabled.

What to Do If You Are Exposed

If you find an unrestricted key in a project where Gemini is enabled, and that key appears in public code, act immediately. Revoke the key from the Google Cloud console (APIs & Services > Credentials) and create a new one. When creating the new key, explicitly restrict it to only the APIs it needs — Maps JavaScript API only for a map widget, for example.

Then review Cloud Audit Logs to detect any unauthorized calls to the Gemini API. If you find suspicious calls, submit a billing support case to Google Cloud to dispute the charges.

For new keys, apply the principle of least privilege consistently: one key per use case, with explicit API restrictions and HTTP referrer restrictions.

What Google Is Doing

Google has taken several corrective actions. Keys identified as publicly exposed are now blocked from accessing the Gemini API, and their owners are notified. New keys created through Google AI Studio will default to Gemini-only access, preventing unintended cross-service usage. Google is also working toward proactively notifying owners of exposed keys.

These measures are useful, but they do not cover exposed keys that Google has not yet detected. A manual audit remains the only way to have full visibility into your exposure.

If you use Google Cloud and have never audited your API keys, now is the right time. The procedure takes less than ten minutes. Contact us if you want support securing your Google Cloud projects.

Sources

1. Truffle Security Co., Google API Keys Weren’t Secrets. But then Gemini Changed the Rules. trufflesecurity.com (February 25, 2026)
2. Google, Getting information about API keys, API Keys API Documentation. docs.cloud.google.com
3. Google, Blocked or non-working API keys, Gemini API Troubleshooting. ai.google.dev
4. Firebase, Security Checklist — API keys are not secret. firebase.google.com