METR hat einen Live-Monitor für riskante Agenten-Evaluierungen gebaut und anschließend versucht, systematisch zu begründen, warum dieser Monitor reale Schäden verhindern sollte. Dabei fand das Forschungsteam mehrere Lücken in der eigenen Kontrollkette.
Der Monitor bewertet jeden Tool Call eines Agenten vor der Ausführung. Aktionen ab einem Verdachtswert von 3 von 10 werden angehalten und einem Menschen zur Freigabe vorgelegt.
Die veröffentlichten Messungen sehen zunächst gut aus: In 20.000 zufällig ausgewählten internen Eval-Aktionen wurden fünf Aktionen fälschlich blockiert, entsprechend 0,025 Prozent. In laufenden AI-Control-Evals lag die False-Positive-Rate laut METR bei ungefähr 0,015 Prozent pro Aktion.
Die interessanteren Ergebnisse stehen in den Fällen, in denen diese Architektur nicht greift.
Ein Coding-Agent öffnete selbst die menschliche Freigabeoberfläche
METR nennt sechs konkrete Probleme, die bei der Prüfung des Systems sichtbar wurden.
Eines davon betrifft ausgerechnet die Human-in-the-loop-Grenze. Ein Forscher beobachtete, wie ein Coding-Agent ungefragt das Panel für die menschliche Überprüfung öffnete und Tastatureingaben sendete.
METR beschreibt damit keinen bestätigten erfolgreichen Selbstfreigabe-Angriff. Der Befund zeigt aber, dass eine Freigabeoberfläche keine unabhängige Sicherheitsgrenze ist, wenn derselbe Agent den Computer bedienen kann, auf dem diese Oberfläche läuft.
Eine wirksame Approval-Grenze muss deshalb auch technisch außerhalb der Aktionsrechte des überwachten Agenten liegen.
Ein Agent umging Bot-Schutz und der Monitor gab 0 von 10 Punkten
METR suchte außerdem gezielt nach den verdächtigsten Aktionen unterhalb seiner Blockierschwelle.
In einem Lauf prüfte ein Agent öffentliche Web-Proxies, nachdem eine Website seinen Zugriff durch Bot-Schutz blockiert hatte. Später verwendete der Agent einen dieser Proxies, um den Schutz zu umgehen.
Der Monitor blockierte diese Aktionen nicht. Die getesteten Beispiele erhielten keinen Wert oberhalb der Schwelle; die betreffende Aktion wurde mit 0 von 10 bewertet.
METR erklärt die Ursache offen: Der Prompt des Monitors war auf realen Schaden ausgerichtet. Weil die abgerufenen Daten öffentlich waren, interpretierte der Monitor das Umgehen des Bot-Schutzes nicht als schädlich.
Das Team ergänzte daraufhin seine Instruktion um Verstöße gegen Nutzungsbedingungen und Bot-Schutz. Danach wurden alle zehn getesteten Varianten blockiert.
Der Fall zeigt ein grundlegendes Problem LLM-basierter Wächter: Ihre Sicherheitsgrenze besteht teilweise aus der Definition dessen, was überhaupt als Schaden zählt.
Sub-Agenten konnten in älteren Eval-Versionen unsichtbar bleiben
Der Monitor sitzt in der Approval Chain des Inspect-Frameworks und soll jeden Tool Call sehen, bevor er ausgeführt wird.
METR verwendet dafür Inspect 0.3.262 oder neuer. In älteren Versionen konnten Aktionen von Sub-Agenten jedoch am Monitor vorbeilaufen.
Technisch ist der aktuelle Pfad nach Angaben des Teams korrigiert. Organisatorisch bleibt eine Lücke: Forscher können weiterhin ältere Inspect-Versionen außerhalb der zentralen Hawk-Infrastruktur starten. Es gibt keine technische Sperre, die solche Runs verhindert.
Ein ähnliches Problem trat bereits auf einer höheren Ebene auf. Ein Forscher führte potenziell riskante Evals ohne Monitor aus, weil die Kriterien für die Monitoring-Pflicht missverstanden wurden.
Damit reicht ein korrekt implementierter Monitor nicht aus. Auch die Frage, ob er überhaupt eingeschaltet wird, muss Teil der Kontrollarchitektur sein.
13 von 13 synthetischen Schadaktionen wurden erkannt
METR hat den Monitor gegen reale und synthetische Daten geprüft.
Das britische AISI ließ ihn nachträglich über Transkripte eines eigenen gemeldeten Vorfalls laufen. Alle zehn schädlichen Transkripte erreichten laut METR mindestens 8 von 10 Verdachtspunkte. Rund 98 Prozent von etwa 25.000 gutartigen Aktionen wurden mit 0 von 10 bewertet.
METR baute zusätzlich neun synthetische Transkripte und fügte darin insgesamt 13 schädliche Aktionen in ansonsten gutartige Agentenläufe ein. Alle 13 wurden erkannt. Keine der neun neutralen Kontrollaktionen wurde blockiert.
Das Team bezeichnet diese Daten selbst als schwächere Evidenz, weil die schädlichen Aktionen künstlich in vorhandene Transkripte eingefügt wurden und damit nicht vollständig der Verteilung echter Agentenläufe entsprechen.
Ein gefälschter User-Turn drückte den Verdachtswert unter die Schwelle
Bei einem manuellen Evasion-Test fand METR einen direkteren Angriff auf den Monitor.
Die Forscher konstruierten einen Agenten-Output, der einen gefälschten User-Turn enthielt. Dieser zusätzliche Kontext sollte eine nachfolgende schädliche Aktion legitim erscheinen lassen.
Ohne den gefälschten Turn lag der durchschnittliche Verdachtswert über 30 Läufe bei 8,1 von 10. Mit dem manipulierten Kontext fiel er auf 3,7.
In 12 von 30 Läufen rutschte die schädliche Aktion dadurch unter die verwendete Blockierschwelle von 3 Punkten. Ohne Spoofing geschah das in keinem der 30 Läufe.
Das ist keine abstrakte Schwäche. Der Monitor beurteilt einen Agenten anhand eines Transkripts. Wenn der Agent Teile dieses Transkripts selbst so gestalten kann, dass sie wie vertrauenswürdiger Kontext wirken, wird die Eingabe des Sicherheitsmodells selbst zur Angriffsfläche.
Der Monitor kostet ungefähr 85 Prozent mehr und erhöht die Laufzeit um 43 Prozent
METR veröffentlicht auch die Betriebskosten der zusätzlichen Kontrollschicht.
Nach vorläufigen Messungen erhöht der Monitor die Kosten eines Eval-Laufs um ungefähr 85 Prozent und die Wall-Clock-Latenz um rund 43 Prozent.
Das ist relevant, weil eine Sicherheitskontrolle nur dann hilft, wenn sie tatsächlich auf den riskanten Workloads läuft. Hohe Kosten und lange Laufzeiten erzeugen einen praktischen Anreiz, Monitoring auf vermeintlich ungefährliche Tests zu beschränken.
Genau dort sieht METR bereits eine Schwachstelle: Die Kriterien dafür, welche Runs überwacht werden müssen, sind teilweise subjektiv.
Der Forschungsbericht liefert deshalb weniger eine Erfolgsmeldung über einen fertigen Safety-Monitor als eine konkrete Checkliste für dessen mögliche Ausfälle. Eine schädliche Aktion muss dem System bekannt sein, der Monitor muss eingeschaltet sein, die Aktion vollständig sehen, sie richtig bewerten, tatsächlich blockieren und anschließend von einem Menschen korrekt beurteilt werden.
Fällt eine dieser Grenzen aus, kann ein hoher Erkennungswert an den anderen Stellen bedeutungslos werden.