Ausgangspunkt des ersten Vorfalls war laut METR eine persönliche EC2-Instanz eines Forschers ohne Zugang zu sensiblen Systemen. Die Instanz war absichtlich öffentlich erreichbar, aber durch eine Google-Authentifizierung geschützt – und enthielt einen API-Schlüssel für METRs Konto für den allgemeinen Zugriff auf öffentliche Modelle.
Die dort betriebene, per „Vibe Coding" entstandene Anwendung wies jedoch eine Schwachstelle auf, die im Fehlerfall den Zugang offen ließ: Die Authentifizierung wurde stillschweigend deaktiviert. Dadurch war das Dashboard zur Agenten-Orchestrierung über mehrere Tage ungeschützt im Internet erreichbar.
Wie die Angreifer das System fanden, rekonstruiert METR als Verdacht: Sie hätten wahrscheinlich kürzlich registrierte Websites durchsucht – etwa in Certificate-Transparency-Listen –, um per Vibe Coding erstellte Seiten mit aussagekräftigen Schlüsselwörtern rund um LLMs und Agenten zu identifizieren und dort exponierte API-Schlüssel von Modellanbietern abzuschöpfen.
Nach dem Auffinden des Systems forderte der Angreifer einen Agenten direkt dazu auf, den API-Schlüssel des Modellanbieters offenzulegen, hinterlegte anschließend einen SSH-Schlüssel für dauerhaften Zugang und nutzte die gestohlenen Zugangsdaten drei Wochen lang, um in erheblichem Umfang API-Guthaben auf öffentlich verfügbaren Modellen zu verbrauchen.
Dass der Missbrauch nicht sofort auffiel, erklärt METR mit dem eigenen Betriebsprofil: Die Organisation führt groß angelegte Evaluierungen und Experimente durch, die ohnehin sehr viele Token verbrauchen, und es existierten keine Obergrenzen für Token-Ausgaben. Als Reaktion hat METR die internen Regeln dafür verschärft, METR-Zugangsdaten oder -Daten auf fremder Infrastruktur und fremden Geräten zu verwenden, die Überwachung verbessert und – wo möglich – Ausgabenwarnungen für Schlüssel eingerichtet.
Den zweiten Vorfall im Mai 2026 beschreibt METR als anhaltende externe Angriffskampagne, hinter der ein wahrscheinlich finanziell motivierter Akteur stand, dem es um unrechtmäßigen Zugang zu Spitzen-KI-Modellen ging. Die Angreifer hätten die öffentlich erreichbare Infrastruktur systematisch abgetastet und dabei stark auf Agenten gesetzt, um die Suche nach Schwachstellen zu automatisieren: mit Credential Stuffing gegen Authentifizierungsanbieter, Versuchen, OAuth-Token zu erlangen, Scans neu bereitgestellter Dienste und Phishing-Versuchen gegen Mitarbeitende.
Etwa im selben Zeitraum legte METR versehentlich einen nur lesenden SQL-Abfragemechanismus offen, der in den öffentlichen Transkript-Viewer eingebaut war. Standardmäßig waren die Abfragen auf öffentliche Daten beschränkt, doch ein Fehler in der Komponente hätte den Zugriff auf unveröffentlichte Evaluierungsdaten ermöglichen können. Zudem enthielt die Datenbank versehentlich sensible Modelldaten, obwohl dort ausschließlich Daten nicht sensibler Modelle liegen sollten.
Aufmerksam wurde METR darauf erst, nachdem ein unabhängiger Sicherheitsforscher das Problem entdeckt und gemeldet hatte; die Schnittstelle wurde daraufhin abgeschaltet. Die Angreifer hätten diesen Endpunkt im Rahmen ihrer Kampagne beiläufig geprüft, es gebe aber keine Hinweise darauf, dass sie den Fehler erkannt oder nicht öffentliche Daten abgerufen hätten.