In February 2026, a developer in Vietnam posted a Google Cloud billing screenshot to Reddit that stopped a lot of people mid-scroll. His usual monthly bill, running a personal project against Google's Gemini API, was about $180. Over February 11th and 12th, it hit $82,314.44.
A credential had been compromised. Google Cloud API keys, it turned out, had quietly become valid for Gemini too, so a key exposed somewhere for one purpose became a live ticket to a frontier model. Security researchers at Truffle Security later scanned public websites and found nearly three thousand more keys in the same state: still live, still billable to someone. This wasn't one unlucky developer. It was a pattern waiting to be found.
He had billing alerts configured. That detail is the one worth sitting with. The alerts fired. They fired after. Cloud billing is metered and retroactive, the invoice tells you what already happened, it doesn't stop it from happening. By the time an alert reaches an inbox, the meter has been running for hours. In this case, two days. Google has not forgiven the charges.
A key to Gemini is a key to your GCP account
The specific failure here is easy to miss. Most developers think of API keys as narrow, a Gemini key opens Gemini, nothing more. But Google Cloud API keys are project-level credentials that predate the AI era. When Google extended them to authenticate Gemini, every existing key in every public repo, in every old config file, in every leaked archive became a potential Gemini key too. The attack surface didn't grow gradually, it expanded overnight, retroactively, for every key ever issued.
That's not unique to Google. It's how credentials work when they accumulate quietly over time: the scope of what a key can do grows faster than anyone's understanding of what it does do. The developer in this story wasn't running a large operation. He had one key for one project. And that key turned out to touch more than he knew.
For a company with dozens of keys across a dozen teams, the exposure isn't one key's worth of risk, it's every key's worst-case scope, multiplied by however many forgotten credentials are still valid in CI, in old branches, in a contractor's dotfiles from last year.
You cannot outsource the alarm to the person selling you the smoke
The most important question in this incident: whose job was it to notice the bill was climbing?
You'd assume the provider's. They can see every call as it happens. But consider the incentive on the other side of that relationship. The provider meters usage in order to bill it, not to protect you from it. Every one of those charges was, from Google's perspective, a successful transaction. There is no version of that business model where the system is designed to aggressively stop you from spending. A circuit breaker costs them revenue.
That isn't a criticism, it's just a structural reality. Your interests and your provider's interests diverge sharply the moment something goes wrong. You want the meter stopped immediately; they have no financial reason to stop it early. If the only mechanism standing between an anomaly and an $82,000 bill is a notification from the party billing you, you don't have a safety mechanism. You have a receipt service.
The alarm has to come from something you own, sitting in the path of the request, with the authority to refuse, not from a party who benefits from letting the traffic run.
Assume there will be an incident. Build for the blast radius, not the prevention.
Security teams spend enormous energy on preventing key leaks. Vaults, rotation schedules, least-privilege policies, all of it valuable, none of it sufficient. The Truffle Security scan found nearly three thousand live Google API keys sitting in public websites. These weren't careless organizations; they were developers who followed reasonable practices and still ended up exposed, often through a dependency, a third-party integration, or a git history that predated their security controls.
The right mental model isn't "how do we prevent a key from leaking", it's "when a key leaks, what does that morning cost us?"
This is how you think about insurance. Nobody buys fire coverage because they expect a fire. They buy it because the day one happens, the difference between manageable and catastrophic was determined entirely by decisions made months earlier, when nothing was on fire. A spending cap on an API key works exactly the same way. It doesn't prevent the leak. It puts a ceiling on what the leak is allowed to cost, the difference, in this developer's exact numbers, between a $20 bad morning and a bill that reportedly put him within sight of bankruptcy.
The organizations that get this right don't have fewer incidents. They have smaller ones.
What a hard cap actually is, and isn't
There's a persistent confusion between a billing alert and a spending cap. They sound similar; they are not the same instrument at all.
A billing alert is a notification that arrives after a threshold has been crossed. It describes the past. By the time it reaches your inbox, the spend is already there, and the meter is still running. The developer had billing alerts. They fired. He still ended up with an $82,000 bill.
A spending cap is an enforcement mechanism that declines requests once a limit is reached. It acts in the present, in the request path, before the provider processes the call. It cannot be circumvented by a billing system being slow to update, it simply refuses the next request. The distinction is the difference between a bank statement and a credit limit. One tells you what you lost; the other prevents the loss.
Most AI providers don't offer hard caps. They offer alerts, which is a different product. Until you have something enforcing limits at the point of the request, something you control, independent of the provider, you are operating on the assumption that nothing goes wrong. That assumption has a known failure rate.
The three questions that don't have answers yet
Strip the incident down and there are three questions every engineering leader should be able to answer about their own AI infrastructure, and almost none currently can.
Where did the money go? Not the monthly total, the breakdown. Which team, which product, which feature drove which spend. Every provider's invoice shows one number for the whole account because everything flows through one credential. Every meaningful boundary inside your business disappears at the provider's billing layer.
What stops a runaway charge? Not "what alerts us", what stops it. If the answer is "we'd see it and turn off the key," that's a human-response-time problem masquerading as a control.
Which vendors touched our data? For compliance, for customer questions, for security reviews. This has an answer only if something was recording it continuously, not reconstructed from memory or vendor invoices after the fact.
These aren't exotic requirements. They're the same controls that exist on every other business-critical system. They simply haven't been pointed at AI infrastructure yet, because AI arrived through engineering teams rather than through procurement, and it moved faster than any process could follow.
The middle setting
Samsung banned ChatGPT across the company in May 2023 after three engineers leaked proprietary source code and meeting recordings to the service in under a month. The ban wasn't irrational, given the choice between an uncontrolled tool and no tool, they chose no tool. That was the only option available to them, because nobody had built the middle setting: the version where the tool stays, but the data boundaries and the spend limits are real.
The developer in this story had only two settings too: the key was live, or the key was deleted. Nothing in between. No per-key ceiling. No circuit breaker in the request path. No way to allow the project to continue while bounding what a bad day could cost.
Building the middle setting, scoped credentials with real limits, enforced at the request, with a complete record underneath, is the practical work that sits between "we approved AI use" and "we actually control it." The gap between those two is where the $82,314 bills live.
Sources: The Register, Tom's Hardware, TechSpot, Truffle Security, Bloomberg (Samsung, May 2023)