Thousands of Public Google Cloud API Keys Exposed with Gemini Access After API Enablement

For over a decade, developers were told something simple: Google Cloud API keys aren’t secrets. They were often embedded in frontend code to power services like Maps, analytics, or Firebase, visible but largely harmless.

That assumption just broke.

Recent research by Truffle Security uncovered 2,863 publicly exposed Google Cloud API keys that can now authenticate to Gemini AI endpoints, creating a serious and previously invisible security risk.

How Google Cloud API keys gained new access to Gemini

Historically, these API keys acted as project identifiers for billing and basic service access. However, once developers enabled Google’s Generative Language (Gemini) API, existing keys in the same project silently gained access to AI endpoints without warning or reconfiguration.

This means keys that were:

• Publicly exposed in JavaScript
• Considered safe to share
• Widely deployed across websites and apps

…are now effectively AI access credentials. This scenario bypasses the original security assumption that exposure equals low risk, turning visibility into direct access.

In practice, any publicly scraped key can now be used to invoke AI services and consume resources without authentication controls.

Risks associated with exposed API keys

With a valid exposed key, attackers can access uploaded files and cached data through Gemini endpoints, execute AI queries using the victim’s account, and trigger significant billing abuse through automated requests. This risk is not theoretical. In one reported case, a compromised key resulted in more than $82,000 in charges within just 48 hours, demonstrating the financial significance of such vulnerability.

Researchers also point out that the risk goes beyond the cost, as AI-enabled endpoints expand the whole blast radius of a compromised key. Even if direct client data is not accessible, attackers can use model access, inference capabilities, and associated cloud resources.

Scale of exposed API keys across industries

The scale of exposure is significant, with researchers identifying thousands of API keys across industries, including financial institutions, security firms, and even Google’s own infrastructure. This represents a larger and ongoing issue, in which API credentials are routinely exposed in public code and may often be accessed for months or even years, making them perfect targets for automated scraping and large-scale attack.

What makes this particularly concerning is not just the longevity and discoverability of these keys, many of which remain active long after deployment. At scale, this creates a continuously expanding attack surface where even a small percentage of exploitable keys can translate into widespread financial and operational risk.

Google’s response to the issue

Google has acknowledged the issue and moved quickly to contain the damage by detecting and blocking leaked keys while tightening controls to prevent misuse of Gemini endpoints. That’s the good news.

The not-so-comfortable part is that the responsibility does not end there. Developers are still responsible for what happens in their own environments. That means going back to carefully audit existing keys, locking down API access so it is not left open, and rotating any credentials that may have been exposed. In simple terms, Google can secure the door, but you still need to know who has the keys.

Security implications for AI and cloud environments

This incident highlights a broader shift. In AI-enabled cloud environments, permissions are no longer static. When platforms introduce new capabilities, especially AI, existing credentials can inherit new permissions without visibility. This increases risk across environments that rely on previously exposed keys.

The takeaway is clear: Treat every API key as a sensitive credential. Also, regularly audit and restrict access scopes. Because in modern cloud systems, the risk is no longer exposure; it’s the power that exposure inherits over time.