Google Cloud keys exposed: from simple identifiers to credentials that activate generative IA and could cost you thousands

A few months ago, it silently changed a assumption that many developers took for granted: the Google Cloud API keys that were placed on public websites for loads such as maps or videos ceased to be simply harmless identifiers. With Gemini's arrival and the possibility of enabling the API of generative models in projects, these keys also started to function as credentials that can authorize calls to the IA assistant and, in some cases, to associated private data.

The problem was highlighted by a research team that tracked the public picture of the web code: by analyzing a representative snapshot of the Internet index, they found thousands of Google keys visible in client code. This investigation, published by Truffle Security, reveals that about 2,800 live keys were exposed on publicly accessible pages and that in several cases those same keys could invoke Gemini's API. Among the findings are keys used by financial institutions, security companies and contracting firms, and even a key integrated into the public web of a Google product.

Traditionally, many Google Cloud keys were treated as non-critical: they served to identify billing or enable simple services in the browser - such as uploading Google Maps, inserting YouTube videos, or using Firebase on a web app - and were confident that reference or use limits were enough. However, when a project activates the Generative Language API, the same key can acquire additional privileges and allow anyone who can run models and access functionalities that were not previously available from the client code.

The practical consequence is double. On the one hand, there is the risk of exposure of information: targeted attacks using the key can try to read or manipulate data to which the service has access. On the other, and perhaps more immediate to many organizations, there is the economic cost: calls to large models are not free, and an aggressor who abuses an exposed key can cause important bills. As researchers point out, saturation of requests against a model with a broad context can result in thousands of dollars per day charged to the victim account.

The findings are based on analysis of a massive set of web pages and are not an anecdotal case. Truffle Security documented that several keys had been in public code for years and, after testing calls to Gemini endpoints to list models, confirmed that those keys worked for the new service. The investigation was notified to Google and, after an exchange of communications, the company classified the problem as a form of escalation of privileges for a specific service.

Google's response, according to statements collected by specialized media, included technical measures and operational recommendations: blocking access of leaked keys to Gemini, issuing proactive notifications when leaks are detected and adjusting the default range of new keys generated from AI Studio to be specific to Gemini. These actions help, but are not a substitute for appropriate safety hygiene in projects.

For developers and product managers this is an immediate audit obligation. It is essential to review the projects and check whether the Generative API is enabled; if so, all public keys or code drinks must be reviewed and rotated without delay. In addition, it is appropriate to review permissions, apply strict reference or IP restrictions where possible, and set quota limits and billing alerts to detect abnormal consumption.

Tools facilitate the detection of exposed secrets in repositories and public code; researchers themselves recommend TruffleHog as a starting point for scanning and finding keys that are accessible from the front or in mission histories. It is also worth reviewing the official Google guides on API key practices and authentication, which describe how to mitigate risks and set up more fine controls: Google Cloud documentation on API keys.

Beyond punctual cleaning, this raises a broader reflection on how the evolution of platforms and services can change the sensitivity of certain technical devices. Something that was considered relatively safe yesterday - a public key used to load a map - can now become a critical vector if the same credential begins to authorize access to generative IA or functions that had not been anticipated. It is therefore key to review assumptions, apply the principle of less privilege and professionalize the management of secrets.

In the operational field, implement server authentication for sensitive calls, use service accounts with minimum permissions, and separate the public use keys from those that have the ability to invoke powerful APIs are measures that reduce exposure. It is also recommended to maintain automatic processes that monitor the appearance of secrets in either the commons or the front and that require the rotation of committed credentials. Security documentation and best practices change with technology; the responsibility of the teams is to keep them up to date.

The incident also underlines the importance of collaboration between researchers and suppliers. The responsible detection and reporting by third parties helped to adopt blockages and controls in a rapidly changing service. For those who want to deepen the original research, the report and entry of the team that detected the exhibition are available on the Truffle Security blog, which details methodology and concrete examples: Truffle Security analysis. The media coverage of Google's statements and the scope of finding in media such as BleepingComputer.

If you manage projects with cloud services, do not leave it for later: check if your client code contains visible keys, identify which permissions have these credentials and act with rotation and restrictions. Security is not static; a key exposed today can become dangerous tomorrow by changes in platforms and the difference between a minor incident and a serious leak is often in the speed with which exposure is detected and corrected.