u/Important_Owl6299

I want to reframe the usual "restrict your API keys" advice, because I think it points at the wrong problem.

I've been on the receiving end of Google Cloud's billing pipeline. A Gemini API key I created in Google AI Studio - never deployed, never checked into a repo, never left Google's own systems - got abused over a couple of hours and racked up roughly $80k on an account that was usually just 1400INR on spends. The first I heard of it wasn't an alert, a hold, or a flag. It was ~$80k quietly materializing in the transactions table after the fact in my credit card e-mandate queue. It was the credit card company which was more honest with me 🥲

Here's what I find remarkable: the billing system is wired tightly enough into Google's financial backend to instantly issue mandates and process charges the moment they cross a threshold - but the customer-facing side of that same system shows you nothing until the money is already gone. That asymmetry isn't an accident of scale; it's an engineering decision. Real-time when it's time to charge you, eventually-consistent when it's time to warn you. I'll call that "dark" and leave it there.

So my actual ask isn't "improve API keys." It's two things:

Make the customer-facing billing APIs reactive and real-time. If the mandate system can act in seconds, the anomaly/notification system can too. Budgets today are advisory and lagging - by the time a budget alert fires, you can already be five figures deep. Give us spend signals on the same clock as the charges.
Give API keys hard, user-defined cutoffs - price, volume, and time - that actually stop traffic. Not alerts. Cutoffs. Right now the user is kept in the dark on most of the config that governs a key. Consider the Firebase angle: you spin up a "Firebase project," but the whole thing is a facade over an underlying GCP project. A non-DevOps founder or a hobbyist has no idea their key is effectively an open secret that can reach any Google service - until they're billed one morning for a service they never knowingly enabled. Nobody hands you that disclaimer up front.

I know unrestricted keys are being phased out after everything that's happened, and that's good. But restriction-by-default is damage control. The real fix is a billing surface that's honest with the customer in real time and lets them set a ceiling that the platform will actually enforce.

I'm posting this as a serious request for improvement, not a jab because I got burned. The engineering talent to do this clearly exists - it's already pointed at collections. Point some of it at the customer.

(For context: Google eventually waived ~75% of the charge, but is holding the remaining ~25% + GST as "valid usage" and won't share the access logs. So even the dispute process runs on the same one-sided visibility.)

haha so my entire lifetime with Google Cloud was always one-sided 💔

I built a Claude Code skill suite + a companion MCP server that automates the API-key audit-and-harden pass on GCP. One invocation and it:

* inventories every API key + SA key across every accessible project, with a risk classification (CRITICAL = unrestricted, etc.)
* detects historical cost anomalies from your BigQuery billing export (catches abuse you may have missed already) \[**Prerequisite:** Need you to connect your billing account with bigquery export\]
* applies safe, **idempotent, reversible** blast-radius controls: quota caps on `generativelanguage.googleapis.com`, Cloud Billing budget alerts, disabling idle paid APIs, restricting unrestricted keys to the APIs they actually call (inferred from monitoring)
* **halts automatically** if any project is currently bleeding (>10× baseline in the last 24h — so it never mutates during an active incident)
* **never auto-deletes credentials, never modifies IAM, never closes billing accounts** — flags those with the exact `gcloud` command for human review

Every applied change has its rollback command in the final report. Re-runs are no-ops once state is hardened.

**Why I built it:** \~$80,000 of unauthorized Gemini-API charges hit a reddit user's project in 8 hours overnight, from an INR1,400/day baseline. Leaked, unrestricted API key, picked up by an automated abuse service that hammered every Gemini model for image generation. Same pattern The Register has been documenting all year.

According to the user, across the dispute and the post-mortem, several Google-side gaps surfaced:

**Unrestricted is the default.** Google's own [May 2026 post on API-key security](https://cloud.google.com/blog/topics/developers-practitioners/api-keys-are-open-secrets) says, in the same article: *"DO NOT create unrestricted keys"* and *"by default a new API key is created without restriction."* The dangerous configuration is what new users get.
**Budgets don't cap spending.** Per Google's own docs, a budget *"does not automatically cap usage/spending."* It emails you while the meter runs.
**Spend tiers auto-upgrade.** The Register documented a developer who set a `$250` spending cap and woke up to a `$10,000` bill, after which their tier was automatically raised to `$100,000`.
**Key-scope expansion.** [Truffle Security](https://www.theregister.com/2026/03/03/gemini\_api\_key\_82314\_dollar\_charge/) reported that Google had quietly broadened the scope of certain API keys to also access Gemini models. Their initial report was dismissed as *"intended behavior"*, then **reclassified as a Bug** after Truffle showed examples on Google's own infrastructure.
**No real-time abuse block.** A jump from `INR`1,400/day to $20,000/hour is, by any measure, anomalous. The detection signal exists in Cloud Monitoring (`serviceruntime.googleapis.com/api/request_count` by `credential_id`) but the platform did not act on it.

**Repo:** [https://github.com/shivamsriva31093/gcp-ironclad\](https://github.com/shivamsriva31093/gcp-ironclad)
MIT-licensed. v1.0.0. 96 unit tests, bandit + pip-audit in CI (all green).
Architecture diagram in the README.

**Help wanted, especially:**

* Org-policy enforcement (`apikeys.googleapis.com/allowedRestrictions` — block unrestricted keys at creation time, so the dangerous default doesn't matter).
* Local-codebase secret scanning (`AIza…` grep across checked-out repos + git history) as an opt-in pre-flight phase.
* Multi-org / cross-tenant operation.

Disclosure: I'm the author. Issues + PRs welcome. There's an `incident-report` issue template if you've been hit by the same pattern and want to share what happened (redacted) — helps tune the risk classifier.

I Will really appreciate your feedback. This is something expert devops can easily do using gcloud cli itself. This is targeted towards developers with little hands on devops expertise and want to do a hygiene check using quick claude session.

GCP doesn't need better API keys - it needs billing that reacts in real time!

`gcp-ironclad`— automated GCP API-key audit + safe spend hardening, run from Claude Code (built after a reddit user posted - $80K of Gemini-API fraud hit their project in 8 hours)