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

Cloud Intelligence™

Schluss mit Gemini-API-Key-Missbrauch – aber die Uhr tickt

By John D'EliaJun 17, 20265 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

TL;DR

  • Google stellt die Standard-API-Keys für die Gemini API in zwei Schritten ab: unrestricted Standard-Keys funktionieren ab dem 19. Juni 2026 nicht mehr; alle Standard-Keys werden im September 2026 abgeschaltet
  • Wer unrestricted Keys einsetzt, hat nicht mehr viel Zeit, diese einzuschränken oder auf den neuen Auth-Key-Typ zu migrieren
  • Die neuen "Authorization Keys" sind an einen Service Account gebunden und schließen damit die Missbrauchslücke, die ich in einem früheren Beitrag beschrieben habe
  • Mit unserem kostenlosen Scanner finden Sie exponierte Keys: github.com/doitintl/gcp-apikey-check

Ein kurzer Rückblick

Vor einigen Wochen habe ich beschrieben, wie Angreifer ungeschützte und unrestricted Google-API-Keys aus Webseiten oder versehentlich veröffentlichten Quellen abgreifen. Sobald sie einen Key in der Hand hatten, generierten sie in kurzer Zeit massenhaft Gemini-Content und verschwanden – zurück blieb der ahnungslose Key-Inhaber mit einer Gemini-Rechnung von typischerweise mehreren zehntausend Dollar, manchmal noch mehr. Wir haben einige dieser Fälle gesehen, und im googlecloud-Subreddit häufen sich die Horrorstorys.

Vor Kurzem hat Google neu erstellte Gemini-API-Keys angepasst. Es sieht so aus, als ginge Google das Problem nun endlich auch bei bestehenden Keys an – mit spürbaren Folgen für alle, die die Gemini API nutzen. Die Änderungen sind gut, aber der Zeitplan ist sportlich!

Was sich ändert

Google stellt die Gemini API von Standard Keys auf Authorization Keys (Auth Keys) um.

Standard Keys ordnen Requests einem Google-Cloud-Projekt für Abrechnung und Kontingent zu, sagen aber nichts darüber aus, wer den Aufruf tätigt. Eine Aufrufer-Identität fehlt – und damit auch die Grundlage für ernsthafte Zugriffskontrollen.

Auth Keys sind an einen bestimmten Google-Cloud-Service-Account gebunden. Requests mit einem Auth Key werden unter der Identität dieses Service Accounts verarbeitet, was eine saubere IAM-basierte Zugriffskontrolle erlaubt. Laut Google greifen bei Auth Keys zudem schneller wirkende Mechanismen zur Betrugserkennung.

Der Migrations-Zeitplan:

  • 19. Juni 2026: Die Gemini API lehnt Requests von unrestricted Standard Keys ab. Standard Keys mit explizit gesetzten API-Restriktionen funktionieren weiter.
  • September 2026: Die Gemini API lehnt Requests von allen Standard Keys ab. Bis dahin muss die Migration auf Auth Keys abgeschlossen sein.

Alle neu und kürzlich in Google AI Studio erstellten Keys sind ohnehin schon standardmäßig Auth Keys.

Wie helfen Auth Keys?

Bei einem Standard Key ohne API-Scoping konnte jeder Angreifer, der ihn fand, ihn gegen die Gemini API ausprobieren und auf Ihre Kosten Content generieren. Genau dieser Angriff war Thema meines vorherigen Beitrags.

Auth Keys schließen diese Lücke gleich mehrfach. Sie sind standardmäßig auf die Gemini API beschränkt – ein geleakter Auth Key lässt sich also nicht für andere Google-APIs missbrauchen. Wichtiger noch: Sie sind an einen Service Account gebunden, sodass IAM-Zugriffskontrollen greifen. Genau das war bei Standard Keys nicht möglich. Requests mit einem Auth Key tauchen außerdem in Audit-Logs auf, und Googles Erkennung geleakter Secrets kann schneller reagieren, weil eine widerrufbare Identität dahintersteht.

