A small startup from Mexico recently found itself facing an $82,314 Google Cloud bill after attackers abused a stolen Google Gemini API key for intensive AI queries over just two days. The incident highlights not only the risk of exposed API keys, but also architectural nuances in the Google Cloud and Gemini API ecosystem that many teams do not fully understand.
How a Stolen Gemini API Key Drove Costs Up by 46,000%
According to the developer who described the case on Reddit, the compromise occurred between 11 and 12 February. In that window, unknown attackers repeatedly invoked Gemini 3 Pro Image and Gemini 3 Pro Text, exhausting available limits and generating a bill of $82,314.
Under normal conditions, the three‑person team spent about $180 per month on API usage. The spike therefore represented a cost increase of roughly 46,000%. After detecting anomalous traffic, the startup immediately revoked the leaked API key, disabled Gemini API access, rotated all credentials and opened a support case with Google to request cancellation or reduction of the charges.
Google’s initial response was framed through the shared responsibility model: the provider secures the cloud platform and infrastructure, while customers are responsible for protecting API keys, tokens and other secrets. The developer stressed that even partial collection of the amount (for example, one third of the bill) could push the small startup into bankruptcy, illustrating the real business impact of API key abuse.
Truffle Security: Legacy Google API Keys Quietly Gain Gemini Permissions
Almost in parallel, researchers from Truffle Security conducted large‑scale scanning of public resources and identified 2,863 valid Google API keys. These keys were originally created as simple project identifiers for billing and service usage, but now can also be used to call the Gemini API.
The core issue lies in the format and reuse of Google Cloud API keys. Many keys start with the prefix AIza, which makes them easy to locate via automated scans of source code, public repositories and web pages. In several official Google guides, particularly for Google Maps and Firebase, such keys are explicitly described as not secrets and suitable for embedding directly into client-side code.
For Google Maps, documentation has long recommended placing the key directly in HTML, meaning it is fully visible to every site visitor, browser extension and search engine crawler. As Gemini integration was added to Google Cloud, many of these same keys automatically gained the ability to authenticate to Gemini—often without a clear warning to project owners.
When a “Non-Secret” Google Maps Key Becomes a Gemini Credential
As Truffle Security researcher Joe Leon explains, a typical scenario looks like this: a developer creates a Google Maps API key three years ago, following the official guidance to embed it in public HTML or front-end code. Later, the team enables Gemini API in the same Google Cloud project. The old Maps key silently gains new capabilities and effectively becomes a full set of credentials to run LLM workloads.
Any attacker who discovers such a key in a public repository or web page can then:
• send high-volume requests to Gemini at the account owner’s expense;
• potentially access uploaded files or model caches, depending on project configuration;
• generate substantial cloud costs that may remain unnoticed until the billing cycle closes.
Google’s Response and Current Mitigations for Gemini API Abuse
Truffle Security reported the issue to Google, providing an example of a public website where a key exposed since 2023 granted access to Gemini API. The initial response classified this behavior as working as designed. After researchers demonstrated similar patterns within Google’s own infrastructure, the case was upgraded to a high-severity bug, and the security team requested the full list of 2,863 exposed keys.
As of early February, Google indicated that work on a broader fix is underway and that proactive mechanisms have been deployed to detect and block leaked keys when they are used against Gemini API. Details of those mechanisms have not been fully disclosed, but they likely involve heuristic detection of anomalous usage and automatic key revocation.
Practical Guidance: How to Protect Google Cloud and Gemini API Keys
Truffle Security recommends that all Google Cloud customers perform an immediate audit of their projects, repositories and web applications using the open-source tool TruffleHog. The tool scans source code, CI/CD pipelines and web assets for exposed secrets and API keys, reducing the time between key exposure and detection.
From a broader cybersecurity perspective, the Gemini incident reflects a recurring pattern: identifiers once treated as low-risk gradually accumulate powerful privileges as platforms add new features like AI and LLM services. Without explicit scope reviews, older keys and tokens can unexpectedly grant access to high-value and high-cost capabilities.
To reduce risk, organizations should:
• treat all API keys as secrets by default and avoid embedding them in client-side or public code;
• regularly review the scope and purpose of existing keys whenever enabling new services such as Gemini or other AI APIs;
• integrate secret scanning into every stage of the CI/CD pipeline and enforce remediation before deployment;
• configure strict budgets, alerts and hard usage quotas in Google Cloud so anomalous AI activity is detected within hours, not weeks.
The story of the stolen Google Gemini API key demonstrates that even a single “non-secret” key can escalate into a financially devastating cloud incident. Organizations that rely on Google Cloud and AI services should treat API key management as a core element of their security program, investing in processes, automation and training that prevent exposed keys from becoming the next six-figure bill.
