Gestohlene KI-API-Schlüssel finanzieren jetzt Hacking-Scans: So sichern Sie Ihre OpenAI-, Anthropic- und Gemini-API-Schlüssel ab

Gestohlene KI-API-Schlüssel finanzieren jetzt das Hack anderer. Im Oktober 2026 beschrieb Bitsights Threat-Intelligence-Team MONST3R-AI, ein Tool, das in einem kriminellen Forum verkauft wird und autonome Penetrationstests auf gestohlenen OpenAI-, Anthropic- und Google-Schlüsseln durchführt. Der Käufer liefert den Schlüssel, das Agenten durchführt das Scannen und der Inhaber des Schlüssels muss die Rechnung bezahlen. Dieser Leitfaden erläutert, wie Schlüssel geleakt werden, wie Missbrauch erkannt werden kann und welche Steuerung jedes Anbieter heute bietet.

Schützen Sie einen OpenAI-, Anthropic- oder Gemini-Schlüssel, indem Sie ihn auf ein einziges Projekt oder Workspace beschränken, eine harte monatliche Ausgabenbegrenzung festlegen, einschränken, von wo er aufgerufen werden darf, ein Ablaufdatum setzen oder ihn rotieren, ihn außerhalb von Client-Code und Repositories halten und das Secret-Scanning mit Push-Schutz aktivieren. Wenn ein Schlüssel geleakt wird, erstellen Sie einen Ersatz, setzen ihn ein und deaktivieren Sie dann den alten Schlüssel sowie die Nutzung.

Was ist LLMjacking?

LLMjacking ist der Missbrauch eines gestohlenen Anmeldedatensatzes eines großen Sprachmodells, normalerweise eines API-Schlüssels, um Inferenz auszuführen, für die der Inhaber des Schlüssels bezahlt. Angreifer verkaufen den Zugang weiter, verbrauchen ihn für ihre eigenen Workloads oder nutzen ihn nun, wie Bitsight berichtet, um autonome Angreifer-Agenten zu betreiben. Das Opfer sieht die Aktivität nur als verrechenbaren Verbrauch auf seinem eigenen Konto.

Was Bitsight über MONST3R-AI herausgefunden hat

Die folgenden Fakten stammen aus der Berichterstattung über Bitsights Forschung durch Help Net Security und AI Weekly, veröffentlicht am 17. Oktober 2026. Bitsights eigene Beschreibung des Tools war zu diesem Zeitpunkt nicht öffentlich bekannt, als dieser Artikel geschrieben wurde.

• Was es ist: ein Verkäufer in einem eingeschränkten kriminellen Forum wirbt mit MONST3R-AI als „autonome Penetrationstest-Plattform“.
• Jense dessen Schlüssel: es läuft mit gestohlenen OpenAI-, Anthropic- und Google-API-Schlüsseln.
• Wer zahlt: der Käufer fügt einen gestohlenen Schlüssel in das Tool-Panel ein, begrenzt ein Budget und zeigt dem Agenten eine Ziel-Liste. Der Verkäufer hostet kein Modell, daher landet die Inferenzrechnung beim rechtmäßigen Inhaber des Schlüssels.
• Behauptete Ergebnisse: das Dashboard des Verkäufers meldet 1.072 Fund bei 199 gescannten Hosts. Bitsight sagt, es könne diese Zahl nicht unabhängig verifizieren, betrachten Sie sie daher als Marketing und nicht als Beweis.
• Der breitere Trend: über 16 Untergrund-Foren vom Februar bis August 2026 stieg die Erwähnung von KI-Agenten, indirekter Prompt Injection und dem Model Context Protocol um 67 Prozent.

Ein geleakter Schlüssel ist keine Überraschungsrechnung mehr. Er kann eine andere Angriffsoperation finanzieren, und jeder Request sieht aus wie Ihr normaler Verkehr.

Wie KI-API-Schlüssel geleakt werden

Die meisten gestohlenen Schlüssel wurden nie „gehackt“. Sie wurden versehentlich veröffentlicht. Die gängigen Wege sind:

