Agentensicherheit endet nicht bei der Modellwahl: Lehren aus zwei Sicherheitsvorfällen bei METR

Auch eine Agentenanwendung mit Google-Anmeldung kann API-Schlüssel oder Daten offenlegen, auf die sie zugreifen kann. METR (Model Evaluation and Threat Research) ist eine nicht gewinnorientierte Organisation, die KI-Modelle evaluiert und mögliche Bedrohungen durch diese Modelle untersucht. Zwei Sicherheitsvorfälle bei METR zeigen, wie Entscheidungen über Authentifizierung, Ausgabenlimits und den laufenden Betrieb die Folgen eines Fehlers bestimmen.

Im März 2026 betrieb ein METR-Forscher auf einer persönlichen EC2-Instanz eine Anwendung zur Steuerung von KI-Agenten. Die Anwendung war über das Internet erreichbar. Der Zugriff erforderte eine Authentifizierung über Google. Auf der Instanz lag ein API-Schlüssel, mit dem METR öffentlich verfügbare Modelle nutzen konnte.

Ein Fehler deaktivierte die Authentifizierung unbemerkt. Mehrere Tage lang war das System für jeden im Internet zugänglich. Ein Angreifer fand die Anwendung, forderte einen Agenten auf, den API-Schlüssel seines Modellanbieters auszugeben, und gelangte so an den Schlüssel.

METR beschreibt beide Vorfälle in seinem Sicherheitsbericht vom 31. August 2026. Der Bericht stützt sich auf Untersuchungen der Organisation und ihres Sicherheitsberaters. METR geht davon aus, dass bei keinem der beiden Vorfälle auf sensible Informationen zugegriffen wurde. Diese Einschätzung setzt auch der folgenden technischen Analyse Grenzen.

Fail-open: Wenn eine fehlgeschlagene Prüfung den Zugriff erlaubt

Fail-open bezeichnet ein Verhalten, bei dem ein Fehler in einer Sicherheitskontrolle den Zugriff offenlässt, statt ihn zu sperren. Bei der Authentifizierung kann das bedeuten, dass eine Anfrage akzeptiert wird, obwohl die Identität des Benutzers nicht bestätigt wurde.

Bei Fail-closed wird die geschützte Aktion abgelehnt, wenn sich die Identität oder die erforderliche Berechtigung nicht bestätigen lässt.

Im ersten METR-Vorfall deaktivierte eine Fail-open-Schwachstelle die Authentifizierung der mit KI-Unterstützung entwickelten Anwendung. Die Anmeldung über Google verhinderte den Fehler in der anwendungseigenen Zugriffskontrolle nicht.

Wer nur den erfolgreichen Anmeldevorgang testet, lässt damit einen Teil des Verhaltens ungeprüft. Das Team muss auch prüfen, was passiert, wenn eine Sitzungsprüfung fehlschlägt, notwendige Konfiguration fehlt oder die Authentifizierungskomponente einen Fehler meldet.

Der Bericht erklärt nicht, wie sich die METR-Anwendung in jedem dieser Fälle verhalten hätte. Es sind Prüffälle für Teams, die dieselbe Fehlerklasse im eigenen System untersuchen. Aus dem Vorfall folgt auch nicht, dass jede Fail-open-Schwachstelle ausgenutzt wird. Die Anforderung an den Entwurf bleibt dennoch klar: Eine fehlgeschlagene Zugriffsprüfung darf keine Erlaubnis zum Fortfahren werden.

Erster Vorfall: Welche Ressourcen ein gestohlener Schlüssel erschloss

Nachdem der Angreifer den API-Schlüssel erhalten hatte, hinterlegte er einen SSH-Schlüssel auf der Instanz, um den Zugriff aufrechtzuerhalten. Mit den gestohlenen Zugangsdaten verbrauchte er innerhalb von drei Wochen bei öffentlich verfügbaren Modellen API-Guthaben im Wert von rund 600.000 US-Dollar.

METR erhielt keine Rechnung über diesen Betrag. Der Modellentwickler hatte das Guthaben kostenlos zur Verfügung gestellt. Den Vorfall als einen Geldverlust von 600.000 US-Dollar zu beschreiben, würde die wirtschaftliche Bedeutung verfälschen. Es blieb aber ein unbefugter Verbrauch einer Ressource, die der Organisation zur Verfügung stand.

