Google's API Keys Now Have a Price Tag Nobody Agreed To

Francis de Souza, Google's cloud chief operating officer, had a clear message for an audience in Los Angeles last week: companies building with AI need to treat security as a foundational layer, not a feature checklist. "Security is not something you can bolt on later," he said. "And it's not something you can leave up to employees to do on their own."

The audience heard a seasoned executive talking about responsible deployment. The developers who have been fighting Google over five-figure billing invoices heard something else.

The Silent Upgrade

For over a decade, Google told developers that API keys — strings of characters that connect apps to Google services like Maps — were safe to embed in publicly visible code. This was intentional. The keys functioned as project identifiers for billing, not as secrets guarding access to sensitive systems. Firebase's own documentation stated explicitly: API keys are not secrets. Google's Maps JavaScript documentation instructed developers to paste keys directly into HTML.

Then Gemini arrived.

When a developer enables the Gemini API on a Google Cloud project, any existing API keys in that project silently gain access to Gemini endpoints — including ones sitting in public JavaScript on their website. No warning. No confirmation dialog. No email notification. The developer finds out when someone else starts running up the bill.

Joe Leon, a threat researcher at Truffle Security Co., described it as a retroactive privilege escalation. "You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed," he told The Register. "Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Nobody told you."

Truffle Security scanned the November 2025 Common Crawl dataset and found 2,863 live Google API keys, originally deployed for public services like Maps, that now also authenticate to Gemini. The victims included major financial institutions, security companies, and global recruiting firms. Leon found one of the exposed keys on Google's own infrastructure.

What $10,000 Looks Like

Rod Danan runs Prentus, an interview-prep platform that tracks job placements for universities. He has used Google Maps API for years without incident, paying roughly $50 a month. His API key was embedded in his application's front end, exactly as Google's own documentation prescribed.

In March, he received an email alert saying he was being charged $3,000. "What the hell's going on?" he told The Register. "As I'm searching, five minutes go by and another $5,000 get charged. It's just draining my money." His credit card was ultimately charged $10,138 — for Veo 3 video generation and Gemini image output tokens, services he has never used or enabled.

Danan had spending caps in place. What he did not know was that Google's automated systems had been upgrading his account's spending tier based on his payment history — automatically raising his effective ceiling from $250 to $100,000. The spending alert fired after the damage was done.

Isuru Fonseka, a Sydney-based developer who has been building in Google Cloud for ten years, woke up to a similar attack in late April. His credit card company declined some of the charges — he had set a $250 hard cap — but approximately AUD $17,000 in charges still went through. Google support told him the same thing it told Danan: no fraud was found.

Google's position, as stated to The Register, is that this is an industry-wide problem. The company says the vast majority of incidents involve compromised user credentials scraped from public code repositories like GitHub. It encourages customers to implement multi-factor authentication, audit API keys regularly, and never commit credentials to public repositories.

The Fix That Keeps the Problem Alive

Google announced changes to its spending tier structure on March 16, 2026. Under the new policy, accounts in Tier 1 — which caps spending at $250 — are automatically upgraded to Tier 2 after $100 in charges, and to Tier 3 after $1,000 in charges plus 30 days of account history. Tier 3 carries a $20,000 to $100,000 cap.

The policy is described as a feature: it gives developers "higher rate limits and increased monthly quota as soon as the criteria are met." For a developer who is legitimately scaling, this is useful. For a developer whose API key has been stolen and is being used to run up Veo 3 bills, it is the mechanism that turns a $250 problem into a $10,000 emergency.

Leon told The Register he was not aware that spending tiers auto-escalated. "That kind of defeats a little bit of the purpose," he said.

Google told The Register that Fonseka's account usage — driven by the attacker — triggered the automated tier upgrade, based on meeting Tier 3 qualification criteria including at least $1,000 in payments to Cloud and 30 days since the first payment. The company said it has since taken steps including rolling out new Gemini API key types with different prefixes and mandating that users configure API restrictions when creating keys. It says it is no longer possible to create a key that can access both Gemini and Maps.

The company reimbursed both Danan and Fonseka after The Register published its investigation. But the underlying logic that produced the bills — silent key expansion, auto-escalating tiers, and the decade-long message that these keys were not secrets — remains in place.

What de Souza Did Not Say

De Souza's talk at the Los Angeles event covered real ground. The attack surface for AI systems has expanded beyond anything the traditional security perimeter was designed to handle. Breach-to-lateral-movement time, he said, has dropped from eight hours to 22 seconds. Agents moving through a company's internal systems can surface forgotten data repositories nobody has thought about in years. The answer, he argued, is AI-native, agentic defense — machines fighting machines at machine speed.

None of this is wrong. The problem is that it describes a world where the platform providers are the trusted arbiters of what secure means. The Gemini API key situation is an example of what happens when that trust is placed in a system whose own documentation and default behaviors created the conditions for harm.

The developers who followed Google's documentation and embedded their keys in client-side code are not bad actors. They are not negligent. They did exactly what they were told to do by the company whose platform they trusted. The bill arrived anyway.

Google's platform approach to AI security is real. So is the gap between that message and the one its own infrastructure is sending.