KI-API-Schlüssel geleakt: sperren, Kosten prüfen, Ursache finden

Ist ein API-Schlüssel von OpenAI, Anthropic, Google oder Mistral öffentlich geworden, löschst du ihn sofort in der Konsole des Anbieters und legst einen neuen an. Danach siehst du nach, wer ihn in der Zwischenzeit benutzt hat, und setzt ein Ausgabenlimit. Erst dann lohnt die Suche, wie er hinausgekommen ist. Die Reihenfolge ist wichtig, weil jeder Schritt vor dem Löschen mit einem gültigen Schlüssel in fremder Hand passiert.

Ein Schlüssel, der einmal öffentlich war, ist verbrannt, auch wenn er nur fünf Minuten sichtbar war. Ihn aus dem Code zu entfernen ändert daran nichts. GitHub schreibt in der eigenen Anleitung zum Entfernen sensibler Daten, dass ein Geheimnis als erster Schritt zu widerrufen oder zu ersetzen ist, bevor man an den Verlauf geht (GitHub, Removing sensitive data). Ein gelöschter Schlüssel ist wertlos, egal wo er noch herumliegt.

Wo sperrst du den Schlüssel bei welchem Anbieter?#

Die Pfade stammen aus der Dokumentation der Anbieter, Stand 25.10.2026. Die Bezeichnungen sind die englischen der Oberflächen.

Quellen: OpenAI API-Referenz, Authentication und Spend limits; Anthropic Schlüssel kompromittiert, Workspaces und Rate limits; Google Gemini API keys und Billing; Mistral API keys und Usage and limits.

Was zu tun ist, in dieser Reihenfolge#

Der Weg dauert eine halbe Stunde, wenn nur ein Schlüssel betroffen ist.

1. Schlüssel löschen. In der Konsole des Anbieters, Pfad laut Tabelle. Bei OpenAI wirkt das laut API-Referenz „within a few seconds“. Google empfiehlt für den Wechsel die umgekehrte Reihenfolge: erst neuer Schlüssel, dann den alten deaktivieren. Liegt der Schlüssel öffentlich herum, sind ein paar Minuten Ausfall billiger als ein paar Minuten fremde Nutzung.
2. Verbrauch prüfen. Die letzten Tage im Usage-Dashboard durchgehen: Spitzen, Modelle, die du nicht nutzt, Uhrzeiten, zu denen deine Anwendung nicht läuft. Bildschirmfotos davon machen, die brauchst du für den Support.
3. Ausgabenlimit setzen. Siehe nächster Abschnitt.
4. Fundstelle finden und schließen. Repository, Website, Workflow-Export, Bildschirmfoto, Chat. Solange die Ursache bleibt, leakt auch der nächste Schlüssel.
5. Neuen Schlüssel anlegen, richtig abgelegt. Mit eingeschränkten Rechten, in einer Umgebungsvariable oder einem Secret-Manager, siehe unten. Wer ihn in dieselbe Datei kopiert, macht in einer Woche dasselbe noch einmal.
6. Andere Zugangsdaten aus derselben Datei ersetzen. Stand der KI-Schlüssel in einer .env, die ins Repository geraten ist, standen dort meist auch Datenbankpasswort oder Mail-Zugang. Alles aus der Datei gilt als verbrannt.
7. Bei fremder Nutzung den Support informieren. Bei OpenAI über das Formular für „Unauthorized Activity“ (OpenAI, unbekannte Aktivität), bei Anthropic über den Support, mit den Bildschirmfotos aus Schritt 2.
8. Prüfen, ob Daten abrufbar waren. Das ist die Frage nach der Datenpanne, eigener Abschnitt weiter unten.

Wurde nicht nur ein Schlüssel öffentlich, sondern das ganze Konto übernommen, gilt zuerst die Liste aus ChatGPT-Konto gehackt: Passwort, Sitzungen, zweiter Faktor. Ein Angreifer im Konto legt sich sonst einfach einen neuen Schlüssel an.

Welche Ausgabenlimits gibt es heute?#

Alle vier Anbieter kennen eine monatliche Obergrenze. Sie unterscheiden sich darin, ob sie Anfragen stoppt oder nur warnt.

OpenAI trennt Warnung und Sperre. Ein Ausgabenlimit überwacht zunächst nur, erst mit eingeschaltetem „hard limit“ schlagen Anfragen danach mit 429 fehl. Limits gibt es für die ganze Organisation und für jedes Projekt einzeln. OpenAI schreibt selbst, dass die Durchsetzung nicht sofort greift und der erfasste Betrag das Limit leicht überschreiten kann (OpenAI, Spend limits).

Anthropic hat eine Obergrenze je Nutzungsstufe, darunter kannst du auf der Billing-Seite unter „Spend limits“ eine eigene setzen. Ist sie erreicht, antworten Anfragen mit 400 und der Meldung „You have reached your specified API usage limits“. Für jeden Workspace außer dem Default Workspace lässt sich zusätzlich ein eigenes Monatslimit mit Warnschwellen setzen (Anthropic, Rate limits, Workspaces).

Google erlaubt in AI Studio eine Obergrenze je Projekt, setzen dürfen sie Konten mit der Rolle Editor, Owner oder Admin im Projekt. Die Abrechnungsdaten in AI Studio können laut Google bis zu etwa zehn Minuten hinterherhinken (Google, Gemini Billing). In diesen zehn Minuten wird weiter verbraucht.

Mistral setzt ein Limit für die Organisation und optional je Workspace; Workspaces haben ohne Einstellung keine eigene Obergrenze. Ist ein Limit erreicht, wird der API-Zugang bis zum Monatsbeginn oder bis zur Erhöhung ausgesetzt (Mistral, Usage and limits).

Ein Limit ist eine Haftungsgrenze, kein Schutz. Es begrenzt den Schaden auf den Betrag, den du einstellst, und es stoppt bei Missbrauch auch deine eigene Anwendung. Deshalb gehört es knapp über den normalen Monatsverbrauch, nicht auf das Zehnfache.

Wo ist der Schlüssel hinausgekommen?#

Meist ist es ein Repository. Die anderen Wege sind schwerer zu finden, weil niemand sie automatisch durchsucht.

Git-Repository. Der Schlüssel aus dem letzten Commit zu entfernen hilft nicht, denn jeder frühere Commit enthält ihn weiter. Mit git log -p --all -S 'ANFANG-DES-SCHLÜSSELS' siehst du jeden Commit auf allen Zweigen, der die Zeichenfolge hinzugefügt oder entfernt hat (git log). Wer den Verlauf wirklich bereinigen will, nimmt laut GitHub git-filter-repo ab Version 2.47 mit --sensitive-data-removal. GitHub nennt die Grenzen gleich mit: Forks behalten die Daten, fremde Klone behalten den alten Verlauf, und zwischengespeicherte Ansichten entfernt der GitHub-Support nur auf Anfrage und nur, wenn das Ersetzen des Schlüssels das Risiko nicht schon beseitigt (GitHub, Removing sensitive data). Für einen gelöschten Schlüssel lohnt das meist nicht, für personenbezogene Daten im selben Commit schon.

Website-JavaScript. Ruft eine Website die KI-API direkt aus dem Browser auf, steht der Schlüssel im ausgelieferten Code, und jeder Besucher kann ihn in den Entwicklerwerkzeugen lesen. OpenAI schreibt ausdrücklich, den Schlüssel nicht „in any client-side code such as browsers or apps“ offenzulegen (OpenAI, Authentication), Google, dass Schlüssel in clientseitigem Code von Nutzern ausgelesen werden können, und empfiehlt einen Proxy auf dem eigenen Server (Google, Gemini API keys). Hier hilft kein Löschen im Repository: Solange die Seite so gebaut ist, liefert sie auch den neuen Schlüssel aus.

n8n-Export. Zugangsdaten speichert n8n getrennt vom Workflow, ein Export enthält nur deren Namen und IDs. Die Ausnahme nennt n8n selbst: HTTP-Request-Knoten, die aus einem cURL-Befehl importiert wurden, können die Authentifizierungs-Kopfzeilen enthalten (n8n, Export und Import). Ein Workflow, der so in einem Forum oder einer Vorlagensammlung gelandet ist, enthält den Schlüssel im Klartext. Wie man n8n so betreibt, dass Zugangsdaten im Credential-Speicher und nicht im Knoten stehen, zeigt n8n selbst hosten.

Bildschirmfoto, Video, Chat. Ein Bildschirmfoto der Konsole im Support-Ticket, ein Tutorial-Video mit eingeblendeter .env, ein Schlüssel im Teams-Chat an den Kollegen. Das durchsucht kein Dienst automatisch. Wenn du weißt, dass es passiert ist, ist der Schlüssel genauso verbrannt wie im Repository.

MCP- und Agenten-Konfiguration. Eine .mcp.json oder eine Konfigurationsdatei eines Agenten mit eingetragenem Schlüssel, die mit dem Projekt geteilt wird. Was dort hineingehört und was nicht, steht in MCP-Server sicher einsetzen.

Was die Anbieter schon von selbst tun#

GitHub durchsucht öffentliche Repositorys automatisch und kostenlos nach Schlüsseln, und zwar im gesamten Git-Verlauf auf allen Zweigen (GitHub, About secret scanning). Für Anbieter im Partnerprogramm geht ein Fund direkt an den Anbieter, der dann entscheidet, ob er den Schlüssel widerruft, einen neuen ausstellt oder dich kontaktiert (GitHub, Secret scanning for partners).

Laut GitHubs Musterliste vom 25.10.2026 sieht das für die vier Anbieter so aus (GitHub, Supported patterns):

Anthropic schreibt, dass ein so gemeldeter Claude-Schlüssel automatisch deaktiviert wird (Anthropic, API-Schlüssel sicher halten). OpenAI deaktiviert nach eigener Angabe Schlüssel sofort, die es im öffentlichen Internet oder in einer App aus einem App-Store findet (OpenAI, Konto absichern). Google nennt für die neuen, an ein Dienstkonto gebundenen Gemini-Schlüssel eine schnell wirkende Sperre erkannter geleakter Schlüssel (Google, Gemini API keys).

Darauf verlassen kannst du dich nicht. Das Partnerprogramm deckt nur öffentliche Repositorys und npm-Pakete ab. Privates Repository mit zu vielen Leuten, Website-Code, Bildschirmfoto, Chat: dort sucht niemand für dich.

Wie legst du den neuen Schlüssel richtig ab?#

Nur auf dem Server, nie im Browser. Der Schlüssel liegt in einer Umgebungsvariable oder einem Secret-Manager. Das empfehlen OpenAI (Production best practices) und Anthropic, das für die lokale Entwicklung eine .env nennt, die in .gitignore steht, und für den Betrieb den Secret-Manager des Cloud-Anbieters (Anthropic, API-Schlüssel sicher halten).

Ein Schlüssel je Anwendung und Umgebung. Ein Schlüssel für die Website, ein anderer für den n8n-Ablauf, ein dritter für die Entwicklung. Anthropic begründet das damit, dass sich ein kompromittierter Schlüssel dann sperren lässt, ohne alles andere mitzunehmen. Bei OpenAI sind dafür Projekte gedacht, bei Anthropic und Mistral Workspaces: Ein Mistral-Schlüssel gilt nur im Workspace, in dem er angelegt wurde, ein Anthropic-Schlüssel kann auf einen Workspace beschränkt werden.

Minimale Rechte. Bei OpenAI lässt sich beim Anlegen „Restricted“ wählen und je Endpunkt festlegen, ob der Schlüssel lesen, schreiben oder gar nichts darf; voreingestellt ist „All“ (OpenAI, API-Key-Berechtigungen). Ein Schlüssel, der nur Texte erzeugen soll, braucht keinen Zugriff auf Dateien. Bei Google wird der Schlüssel auf die Gemini API beschränkt; unbeschränkte Standard-Schlüssel lehnt die Gemini API laut Google inzwischen ab, neue Schlüssel aus AI Studio sind seit 28. Mai 2026 an ein Dienstkonto gebunden (Google, Gemini API keys).

Ablaufdatum. OpenAI empfiehlt ausdrücklich, beim Anlegen eines Projektschlüssels ein Ablaufdatum zu setzen und regelmäßig zu wechseln. Mistral erlaubt Admins, eine maximale Gültigkeit für neue Schlüssel vorzugeben.

Prüfung vor dem Commit. GitHubs Push-Schutz für Nutzer blockiert Schlüssel beim Hochladen in öffentliche Repositorys und ist laut GitHub standardmäßig eingeschaltet (GitHub, Push protection). Für Gemini-Schlüssel greift er laut Musterliste nicht. OWASP empfiehlt zusätzlich eine Prüfung vor dem Commit, etwa als Pre-Commit-Hook (OWASP, Secrets Management). Wie man einem KI-Agenten von Anfang an nur die Rechte gibt, die er braucht, beschreibt KI-Agent erstellen.

Ist das eine Datenpanne?#

Ein geleakter Schlüssel kostet zuerst Geld. Eine Datenpanne nach Art. 33 DSGVO wird daraus nur, wenn über den Schlüssel personenbezogene Daten abrufbar waren (DSGVO, EUR-Lex). Das hängt davon ab, was im Projekt oder Workspace gespeichert ist, nicht von den Anfragen, die deine Anwendung stellt.

Bei OpenAI gehören hochgeladene Dateien zum Projekt, und die API hat einen Endpunkt, der den Inhalt einer Datei zurückgibt (OpenAI, Files). Ein Schlüssel mit vollen Rechten in einem Projekt, in dem Kundendokumente für einen Assistenten liegen, gibt diese Dokumente her.

Bei Anthropic lassen sich hochgeladene Dateien nicht herunterladen, aber jeder Schlüssel mit Zugriff auf den Workspace kann sie in einer Anfrage verwenden. Anthropic warnt selbst, dass Dateien für den ganzen Workspace zugänglich sind (Anthropic, Files API). Wer Dateien in Anfragen einbinden kann, kann sich ihren Inhalt vom Modell wiedergeben lassen.

Ein Schlüssel, der nur Anfragen stellt und nichts gespeichert vorfindet, gibt keine personenbezogenen Daten preis. Dann ist der Vorfall ein Kostenproblem, das du trotzdem dokumentierst. Lagen dagegen Kundendaten, Bewerbungen oder Mitarbeiterdaten im Projekt, läuft die 72-Stunden-Frist ab dem Bemerken. Wie du das Risiko einschätzt und meldest, steht in Datenpanne melden.

Was nicht hilft#

Den Schlüssel im Code löschen und neu committen. Er steht weiter im Verlauf, in Forks und in jedem Klon. Ohne Löschen beim Anbieter bleibt er gültig.

Das Repository auf privat stellen. Wer den Schlüssel schon kopiert hat, braucht das Repository nicht mehr.

Den Schlüssel im Frontend verschleiern. Base64, Aufteilen auf mehrere Variablen, ein Build-Schritt: Der Browser muss den Schlüssel am Ende im Klartext an die API schicken, und dort liest ihn jeder mit.

Nur ein Limit setzen und den Schlüssel behalten. Das Limit begrenzt die Rechnung, nicht den Zugriff auf gespeicherte Dateien.

Prüfliste#

• Schlüssel beim Anbieter gelöscht, nicht nur im Code entfernt
• Verbrauch der letzten Tage angesehen und gesichert
• Ausgabenlimit für Organisation und Projekt oder Workspace gesetzt, bei OpenAI mit „hard limit“
• Fundstelle gefunden: Repository samt Verlauf, Website-Code, Export, Bildschirmfoto, Chat
• Neuer Schlüssel je Anwendung, mit eingeschränkten Rechten und Ablaufdatum, nur in Umgebungsvariable oder Secret-Manager
• Alle anderen Zugangsdaten aus derselben Datei ebenfalls ersetzt
• Kein Aufruf der KI-API direkt aus dem Browser
• Push-Schutz bzw. Pre-Commit-Prüfung aktiv
• Gespeicherte Dateien im Projekt oder Workspace geprüft, Datenpanne bewertet und dokumentiert
• Bei fremder Nutzung Support mit Belegen kontaktiert

In Betrieben gehört dazu eine Regel, wer überhaupt API-Schlüssel anlegen darf und wo sie liegen. Die KI-Richtlinie für kleine Betriebe ist dafür ein Anfang.

Häufige Fragen#

Stand 25.10.2026. Alle Quellen am 25.10.2026 abgerufen. Menüpfade vor dem Befolgen in der eigenen Konsole abgleichen.