Googles Gemini API-Schlüssel-Leitfaden besagt die Client-seitige Regel unverblümt: Schlüssel, die in Web- oder Mobil-Apps kompiliert sind, können von Benutzern extrahiert werden, also rufen Sie das Modell nur von Ihrem Backend auf. Unser Leitfaden zur Speicherung von API-Schlüsseln behandelt die Speicherung eingehender. Agentenkonfigurationen verdienen zusätzliche Sorgfalt: MCP- und Agenteneinstellungsdateien finden sich in Dotfile-Repos, Bildschirmfreigaben und Fehlermeldungen.

Wie man erkennt, dass der eigene Schlüssel missbraucht wird

Keine Warnung besagt „Ein Krimineller nutzt dies.“ Überwachen Sie die Nutzungs- und Abrechnungsdaten auf Folgendes:

1. Ausgaben steigen ohne dazugehörendes Deployment. Eine flache Tageskostenpauschale, die über Nacht verdoppelt wird, ist das deutlichste Zeichen.
2. Modelle, die Sie nicht nutzen. Nutzung eines Modell-Clusters, den Ihr Produkt nie aufruft.
3. Verkehr außerhalb der Betriebszeiten. Stetige Requests um 3 Uhr morgens in Ihrer Zeitzone von einem Schlüssel eines Tag-Apps.
4. Ratenlimit-Fehler, die Sie nicht verursacht haben. Jemand anderes verbraucht Ihr minutengesteuertes Kontingent.
5. Unbekannte Schlüssel oder Projekte in den Nutzungsseite. Googles AI Studio gruppiert Requests, die es nicht einem benannten Schlüssel zuordnen kann, unter „(unbekannte Schlüssel)“.

Spalten Sie Schlüssel so fein auf, dass ein Anstieg auf einen spezifischen Schlüssel hinweist.

Wie man den OpenAI API-Schlüssel sichert

Prüfung am 28. Oktober 2026 basierend auf den Entwickler-Dokumentationen von OpenAI.

• Feste Ausgabenlimits: Gemäß dem Leitfaden zu Ausgabenlimits können Sie ein monatliches Limit für die Organisation oder ein einzelnes Projekt festlegen und „Einbinden Sie ein festes Limit“ aktivieren. Sobald die verfolgten Ausgaben dieses Limit erreichen, schlagen die Requests mit einem 429-Status fehlerhaft und der Code organization_spend_limit_exceeded oder project_spend_limit_exceeded. Die Durchsetzung erfolgt nicht sofort, sodass die Ausgaben geringfügig über das Limit hinausgehen können.
• Spend-Alert-Benachrichtigungen: Benachrichtigungen informieren Sie, stoppen den Verkehr jedoch nicht. Nutzen Sie beides, mit dem Alert deutlich unter dem harten Limit.
• IP-Anlage (Allowlist): Die IP-Anlage lehnt Requests von anderen IPs ab, selbst mit einem gültigen Schlüssel. Es können bis zu 50 Adressen oder CIDR-Bereiche verwendet werden, gilt pro Projekt oder über die gesamte Organisation und blockierte Calls erhalten HTTP 401 mit ip_not_authorized. Änderungen dauern bis zu 15 Minuten.
• Ein Projekt pro App und Umgebung: Projekt- und Allowlist-Limits helfen nur, wenn Schlüssel nach Projekt aufgeteilt werden.
• Eingeschränkte Schlüsselberechtigungen: OpenAIs Projekt-Leitfaden listet die Berechtigungen All (Standard), Restricted und Read Only für Benutzereigene Schlüssel. Geben Sie jedem Schlüssel nur das, was seine App benötigt.
• Modellzugriff pro Projekt: Unter den Limits eines Projekts wählt die Modellnutzung aus, welche Modelle das Projekt aufrufen darf. Ein gestohlener Schlüssel kann dann nicht auf ein teureres Modell wechseln, das Sie nie nutzen.

Sehen Sie sich unseren OpenAI API-Schlüssel-Leitfaden an.

Wie man den Anthropic API-Schlüssel sichert

Prüfung am 28. Oktober 2026 anhand der Claude Platform-Dokumentation.

