✨ From vibe coding to vibe deployment. UBOS MCP turns ideas into infra with one message.

Learn more
Andrii Bidochko
  • Updated: February 26, 2026
  • 6 min read

Google Maps API Keys Exposed: Gemini AI Turns Public Keys into Privileged Credentials

Public Google Maps API keys become a severe security risk when Gemini is enabled because the same key can be used to call private Gemini endpoints, leading to privilege escalation, data leakage, and unexpected billing.

Google Maps API Keys Exposed: Why Gemini Turns a Public Key Into a Critical Vulnerability

Google API key illustration

On 26 February 2026, security researcher Simon Willison highlighted a new attack surface: thousands of Google Maps API keys that were originally intended to be public are now capable of accessing Gemini, Google’s generative‑AI service. The discovery shows how a seemingly harmless public key can silently become a secret credential, exposing organizations to a classic privilege escalation scenario.

Why Google Maps API keys are public by design

Google Maps is embedded in millions of websites, mobile apps, and dashboards. To render a map, the client‑side JavaScript must include an API key in the request URL. Google’s documentation explicitly states that these keys are “public identifiers” and can be safely exposed in HTML or JavaScript because they are scoped only to the Maps service.

Key characteristics of a typical Google Maps API key:

  • Limited to map rendering, geocoding, and place‑search endpoints.
  • Often restricted by HTTP referrer or IP address to mitigate abuse.
  • Never intended to grant access to billing‑sensitive or data‑sensitive services.

Because the key is embedded in the page source, search engines, crawlers, and even casual users can view it. Historically, this exposure was harmless—Google’s Maps service simply returned map tiles and did not expose any private data.

Gemini flips the script: a single key, two very different services

When a Google Cloud project enables the Gemini API, the same API key that was created for Maps automatically inherits the permissions of the Gemini service. Gemini is a generative‑AI platform that can:

  • Run large language models (LLMs) on private data.
  • Generate billable inference calls.
  • Access files stored in Google Cloud Storage when granted the appropriate IAM role.

The key transition is silent. Developers who originally generated a Maps key receive no warning that enabling Gemini on the same project retroactively expands the key’s scope. Consequently, a key that was safe to publish now becomes a secret credential capable of invoking private AI models and incurring costs.

How many keys are we talking about?

Security firm Truffle Security scanned the November 2025 Common Crawl dataset and identified 2,863 distinct API keys that could successfully call the Gemini /models endpoint. The breakdown is striking:

Category Count
Keys found in public web pages 2,412
Keys belonging to Google-owned projects 31
Keys with no referrer restrictions 420

One of the Google‑owned keys had been in production since February 2023—well before Gemini existed—demonstrating how legacy keys can be unintentionally upgraded to privileged credentials.

What can an attacker do with a compromised Maps‑Gemini key?

The risk vector expands dramatically once Gemini is enabled:

  1. Privilege escalation: A key that was only allowed to fetch map tiles can now invoke Gemini models, read private data, and execute code in the context of the project.
  2. Unexpected billing: Each Gemini inference call is billable. An attacker can generate thousands of requests, inflating the cloud bill by thousands of dollars within minutes.
  3. Data exfiltration: If the project has IAM roles that grant access to Cloud Storage or BigQuery, Gemini can be prompted to read and return that data.
  4. Service disruption: Malicious prompts can cause runaway token usage, leading to quota exhaustion and denial‑of‑service for legitimate users.

Because the key is publicly visible, automated bots can harvest it at scale, making the attack both low‑effort and high‑impact.

Immediate steps for developers and security teams

Mitigating this exposure requires a disciplined, multi‑layered approach. Below is a MECE‑structured checklist you can run today:

1️⃣ Inventory & Audit

  • Export all API keys from the Google Cloud Console (IAM → API keys).
  • Cross‑reference each key with your code repositories and CI/CD pipelines.
  • Identify keys that are embedded in public assets (HTML, JavaScript, mobile binaries).

2️⃣ Rotate & Replace

  • Generate new, restricted keys for Maps‑only usage.
  • Immediately revoke any key that has Gemini permissions and is publicly exposed.
  • Update your front‑end code to reference the new keys and redeploy.

3️⃣ Apply Service‑Specific Restrictions

  • Use HTTP referrer or IP address restrictions for Maps keys.
  • For Gemini, enforce OAuth 2.0 or service‑account authentication instead of API keys.
  • Enable quota limits on Gemini to prevent runaway billing.

4️⃣ Continuous Monitoring

  • Set up Cloud Logging alerts for any Gemini API call originating from a Maps‑only key.
  • Leverage Google Cloud’s “API Key Usage” dashboard to spot anomalies.
  • Integrate with a SIEM solution to correlate usage spikes with other security events.

5️⃣ Educate & Document

  • Update internal documentation to clarify that enabling Gemini on a project automatically expands key privileges.
  • Train developers on the principle of “least privilege” for API keys.
  • Publish a run‑book for rapid key rotation in case of future exposures.

Leveraging UBOS to harden your API‑key lifecycle

UBOS offers a suite of tools that simplify the entire remediation workflow—from discovery to enforcement.

By integrating these capabilities, you can turn a reactive “rotate‑and‑pray” approach into a proactive, continuously monitored security posture.

Take action now

Don’t wait for Google to revoke your keys—act today:

Conclusion

The convergence of public Google Maps API keys and the newly enabled Gemini service illustrates a classic security paradox: a feature designed for convenience can become a vector for massive compromise when the underlying permission model changes. By conducting a thorough inventory, rotating exposed keys, applying strict service‑specific restrictions, and leveraging automated platforms like UBOS, organizations can neutralize this threat and safeguard both their data and their cloud spend.

Stay vigilant, keep your API keys under continuous review, and remember that today’s “public” key could be tomorrow’s “privileged” credential.


Andrii Bidochko

CTO UBOS

Andrii Bidochko is an AI entrepreneur and researcher focused on AI agents, reinforcement learning, and autonomous systems. He writes about the technologies shaping the future of machine intelligence, from frontier models and agent architectures to real-world AI applications.

Sign up for our newsletter

Stay up to date with the roadmap progress, announcements and exclusive discounts feel free to sign up with your email.

Sign In

Register

Reset Password

Please enter your username or email address, you will receive a link to create a new password via email.