Google Maps/Cloud API (Application Programming Interface) keys that used to be safe to publish can now, in many cases, be used as real Gemini AI credentials. This means that any key sitting in public JavaScript or application code may now let attackers connect to Gemini through its API, access data, or run up someone else’s bill.

Researchers found around 2,800 live Google API keys in public code that can authenticate to Gemini, including keys belonging to major financial, security, recruiting firms, and even Google itself.

Historically, Google Cloud API keys for services like Maps, YouTube embeds, Firebase, etc., were treated as non‑secret billing identifiers, and Google’s own guidance allowed embedding them in client‑side code.

If we compare this issue to reusing your password across different sites and platforms, we see that using a single identifier can become a skeleton key to more valuable assets than users or developers ever intended. 

The key difference is where responsibility sits. With password reuse, end users are explicitly warned. Every service tells them to pick unique passwords, and the security community has hammered this message for years. If the same password is reused across three sites and one breach compromises all of them, the risk comes from a user decision, even if convenience drove that decision.

With Google API keys, developers and security teams were following Google’s own historical guidance that these keys were just billing identifiers safe for client‑side exposure. When Gemini was turned on, those old API keys suddenly worked as real authentication credentials.

From an attacker’s perspective, password reuse means you can take one credential stolen from a weak site and replay it against email, banking, or cloud accounts using credential stuffing. The Gemini change means a key originally scoped in everyone’s mental model as “just for Maps” now works against an AI endpoint that may be wired into documents, calendars, or other sensitive workflows. It can also be abused to burn through someone’s cloud budget at scale.

How to stay safe

The difference with this instance of what is effectively password reuse is that this time it’s been effectively baked in by design rather than chosen by users.

The core problem is that Google uses a single API key format for two fundamentally different purposes: public identification and sensitive authentication. The Gemini API inherited a key management architecture built for a different purpose.

The researchers say Google has recognized the problem they reported and took meaningful steps, but have yet to fix the root cause.

Advice for developers

Developers should check whether Gemini (Generative Language API) is enabled on their projects and audit all API keys in their environment to determine if any are publicly exposed and rotate them immediately.

• Check every Google Cloud Platform (GC project for the Generative Language API. Go to the GCP console, navigate to APIs & Services > Enabled APIs & Services, and look for the Generative Language API. Do this for every project in your organization. If it’s not enabled, you’re not affected by this specific issue.
• If the Generative Language API is enabled, audit your API keys. Navigate to APIs & Services > Credentials. Check each API key’s configuration. You’re looking for two types of keys:
  • Keys showing a warning icon, meaning they are set to unrestricted
  • Keys that explicitly list the Generative Language API in their allowed services

Either configuration allows the key to access Gemini.

• Verify that none of those keys are public. This is the critical step. If you find a key with Gemini access embedded in client-side JavaScript, checked into a public repository, or otherwise exposed online, you have a problem. Start with your oldest keys first. Those are the most likely to have been deployed publicly under the old guidance that API keys are safe to share, and then retroactively gained Gemini privileges when someone on your team enabled the API. If you find an exposed key, rotate it.

Advice for individuals

For regular users, this is less about key management and more about keeping your Google account locked down and being cautious about third-party access.

• Only link Gemini to accounts or data stores (Drive, Mail, Calendar, enterprise systems) you’re comfortable being reachable via API and regularly review which integrations and third‑party apps have access to your Google account.
• When evaluating apps that integrate Gemini (browser extensions, SaaS tools, mobile apps), favour those that make Gemini calls from their backend rather than directly from your browser.
• If you use Gemini via a Google Cloud project (e.g., you’re a power user or use it for work), monitor GCP billing reports and usage logs for unusual Gemini activity, especially spikes that do not match your own usage.

We don’t just report on privacy—we offer you the option to use it.

Privacy risks should never spread beyond a headline. Keep your online privacy yours by using Malwarebytes Privacy VPN.

*** This is a Security Bloggers Network syndicated blog from Malwarebytes authored by Malwarebytes. Read the original post at: https://www.malwarebytes.com/blog/news/2026/02/public-google-api-keys-can-be-used-to-expose-gemini-ai-data