Trotzdem sind Auth Keys keine perfekte Lösung. Geleakte oder exfiltrierte Auth Keys lassen sich weiterhin missbrauchen, um Content zu generieren und Kosten zu verursachen. Wie wirksam Googles Anti-Fraud-Systeme in solchen Fällen sind, lässt sich noch nicht abschätzen.

Die bessere Lösung lautet: gar keine API-Keys verwenden. Wer Gemini im Backend einsetzt, sollte über den Umstieg auf die Gemini Enterprise Agent Platform nachdenken. Sie nutzt kurzlebige IAM-Credentials statt statischer Keys – nichts, was leaken kann, nichts, was rotiert werden muss.

Was Sie jetzt tun sollten

Bis zum 19. Juni 2026: Unrestricted Standard Keys absichern

Führen Sie den Scanner aus, um unrestricted Keys in Ihrer gesamten GCP-Organisation aufzuspüren:

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


# Eine gesamte Organisation scannen (**empfohlen**)
uv run gcpkeyscan.py --org-id YOUR_ORG_ID


# Oder ein einzelnes Projekt
uv run gcpkeyscan.py --project-id YOUR_PROJECT_ID

Für jeden gefundenen unrestricted Key haben Sie zwei Möglichkeiten:

Option 1 – Key einschränken (verschafft Zeit bis September): Öffnen Sie in Google AI Studio die Seite "API Keys", suchen Sie Keys mit der Markierung "Unrestricted", fahren Sie mit der Maus über das Label, klicken Sie auf "Add restrictions" und wählen Sie "Restrict to Gemini API only."

Option 2 – Jetzt auf einen Auth Key migrieren (empfohlen):

  1. Öffnen Sie AI Studio API Keys
  2. Klicken Sie auf "Create API key" – neue Keys sind jetzt standardmäßig Auth Keys
  3. Übernehmen Sie den neuen Key in Ihren Anwendungscode, die Umgebungsvariablen und die Deployment-Konfigurationen
  4. Testen, testen, testen
  5. Löschen oder widerrufen Sie den alten Standard Key

Details finden Sie in Googles Migrations-Dokumentation, falls Sie auf Probleme stoßen.

Bis September 2026: Alle verbleibenden Standard Keys migrieren

Alle Standard Keys, die Sie im ersten Schritt nur eingeschränkt haben, werden im September abgeschaltet. Nutzen Sie die gleichen Migrationsschritte wie oben, um Auth-Key-Nachfolger anzulegen und Ihre Anwendungen umzustellen.

Das größere Bild

Die Migration auf Auth Keys ist ein Fortschritt – an der grundlegenden Best Practice ändert sie nichts.

Für die meisten Google-Cloud-workloads gilt: Workload Identity Federation und Application Default Credentials mit IAM-Rollen sind die bessere Wahl – kein Key zum Leaken, keine Rotation zu verwalten, saubere Audit-Trails ab Werk. Wer die Gemini API produktiv einsetzt, dem empfehlen wir den Wechsel auf die Gemini Enterprise Agent Platform. Sie setzt auf kurzlebige Credentials statt statischer API-Keys und bringt weitere produktionsrelevante Funktionen mit, etwa Vendor-Support.

Für Maps- und Firebase-Anwendungen: Diese Keys bleiben Standard-API-Keys. Halten Sie sich aber an die Best Practices – beschränken Sie jeden Key auf die konkret benötigte(n) API(s), setzen Sie Application Restrictions ein und kombinieren Sie Maps- oder Firebase-Keys niemals mit Gemini- oder anderen AI-APIs auf demselben Key. Wenn möglich, halten Sie Gemini-Keys in einem separaten Projekt – als zusätzliche Sicherheitsschicht.

Nächste Schritte

Die Deadline am 19. Juni rückt näher. Falls Sie Ihre Keys noch nicht geprüft haben, ist jetzt der richtige Moment: