Ein kleiner Startup-Betrieb aus Mexiko erlebte ein Szenario, das für Cloud-Umgebungen typisch, aber finanziell existenzbedrohend ist: Ein gestohlener Google Gemini API-Key wurde von Angreifern missbraucht, um in nur zwei Tagen massenhaft Anfragen an KI-Modelle zu stellen. Ergebnis war eine Cloud-Rechnung von über 82.000 US‑Dollar – bei sonst üblichen Monatskosten von rund 180 Dollar.
Vom API-Schlüssel-Diebstahl zur Kostenexplosion um 46.000 %
Nach der Schilderung des betroffenen Entwicklers auf Reddit erfolgte die Kompromittierung des Schlüssels zwischen dem 11. und 12. Februar. In diesem Zeitraum nutzten unbekannte Angreifer intensiv Gemini 3 Pro Image und Gemini 3 Pro Text. Die Folge: Der komplette verfügbare Nutzungsrahmen wurde ausgeschöpft, die Rechnung belief sich auf 82.314 US‑Dollar – ein Anstieg der Kosten um etwa 46.000 % im Vergleich zum üblichen Verbrauch.
Der Entwickler reagierte, indem er den kompromittierten Schlüssel sofort widerrief, die Gemini API deaktivierte, sämtliche Zugangsdaten änderte und sich anschließend an den Google-Support mit der Bitte um Erlass oder Reduzierung der Forderung wandte.
Google verwies in der Antwort auf das Modell der „Shared Responsibility“: Der Anbieter sichert die Cloud-Plattform, der Schutz von Schlüsseln, Tokens und sonstigen Secrets liegt jedoch in der Verantwortung der Kunden. Für kleine Startups kann selbst eine teilweise Zahlung einer derartigen Summe faktisch das Aus bedeuten.
Warum alte Google-API-Schlüssel plötzlich Zugang zur Gemini API bieten
Parallel zu diesem Vorfall führte das Unternehmen Truffle Security eine groß angelegte Analyse öffentlicher Quellen durch. Die Forscher fanden 2.863 gültige Google-API-Schlüssel, die ursprünglich nur als Projektkennungen für Kosten-Tracking vorgesehen waren, nun aber direkten Zugriff auf die Gemini API ermöglichten.
Die Ursache liegt in der Architektur der Google-Cloud-API-Schlüssel. Diese beginnen typischerweise mit dem Präfix AIza und lassen sich mit automatisierten Scans leicht in Quellcode-Repositorien, Websites und öffentlichen Projekten finden. In mehreren offiziellen Google-Dokumentationen – etwa für Google Maps oder Firebase – wird zudem explizit erwähnt, dass diese Keys keine Secrets seien und primär der Projektidentifikation dienten.
Für Google Maps empfiehlt Google bis heute, den API-Schlüssel direkt im HTML zu platzieren. Damit ist er für jeden Besucher und für Suchmaschinen sichtbar. Problematisch wird dies, wenn dieselben Schlüssel später implizit auch für neue Dienste wie Gemini freigeschaltet werden – ohne dass die Besitzer aktiv zustimmen oder gewarnt werden.
Wenn ein „nicht geheimer“ Key zu vollwertigen KI-Zugangsdaten wird
Nach Darstellung von Joe Leon (Truffle Security) sieht ein typisches Szenario so aus: Ein Entwickler generiert vor drei Jahren einen API-Key für Google Maps und bindet ihn entsprechend der Anleitung im frei zugänglichen Frontend-Code ein. Später wird im gleichen Google-Cloud-Projekt die Gemini API aktiviert. Der alte Maps-Key erhält dadurch neue Privilegien und fungiert plötzlich als vollwertige Anmeldeinformation für ein kostenintensives LLM.
Jede Person, die einen solchen Key in einem öffentlichen Repository oder im HTML einer Website findet, kann anschließend:
• Anfragen an Gemini auf Kosten des Kontoinhabers ausführen;
• je nach Konfiguration auf hochgeladene Dateien und Model-Caches zugreifen;
• unbemerkt erhebliche Cloud-Kosten verursachen, die oft erst mit der Monatsrechnung auffallen.
Googles Reaktion und aktueller Stand des Sicherheitsproblems
Truffle Security meldete die Schwachstelle an Google und belegte sie mit einem Beispiel einer öffentlichen Website, auf der ein 2023 platzierter Key Zugang zur Gemini API eröffnete. Der Report wurde zunächst als „erwartetes Systemverhalten“ abgelehnt.
Nachdem die Forscher vergleichbare Konstellationen innerhalb von Googles eigener Infrastruktur demonstriert hatten, stufte Google den Fall als Sicherheitsbug hoher Schwere ein und forderte den vollständigen Satz der 2.863 identifizierten Schlüssel an. Nach Unternehmensangaben arbeitet Google an einer Korrektur und hat bereits proaktive Mechanismen eingeführt, um geleakte Keys beim Zugriff auf die Gemini API zu erkennen und zu blockieren.
Best Practices: So schützen Unternehmen ihre Google-Cloud- und Gemini-API-Schlüssel
Truffle Security empfiehlt allen Google-Cloud-Nutzern einen umfassenden Audit ihrer Projekte und Repositories, etwa mit dem Open-Source-Tool TruffleHog, das Quellcode, CI/CD-Pipelines und Webressourcen auf geleakte Secrets und API-Schlüssel scannt.
Aus Sicht der Cybersicherheit zeigt der Vorfall ein wiederkehrendes Muster: Anfangs harmlose, öffentliche Identifikatoren erhalten im Zeitverlauf zusätzliche, sicherheitskritische Privilegien. Wenn große Plattformen KI-Funktionen zügig in bestehende Produkte integrieren, werden alte Schlüssel und Tokens oft unbemerkt zu Zugangspässen für neue, teure Dienste.
Um Risiken zu minimieren, sollten Organisationen insbesondere:
• alle API-Schlüssel standardmäßig wie Secrets behandeln und niemals unverschlüsselt in Frontend-Code, öffentlichen Repos oder Foren veröffentlichen;
• Scope und Berechtigungen pro Key strikt begrenzen, getrennte Schlüssel pro Dienst nutzen und Schlüssel regelmäßig rotieren;
• bei Aktivierung neuer Services (insbesondere LLM- und KI-APIs) bestehende Keys prüfen und deren Rechte anpassen oder neu ausstellen;
• automatisches Secret-Scanning in jeden Schritt der CI/CD-Pipeline integrieren;
• in Google Cloud Budgets, Alarme und harte Ausgabengrenzen konfigurieren, damit Anomalien in Stunden statt erst nach Wochen auffallen;
• wo möglich Service Accounts und OAuth anstelle einfacher API-Keys nutzen, um granularere Kontrolle und Protokollierung zu erreichen.
Die geschilderte Gemini-API-Panne macht deutlich, dass bereits ein einziger „nicht geheimer“ Schlüssel ausreicht, um einen sicherheitsrelevanten und finanziell gravierenden Vorfall auszulösen. Unternehmen, die KI- und Cloud-Dienste nutzen, sollten das Management von API-Schlüsseln als zentralen Bestandteil ihrer Informationssicherheitsstrategie begreifen – inklusive technischer Kontrollen, klarer Prozesse und regelmäßiger Schulungen. Wer frühzeitig in diese Schutzmaßnahmen investiert, senkt nicht nur das Risiko von Daten- und Kostenvorfällen, sondern stärkt insgesamt die Resilienz der eigenen Cloud-Architektur.
