Home/ Incident database/google-cloud-api-key-abuse-2026-05
Financial loss Cloud cost spike verified

Google Cloud customers receive tens of thousands in unauthorized API bills after key exposure

Google Cloud (affected customers: Prentus, Fonseka) · May 13, 2026 · General agent

What happened

At least two Google Cloud customers had their API keys compromised and used by attackers to run expensive video and image generation workloads on Gemini and Veo 3, producing bills of $10,138 and roughly AUD $17,000. Both had spending caps set at $250 that Google automatically escalated to $100,000 after the attacker-driven usage triggered the account's tier upgrade path -- $100 in spend unlocks the next tier, $1,000 and 30 days unlocks Tier 3 with a $20,000-$100,000 cap.

$10K
Loss / impact
May 13
2026
Cloud
Failure mode
General
Agent type

Causal vector

Exposed API keys plus automated spending-limit escalation let attackers burn expensive models unchecked

Source

Reported by The Register. Verified against the primary report.

Read the original report ↗

How a spend firewall would have helped

A merchant allowlist that only permits the models and endpoints a project actually uses returns BLOCKED on Veo 3 and Gemini image calls that have no business reason -- regardless of whether the key was exposed. A daily total cap sized to the real project budget would have stopped the burn at $250 instead of $100,000.

The six rule types that contain this class of failure

Per-transaction cap

Any single spend above your ceiling is BLOCKED before it moves.

Daily total

Cumulative spend across all agent calls, bounded per day.

Velocity limit

Stops runaway retry loops — the #1 cause of overnight losses.

Merchant allowlist

Only approved destinations can ever receive funds.

Category rules

Flag high-risk classes (crypto, infra, refunds) for review.

Approval threshold

Above a value, the action waits for a human.

Related incidents

AWS user faces a $30K–$38K Bedrock bill that cost-anomaly detection never flagged

AWS Bedrock customer (individual developer) · May 14, 2026

Don't be the next entry

Every incident in this database is the result of trusting a prompt, a provider cap, or a human review cycle. sipi.bot replaces all three with one deterministic call. 85 documented failures, one control.