METRs vibe-codiertes Agenten-Dashboard deaktivierte seinen eigenen Login, und ein Angreifer verbrauchte Modellguthaben im Wert von 600.000 US-Dollar

Im März 2026 entwendete jemand einen API-Schlüssel für das Konto für öffentliche Modelle von METR von der persönlichen Amazon-EC2-Instanz eines Forschers und nutzte ihn für drei Wochen. METR – Model Evaluation and Threat Research, die gemeinnützige Organisation, die misst, wie weit KI-Agenten bei Aufgaben mit langem Zeithorizont kommen – bezifferte den kommerziellen Wert des verbrauchten Guthabens auf etwa 600.000 US-Dollar. Der Schlüssel wurde keinem Menschen durch Phishing entwendet: Der Angreifer brachte einen Agenten, der auf dem per Vibe-Coding erstellten Dashboard des Forschers lief, dazu, den API-Schlüssel seines Modellanbieters herauszugeben, und fügte dann einen SSH-Schlüssel hinzu, damit er zurückkehren konnte. METR machte den Vorfall am 31. August 2026 öffentlich, und der Eintrag trägt die hohe Schweregrad-Einstufung des Archivs sowie eine Konfidenzbewertung der Stufe A. Die Offenlegung ist ein Eintrag im KI-Vorfallarchiv, das den vollständigen Bestand an Einträgen, seine Quellen und die benachbarten Einträge dieser Reihe enthält.

Was die Aufzeichnung tatsächlich sagt

Das Archiv klassifiziert dies als einen tatsächlich eingetretenen Vorfall, nicht als Offenlegung einer theoretischen Schwachstelle: Schweregrad hoch, Konfidenz A, nicht bestritten, mit dokumentiertem realen Schaden und bestätigter Beteiligung von KI. Das Typ-Tag ist CRED, bei der Region handelt es sich um die Vereinigten Staaten, und das Datum ist nur monatsgenau erfasst — das Archiv weiß, dass der Diebstahl im März 2026 geschah, und nennt keinen Tag, und METR ebenso wenig.

Der Schaden bedarf einer Einschränkung, und METR liefert sie. Die Guthaben wurden METR vom Modellentwickler kostenlos gewährt, sodass die 600.000 US-Dollar den Wert des Verbrauchten darstellen und nicht Geld, das von einem Konto abgeflossen ist. Der Vorspann von The Register brachte denselben Punkt unverblümter auf den Punkt: Der Modellanbieter gab METR die Guthaben, und ein tatsächlich zahlender Kunde hätte nicht so viel Glück gehabt. Infosecurity Magazine berichtete die Zahl auf dieselbe Weise – als kommerziellen Wert statt als direkten finanziellen Verlust.

Der Beitrag von METR behandelt zwei Vorfälle, nicht einen. Die Kampagne vom Mai 2026 wird weiter unten separat beschrieben; der Diebstahl des Schlüssels und die drei Wochen, in denen Ausgaben getätigt wurden, sind der Vorfall im März, und sie sind Gegenstand dieses Artikels.

Der Fehler lag beim Login, nicht im Modell.

Ein METR-Forscher ohne Zugriff auf sensible Daten betrieb Agenten auf einer persönlichen EC2-Instanz, die absichtlich öffentlich erreichbar gemacht worden war, hinter Google-Authentifizierung. Die Instanz enthielt einen API-Schlüssel für das Konto von METR für allgemeinen Zugriff – das für öffentliche Modelle genutzte Konto, das METR als seine am zweitwenigsten sensible Datenkategorie führt. Die Orchestrierungs-App um diese Agenten herum war per Vibe-Coding entstanden und enthielt eine von METR so genannte Fail-open-Schwachstelle, die die Authentifizierung stillschweigend deaktivierte.

