Follow-up to my thread from 30 July (link) — full timeline and
evidence there. The short version of what has happened since, because the
sequence speaks for itself.
Google has now denied the billing adjustment three times, each time on a
different basis:
- 30 July: “no evidence of abuse or unauthorized activity exists”
- 1 August: the account holder is responsible “even in cases where unauthorized
access or credential exposure may have occurred” - 5 August, from an escalation manager, marked as the final resolution: “the
usage was valid and processed in accordance with standard platform
functionality”
The usage being called valid: 1,041,183 requests to generativelanguage in 90
minutes from a service account whose only IAM role was roles/dialogflow.client,
which grants no permission on that API. If that is standard platform
functionality, then IAM role bindings had no effect on this API — the access
configuration we are told we are responsible for was configured correctly and
did nothing. And this is the same traffic Google’s own Trust & Safety flagged
on 10 July as a possible compromise and ToS violation (case 73119898), reducing
our quotas on that basis.
One more detail from the final letter. It recommends a Monthly Spend Cap as
“your strongest line of defense” going forward. According to the Cloud Billing
release notes, spend cap budgets shipped on 27 July 2026, in Preview —
seventeen days after the incident.
We paid the July invoice in full and on time, under protest, because the same
billing account carries our production workloads. We are not even asking for
cash back — a credit memo against future usage would settle this.
If anyone from Google reads this: cases 73119898 and 72951659 need to be
reviewed together with the billing dispute, by someone with the mandate to do
so. Metrics Explorer exports per credential_id and per response_code, Admin
Activity and Access Transparency extracts — available privately to anyone who
can act on this.