• Workspace-Ausgabenlimits: Laut den Workspace-Dokumentationen können Sie die monatlichen Ausgaben pro Workspace begrenzen und Alerts an Schwellenwerten konfigurieren. Sie können keine Ausgabenlimits für den Standard-Workspace setzen, daher sollten Sie Produktionsschlüssel in ihren eigenen Workspace einstellen.
• Workspace-Ratenlimits: Begrenzen Sie Requests, Eingabe-Tokens und Ausgabe-Tokens pro Minute für jeden Workspace.
• Schlüsselaablauf: Die Authentifizierungsdokumentation ermöglicht es Ihnen, bei der Erstellung ein Ablaufdatum zu wählen: 3 Stunden, 1 Tag, 7 Tage, 30 Tage, eine benutzerdefinierte Dauer oder Nie. Dies kann später nicht mehr geändert werden.
• Identitätsspezifische Schlüssel: Persönliche und Service-Schlüssel funktionieren nicht mehr, wenn der Inhaber entfernt wird. Anthropic bezeichnet Workspace-Schlüssel als legacy und empfiehlt Workload Identity Federation für die Produktion in der Cloud und CI.
• Deaktivieren vs. Löschen: Deaktivieren ist umkehrbar und zeigt den Schlüssel als inaktiv an. Löschen ist permanent. Wenn Sie unsicher sind, deaktivieren Sie zuerst.

Sehen Sie sich unseren Anthropic API-Schlüssel-Leitfaden an.

Wie man den Google Gemini API-Schlüssel sichert

Prüfung am 28. Oktober 2026 anhand der Gemini API-Schlüssel-Dokumentation und Abrechnungsdokumentation von Google.

• Auth Keys: Seit dem 28. Mai 2026 sind neue Schlüssel in Google AI Studio Authentifizierungsschlüssel, die an ein Service-Konto gebunden sind und standardmäßig auf die Gemini API beschränkt sind. Google sagt, sie verfügen über eine schnell wirkende Durchsetzung bei von ihren Systemen erkannten geleakten Schlüsseln.
• Keine unbeschränkten Schlüssel: Die Gemini API lehnt Requests von unbeaufsichtigten Standard-Schlüsseln ab. Beschränken Sie alte Schlüssel auf die Gemini API in AI Studio oder migrieren Sie zu einem Auth Key.
• Anwendungseinschränkungen: Beschränken Sie einen Schlüssel in der Cloud-Konsole auf spezifische IP-Adressen.
• Projekt-Ausgabenlimits: Legen Sie auf der Spend-Seite von AI Studio ein monatliches Limit pro Projekt fest. Google kennzeichnet dies als experimentell und warnt vor Überziehungen aufgrund einer etwa 10-minütigen Abrechnungsverzögerung.

Die Sperr-Checkliste für jeden Anbieter

Führen Sie dies einmal für jeden Schlüssel durch, den Sie besitzen:

1. Inventarisierung. Listen Sie jeden Schlüssel, die App, die ihn verwendet, und wo er gespeichert ist auf.
2. Aufsplittung. Ein Projekt oder Workspace pro App und Umgebung, damit ein Spike seine Quelle benennt.
3. Kapazitätsgrenze. Legen Sie ein hartes monatliches Limit und eine frühere Warnung fest.
4. Beschränkung. IP-Anlage oder Anwendungseinschränkung dort, wo Ihr ausgehender Datenverkehr festgelegt ist.
5. Ablaufdatum setzen oder rotieren. Kurze Gültigkeitsdauer, sofern der Anbieter dies unterstützt; ein Rotationsplan, falls dies nicht möglich ist.
6. Scannen. GitHub's Secret Scanning Patterns enthalten OpenAI-, Anthropic- und Google Gemini API-Schlüssel, und OpenAI-Schlüssel unterstützen Push-Schutz. Unser Beitrag zur Prüfung auf geleakte API-Schlüssel beschreibt Scanner, die Sie lokal ausführen können.
7. Kurzlebigen Anmeldeinformationen vorziehen. Anthropic und OpenAI dokumentieren Workload Identity Federation für die Produktion.

Für die Richtlinie siehe Best Practices zum API-Schlüssel-Management.

Was in der ersten Stunde nach einem Leck zu tun ist

Geschwindigkeit schlägt Grundursache. In dieser Reihenfolge:

