"[The] account was engaged in abusive activity consistent with hijacked resources," a June 7 suspension notice told developer Charles Jones — a finding that left him on the hook for $11,089.77 in Google Cloud charges even after he reported the account compromise and revoked the implicated keys.
June 7–8: $11,089.77 in charges tied to Gemini image-generation
Over a 48-hour period from June 7 to 8, Jones's Google Cloud account accrued $11,089.77 in charges, most of them associated with the use of Gemini image-generation models. Jones, a solo developer who runs programmatic SEO and insurance sites, told The Register he does not operate any workflow that produces AI images. Google suspended his account on June 7, citing abusive activity consistent with a hijacked resource.
Firebase-adminsdk key compromise identified; developer sees no forensic trail
Google attributed the root cause to a "compromised firebase-adminsdk service account key," according to documentation Jones provided to The Register. Jones says he followed Google's recommended security practices, that he was the only person with access to the virtual machine where the service account key resided, and that he disabled the service account and revoked the key after receiving Google's alert and the suspension notice.
Jones told The Register that Trust & Safety was quick to point out the compromised key, but he has been given "no route, anywhere, to see HOW or WHERE that key was actually exposed." He says there is "no trace, no log path, no forensic detail offered." Jones framed the dilemma succinctly: if Google can’t (or won’t) show how the key was exposed, why is the burden on him to prove a security lapse?
Google Cloud billing refused to forgive charges; appeals process opaque
Despite Jones taking the steps Google required to have the account reinstated, the Google Cloud billing team has repeatedly refused to forgive the charges. The Register reports that Google may choose to hold developers liable for unauthorized charges even when a credit-card issuing bank has reversed the charge as fraudulent.
The company's Shared Responsibility Model was invoked to deny a refund, Jones said, but he maintains that Google has not demonstrated a customer security failure. The Register twice asked Google for an explanation and evidence supporting its decision and had not received a response at the time of reporting.
Spend caps and budget controls: available but limited and sometimes experimental
Google has not publicly released a general mechanism to cap Google Cloud spending. The company introduced "Spend Caps" for certain services as a private preview, but it has not made the service generally available. The Register notes that API-specific usage limits "aren't designed to act as a project-wide spending cap," and that Budget Alerts "don't automatically prevent the use or billing of your services when the budget amount or threshold rules are met or exceeded."
Google provides a workaround that lets Budget Alert notifications disable cloud billing, but it warns that doing so risks resources being "irretrievably deleted." In March Google introduced project spend caps for the Gemini API as an experimental feature, but those caps reportedly have a 10-minute delay; customers remain responsible for spending during that period. The company also said its system "now automatically upgrades you to the next [usage] tier as your usage grows and your payment history matures," and that higher tiers raise spending caps — a dynamic that can increase exposure for customers as usage increases.
What this means for developers, procurement leaders, and security teams
- Developers and solo operators: The case of Charles Jones underscores the risk of rapid, large bills arising from API-key misuse and the difficulty of reversing charges when a cloud provider determines an account was "hijacked" but does not share forensic evidence.
- Procurement and finance teams: Without a generally available, project-wide spend cap and with experimental caps that include delays, organizations may be unable to limit financial exposure from sudden, fraudulent API usage.
- Security teams and incident responders: The absence of a provided log trail or forensic detail in this instance complicates internal investigation and dispute resolution when a provider flags a service-account key compromise but does not share the underlying traces.
The episode raises a pointed question Jones has pressed: if Google can detect and alert to a compromised service account key, why will it not show customers how the key was exposed? With Google declining to explain its refund decision to The Register, the dispute leaves intact a stark choice for cloud customers — trust that provider-side detection will be accompanied by transparent forensic evidence, or accept potential financial liability under the Shared Responsibility Model without seeing the audit trail that led to that determination.