Fail-open lohnt eine Übersetzung, denn es ist der gesamte Vorfall in zwei Worten. Eine Login-Prüfung kann auf zwei Arten falsch sein: Sie kann einen legitimen Nutzer abweisen oder jeden zulassen, wenn die Prüfung selbst ausfällt. Fail-open bedeutet das Zweite – wenn der Authentifizierungsschritt fehlschlug oder übersprungen wurde, behandelte die App die Anfrage als erlaubt statt als abgelehnt. Nichts schlug Alarm. In METRs Darstellung war das Ergebnis ein System, das im öffentlichen Internet für mehrere Tage mit weit offener Eingangstür stand und ohne jeden Hinweis darauf, dass sich etwas verändert hatte.

METR nennt weder das Orchestrierungstool noch das Framework, mit dem das Dashboard gebaut wurde, veröffentlicht den Code nicht und sagt nicht, in welcher Weise die Authentifizierungsintegration fehlgeschlagen ist. Was der Beitrag jedoch belegt, ist der architektonische Fehler unter dem Bug: Ein Zugangsdatum für ein Konto eines Organisationsmodells befand sich auf einer Infrastruktur, die METR nicht kontrollierte, in einer Anwendung, die ein Forscher selbst bereitgestellt hatte.

Wie der Schlüssel das Gebäude verließ

METRs Rekonstruktion der Vorgehensweise des Angreifers ist ausdrücklich eine Vermutung, kein Befund, und sie ist die interessanteste unbewiesene Behauptung in der Offenlegung. Der Beitrag sagt, METR vermute, der Angreifer habe die Instanz gefunden, indem er kürzlich registrierte Websites durchsuchte – Certificate-Transparency-Listen werden als Beispiel genannt –, auf der Suche nach vibe-codierten Seiten mit Schlüsselwörtern, die auf LLM- oder Agent-Projekte hinweisen, um API-Schlüssel von Modellanbietern abzugreifen, die offen zugänglich hinterlassen worden waren.

Certificate-Transparency-Logs sind von Natur aus öffentlich: Jedes Zertifikat, das für eine öffentlich vertrauenswürdige Website ausgestellt wird, wird erfasst, sodass ein neuer Hostname innerhalb von Minuten nach dem Livegang in einem durchsuchbaren Feed erscheint. Diesen Feed nach Namen zu filtern, die Agent- oder Modellterminologie enthalten, ist günstig, erfordert keinen Zugriff auf das Ziel und erzeugt eine Liste frischer Deployments, die möglicherweise von niemandem überprüft wurden. Als Jagdtechnik gelesen, verwandelt es den gewöhnlichen Akt, eine Demo zu veröffentlichen, in ein Signal.

Einmal eingedrungen, musste der Angreifer kein Geheimnis aus einem Dateisystem stehlen. Er forderte den Agenten direkt dazu auf, den API-Schlüssel seines Modellanbieters preiszugeben, was ein Satz ist, der einen Moment verdient: Der Agent hatte die Zugangsdaten in seinem Kontext und ließ sich dazu überreden, sie auszugeben. Der Angreifer fügte dann einen SSH-Schlüssel für dauerhaften Zugriff hinzu, sodass das Schließen der Authentifizierungslücke ihn nicht vertrieben hätte, und blieb für drei Wochen, um Inferenz auf öffentlich verfügbaren Modellen zu betreiben.

Der Entwickler des Modells wird nicht genannt – weder von METR noch von The Register, Dark Reading, Infosecurity Magazine oder The Hacker News in ihrer Berichterstattung über die Offenlegung. Es wurde keine CVE vergeben, da keine Produktschwachstelle vorliegt. Es wurde weder eine Festnahme noch eine Anklage noch eine Zuschreibung zu einer benannten Gruppe gemeldet.

Warum drei Wochen abnormaler Nutzung normal aussahen

METR beantwortet die naheliegende Frage direkt, und die Antwort ist der Teil, den andere Organisationen zweimal lesen sollten. Die gemeinnützige Organisation führt groß angelegte Evaluierungen durch, was bedeutet, dass sie an sehr große Tokenmengen und an eine Reihe seltsamer Rate-Limit- und API-Fehler gewöhnt ist, von denen viele unecht sind. Ein Anstieg des Modellverkehrs war für sich genommen kein Signal.

