Gemini API Key Restriction Enforcement Is Live: What Routing Teams Must Check Now

Google's Gemini API stopped accepting unrestricted standard API keys as of June 19, 2026. If your routing layer or gateway is proxying Gemini requests through a key that has no explicit API restrictions configured, those calls now return errors. The enforcement landed as announced — operators who missed the deadline are discovering broken production pipelines today.

What changed

Google sent an "Action Required" notice to all Gemini API users several weeks before the deadline, posted the enforcement announcement in the official Gemini API forum, and set a hard cutoff: starting June 19, 2026, the Gemini API will stop accepting requests made with unrestricted standard keys.

An "unrestricted" key is any key created in Google Cloud Console or AI Studio that has not had explicit API-level restrictions applied. Prior to June 19, those keys worked fine for Gemini requests. As of today, they do not.

Keys that continue working are those with at least one of the following restrictions applied in Google Cloud Console:

• API restrictions set to the Gemini API (or a specific subset of APIs).
• Application restrictions with allowed referrers, IP ranges, or Android/iOS app fingerprints.

The fix is simple: open Google Cloud Console → Credentials, find every key used for Gemini requests, and ensure it has a non-empty API restrictions list. The Gemini API and/or Generative Language API must appear in the list.

Why it matters for Gemini routing

For teams routing to Google Gemini through any gateway — whether that is a self-hosted proxy, a shared inference platform, or a custom routing layer — the API key is a shared credential that sits in gateway configuration, not in application code. That means:

1. Gateway credentials age silently. A key created at launch and never audited is almost certainly unrestricted. If it has been working for months, it will fail now with no warning other than a sudden 403 or service-disruption error.

2. Per-key restrictions are not inherited. If your gateway rotates keys or uses a pool, each key needs to be individually restricted. Restricting one key in a pool does not protect the others.

3. Routing failover may mask the problem briefly. If your routing policy falls back to another provider on 4xx, a Gemini key rejection may be silently absorbed — until you notice Gemini's share of routed traffic has dropped to zero.

4. The restriction is at the credential layer, not the quota layer. This is not a rate limit. Adding usage credits will not fix it. The key itself must carry the restriction metadata before Google's auth layer will pass it through.

What to audit

Operators routing to Gemini should work through this checklist:

Step 1 — List all Gemini credentials in use. Query your gateway's credential store for any key that matches AIza*. These are Google standard API keys.

Step 2 — Check restriction status. For each key, open Google Cloud Console → Credentials → the key's details page. Under "API restrictions," the value must NOT be "None" or "Don't restrict key."

Step 3 — Apply restrictions. If a key is unrestricted, set the API restrictions to include the Generative Language API (the API that backs the Gemini API). Applying the restriction takes effect immediately; no redeploy needed.

Step 4 — Test. Make a lightweight request (model: gemini-3.5-flash, minimal tokens) directly through the key after restricting it to confirm the 200 response comes back.

Step 5 — Rotate. This enforcement is also a forcing function to audit key age and scope. Consider rotating any key older than 90 days and narrowing the restriction to only the specific Gemini API surface your routing layer actually calls (Generative Language vs. Vertex AI vs. AI Studio).

The broader credential hygiene signal

This enforcement is consistent with a pattern across all major providers: API credentials are becoming more, not less, restricted over time. Google began this cycle when Gemini's API launch made formerly-public-safe Firebase/GCP API keys suddenly capable of calling a paid, quota-consuming model. The research community documented thousands of exposed keys that were technically public by Google's own Firebase guidance, but which became live Gemini credentials overnight.

The June 19 enforcement closes the other side of that gap: even keys that are not publicly exposed but are simply "unrestricted" inside your own project are no longer acceptable.

For routing teams, the lesson is operational: treat Gemini API key restriction status as part of your credential rotation checklist, not a one-time setup step. Each new key needs to ship with restrictions, and existing keys need a periodic audit pass.

What to watch

Google has not announced further enforcement steps for keys that have application restrictions but no API restrictions, or for keys used exclusively through the Vertex AI endpoint (which uses service accounts, not standard API keys). Those remain unaffected.

The Gemini Enterprise Agent Platform, which uses OAuth 2.0 and service account credentials, is unaffected. This enforcement applies exclusively to the standard AIza* API key auth path used by AI Studio and the direct Gemini API.

Related

• Gemini Enterprise Agent Platform Memory Bank and Sessions Go GA
• Google Antigravity and Managed Agents Reshape the Gemini API
• Vertex AI Extensions Deprecation: Migration to Agent Platform
• TheRouter Docs