1. Erstellen Sie einen Ersatzschlüssel in einem frischen Projekt oder Workspace.
2. Setzen Sie ihn ein in die Apps, die ihn benötigen.
3. Deaktivieren Sie den geleakten Schlüssel. Googles Leak-Checklist besagt, dass der alte Schlüssel nur deaktiviert werden sollte, nachdem der neue verifiziert ist, um Ausfallzeiten zu vermeiden. Wenn die Ausgaben jedoch schnell steigen, deaktivieren Sie ihn zuerst und akzeptieren Sie den Ausfall.
4. Senken Sie das Spend-Cap im betroffenen Projekt, während Sie untersuchen.
5. Auditieren Sie die Nutzung nach Modell, Stunde und Schlüssel für den Zeitraum seit dem Leak.
6. Finden Sie den Leak-Pfad mithilfe der obigen Tabelle und entfernen Sie ihn aus dem Git-Verlauf.
7. Kontaktieren Sie den Anbieter bezüglich des betrügerischen Verbrauchs, sobald Sie den Zeitplan haben.

Lassen Sie Ihren Coding-Agenten die Schlüssel-Behandlung mit Apidog CLI testen

Ihr Backend-Proxy zu OpenAI, Anthropic oder Gemini ist der Ort, an dem die Schlüssel-Behandlung fehlschlägt: Er akzeptiert nicht authentifizierte Anfragen oder spiegelt den Anbieter-Schlüssel in einer Fehlerausgabe wider. Lassen Sie Ihren Coding-Agenten Tests dafür mit Apidog CLI schreiben und ausführen, wobei Geheimnisse außerhalb der Testdefinitionen bleiben.

Richten Sie es einmal ein:

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # wählen Sie Ihren Agenten, wenn Sie dazu aufgefordert werden

Geben Sie dann Ihrem Agenten einen Prompt:

In Apidog Projekt <id> erstellen Sie einen Testfall für POST /v1/ai/chat auf unserem Proxy.
Bestätigen: kein Authorization-Header, der 401 zurückgibt, ein falscher Token gibt 401 zurück, ein gültiger Token gibt 200 zurück und kein Antwortkörper enthält „sk-“ oder „AIza“. Lesen Sie den Token aus der Umgebungsvariable {{PROXY_TOKEN}}, niemals hart codieren.
Führen Sie ihn dann gegen die Staging-Umgebung aus und fassen Sie die Fehler zusammen.

Der Agent liest das Payloads-Schema, validiert es, erstellt den Fall und führt ihn aus:

apidog cli-schema get test-case-create
apidog test-case category --project <id>
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> \
  --env-var "PROXY_TOKEN=$PROXY_TOKEN" -r cli,junit

--env-var gibt den Token zur Laufzeit weiter, er lebt also nie in der Spezifikation oder im Repo. Dieselbe apidog run-Zeile wird in CI geschrieben; siehe Apidog CLI in einer CI/CD-Pipeline und Apidog CLI in Claude Code.

FAQ

Was ist LLMjacking? Es ist die Nutzung einer gestohlenen LLM-Anmeldeinformation, meist eines API-Schlüssels, um Inferenz durchzuführen, für die der Inhaber bezahlt. Angreifer verkaufen den Zugang weiter oder nutzen ihn, wie bei MONST3R-AI, um Angreifer-Agenten zu betreiben.

Können gestohlene KI-API-Schlüssel wirklich für Hacking-Tools bezahlen? Ja. Bitsight berichtete, dass die Käufer von MONST3R-AI gestohlene OpenAI-, Anthropic- oder Google-Schlüssel in das Panel eingeben, und da der Verkäufer kein Modell hostet, zahlen die Opfer. Die behaupteten Ergebnisse des Verkäufers sind nicht verifiziert.

Stoppt ein Ausgabenlimit einen gestohlenen Schlüssel? Ein hartes Limit stoppt die Ausgaben beim Limit, aber nicht sofort. OpenAI und Google weisen beide auf geringfügige Überschreitungen hin, während die Limits sich ausbreiten. Allein Spend-Alert-Benachrichtigungen stoppen den Verkehr jedoch niemals.

Kann ich meinen OpenAI API-Schlüssel im Frontend-Code platzieren? Nein. Alles, was an einen Browser oder eine mobile App geschickt wird, kann extrahiert werden. Rufen Sie das Modell von Ihrem Backend auf.

Findet GitHub einen geleakten KI-Schlüssel? GitHub's Secret-Scanning erkennt Muster von OpenAI-, Anthropic- und Google Gemini API-Schlüsseln. Schalten Sie den Push-Schutz ein, sodass ein Commit mit einem Schlüssel blockiert wird, bevor er öffentlich ist.