Drei konkrete Lücken verwandelten diese Vertrautheit in drei Wochen Stille. Das interne Nutzungs-Dashboard von METR zeigte selbst dann keine Daten zu rate-limitierten Anfragen über alle Nutzer hinweg, wenn diese Anfragen gerade liefen. Da die Tokens kostenlos waren, gab es keine Rechnung und damit auch keine natürliche Ausgabenobergrenze, die ausgelöst worden wäre. Und damals gab es laut METR überhaupt keine Möglichkeit, für einen Schlüssel dieser Art ein Ausgabenlimit festzulegen. Eine Organisation, die den Listenpreis zahlte und eine harte Obergrenze hatte, wäre innerhalb von Stunden an eine Grenze gestoßen; eine Organisation mit gespendetem Guthaben und ohne Obergrenze hatte nichts, woran sie anstoßen konnte.

Was nicht genommen wurde

METRs Datentaxonomie reicht von veröffentlichtem Material über generischen Modellzugriff und sensiblen Modellzugriff bis hin zu hochsensiblen Geschäftsinformationen. Der beteiligte Forscher hatte keinen Zugriff auf die beiden obersten Kategorien, und METR gibt an, dass nach bestem Wissen keine Daten aus diesen Kategorien infolge eines der beiden Vorfälle abgerufen wurden.

Abgesehen von dem einen Schlüssel sagt METR, manuelle und agentenunterstützte forensische Untersuchungen hätten keine Kompromittierung gefunden, und der Sicherheitsberater von METR, Calif, habe die Ergebnisse validiert und eine eigene Kompromittierungsanalyse durchgeführt. Das ist eine aussagekräftige Kontrolle – ein externes Unternehmen, das die Darstellung prüft, statt sie einfach zu übernehmen –, aber sie ist nicht unabhängig von METR, das Calif beauftragt und bezahlt hat. Keine dritte Partei hat eine eigene forensische Überprüfung des Vorfalls veröffentlicht.

Was METR tat, als es bemerkte

Der Reaktionsablauf im Beitrag ist konkret. METR stellte fest, dass der Nutzungsanstieg nicht Teil einer Evaluierung war, führte ihn auf die kompromittierte persönliche Instanz zurück, entzog dem Forscher sämtliche Zugriffsrechte, stoppte die Instanz und erstellte ein Image davon, rotierte sämtliche darauf vorhandenen Zugangsdaten und erstellte ein Image des Laptops des Forschers und löschte ihn. METR benachrichtigte das Partner-KI-Unternehmen, dessen Guthaben verbraucht wurde, und hielt es während der gesamten Reaktion auf dem Laufenden.

METR erklärt nicht die Begründung für das Wipen des Laptops, und es ist der eine Schritt in der Abfolge, der über das Entziehen des Zugriffs auf die Instanz selbst hinausgeht – die naheliegende Lesart ist, dass derselbe Forscher die Anmeldedaten von einer Workstation aus verwendet hatte, die der Angreifer erreichen konnte, und dass es die kostengünstige Methode ist, ein Image zu erstellen und dann neu aufzusetzen, um bei einer Maschine sicher zu sein.

Was hat sich danach geändert?

METR führt vier Änderungen im Zusammenhang mit diesem Vorfall auf:

• Die Sicherheitsrichtlinien für Mitarbeitende und Auftragnehmer wurden klargestellt und erweitert, insbesondere im Hinblick darauf, METR-Zugangsdaten oder -Daten auf Infrastruktur und Geräten abzulegen, die nicht METR gehören.

• Für alle Forschenden, die eine Anwendung öffentlich bereitstellen, gilt jetzt ein formelles Sicherheitsüberprüfungsverfahren.

Die Überwachungsabdeckung wurde erhöht, wobei daran gearbeitet wurde, störende Warnmeldungen zu beseitigen, die Einsatzkräfte dazu verleiten, sie zu ignorieren.