Mehrere Kontrolllücken verbanden sich zu einem Angriffsweg. Eine Person aus dem Internet konnte den Agenten nutzen, über ihn an einen geheimen Schlüssel gelangen und diesen anschließend außerhalb der Anwendung einsetzen. Der SSH-Schlüssel ermöglichte erneuten Zugriff auf die Instanz.

Auch die Erkennung des Verbrauchs war lückenhaft. Damals konnten nicht alle Nutzer des internen METR-Dashboards Daten zu Anfragen sehen, die wegen Rate-Limits abgewiesen wurden. Da METR das Guthaben kostenlos erhielt, war der Verbrauch nicht durch ein reguläres Ausgabenbudget begrenzt. Laut Bericht ließ sich für diese Art von API-Schlüssel auch kein Ausgabenlimit festlegen.

Der Authentifizierungsfehler erklärt den ersten Zugriff. Der zugängliche Schlüssel erklärt, was der Angreifer erlangte. Die Sichtbarkeit des Verbrauchs und dessen Begrenzung tragen dazu bei, die Dauer der missbräuchlichen Nutzung zu erklären. Dahinter stehen jeweils andere technische Entscheidungen.

METR entzog dem Forscher die Zugriffsrechte, stoppte die Instanz, erstellte ein Datenträgerabbild und tauschte die dort gespeicherten Zugangsdaten aus. Auch das Notebook des Forschers wurde nach der Erstellung eines Abbilds gelöscht. METR informierte den betreffenden Modellanbieter, zog seinen Sicherheitsberater hinzu und änderte Regeln für Zugangsdaten auf externen Geräten sowie für die Bereitstellung öffentlich erreichbarer Anwendungen.

Diese Reaktion zeigt, warum ein Sicherheitsvorfall bei einem Forschungswerkzeug mehr erfordern kann, als das Werkzeug selbst abzuschalten.

Zweiter Vorfall: Lesezugriff schützt noch keine Vertraulichkeit

Im Mai 2026 beobachtete METR, wie Angreifer die öffentlich erreichbare Infrastruktur systematisch auf Schwachstellen prüften. Sie probierten gestohlene Kombinationen aus Benutzernamen und Passwörtern aus, versuchten über OAuth Zugriff zu erlangen, scannten neu bereitgestellte Dienste und richteten Phishing-Versuche gegen Beschäftigte. Laut METR setzten sie auch Agenten ein, um die Suche nach Schwachstellen zu automatisieren.

Im selben Zeitraum wurde über eine öffentliche Anwendung für Gesprächsprotokolle von Modellen versehentlich eine Schnittstelle für SQL-Abfragen mit reinem Lesezugriff zugänglich. Die Abfragen waren standardmäßig auf öffentliche Daten beschränkt. Ein Fehler machte jedoch auch unveröffentlichte Evaluationsdaten erreichbar. Außerdem waren versehentlich sensible Modellausgaben in die Datenbank gelangt.

Ein unabhängiger Sicherheitsforscher entdeckte und meldete die Schwachstelle. METR nahm den Dienst offline. Die Untersuchung ergab keine Hinweise darauf, dass die Angreifer die Schwachstelle entdeckt oder auf nicht öffentliche Daten zugegriffen hatten.

Reine Leserechte können verhindern, dass Daten verändert werden. Vertraulichkeit verlangt zusätzlich eine Begrenzung der lesbaren Daten. Ein Dienst kann Informationen preisgeben, indem er die falschen Datensätze zurückliefert, ohne eine einzige Zeile zu verändern.

Der Fehler bei der Begrenzung der Abfragen und die Daten am falschen Ort müssen deshalb gemeinsam betrachtet werden. Wurde der Abfragebereich unerwartet erweitert, waren Daten erreichbar, die über den vorgesehenen Veröffentlichungsumfang des Dienstes hinausgingen.

METR hat nach eigenen Angaben eine öffentliche Produktionsumgebung geschaffen, die architektonisch von der internen Infrastruktur getrennt ist. Zudem hat die Organisation Berechtigungen eingeschränkt, die Gültigkeitsdauer von Zugangsdaten verkürzt und den Schutz von Endgeräten und Servern sowie die externe Unterstützung bei der Cybersicherheit ausgebaut.

Vertrauensgrenzen und die Reichweite eines Angriffs

Zwei Begriffe helfen, den Zusammenhang zwischen den Vorfällen zu verstehen: Vertrauensgrenzen und die Reichweite nach einem erfolgreichen Zugriff.

Eine Vertrauensgrenze trennt Systembereiche, in denen unterschiedliche Zugriffsregeln und Berechtigungen gelten. Eine Internetanfrage, die Werkzeuge eines Agenten erreicht, ein Agent, der einen API-Schlüssel liest, und ein öffentlicher Dienst, der interne Daten abfragt, sind unterschiedliche Übergänge. Jeder dieser Übergänge braucht eigene Kontrollen.

Der Begriff Blast Radius beschreibt, auf welche Ressourcen ein Angreifer nach der Kompromittierung einer Komponente zugreifen und welche Aktionen er ausführen kann. Auch eine kleine Anwendung kann ihm weitreichende Möglichkeiten eröffnen. Ein Forschungswerkzeug auf einer persönlichen Instanz kann einen Schlüssel enthalten, der umfangreiche Ressourcen der Organisation zugänglich macht.

Im ersten Vorfall eröffnete der Zugang zu einer Anwendung einen Weg zur Modellnutzung von METR. Im zweiten schuf ein Fehler in einem öffentlichen Dienst die Möglichkeit, Daten abzurufen, die nicht veröffentlicht werden sollten.

Daraus ergibt sich eine konkrete Entwurfsfrage: Welche anderen Kontrollen funktionieren noch, wenn eine ausfällt? Die Verwaltung von Zugangsdaten, die Trennung von Daten und Nutzungsgrenzen sollten auch dann schützen, wenn die Authentifizierung versagt.

Vor dem Produktivbetrieb die Grenzen festlegen

Für die Entscheidung über den Produktivbetrieb lässt sich aus diesen Vorfällen ein Vorgehen ableiten: Jede Kontrolle danach beurteilen, welches Risiko sie verringert. Wie weit die folgenden Maßnahmen reichen müssen, hängt von der Aufgabe des Agenten und den benötigten Ressourcen ab.

Schlägt die Authentifizierung fehl, muss die geschützte Aktion abgelehnt werden. Die Zugriffsentscheidung gehört auf die Serverseite an den jeweiligen Endpunkt. Eine Anmeldeseite belegt noch nicht, dass alle dahinterliegenden Funktionen geschützt sind. Prüfen Sie die Fehlerfälle, bevor die Anwendung über das Internet erreichbar wird. Planen Sie auch, wie der Betrieb weiterläuft, wenn ein Fail-closed-Verhalten legitime Arbeitsabläufe unterbricht.

Die Berechtigungen des authentifizierten Benutzers und des in seinem Auftrag handelnden Agenten müssen getrennt begrenzt werden. Wer für eine Aufgabe bestimmte Datensätze lesen muss, braucht keinen Zugriff auf die gesamte Datenbank. Ebenso sind ein Modellaufruf und das Ändern der Zugriffseinstellungen eines Servers unterschiedliche Befugnisse. Jede Berechtigung sollte durch die Aufgabe begründet sein, die sie erfordert.

Bei geheimen Schlüsseln zählt neben dem Speicherort, welche Komponente sie lesen kann. Kann ein Agent auf die Umgebungsvariablen seines Prozesses lesend zugreifen, entzieht ihm das Verschieben eines Schlüssels aus dem Quellcode in eine Umgebungsvariable diesen Zugriff nicht. Trennen Sie nach Möglichkeit die Komponente, die den Anbieter aufruft, vom Arbeitsbereich, den der Agent lesen kann. Zugangsdaten mit eng begrenzten Rechten und kurzer Gültigkeit verringern außerdem die Möglichkeiten eines Angreifers und die Dauer, in der gestohlene Zugangsdaten nutzbar bleiben.

Die Überwachung der Nutzung sollte mehr zeigen als die Zahl erfolgreicher Anfragen. Der Verbrauch muss einem Schlüssel, einem Auftrag und einem Zeitraum zugeordnet werden können. Fehlermeldungen zu Rate-Limits und unerwartete Verbrauchsänderungen müssen anhand der tatsächlich laufenden Arbeit bewertet werden. Zur Gestaltung gehört auch, wer eine Warnung erhält und wie diese Person die Nutzung stoppen kann.

Eine Ausgabenwarnung und ein Ausgabenlimit erfüllen unterschiedliche Aufgaben. Eine Warnung wartet darauf, dass jemand handelt. Ein durchgesetztes Limit stoppt oder begrenzt den Verbrauch. Kann der Anbieter kein Limit setzen, verhindert ein Zähler in der eigenen Anwendung nicht, dass ein gestohlener Schlüssel andernorts verwendet wird. Diese Lücke gehört in die Entscheidung über den Produktivbetrieb.

Öffentliche Dienste sollten nur auf die Daten zugreifen können, die ihr Zweck erfordert. Eine Anwendung für veröffentlichte Datensätze braucht möglicherweise keinen direkten Zugang zu internen Evaluationsdaten. Ein separater Datenspeicher und eine Dienstidentität mit eingeschränkten Rechten schränken ein, welche Daten durch einen Anwendungsfehler zugänglich werden können. Ob diese Trennung Bestand hat, hängt auch davon ab, welche Daten für den Export ausgewählt werden.

Protokolle müssen die Untersuchung eines Vorfalls ermöglichen. Einer Benutzeranfrage sollten sich die Werkzeugaufrufe des Agenten, die verwendete Dienstidentität und die daraus folgenden Datenzugriffe zuordnen lassen. Schlüssel oder unnötige sensible Inhalte in Protokollen schaffen ein weiteres Offenlegungsrisiko. Inhalt, Leserechte und Aufbewahrungsdauer der Protokolle müssen daher gemeinsam festgelegt werden.

Vor einem Vorfall sollte außerdem feststehen, wer Zugänge sperren kann, welche Zugangsdaten auszutauschen sind und wie Beweismaterial erhalten bleibt. Während eines Angriffs muss das Team gleichzeitig den Zugriff stoppen und den Ablauf verstehen. Der Reaktionsplan sollte auch festlegen, welche Belege vorliegen müssen, bevor ein Dienst wieder online geht.

Was der Bericht belegt und was offenbleibt

Der Bericht von METR hilft, die Zugriffswege in diesen beiden Vorfällen und die Reaktion der Organisation zu verstehen. Er beruht auf Untersuchungen von METR und seinem Sicherheitsberater. Ein öffentlich zugänglicher unabhängiger Auditbericht wird damit nicht vorgelegt.

Dass keine Hinweise auf einen Zugriff auf sensible Daten gefunden wurden, bedeutet noch nicht, dass ein solcher Zugriff abschließend ausgeschlossen ist. METR formuliert seine Einschätzung innerhalb dieser Grenze.

Aus zwei Vorfällen lässt sich nicht ableiten, wie häufig Agentensysteme kompromittiert werden. Der Einsatz von Agenten durch die Angreifer zeigt auch nicht, um wie viel diese Werkzeuge branchenweit die Erfolgsquote von Angriffen erhöhen. Dafür wären Vergleichsdaten nötig. Der Bericht vergleicht ebenso wenig die Sicherheit unterschiedlicher Modelle unter demselben Angriff.

Autonomie innerhalb geprüfter Grenzen erweitern

Vor dem produktiven Einsatz eines Agenten sollte das Team erklären können, auf welche Daten eine problematische Anfrage zugreifen und welchen Ressourcenverbrauch sie auslösen könnte. Das Verhalten des Modells zu bewerten, ist ein Teil dieser Entscheidung. Kontrollen für Identität, Berechtigungen, Daten und Nutzung haben jeweils eine eigene Aufgabe.

Zu Beginn lässt sich die Autonomie auf den Bereich begrenzen, in dem sich diese Kontrollen einrichten und überprüfen lassen. Mit jedem zusätzlichen Werkzeug, jeder neuen Datenquelle und jeder weiteren Berechtigung muss die Reichweite eines möglichen Angriffs erneut betrachtet werden. Wenn der Handlungsspielraum des Agenten wächst, sollte die Fähigkeit der Organisation, Fehler zu erkennen und zu stoppen, mitwachsen.