26.02.2026

Google API Keys and Gemini: A Silent Privilege Escalation You Need to Know

Google API Keys Security

For over a decade, Google told developers that API keys (the AIza... format) are not secrets. They were safe to embed in client-side JavaScript, exactly as the Maps and Firebase documentation instructed. Then Gemini arrived, and everything changed.

The Problem

TruffleSecurity recently disclosed a critical finding: when you enable the Gemini API (Generative Language API) on a Google Cloud project, existing API keys in that project silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification.

This means a Maps API key you embedded in your website three years ago could now be a Gemini credential. Anyone who scrapes it can:

Access uploaded files and cached data through the Gemini API
Run up your AI billing (thousands of dollars per day)
Exhaust your quotas and disrupt legitimate services

Quick Security Check

Run this against any Google API key you find:

# Test if a key has Gemini access
curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"

# 200 OK = Key has Gemini access (vulnerable)
# 403 Forbidden = Key does not have Gemini access

Why This Is a Privilege Escalation

The sequence of events matters:

Developer creates an API key for Maps and embeds it publicly (harmless at the time)
Someone enables the Gemini API on the same GCP project
The old public key now has Gemini privileges
No one is notified of this change

The key went from a billing identifier to a sensitive credential without any developer action.

Real-World Impact

TruffleSecurity scanned the November 2025 Common Crawl dataset and found 2,863 live Google API keys vulnerable to this privilege escalation. The victims included:

Major financial institutions
Security companies
Global recruiting firms
Google itself

Yes, even Google had old public API keys that could access their internal Gemini instances.

How to Audit Your GCP Projects

Step 1: Check for the Generative Language API

For every GCP project in your organization:

# List enabled APIs
gcloud services list --enabled --project=YOUR_PROJECT_ID | grep generativelanguage

If the Generative Language API is not enabled, you are not affected.

Step 2: Audit Your API Keys

Navigate to APIs & Services > Credentials in the GCP Console. Look for:

Keys with a warning icon (unrestricted access)
Keys that list "Generative Language API" in allowed services

Step 3: Find Public Keys

Check if any Gemini-enabled keys are exposed:

Client-side JavaScript (view page source)
Public Git repositories
Build artifacts and logs
Documentation and config files

Step 4: Rotate Exposed Keys

If you find an exposed key with Gemini access, rotate it immediately:

# Rotate an API key
gcloud services api-keys update KEY_ID --clear-restrictions
gcloud services api-keys delete KEY_ID
gcloud services api-keys create --display-name="new-restricted-key"

Best Practices Going Forward

1. Separate Keys by Purpose

Never use the same API key for public (Maps) and sensitive (Gemini) services:

# Create a Maps-only key
gcloud services api-keys create \
  --display-name="maps-public" \
  --api-target=service=maps-backend.googleapis.com

# Create a Gemini-only key with restrictions
gcloud services api-keys create \
  --display-name="gemini-internal" \
  --api-target=service=generativelanguage.googleapis.com

2. Use Service Accounts for Gemini

For backend services, prefer service account authentication over API keys:

from google.oauth2 import service_account
import google.generativeai as genai

credentials = service_account.Credentials.from_service_account_file(
    'service-account.json',
    scopes=['https://www.googleapis.com/auth/generative-language']
)
genai.configure(credentials=credentials)

3. Monitor API Key Usage

Set up alerts for unexpected Gemini API calls:

# Cloud Monitoring alert policy
displayName: Unexpected Gemini Usage
conditions:
  - displayName: Gemini API calls from unknown sources
    conditionThreshold:
      filter: >
        resource.type="consumed_api"
        AND resource.labels.service="generativelanguage.googleapis.com"
      comparison: COMPARISON_GT
      thresholdValue: 100
      duration: 300s

4. Scan Your Repositories

Use TruffleHog to find leaked keys:

# Install TruffleHog
pip install trufflehog

# Scan a repository
trufflehog git https://github.com/your-org/your-repo --only-verified

Google's Response

Google acknowledged the vulnerability and committed to:

Defaulting new AI Studio keys to Gemini-only access
Blocking API keys discovered as leaked
Proactive notification when leaked keys are identified

However, they have not announced plans to retroactively notify existing users with exposed keys.

Conclusion

This is a textbook example of how security assumptions can become invalid as platforms evolve. Keys that were designed as public identifiers gained sensitive privileges without any warning.

Action items for SRE teams:

Audit all GCP projects for the Generative Language API
Review and restrict all API keys in those projects
Scan public code and websites for exposed keys
Implement separate key management for AI services
Set up monitoring for unexpected Gemini API usage

The silent privilege escalation affecting Google API keys is a reminder that security is not a one-time task. As platforms add new capabilities, your security posture must evolve with them.

At Akmatori, we are building AI agents that help SRE teams detect misconfigurations and security issues before they become incidents. If you are tired of manual audits and want proactive infrastructure monitoring, check out what we are working on.

Akmatori team