METR: Gestohlener API-Schlüssel und Credits im Wert von 600.000 USD

Stand: 10. Oktober 2026

METR hat den Diebstahl eines API-Schlüssels und die unbefugte Nutzung kostenloser Guthaben in einem Bericht vom 31.08.2026 offengelegt. Es handelt sich um einen Fall, bei dem man den rechnerischen Wert der genutzten Ressource von einem echten Barverlust trennen muss - ebenso wie den Verlust der Zugriffskontrolle von einem bestätigten Datenabfluss.

Chronologie

1. März - früherer Kontext: Diebstahl des Schlüssels, der erst im August öffentlich gemacht wurde.
2. Mai: Separater Sondierungsversuch, teils agentenbasiert; ein Forscher meldete eine Schwachstelle im Viewer.
3. Offenlegung im August: METR beschrieb Anpassungen beim Monitoring, der Schlüsselrotation und der Infrastruktur-Trennung.

Quelle der Chronologie: METR, 31.08.2026.

Was man bei einem API-Vorfall messen muss

Ablauf: Der Schlüssel und eine separate Sicherheitslücke

Die im März auf einer persönlichen EC2-Instanz betriebene Anwendung eines Forschers wies einen Fail-Open-Authentifizierungsfehler auf. Beim separaten Vorfall im Mai fand METR keine Beweise dafür, dass die Schwachstelle im Viewer von Angreifern ausgenutzt oder nicht-öffentliche Daten heruntergeladen wurden: METR, 31.08.2026.

Diese Ereignisse erfordern eine getrennte Betrachtung. Der Schlüsseldiebstahl wirft Fragen nach der Kontrolle über Berechtigungen und den Ressourcenverbrauch auf. Ein fehlerhafter Datenzugriff verlangt hingegen die Prüfung, ob die Möglichkeit tatsächlich genutzt wurde. Beide Vorkommnisse zu einer Erzählung über ein riesiges Datenleck zu vermengen, würde den Unterschied zwischen einer bestätigten Auswirkung und einer bloß entdeckten Schwachstelle verwischen.

Analyse: Auch kostenlose Ressourcen erfordern Zugriffskontrolle

Ein kostenloses Kontingent befreit von der Bezahlung bei der Zuteilung, nicht aber von der Verwaltung des Zugriffs. Es besitzt einen praktischen Nutzen: Es ermöglicht Aufgaben, die eine Organisation durchführen möchte. Ein unbefugter Verbrauch entzieht die Kontrolle darüber, wofür diese Mittel eingesetzt werden. Daher sollte eine Abrechnung über null Euro die Bewertung eines solchen Vorfalls keineswegs beenden.

Ein Monitoring, das sich rein auf Zahlungsströme stützt, beantwortet eine viel zu enge Frage: Muss gezahlt werden? Notwendig ist auch die Klärung, ob die Ressource von der richtigen Person, für den vorgesehenen Zweck und im genehmigten Umfang genutzt wird. Nutzungswarnungen sind auch dann sinnvoll, wenn das Abrechnungssystem keine offenen Posten anzeigt.

Das bedeutet nicht, dass der Nennwert des Kontingents automatisch als Gesamtschaden gewertet werden sollte. In der Bewertung müssen tatsächlicher Verbrauch, verlorene Berechtigungen und dokumentierte Kosten separat erfasst werden. Eine solche Aufteilung erlaubt eine zielgerichtete Reaktion, statt sich allein von aufsehenerregenden Summen leiten zu lassen.

Ein Schlüssel ist eine Berechtigung, nicht nur Text

Der Schutz eines Geheimnisses muss sich danach richten, welche Aktionen es ermöglicht. Ein Schlüssel mit weitreichenden Rechten verlangt eine andere Absicherung als ein Zugriff, der auf eine spezifische Aufgabe beschränkt ist. Reine Verbrauchsdaten ersetzen keine Berechtigungsübersicht: Sie zeigen weder alle Möglichkeiten auf noch klären sie, welche davon genutzt wurden.

