Google Cloud Customer Billed $11,000 After Account Hijacked Via Compromised Service Account Key

A solo developer, Charles Jones, found himself facing an $11,089.77 bill from Google Cloud, primarily for AI image generation using Gemini models, over a 48-hour period in early June. Jones, who manages programmatic SEO and insurance websites, stated he had no active workflow that would generate AI images, leading him to suspect an account compromise. Google Cloud suspended his account, citing "abusive activity consistent with hijacked resources," and attributed the root cause to a compromised firebase-adminsdk service account key.

Jones provided documentation of his exchanges with Google Cloud support, detailing how he followed the company's guidance to reinstate his account after the compromise. He promptly disabled the compromised service account and revoked the associated key. However, despite these actions and the clear indication of a third-party intrusion, the Google Cloud billing team has repeatedly refused to waive the substantial charges.

This incident echoes a pattern of similar complaints from Google Cloud customers who have faced unexpected and exorbitant bills due to compromised API keys. In February, another developer reported over $82,000 in charges from a similar API key compromise, and a comparable case involving over $10,000 surfaced on Reddit a month later. These situations highlight a persistent challenge for cloud users: the potential for significant financial liability stemming from unauthorized resource usage, even when the compromise is not due to user negligence.

Adding to the frustration, Google Cloud has yet to widely implement robust, universally available spending controls. While the company has introduced "Spend Caps" for certain services as a private preview, they are not generally available. Other measures, such as API-specific usage limits or budget alerts, are not designed to automatically prevent overspending and can only notify users or, in the case of budget alerts, disable billing with the risk of resource deletion.

Google's introduction of project spend caps for the Gemini API as an experimental feature in March offered some relief, but with caveats. These caps reportedly have a delay of up to 10 minutes, meaning customers remain liable for spending during that window. Furthermore, Google's system can automatically upgrade users to higher tiers based on usage and payment history, which in turn raises spending caps, potentially negating the intended protection.

Jones expressed deep frustration with Google's response, questioning the lack of transparency regarding the compromise. "Google's Trust & Safety was quick to alert me that a service account key was compromised — but I have been given no route, anywhere, to see HOW or WHERE that key was actually exposed," he stated. He insists he followed Google's recommended security practices on the VM where the key resided, yet the company invoked its Shared Responsibility Model to deny a refund without demonstrating a specific customer security failure.

This case underscores the ongoing difficulties Google Cloud customers face in avoiding unbounded financial obligations following an account or API key compromise. The opaque appeals process and the burden of proof placed on the customer to demonstrate security diligence, rather than Google providing forensic details of the breach, leave users vulnerable to unexpected and substantial charges.