API-Schlüssel blieb drei Wochen lang unbemerkt kompromittiert
Die KI-Sicherheitsorganisation METR hat zwei Angriffe aus dem Frühjahr 2026 öffentlich gemacht. Beim schwerwiegenderen Vorfall stahlen Angreifer im März einen API-Schlüssel und verbrauchten damit innerhalb von drei Wochen Guthaben im Wert von rund 600.000 US-Dollar.
Der Schlüssel erlaubte den Zugriff auf öffentlich verfügbare KI-Modelle eines nicht genannten Anbieters. Welche Modelle verwendet wurden und welchem Zweck die verbrauchte Rechenleistung diente, ist nicht bekannt.
Im März 2026 stahlen Angreifer einen API-Schlüssel für die Inferenz auf öffentlichen Modellen und verbrauchten eine beträchtliche Menge an Guthaben, erklärte METR sinngemäß.
| Kennzahl | Angabe |
|---|---|
| Zeitpunkt des Schlüsseldiebstahls | März 2026 |
| Dauer des unbemerkten Missbrauchs | 3 Wochen |
| Verbrauchtes API-Guthaben | rund 600.000 US-Dollar |
| Zweite Angriffswelle | Mai 2026 |
Fehlerhafte Vibe-Coding-App öffnete den Zugang
Ausgangspunkt war eine persönliche AWS-EC2-Instanz eines METR-Forschers. EC2 ist ein Cloud-Dienst für virtuelle Server. Auf der Instanz liefen KI-Agenten sowie eine mit Vibe Coding, also weitgehend durch KI erzeugtem Code, erstellte Prototyp-Anwendung.
Die Anwendung enthielt einen Fail-Open-Fehler. Bei einem solchen Fehler wird der Zugriff trotz einer gestörten oder fehlerhaften Authentifizierung freigegeben, statt standardmäßig blockiert zu werden. Dadurch war die Instanz mehrere Tage ohne wirksamen Schutz über das öffentliche Internet erreichbar.
METR vermutet, dass die Angreifer Certificate-Transparency-Listen nach neu registrierten Internetangeboten und auffälligen Begriffen rund um LLMs und Agenten durchsuchten. Diese öffentlich einsehbaren Listen dokumentieren ausgestellte TLS-Zertifikate und lassen sich automatisiert auswerten.
Agent gab den hinterlegten Schlüssel preis
Nach dem Fund der Anwendung brachten die Angreifer einen KI-Agenten dazu, den hinterlegten API-Schlüssel offenzulegen. Diese Form der Manipulation wird als Prompt Injection bezeichnet. Dass bereits der Inhalt einer Website einen Agenten zu riskanten Aktionen bewegen kann, zeigt auch der Fall einer Prompt Injection gegen Claude Code.
Zusätzlich hinterlegten die Angreifer einen eigenen SSH-Schlüssel und schufen sich damit einen dauerhaften Fernzugang. Der Vorfall war daher nicht nur ein gestohlener Zugangsschlüssel, sondern eine vollständige Kompromittierung der öffentlich erreichbaren Entwicklungsumgebung.
Hoher Token-Verbrauch löste keinen Alarm aus
METR führt regelmäßig umfangreiche Modelltests mit hohem Token-Verbrauch durch. Ungewöhnliche API-Fehler und überschrittene Ratenlimits gehörten deshalb bereits zum normalen Betrieb. Der zusätzliche Verbrauch fiel in dieser Geräuschkulisse nicht unmittelbar auf.
Hinzu kam, dass METR die Credits kostenlos vom Modellanbieter erhalten hatte. Deshalb entstand keine Rechnung, die den Missbrauch frühzeitig sichtbar gemacht hätte. Für den betroffenen Schlüssel gab es zu diesem Zeitpunkt zudem kein Ausgabenlimit.
METR entstand dadurch kein direkter finanzieller Schaden. Bei einem regulär abgerechneten Geschäftskonto hätte ein vergleichbarer Verbrauch jedoch eine erhebliche Forderung auslösen können. API-Schlüssel für nutzungsabhängig abgerechnete KI-Dienste sind wirtschaftlich mit ungeschützten Zahlungsmitteln vergleichbar.
Ausgabenlimits gehören in die technische Absicherung
Für Unternehmen reicht es nicht, API-Schlüssel lediglich in Umgebungsvariablen oder Secret Stores abzulegen. Zusätzlich erforderlich sind harte Budgetgrenzen, getrennte Schlüssel je Anwendung, eng begrenzte Berechtigungen und Warnungen bei ungewöhnlichem Verbrauch.
Ein Beispiel für eine feste Kostengrenze ist das auf 300 US-Dollar begrenzte KI-Tokenbudget von Red Hat. Auch zentrale Verwaltungswerkzeuge können helfen, wie das OpenAI Admin-Plugin für Rechte und Budgets zeigt. Entscheidend ist, dass Limits technisch durchgesetzt werden und nicht nur in internen Richtlinien stehen.
| Kontrolle | Praktischer Zweck |
|---|---|
| Hartes Ausgabenlimit | Begrenzt den maximalen finanziellen Schaden |
| Eigener Schlüssel pro Anwendung | Erleichtert Sperrung und Zuordnung |
| Minimale Berechtigungen | Reduziert den erreichbaren Funktionsumfang |
| Verbrauchsalarme | Melden Abweichungen frühzeitig |
| Keine öffentlichen Entwicklungsinstanzen | Verkleinert die Angriffsfläche |
| Regelmäßige Schlüsselrotation | Verkürzt die Nutzungsdauer gestohlener Zugangsdaten |
Zweiter Angriff traf öffentliche Infrastruktur
Im Mai 2026 beobachtete METR eine weitere koordinierte Angriffswelle gegen öffentlich erreichbare Systeme. Dabei wurde auch eine versehentlich exponierte SQL-Schnittstelle entdeckt, über die wegen eines Fehlers grundsätzlich unveröffentlichte Evaluierungsdaten erreichbar gewesen wären.
Ein unabhängiger Sicherheitsforscher meldete die Schwachstelle über ein Bug-Bounty-Programm. METR nahm die Schnittstelle anschließend offline. Nach Angaben der Organisation gibt es keine Hinweise darauf, dass die Angreifer die Lücke fanden oder nicht öffentliche Daten abgerufen haben.
Als Reaktion trennte METR öffentlich erreichbare Anwendungen stärker von internen Systemen und verstärkte Sicherheitsprozesse sowie Personal. Der Fall zeigt dennoch, wie schnell experimentelle KI-Anwendungen zum Einstiegspunkt in Cloud-Konten werden können.
Self-Hosting begrenzt das Abrechnungsrisiko, nicht die Angriffe
Bei proprietären Cloud-KI-Diensten kann ein einzelner kompromittierter Schlüssel unmittelbar hohe variable Kosten auslösen. Gerade Pay-per-Token-Modelle benötigen deshalb eine technische Kostenobergrenze. Eine nachträgliche Prüfung der Rechnung ist kein ausreichender Schutz.
Self-Hosting mit Open-Source-Modellen beseitigt dieses ungedeckelte API-Abrechnungsrisiko, weil die Nutzung durch die vorhandene Infrastruktur begrenzt wird. Angriffe, Datendiebstahl und der Missbrauch von Rechenkapazität bleiben jedoch möglich. Eigene Systeme ersetzen daher keine Sicherheitsarchitektur, sie machen Kosten und Kontrollmöglichkeiten lediglich besser planbar.