Gemini's billing key: the increasing risk of the API keys exposed in Google Cloud

A security investigation recently brought to light a failure that reveals how an apparently harmless element - Google Cloud's API keys - can become an entry door to advanced artificial intelligence functions and, consequently, to private data and disorbiter invoices. The report, published by Truffle Security, shows that thousands of those keys were visible in client code on web pages and, for a change in how Google enabled its APIs, began to function as credentials for Gemini's endpoints (Google's Generative Language API).

Traditionally, "Aiza" prefix keys have been used mainly as project identifiers for billing purposes, for example for services such as embedded maps. Truffle Security found about 2,900 keys publicly exposed in JavaScript from sites that used them openly. The worrying thing is not just the exposure: it is that when a project activates Gemini's API, those keys stop being merely billing tokens and start authorizing calls to the language generation API without the developers warning it.

The practical effect is easy to explain and difficult to mitigate after the fact. An attacker who scratches the web and collects one of those keys can make requests to Gemini, consume inference fee that will be charged to the key owner and, in some cases, access private content through endpoints such as / files and / cachedContents. That is, the same key that was previously only on invoices can now allow you to download uploaded files or recover data that had been stored in cache.

In addition, Truffle Security documented that the creation of a new API key in Google Cloud usually comes with a very permissive default configuration: "Unrestricted," which means that the key is associated with any API enabled in the project, including Gemini. The result, in the words of the researchers, is that many keys that were considered safe because they were used only for billing went on to act as Gemini's credentials and appeared on the public surface.

This problem is magnified when considering the mobile ecosystem: the Quokka firm carried out a sweep of 250,000 Android applications and found more than 35,000 unique Google keys embedded in those apps. The full picture suggests that it is not an isolated case but a mass exposure pattern that, with the arrival of APIs of IA, changes the risk profile significantly.

In the light of the report, Google responded that it was working with researchers to mitigate the problem and that it had implemented proactive measures to detect and block leaked keys that attempt to access Gemini's API. This public communication from Google can be consulted along with the technical details and recommendations in the official Google Cloud documentation on API keys and in the pages that describe its generative offer: Truffle Security report, the technical entry of Quokka and Google Cloud documentation on authentication and the generative API ( API keys and Generative AI).

It is not clear whether these keys have been widely used in targeted attacks, but anecdotal reports have already appeared that show the potential economic impact: in Reddit a publication circulated where a user claims to have received charges of over $80,000 in 48 hours after the theft of a Google Cloud key and use of the Gemini API. Although this individual case has not been publicly verified, it illustrates the type of abuse that concerns the security community ( see publication in Reddit).

The lesson here is double. On the one hand, the risks associated with API keys are dynamic: a piece of infrastructure considered low risk can become critical when the services linked to the project change. On the other hand, basic safety hygiene - key rotation, IP or reference restrictions, and avoid including keys in client code or public repositories - is no longer a recommendation and becomes an urgent need.

If you manage projects in Google Cloud, you should review your APIs and services already activated and identify key ones that are accessible from the customer (public JavaScript, public repositories or mobile apps). Prioritizes the rotation of the oldest keys, which are the most likely to have been deployed under less stringent previous practices. In turn, it limits its scope by applying restrictions on which APIs can use them and from which origins they can be invoked; Google Cloud documentation offers guides and controls for that.

Beyond specific actions, this incident underlines the need for continuous surveillance: safety scanning, detection of abnormal behaviors in the use of APIs and automatic blockages when suspicious activity is detected. As several experts point out, the adoption of the A in cloud infrastructure adds new vectors that did not exist when many of these keys were considered harmless, so the "configure and forget" approach no longer works.

In short, what seemed like a billing token can now be the key to an API that processes prompts, stores results and gives access to content. Review projects, apply use restrictions, rotate and remove exposed keys and monitor consumption patterns are essential steps to reduce the attack surface. For those who need to start now, both Truffle Security and Quokka's analysis and Google's official documentation offer clear and technical starting points to understand the scope and remedy: Truffle Security, Quokka and Google Cloud documentation.