Beim Design von KI-Agenten sollte man die verarbeiteten Inhalte strikt von den für die Ausführung nötigen Berechtigungen trennen. Eine Aufgabe, die einen externen Dienst nutzt, erfordert nicht zwangsläufig, dass der geheime Schlüssel im Kontextfenster des Modells auftaucht. Ziel ist es, die Stellen zu minimieren, an denen ein Schlüssel zu reinem Klartext wird, der weitergegeben werden kann.

Wer verliert, wer profitieren kann

Die bestätigte Folge aufseiten von METR ist der Kontrollverlust über den genutzten Teil des Kontingents sowie über den kompromittierten Schlüssel. Dies sollte nicht durch die Behauptung eines tatsächlichen Geldabflusses ersetzt werden. Ohne zusätzliche Daten lassen sich der Organisation auch keine konkreten Verzögerungen in der Forschung zuschreiben oder nicht durchgeführte Arbeiten beziffern.

Der Angreifer erlangte die Möglichkeit, Ressourcen außerhalb des autorisierten Zwecks zu nutzen. Das ist das belegte Resultat. Mögliche finanzielle Gewinne, die Weiterverwertung von Ergebnissen oder Zugriffe auf andere Ressourcen bleiben rein spekulativ. Diese Unterscheidung schützt vor einer Aufblähung des Schadensbildes durch bloße Vermutungen.

Eine Organisation kann langfristig davon profitieren, Verantwortlichkeiten klarer zuzuweisen und Zugriffsrechte einzuschränken. Die bloße Einführung neuer Richtlinien beweist jedoch noch nicht deren Wirksamkeit. Der Maßstab muss praxistauglich sein: Erreicht ein Alarm die zuständige Person, lässt sich eine Berechtigung schnell entziehen und betrifft die Sperrung tatsächlich nur den gefährdeten Zugang?

Ressourcenanbieter und Forscher haben unterschiedliche Anforderungen: Kontrolle über die Nutzung versus reibungslose Arbeitsabläufe. Es muss keine Entscheidung zwischen uneingeschränkter Freiheit und der Blockade jeder Operation sein. Enger gefasste Berechtigungen und klare Reaktionsregeln begrenzen Fehlerfolgen, ohne die Funktionalität lahmzulegen.

Lektionen für Unternehmen

Unternehmen sollten API-Schlüssel als verwaltete Zugriffselemente behandeln - mit einem klaren Verantwortlichen und einem definierten Deaktivierungsprozess. Zuständigkeit darf nicht bei einem Namen in der Dokumentation enden. Wer Alarmmeldungen erhält, benötigt Handlungsbefugnisse, und bei Abwesenheit muss eine Vertretung geregelt sein.

• Definieren Sie den Zweck des Schlüssels, den nötigen Berechtigungsumfang und erlaubte Einsatzbereiche.
• Weisen Sie einen Verantwortlichen sowie eine Vertretung für Vorfallmeldungen zu.
• Richten Sie Nutzungslimits ein, unabhängig davon, ob das Kontingent kostenpflichtig ist.
• Trennen Sie Benachrichtigungsschwellen von automatischen Sperrmechanismen.
• Prüfen Sie bei einer Schlüsselrotation stets die Ungültigkeit des alten Schlüssels sowie abhängige Integrationen.

Ein Limit sollte sich am Arbeitsziel orientieren und nicht nur an der maximal verfügbaren Obergrenze. Ein Kontingent legt fest, wie viel insgesamt verbraucht werden darf; es sagt nichts darüber aus, ob eine einzelne Nutzung legitim ist. Nötig ist die Möglichkeit, Zugriffe aufgabenbezogen einzuschränken und zu stoppen, ohne unbeteiligte Prozesse zu stören.

Lektionen für Nutzer

Anwender sollten Integrationen immer auch danach beurteilen, wie leicht Zugriffe wieder entzogen werden können - nicht nur nach dem Einrichtungsaufwand. Vor der Weitergabe eines Schlüssels empfiehlt sich die Prüfung: Wo wird er gespeichert, welche Aktionen erlaubt er und wer überwacht die Nutzung? Unklare Antworten sind ein Grund, Berechtigungen einzuschränken oder auf die Integration zu verzichten.

• Wählen Sie stets das für die Aufgabe minimale Berechtigungsniveau.
• Nutzen Sie Limits und Benachrichtigungen, sofern der Dienst diese anbietet.
• Überwachen Sie die tatsächliche Ressourcennutzung und nicht nur den fälligen Rechnungsbetrag.
• Widerrufen Sie den Zugriff bei Verdacht auf Kompromittierung sofort und prüfen Sie die verfügbaren Nutzungsprotokolle.

Das bloße Löschen einer Nachricht, die einen Schlüssel enthielt, entzieht nicht die Berechtigung selbst. Die Reaktion muss die weitere Verwendbarkeit des Schlüssels betreffen, nicht nur die sichtbare Textkopie. Ebenso löst ein neuer Schlüssel das Problem nicht, wenn der alte aktiv bleibt oder erneut an unsicherer Stelle hinterlegt wird.

Hypothetisches Beispiel: KI-Agent mit Gratis-Kontingent

Angenommen, ein Unternehmen stattet einen Agenten zur Dokumentenanalyse mit einem kostenlosen API-Kontingent aus. Bei unüblichem Verbrauch entsteht ein Dilemma: Ein sofortiger Stopp unterbricht möglicherweise wichtige Aufgaben, eine reine Benachrichtigung lässt den Zugriff jedoch bis zu einer menschlichen Entscheidung offen.

Die Lösung besteht darin, Reaktionsregeln vorab festzulegen. Eine Warnung geht an den Verantwortlichen; wird ein vereinbarter Schwellenwert überschritten, wird der Zugriff für diese konkrete Aufgabe automatisch pausiert. Eine Wiederaufnahme erfordert eine Überprüfung der Ursache. Dies garantiert keine fehlerfreie Erkennung, legt aber fest, wer die Verantwortung für die weitere Nutzung trägt.

Falls die Beschränkung eine legitime Arbeit stoppt, kann der Verantwortliche den Rahmen bewusst erweitern. Ist die zuständige Person nicht erreichbar, bleibt der Prozess gemäß den Regeln pausiert. Der Preis dieser Vorsicht ist transparent: etwas weniger Komfort für mehr Kontrolle. Das Fehlen einer Rechnung ändert an diesem Grundsatz nichts.

Offene Fragen

Die genaue Verteilung des Verbrauchs, die Gesamtkosten für die Vorfallbewältigung sowie die Wirksamkeit der nachträglich eingerichteten Sicherheitsmaßnahmen sind öffentlich nicht bekannt. Es gibt zudem keine verlässliche Basis, um entgangene Forschungsmöglichkeiten finanziell zu beziffern. Diese Lücken erschweren eine exakte Gesamteinschätzung, ändern aber nichts an der Kernlektion: Ressourcenverbrauch, Geheimnisschutz und Zahlungsabwicklung müssen getrennt voneinander bewertet werden.

Weitere Analysen zu Sicherheitsvorfällen finden Sie in unserer Reihe KI-Fallstudien.

Wer Limits verwaltet, muss Zugriffe stoppen können

Ein strukturiertes Zugriffsregister sollte jeden Schlüssel mit Projekt, Verantwortlichem und Notfallprozedur verknüpfen. Ein reines Verbrauchsdiagramm nützt nichts, wenn die Person, die den Alarm erhält, keine Befugnis zum Eingreifen besitzt. Vertretungsregelungen sollten vorab geklärt und Ausgabenbeschränkungen klar vom Widerruf kompromittierter Schlüssel unterschieden werden. Ein reduziertes Ausgabenlimit stellt die Vertraulichkeit eines offengelegten Schlüssels nicht wieder her.

Quellen

• METR - Sicherheits-Update, 31.08.2026.