Production project hijacked April 23, 200,000+ SEK fraud, 5 open support cases, multiple written commitments broken — needs Trust & Safety attention

Hi all,

Posting here as a last resort after 20 days of trying to resolve a serious
Gemini API hijacking through normal Google Cloud Billing Support channels
with no resolution. A comprehensive incident report has been submitted to
all 5 active support cases today. Hoping someone from the Gemini/AI Studio
team sees this. Police report being filed this week; insurance claim being initiated.

What happened

On April 23, 2026, attackers obtained Gemini API keys from our Google Cloud
organization (Flexibel Friskvård & Hälsa, Sweden) and generated massive,
automated, unauthorized API usage. Total documented fraud across 4 billing
accounts now exceeds 200,000 SEK (visible in Google Cloud Console reports),
up from an initial ~61,100 SEK as delayed usage reporting came through.

What we have already done

Within hours of detection, and continuously since:

  • Deleted the primarily compromised project
  • Deleted the auto-generated AI Studio project gen-lang-client-0637496414
  • Rotated all compromised API keys with strict Website Restrictions
  • Moved active keys to Google Cloud Secret Manager
  • Rebuilt our chatbot to use a backend proxy (no frontend API access)
  • Implemented Firebase Authentication
  • Set rate limit of 15 requests/hour
  • Removed exposed Gemini keys from vite.config.ts and geminiService.ts
  • Patched a privilege-escalation in our inviteUser Cloud Function
  • Set up Budget Alerts
  • Deleted all compromised Gemini API keys across all projects (May 13);
    Firebase and Google Maps keys deliberately retained to avoid disrupting
    independent customer-facing services
  • Manually enabled “Disable Billing” on all affected projects
  • Had our bank block further automated charges

Google’s own Trust & Safety team approved our hijacking appeal early on
— meaning Google internally has already acknowledged this as hijacking,
not legitimate usage. The internal appeal reference is documented in
our support cases.

Open support cases (all “In Progress”)

Case Date Issue
70679453 Apr 28 Initial fraud report and credit request
70894119 May 5 Broken Billing Hold promise + smart-skylt suspension
71066516 May 10 Production down — May 18 extension promised
71087976 May 11 Production down (continued) — partial fix
71136766 May 12 403 PERMISSION_DENIED on gym-screen

The most damning evidence: written commitments that were broken

May 5, 2026 — Google Cloud Support agent on Case 70894119 wrote
verbatim in the chat:

“Your account will not be suspended until we finalize the update on the case.”
“Yes, The hold is currently active on the account”
“The expected time of resolutuin is on or before 9th of this month”

Approximately 1.5 hours later, Google reserved 29,083.56 SEK from our card.
The next day, smart-skylt-prod was suspended again — and remains suspended
7 days later as of today. May 9 came and went with no resolution.

May 11, 2026 — Google Cloud Support agent on Case 71087976 wrote
verbatim in the chat:

“due to the unique status of your project it is for a different team
and is handled by our account and security team since it is considered
as a compromised key”

Google’s own written acknowledgment that this is hijacking, yet the
project remains suspended.

What I need

  1. A human at Trust & Safety or Account Security with authority to
    actually resolve this — not another transfer to an email queue with no
    response.

  2. Full credit of the fraudulent charges (Trust & Safety has already
    classified the activity as hijacking).

  3. Safe reinstatement of smart-skylt-prod now that mitigation is complete.

  4. Honoring of the written commitments made by Google Cloud Support
    agents across the five active cases.

What’s been frustrating

Across five separate cases and at least six different agents, no Google
Cloud Support representative has — at any point — suggested the most basic
“stop the bleeding” mitigation for API hijacking: disabling billing at the
project level. I had to find this myself. Multiple agents refused
escalation to supervisors. One offered Korean support to a Swedish
customer. Google’s own automated anomaly detection system triggered
(16,865 SEK Gemini API spike alert) but no proactive intervention
followed.

I have a complete incident report (chat transcripts, timestamps, quotes,
screenshots) ready to share with anyone at Google who can actually help.

Has anyone here had a similar experience? Is there a path I’m missing
between Billing Support and Trust & Safety that actually gets a response?

Thanks for reading.

-– Karin Gustafsson
Flexibel Friskvård & Hälsa
Sweden

Update: This is part of the systemic Gemini API key flaw Google itselfpublicly acknowledged in February 2026 (~2,800 affected organizationsper Truffle Security/Malwarebytes/CSO). Remediations announced forMay 7 and June 19, 2026. Our case predates these fixes.

Hi @Karin_Gustafsson

I have DM’ed you for more details

Thanks @Mustan_lokhand — really appreciate the quick response. I’ve
replied with the full case details, project IDs and incident report
via DM.

I’d love to hear how this gets resolved, facing a similar situation.

Hey Karin, what was the final resolution for you?

Hi Mauricio, Honestly, it is not fully resolved yet — still in the middle of it after six weeks. Partial credits have been issued but the full refund and a working billing hold are still outstanding. How is it going for you?

Thanks for replying. Mine’s similar, partial refund issued. I disabled all my Google Cloud Project Billing until I get it sorted out.

UPDATE — Two months later, still unresolved. Account terminated
mid-dispute despite active support case.

Interesting context: the pinned banner at the top of this forum now
confirms that as of 19 June 2026, Gemini API stops accepting requests
from unrestricted API keys “to prevent unauthorized usage and billing
risks.” That is exactly the systemic vulnerability my case was exposed
to during April-May 2026, before that protection existed. Google’s
own new policy validates the root cause I have been documenting since
day one.

WHAT GOOGLE HAS ACKNOWLEDGED (in writing):

  • Trust & Safety internally classified
  • A Google support agent confirmed my project as “compromised key”
  • Credit notes totaling ~SEK 191,000 have been issued across the
    affected billing accounts
  • One refund of SEK 3,596.62 was formally approved by Google Payments

WHAT HAS ACTUALLY REACHED MY BANK ACCOUNT:

  • SEK 0.00 (yes, zero — after two months)
  • The approved refund expected 21 June has still not landed as of
    today (1 July)

WHAT HAPPENED THURSDAY 25 JUNE:
Google TERMINATED one of the affected billing accounts by automated
process — only 10 days after issuing a major credit on that same
account, and while a significant portion (25% of the acknowledged
fraud) was still in active formal dispute over Google’s “shared
security guidelines” retention policy.

Also noteworthy: Google support agents I chatted with DURING the
active fraud period never advised me to rotate or revoke the
compromised API key — despite multiple live chat sessions. I
discovered this basic mitigation myself, after days . It is hard to see how “shared security guidelines” can be invoked to retain 25% confirmed , when Google’s own
front-line support gave zero security guidance during the incident.

WHERE I AM NOW (after two months):

  • Approximately SEK 47,836 paid out of my company bank account
    during the fraud period
  • ~SEK 191,000 acknowledged by Google
  • SEK 0.00 actually returned to my bank
  • One approved refund pending and 10 days overdue
  • One account terminated mid-dispute
  • No confirmed hard hold on any of the affected accounts

For the community: document everything, do not accept internal
“credit adjustments” as equivalent to refunds, lock your card if
you can, and file a police report early for insurance and paper
trail.

If anyone from Google reads this thread and can help move this
across the finish line, please reach out.