Google Billed a Developer $11,000 for a Hack It Detected and Still Won't Explain

Charles Jones is a solo developer running programmatic SEO and insurance sites. He does not generate AI images. So when his Google Cloud account racked up over $11,000 in charges across a 48-hour window in early June, almost all of it tied to Gemini image-generation models, something had clearly gone wrong.

Google agreed something had gone wrong. Its Trust & Safety team suspended his account on June 7 with a notification stating it had been "engaged in abusive activity consistent with hijacked resources." The culprit, Google said, was a compromised Firebase Admin SDK service account key.

Jones did everything Google asked. He disabled the service account, revoked the key, and followed the reinstatement process. His account was restored. Then Google's billing team sent him the invoice anyway.

He's been fighting it ever since.

This is not a rare story. In February, a developer in Vietnam faced over $82,000 in charges after an API key compromise. Similar reports surface on Reddit with depressing regularity. The pattern is consistent: key gets stolen, fraudulent usage spikes, Google detects abuse, developer gets billed regardless.

Part of the problem is structural. Google still has no publicly available hard spending cap for Cloud accounts. There are budget alerts, but these don't automatically stop services when limits are hit. There are API-level usage limits, but Google explicitly states these aren't project-wide caps. There's a workaround that lets budget alerts disable billing entirely, but Google warns this risks resources being "irretrievably deleted." In March, Google added experimental spend caps to the Gemini API, then quietly noted they carry a ten-minute delay and customers remain liable for anything spent during that window. Some cap.

To make things worse, Google's system apparently auto-upgrades accounts to higher usage tiers as payment history matures, which also raises those loosely-defined spending limits. So not only is there no hard ceiling, the ceiling actively moves upward over time.

Jones's frustration goes beyond the bill. He's been told by Google that he bears responsibility under its Shared Responsibility Model, the standard cloud defence that essentially says: we secure the infrastructure, you secure your access credentials. Fine in principle. But Jones has a pointed question Google hasn't answered.

"Google's Trust & Safety was quick to alert me that a service account key was compromised," he said, "but I have been given no route, anywhere, to see HOW or WHERE that key was actually exposed. There is no trace, no log path, no forensic detail offered."

He was, he says, the only person with access to the VM where the key lived. He followed Google's recommended practices. Google has not shown him where he failed. It has simply declined the refund and cited the Shared Responsibility Model as justification.

"So how does a single-access VM produce a leaked service account key," he asked, "and why is the burden on me to prove I secured something Google itself can't show me how I failed to secure?"

It's a reasonable question. If Google can detect the compromise quickly enough to suspend the account, it presumably has logs of the incident. Sharing those with the customer seems like a basic requirement for fairly applying a model that assumes customer-side failure. Instead, the appeals process is opaque, Google has no obligation to demonstrate negligence, and the developer is left holding a five-figure bill for usage they didn't authorise.

The Register asked Google twice why it denied the refund and what evidence supports that decision. No response.