• Ausgabenwarnungen wurden zu Schlüsseln hinzugefügt, bei denen der Anbieter das möglich macht – die Relativierung ist wichtig, denn der frühere Punkt des Beitrags war, dass einige Schlüssel dieser Art damals nicht mit einer Obergrenze versehen werden konnten.

Die Offenlegung listet außerdem unternehmensweite Maßnahmen auf: die Einstellung eines Security-Leads und die Planung eines Vollzeit-Sicherheitsingenieurs, die stärkere Einbindung von Calif, die Abschaltung von Legacy-Infrastruktur, die die Angriffsfläche vergrößerte, regelmäßige Threat-Modelling-Reviews, die Ausweitung des Loggings auf Datenbankabfragen und API-Nutzung, die Überwachung ungewöhnlicher API-Schlüssel-Nutzung, die Bereitstellung zusätzlicher Endpoint- und Server-Sicherheitssoftware, die Verkürzung der Lebensdauer von Anmeldedaten und die Reduzierung von Berechtigungsbereichen. METR datiert diese Maßnahmen als gültig bis zum 30. Juli 2026 und gibt an, dass sie Änderungen vorbehalten sind — ein Vorbehalt, den man im Hinterkopf behalten sollte, denn er bedeutet, dass der Beitrag einen Zustand etwa vier Monate nach dem Diebstahl und rund einen Monat vor der Veröffentlichung beschreibt.

Der andere Vorfall im selben Beitrag

METRs Offenlegung verknüpft den Schlüsseldiebstahl mit einem zweiten, separaten Ereignis in Anfang Mai 2026, und die beiden sind leicht zu verwechseln. Bei diesem zweiten Ereignis erhielt METR den Hinweis, dass es von Angreifern ins Visier genommen wurde, die finanziell motiviert zu sein schienen und möglicherweise auf Zugriff auf Frontier-Modelle aus waren; METR beobachtete, wie sie seine öffentliche Infrastruktur sondierten und dabei in großem Umfang Agenten einsetzten, um die Entdeckung von Schwachstellen zu automatisieren, einschließlich Credential Stuffing gegen Authentifizierungsanbieter, versuchter OAuth-Token-Grants, Scans neu bereitgestellter Dienste und Phishing gegen Mitarbeitende.

Im selben Zeitraum hat METR versehentlich einen schreibgeschützten SQL-Abfragemechanismus über seinen öffentlichen Transkript-Viewer offengelegt. Abfragen waren standardmäßig auf öffentliche Daten beschränkt, doch ein Fehler ließ sich auf unveröffentlichte Evaluationsdaten richten, und einige sensible Modellausgaben waren versehentlich in diese Datenbank geladen worden. Ein unabhängiger Sicherheitsforscher entdeckte die Schwachstelle und meldete sie verantwortungsvoll; METR nahm die API offline und zahlte eine Prämie. Nach METRs Darstellung durchliefen die Angreifer den Endpunkt im Rahmen ihrer breiteren Kampagne, zeigten jedoch keine Hinweise darauf, dass sie den Exploit fanden oder auf nicht öffentliche Daten zugriffen — eine Schlussfolgerung, die METR in einer Fußnote als „höchst unwahrscheinlich“ statt bei null angibt.

Was gilt als gesichert und was nicht

Bestätigt. METR veröffentlichte die Offenlegung am 31. August 2026 und beschreibt darin den Diebstahl im März, den Fail-Open-Authentifizierungsfehler, die agentenvermittelte Offenlegung des Schlüssels, den SSH-Schlüssel, das Zeitfenster von drei Wochen und die Bewertung von rund 600.000 US-Dollar. Vier Sicherheitsportale – The Register, Dark Reading, Infosecurity Magazine und The Hacker News – berichteten binnen eines Tages über dieselbe Darstellung, und keines von ihnen widerspricht ihr – obwohl sich alle vier auf denselben METR-Beitrag stützen und nicht auf unabhängigen Zugriff auf METRs Protokolle oder die Abrechnung des Anbieters.

