With PerfectScale™ for Commitments, we're bringing rate optimization to every cloud
Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

The Gemini API Key Abuse Fix Is Here And It Has a Deadline

By John D'EliaJun 17, 20265 min read

This page is also available in Deutsch, Español, Français, Italiano, 日本語, and Português.

TL;DR

  • Google is phasing out standard API keys for the Gemini API in two steps: unrestricted standard keys stop working June 19, 2026; all standard keys stop working September 2026
  • If you have unrestricted keys, you do not have much time to either restrict them or migrate to the new auth key type
  • New "authorization keys" are bound to a service account, which addresses the key abuse vector I covered in a previous post
  • Run our free scanner to find your exposed keys: github.com/doitintl/gcp-apikey-check

A Little History

Some weeks ago I wrote about how nefarious actors were obtaining unscoped and unrestricted Google API keys from web pages or accidentally published keys. Once the keys were obtained, these actors would quickly generate Gemini content and disappear, leaving the unknowing key owner with a large Gemini bill typically in the tens of thousands of dollars, sometimes more. We've seen our share of these cases and googlecloud sub-reddit is full of horror stories.

Recently, Google made changes to newly created Gemini API keys. It looks like Google is finally taking action to close the gap with existing keys that will affect Gemini API users. The changes are good but the timeline is aggressive!

What's Changing

Google is transitioning the Gemini API from standard keys to authorization (auth) keys.

Standard keys associate requests with a Google Cloud project for billing and quota, but they don't identify who's making the call. There's no caller identity, which limits what access controls can be applied.

Auth keys are bound to a specific Google Cloud service account. Requests made with an auth key are processed under that service account's identity, which enables proper IAM-based access control. Google reports that auth keys will also have faster acting fraud detection controls.

The migration timeline:

  • June 19, 2026: The Gemini API will reject requests from unrestricted standard keys. Standard keys with explicit API restrictions applied will continue to work.
  • September 2026: The Gemini API will reject requests from all standard keys. You'll need to be on auth keys by then.

All new and recently created keys in Google AI Studio are already auth keys by default.

How do Auth Keys Help?

With a standard key that had no API scoping, any malicious actor who found it could test it against the Gemini API and start generating content billed to your account. That was the attack described in my previous post.

Auth keys close that gap in a few ways. They're scoped to the Gemini API by default, so a leaked auth key can't be used with other Google APIs. More importantly, they're tied to a service account, which means IAM access controls can be applied. This is something that wasn't possible with standard keys. Requests made with an auth key also show up in audit logs, and Google's leaked-secret detection can act on them faster because there's an identity to revoke.

That said, auth keys aren't a perfect solution. Leaked or exfiltrated auth keys could still potentially be used to generate content and run up a bill. We don't know how effective Google's anti-fraud systems are for these cases yet.

The better solution is to not use API keys at all. If you're using Gemini on the backend, consider migrating to the Gemini Enterprise Agent Platform, which uses short-lived IAM credentials instead of static keys; nothing to leak, nothing to rotate.

What You Should Do

Before June 19 2026: Secure any unrestricted standard keys

Run the scanner to find your unrestricted keys across your GCP org:

Terminal window
git clone https://github.com/doitintl/gcp-apikey-check
cd gcp-apikey-check
uv sync


# Scan an entire organization (**recommended**)
uv run gcpkeyscan.py --org-id YOUR_ORG_ID


# Or a single project
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

For any unrestricted keys you find, you have two options:

Option 1 — Restrict the key (buys time until September): In Google AI Studio, go to the API Keys page, find keys marked "Unrestricted", hover over the label, click "Add restrictions", and select "Restrict to Gemini API only."

Option 2 — Migrate to an auth key now (recommended):

  1. Go to AI Studio API Keys
  2. Click "Create API key" — new keys are auth keys by default now
  3. Update your app code, environment variables, and deployment configs with the new key
  4. Test, test, test
  5. Delete or revoke the old standard key

Refer to Google's migration documentation for additional details should you run in to issues.

Before September 2026: Migrate all remaining standard keys

Any standard keys that you restricted in the first step will stop working in September. Use the same migration steps above to create auth key replacements and update your applications.

The Bigger Picture

Migrating to auth keys is an improvement, but the underlying best practice hasn't changed.

For most Google Cloud workloads: Workload Identity Federation and Application Default Credentials with IAM roles are better options — no key to leak, no rotation to manage, proper audit trails by default. If you are using Gemini API for production use, we recommend moving over to Gemini Enterprise Agent Platform, which uses short-term credentials instead of static API keys along with other features useful for production use like vendor support.

For Maps and Firebase applications: these keys remain as standard API keys, however, you should follow best practices and restrict each key to the specific API(s) it needs, add application restrictions, and never put Maps or Firebase keys on the same key as Gemini or other AI APIs. If you can, keep Gemini keys in a separate project for extra measure.

Next Steps

The June 19 deadline is here. If you haven't audited your keys yet, do it now: