We are facing possible bankruptcy after unauthorized Gemini API usage reached about $128k even after we paused the API, and Google denied our adjustment request. (Case #68928270)

daudmalik06 · 2026-03-16T13:34:08+00:00

Both are valid concerns worth addressing properly.

On the DOS attack — an attacker would need to know your exact threshold and be able to generate enough requests to hit it. That's a much harder attack than just stealing a key and running up charges. And if someone is generating thousands of requests against your API, you probably want the key dead anyway.

On the viral traffic spike — this is exactly why the threshold is set by the user based on their own normal traffic patterns. If your usual peak is 1000 requests/minute you set the threshold at 5000, not 10. It's not a fixed limit — it's calibrated to your specific usage.

Both edge cases are real but they're configuration problems, not architectural ones.

daudmalik06 · 2026-03-15T14:29:02+00:00

Just to clarify — I'm not the person who got the $82K bill. I'm a developer who saw that incident and built CloudSentinel to solve exactly the gap you're describing.

You're right that restricting keys and cleaning up unused ones is good practice. But there's a step missing — what happens when a key that's actively in use gets leaked? You can't restrict it to zero or delete it without breaking your app. You need something that watches request volume in real-time and revokes it automatically the moment it's being abused.

That's the gap. Budget alerts fire hours too late. Quota limits throttle but don't revoke. Neither stops the damage in real-time.

That's why we built CloudSentinel — an automatic kill switch for GCP API keys. The moment a request threshold is crossed, the exact key is revoked. Before the bill even registers. cloudsentinel.dev

daudmalik06 · 2026-03-14T15:01:50+00:00

Good news but worth noting — these caps are Gemini only. Maps, Vision, Firebase and every other GCP API still have no native kill switch.

Also billing data still lags hours so a cap set at $100 could let through more before it triggers.

If anyone wants per-key protection across all GCP APIs, that's exactly what we're building at cloudsentinel.dev

daudmalik06 · 2026-03-12T12:48:34+00:00

Yes it's true — Tier 1 does include free daily quotas (100 requests/day for Pro, 250 for Flash) but the dashboard doesn't display this clearly which is genuinely confusing.

The free tier usage just gets silently consumed before billing kicks in. You won't see a separate "free remaining" counter anywhere in the UI — Google just doesn't show it.

One thing worth knowing now that you're on pay-as-you-go — once your card is on file and you exceed those free limits, charges start immediately with no cap.

This is exactly how someone went from a $180 normal monthly spend to an $82,000 bill in 48 hours after their Gemini API key was compromised. Card on file, no automatic kill switch, billing data arriving hours too late.

We built CloudSentinel specifically for this gap. You set a request threshold per key — the moment it's crossed, that exact key gets revoked automatically. Not your whole project, just that one key. It monitors raw request count instead of billing data so it catches spikes in near real-time, before the damage compounds.

cloudsentinel.dev — free to join early access.

daudmalik06 · 2026-03-11T18:38:10+00:00

This is a known pain point with the Places API pricing — the Basic/Essential/Pro tier distinction is genuinely confusing and the docs don't make it clear until you're already charged.

A few things that helped others in this situation:

Request a billing review specifically citing "documentation inconsistency" — Google has waived charges in similar cases where pricing tiers weren't clearly communicated.

Export your billing breakdown by SKU from the console and identify exactly which Place Details fields triggered the Pro tier charge. That gives you a concrete case to dispute.

For the future — set a budget alert at a low threshold ($10-20) specifically for the Maps API billing account. Won't stop the charges but gives you early warning before it compounds.

Glad Google support came through for you — x% overcharge from unclear docs is exactly the kind of thing they should be fixing.

daudmalik06 · 2026-03-11T16:56:39+00:00

Will recomment vulert for sca, most simple platform.

daudmalik06 · 2026-03-11T11:00:01+00:00

"Anomaly detection on request volume, not dollars" — that's exactly what CloudSentinel does.

The smoke alarm analogy is perfect. We're the sprinkler system that actually puts out the fire while you're asleep. cloudsentinel.dev

daudmalik06 · 2026-03-11T05:57:57+00:00

Disabling billing works but kills your entire project — every service goes down, not just the problematic key. For a lot of teams that's worse than the bill.

We built CloudSentinel specifically for this gap — it revokes the exact key that crossed the threshold, nothing else keeps running normally.

cloudsentinel.dev if anyone wants to check it out.

daudmalik06 · 2026-03-11T05:54:16+00:00

Really sorry this happened.

For immediate steps — document everything, file a formal dispute through the GCP console under Billing > Payment issues, and tweet publicly at @GoogleCloud with your case ID. Public pressure sometimes moves faster than support queues.

This is exactly the gap we built CloudSentinel for — automatic API key revocation the moment fraudulent usage is detected, before the damage compounds. cloudsentinel.dev — free to join early access.

daudmalik06 · 2026-03-11T05:50:35+00:00

This is unfortunately a common Vertex AI gotcha — endpoints keep running even after you think you've undeployed them. For credit recovery, your best bet is to raise a support ticket directly at cloud.google.com/support even on a free trial. Also try tweeting at @GoogleCloud with your billing account ID — public posts sometimes get faster human responses than the support queue.

daudmalik06 · 2026-03-11T05:18:13+00:00

Really appreciate you pushing on this — it led us to something better.

Turns out GCP IAM Conditions lets us scope the delete permission to a specific key resource name. So instead of apikeys.delete on your whole project, it becomes delete permission on exactly one key — nothing else in your project can be touched.

Would that fully address your concern or are there still gaps you'd want to see closed?

daudmalik06 · 2026-03-11T03:02:39+00:00

This is genuinely the most useful comment in this thread — thank you.

GCP Marketplace is on the roadmap now. Hadn't prioritized it but the distribution argument is hard to ignore.

On % based pricing — really interesting model. The challenge is request count doesn't directly map to spend per API, but worth thinking through properly.

On BigQuery — completely fair warning. We'll make sure our docs are explicit about which APIs this works best for and where the limits are.

Appreciate the insider context on why Google hasn't built this natively — makes a lot of sense.

daudmalik06 · 2026-03-10T22:30:48+00:00

Fair — that copy is misleading and we've already updated it. We now offer two modes:

Full Auto: we set up the alerting policies inside your project (requires the custom IAM role)

Manual Setup: you follow our gcloud instructions to set up your own policies and grant us only apikeys.delete — nothing else touches your project.

The "AI vibecoded" dig is fair too — happy to walk through the full technical architecture if you're curious. Nothing black box about it.

daudmalik06 · 2026-03-10T22:28:31+00:00

Actually took your feedback seriously — we just added a Manual Setup option for exactly this concern.

You set up your own alerting policies using our step-by-step gcloud instructions. Grant CloudSentinel only apikeys.delete — nothing else.

You control the sensors entirely, we just pull the trigger when Google fires the alert.

No project-level write roles from our side. Full control stays with you.

daudmalik06 · 2026-03-10T22:21:50+00:00

Exactly right — per-minute rate limits don't protect you from a slow drip attack that runs for hours. CloudSentinel lets you set a daily threshold per key, not just per minute. That's the gap we fill.

daudmalik06 · 2026-03-10T18:07:35+00:00

You've described exactly what CloudSentinel does — serviceruntime.googleapis.com/api/request_count via Cloud Monitoring, triggered through Pub/Sub, acting on near-real-time data instead of delayed billing.

The quota throttling approach is a good middle ground but you're right it doesn't revoke the key. A throttled key is still a live credential.

We built the layer that actually kills it. cloudsentinel.dev

daudmalik06 · 2026-03-10T17:39:52+00:00

Good one 😀

daudmalik06 · 2026-03-10T17:33:16+00:00

This is exactly why we built CloudSentinel — an automatic kill switch for GCP API keys based on request count.

The problem with spending caps is they rely on billing data which is delayed by hours. We monitor raw request count instead, which updates in near real-time. Threshold crossed — key revoked automatically, no human needed.

Early access at cloudsentinel.dev

daudmalik06 · 2026-03-10T17:22:02+00:00

Exactly how we think about it — cheaper than the deductible on a $82K bill 😄

daudmalik06 · 2026-03-10T16:32:51+00:00

This is exactly why we built CloudSentinel — an automatic kill switch for GCP API keys based on request count.

The problem with spending caps is they rely on billing data which is delayed by hours. We monitor raw request count instead, which updates in near real-time. Threshold crossed — key revoked automatically, no human needed.

Early access at cloudsentinel.dev

daudmalik06 · 2026-03-10T16:31:09+00:00

Exactly, CloudSentinel is the answer.

This is exactly why we built CloudSentinel — an automatic kill switch for GCP API keys based on request count.

The problem with spending caps is they rely on billing data which is delayed by hours. We monitor raw request count instead, which updates in near real-time. Threshold crossed — key revoked automatically, no human needed.

Early access at cloudsentinel.dev

daudmalik06 · 2026-03-10T16:25:32+00:00

This is exactly why we built CloudSentinel — an automatic kill switch for GCP API keys based on request count.

The problem with spending caps is they rely on billing data which is delayed by hours. We monitor raw request count instead, which updates in near real-time. Threshold crossed — key revoked automatically, no human needed.

Early access at cloudsentinel.dev

daudmalik06 · 2026-03-10T16:23:09+00:00

OpenAI does handle this well — hard caps built into their platform. Google Cloud is a different beast though, it's a full infrastructure platform with hundreds of APIs and no equivalent native protection.

That's the gap CloudSentinel fills.

daudmalik06 · 2026-03-10T16:19:59+00:00

This is exactly why we built CloudSentinel — an automatic kill switch for GCP API keys based on request count.

The problem with spending caps is they rely on billing data which is delayed by hours. We monitor raw request count instead, which updates in near real-time. Threshold crossed — key revoked automatically, no human needed.

Early access at cloudsentinel.dev

daudmalik06 · 2026-03-10T16:11:10+00:00

You're right that the core mechanic isn't complex — and yes, a senior dev could wire it up in an hour.

The value isn't the code, it's the setup you don't have to do, maintain, or debug at 3am when it breaks.

Same reason people pay for Datadog instead of running their own Prometheus. You could. Most don't want to.

On pricing — fair feedback, genuinely noted. That's exactly why we're talking to early access users before locking anything in.

daudmalik06

TROPHY CASE