Nicht belegt. Die 600.000 US-Dollar sind METRs eigene Schätzung des gespendeten Guthabens; es wurden keine Rechnung, keine Anbietererklärung und keine unabhängige Bewertung veröffentlicht, und da nichts gezahlt wurde, gibt es keine Transaktion, an der sich das überprüfen ließe. Die Certificate-Transparency-Suchmethode wird von METR als Verdacht eingestuft und wurde von keiner Partei bestätigt, die Einblick in die Aktivitäten des Angreifers hat. Die Identität des Angreifers, die Identität des Modellanbieters und der genaue Tag im März sind alle unbekannt oder nicht veröffentlicht. Und die Behauptung, dass keine sensiblen Daten erreicht wurden, stützt sich auf METRs Forensik und die Prüfung durch seinen Berater, nicht auf eine externe Auditierung.

Es lohnt sich auch, beim Wort Beinahe-Vorfall präzise zu sein. METR bezeichnet beide Vorfälle so, und Dark Reading widersprach dieser Darstellung für das März-Ereignis mit der Begründung, es sei eine erfolgreiche Kompromittierung gewesen, bei der ein Angreifer Persistenz etabliert und drei Wochen lang in einer gestohlenen Zugangsberechtigung verbracht habe. Beide Beschreibungen treffen unterschiedliche Dinge genau: Das Ergebnis wurde eingedämmt, und der Einbruch war real.

{{1}}Dark Reading brachte in seinem Bericht auch die schärfste externe Einschätzung.{{/1}} Jacob Krell, {{2}}Senior Director für sichere KI-Lösungen und Cybersicherheit bei Suzu Labs,{{/2}} sagte gegenüber dem Medium, dass {{3}}METR eine der in Sicherheitsfragen reiferen Organisationen im KI-Bereich sei, mit SOC 2 Type I-Zertifizierung, einem dedizierten Sicherheitsberater und einem vierstufigen Datenklassifizierungssystem,{{/3}} und dass {{4}}die Vorfälle dennoch auf gewöhnliche Weise zustande kamen – ein Fail-open-Authentifizierungsfehler auf einer persönlichen Cloud-Instanz.{{/4}} {{5}}Wenn eine Organisation auf diesem Reifegrad von grundlegender Cloud- und Credential-Hygiene erwischt wird, argumentierte Krell, sagt das etwas über die Untergrenze der Sicherheit in der KI-Branche aus und nicht über die Obergrenze.{{/5}} {{6}}Dark Reading merkt an, dass METR nicht auf seine Bitte um Stellungnahme zu dem Artikel reagiert habe.{{/6}}

Warum der Schlüssel eines Evaluators keine Kleinigkeit ist

METRs Rolle ist der Grund, warum dieser Eintrag in einem Sicherheitsarchiv und nicht in einem Sammelbericht zur Cloud-Hygiene steht. Dark Reading berichtet, dass die Organisation mit den meisten großen westlichen Modellanbietern zusammenarbeitet, darunter OpenAI, Anthropic, Google, Meta und Amazon, und The Register merkt an, dass METR mit OpenAI zusammengearbeitet hat, um zu untersuchen, wie OpenAI-Agenten Anfang 2026 auf Server von Hugging Face gelangten. Ein Evaluator verfügt über nicht öffentlich gemachte Ergebnisse, unveröffentlichte Transkripte und Zugang zu Modellen vor deren Veröffentlichung; seine Zugangsberechtigungen sind faktisch Teil des Sicherheitsperimeters seiner Kunden.

Der Vorfall im März erreichte nichts davon. Er erreichte einen Schlüssel für öffentliche Modelle, auf einer persönlichen Instanz, hinter einem Login, das stillschweigend aufgehört hatte zu funktionieren – genau deshalb ist er ein nützlicher Beleg. Das Versagen erforderte keinen neuartigen Angriff auf ein Modell. Es erforderte ein Demo-Deployment, das niemand überprüft hatte, eine Authentifizierungsprüfung, die bei einem Ausfall standardmäßig auf Ja zurückfiel, und ein Abrechnungssystem, in dem eine enorme Nutzung der Normalzustand war.