Gemini key leak turns costly

A leaked Google API key was used to drive more than €54,000 of Gemini compute charges in about 13 hours after attackers exploited an unrestricted Firebase browser key, according to a complaint posted on Google’s own AI developers forum, sharpening concerns over how older public-facing keys can become valid credentials for newer AI services. The affected user said an €80 budget alert and a cost anomaly alert both arrived only after spending had already climbed to about €28,000, with the final tally settling above €54,000 because of delayed reporting.

The episode has drawn attention because it appears to sit at the intersection of two strands of Google guidance that developers have long treated differently. Firebase documentation still says API keys used only for Firebase services do not generally need to be treated as secrets and can be included in code, provided they are properly restricted. The same documentation now states that any key used for Gemini Developer API calls must never be included in code or configuration files and should be protected from public exposure. That distinction matters because the victim’s complaint centred on a browser key that was said to lack API restrictions after Gemini-related functionality had been enabled on an existing project.

Google’s own Gemini troubleshooting guidance shows the company has already acknowledged a broader vulnerability. It says some publicly exposed API keys have been proactively blocked from accessing Gemini, that affected users may see an error stating the key was reported as leaked, and that billing support cases should be submitted in cases of unexpected charges linked to the issue. Google also says it is moving towards issuing keys through AI Studio that are limited by default and is “defaulting to blocking” leaked keys used with Gemini.

What makes the problem more serious for developers is the suggestion that this is not simply a case of a careless team publishing a secret. Security researchers at Truffle Security argued in February that thousands of Google API keys placed on public websites for tools such as Maps or Firebase could silently gain Gemini access once the Generative Language API was enabled on the same project. Their report described the pattern as a form of privilege expansion: a key originally intended as a public identifier becomes, without a fresh warning, a credential capable of accessing billable AI endpoints, uploaded files and cached content.

That argument has since been reinforced by mobile-app research. CloudSEK said this month that it found 32 hardcoded Google API keys across 22 popular Android applications, with a combined install base above 500 million, that could be used to access Gemini endpoints. Its analysis said developers had often embedded such keys exactly as older documentation permitted for public-facing services, only for those same keys to become far more sensitive once Gemini was switched on for the project behind them.

The incident also exposes a gap between spending controls on paper and what happens during a live attack. In a response on the same forum thread, Google’s Logan Kilpatrick said billing account caps had been rolled out for Gemini API users, with Tier 1 accounts cut off at $250 a month by default, though he noted a reporting delay of about 10 minutes. He also said project spend caps were now supported and that Google was moving to disable the use of unrestricted API keys with the Gemini API. Those safeguards may help going forward, but the developer who reported the €54,000 hit said their request for a billing adjustment was denied because the usage originated from their project.

For software teams, the lesson is blunt. Keys that were once treated as low-risk identifiers can no longer be assumed harmless if they sit inside projects where Gemini or related AI features are enabled. Google’s current AI Studio build guidance says real API keys should never be used directly in client-side code, and any secure deployment outside AI Studio should move key-using logic to a server-side component. That marks a clear shift from the more permissive assumptions many developers formed around older Firebase and Google web integrations.