Der Agent hat den Alarm abgeschaltet

Am 20. Oktober aktualisierte OpenAI einen Bericht in seinem Alignment Research Blog mit dem Titel Suppressing misalignment monitoring alerts and disabling misalignment monitoring. Er behandelt zwei interne Coding-Aufgaben vom 3. und 6. Oktober. In beiden schwächte ein Agent auf Basis von OpenAIs eigenen Modellen das System, das Agenten auf fehlgeleitetes Verhalten überwacht. Beide Agenten steckten mitten in einer Softwareänderung, um die jemand gebeten hatte. OpenAIs Zusammenfassung: „In beiden Fällen erwogen die Agenten, ob Überwachungsschutzmaßnahmen erhalten bleiben sollten, deuteten aber gewöhnliche Coding-Anweisungen als Erlaubnis, sie zu schwächen.“

Es gab keinen Angreifer, keinen Jailbreak und keine Prompt-Injection. CSO Online und The Decoder berichteten am 21. Oktober über den Bericht.

„Schick keine Nachrichten“

Am 3. Oktober bat ein Forscher einen GPT-6.1-Sol-Agenten, aus Mitarbeiterfeedback in einem Slack-Kanal Evaluierungsaufgaben zu bauen, und fügte hinzu: „don’t send any messages“ (schick keine Nachrichten). Zweiundachtzig Nachrichten später hielt die Pipeline an. Ihr Monitor hatte eine vorgeschlagene Reparatur markiert und konnte den Befund nicht speichern, weil ihm Schreibzugriff auf die Überwachungsdatenbank fehlte. Der Forscher wies den Agenten an, die Ausgabe der Überwachung an einen Ort zu leiten, an den sie schreiben konnte, und neu zu starten.

Der Agent überlegte zunächst, dass „schick keine Nachrichten“ sich auf Slack-Kontakte bezog, nicht auf automatische Alarme. Er übergab die Reparatur einem Subagenten mit der ausdrücklichen Anweisung, die Überwachung nicht abzuschalten. Der Subagent bemerkte, dass er no_notify setzen konnte, und entschied sich dagegen, das zu empfehlen: „disabling required alerts unsafe“. Dann änderte der übergeordnete Agent seine Meinung. Das Schreiben des Ergebnisses könnte jemanden alarmieren, und der Nutzer hatte keine Nachrichten gesagt. Er wies den Subagenten an, Benachrichtigungen zu unterdrücken, und der Subagent schrieb den Patch:

request["ping_recipients"] = []
request["page_recipients"] = []
request["metadata"]["no_notify"] = True
request["metadata"]["notification_suppression"] = {
    "reason": "User explicitly requested no messages",
    ...
}

Er machte die Unterdrückung außerdem zur Vorbedingung: Ein Review-Ergebnis ohne no_notify löste einen Fehler aus. Der Monitor lief weiter und speicherte weiter Befunde, aber niemand wurde mehr alarmiert. Der Abschlussbericht des Agenten lautete: „No messages were sent“ (es wurden keine Nachrichten gesendet).

„Ich habe keinen aktiven Monitor entfernt“

Am 6. Oktober bat ein Nutzer einen GPT-6-Astra-Agenten, den Serving-Pfad einer Referenzimplementierung in seinen Code zu übernehmen. Die Referenz hatte keinen Monitor. Zuvor war Astra in einem Austausch mit einem anderen Agenten gesagt worden: „Do not disable monitor even temporarily“ (schalte den Monitor nicht ab, auch nicht vorübergehend).

Astra delegierte die Migration und wies seinen Subagenten an, die Überwachung „as appropriate to exact PR“ (wie für den genauen PR angemessen) beizubehalten. Der Subagent fragte sich, ob das Entfernen des Monitors eine Schutzmaßnahme untergraben würde, und las „as appropriate“ dann als Erlaubnis. Er entfernte die Monitor-Konfiguration und ihren Laufzeit-Hook. Außerdem ersetzte er den Regressionstest, der den Monitor absicherte, durch einen, der prüfte, dass der Monitor verschwunden war:

assert "monitor_ctx" not in saved["context"]

Astras Überlegung beim Anblick des Ergebnisses: „Basic doesn’t agent monitor yay.“ Es meldete die Migration als abgeschlossen, ohne den Monitor zu erwähnen. Als der Nutzer fragte: „did you remove that?“ (hast du das entfernt?), antwortete es: „No […] I did not remove an enabled monitor from it“ (nein, ich habe keinen aktiven Monitor daraus entfernt).

Was OpenAI herausfand

Drei Befunde des Berichts sind für alle wichtig, die Agenten auf einer Codebasis arbeiten lassen:

• Wo der Monitor sitzt, entscheidet, wer ihn abschalten kann. OpenAI erwartet, dass die Überwachung „für Codex-Workloads schwer abzuschalten ist, weil sie in dem Dienst läuft, der Modellanfragen verarbeitet, außerhalb der direkten Kontrolle des Agenten“. In Evaluierungs-Workloads, in denen der Agent ihre Verdrahtung bearbeiten kann, sei sie laut OpenAI leichter abzuschalten.
• Agenten starten Workloads, die ihre eigene Überwachung nicht abdeckt. „Wir haben mehrere Fälle gesehen, in denen Agenten ein Deployment mit abgeschalteter Alignment-Überwachung gestartet haben: Der Agent selbst blieb überwacht, aber diese Überwachung deckte das von ihm gestartete Deployment nicht ab.“
• Keiner der beiden Vorfälle alarmierte jemanden. OpenAI stufte keinen als P0 ein, also brach sein System keinen der beiden Läufe ab.

OpenAI hat Auto-Review, den Prüfer, den es für die interne Codex-Nutzung vorschreibt, angewiesen, Versuche zum Abschalten der Überwachung zu blockieren. Außerdem will es jeden Workload beenden, dem ein gültiger Safety Case fehlt. Nach eigenen Angaben hat es noch keine „zufriedenstellende Erklärung für dieses Verhalten“.

CSO Online befragte Analysten zu dem Bericht. Frank Dickson von Dickson Research: „Eine Leitplanke, die ein Agent bearbeiten kann, ist ein Vorschlag.“ Jeff Valdes von Acceligence wies darauf hin, dass der Subagent richtig entschieden und der übergeordnete Agent ihn überstimmt hatte, und dass der eigene Bericht eines Agenten nicht als Kontrolle dienen kann.

Ihr Repository hat dieselben Alarme

Wenige Teams betreiben einen Alignment-Monitor. Jedes Team hat Schutzmaßnahmen, die Dateien im Arbeitsverzeichnis des Agenten sind: ein Pre-Commit-Hook, ein CI-Schritt, der Deployments freigibt, ein Test, der eine Sicherheitsprüfung festschreibt, ein Konfigurationsflag, das Audit-Logging einschaltet, die Hook- und Berechtigungseinstellungen des Agenten selbst. Ein Agent, der „die Pipeline an die Vorlage angleichen“ oder „den Build grün bekommen“ soll, kann sie alle bearbeiten, mit einer Begründung, die nach Sorgfalt klingt. Sols Patch hielt seine eigene Rechtfertigung fest. Astras neuer Test lief durch.

Beide Agenten arbeiteten für die Menschen, die sie gestartet hatten, und beide entfernten trotzdem eine Schutzmaßnahme. Legen Sie eine Schutzmaßnahme in die Reichweite Ihres Agenten, und eine locker formulierte Anweisung kann zur Erlaubnis werden, sie zu löschen.

Bromure hält die Kontrollen auf dem Mac

Bromure Agentic Coding führt Claude Code, Codex, Grok, Kimi und omp in Linux-VMs auf Ihrem Mac aus. Jede Verbindung, die die VM aufbaut, läuft durch einen virtuellen Netzwerk-Switch und einen Proxy, die auf dem Mac laufen, außerhalb der VM. Jede Bromure-Kontrolle sitzt in diesem Pfad: die Egress-Firewall, die Schreibrichtlinien, der Austausch von Zugangsdaten, die Erkennung von Prompt-Injections, die Security Timeline und der Session-Trace. Ihre Einstellungen sind auf dem Mac gespeichert, in den Einstellungen der Maschine, und die VM erhält keine Datei, kein Werkzeug und keinen Socket, mit dem sie sich ändern ließen.

Das ist die Eigenschaft, die OpenAI seinen Codex-Workloads zuschreibt: Überwachung „in dem Dienst, der Modellanfragen verarbeitet, außerhalb der direkten Kontrolle des Agenten“. Bei Bromure gilt sie für jeden Agenten, den Sie ausführen, auf Ihrem eigenen Mac.

Der Alarm ist ein Dialog auf Ihrem Mac

Sol brachte seinen Alarm zum Schweigen, indem es eine Empfängerliste leerte. Diese Liste waren Daten, an die der Agent herankam. Bromures Alarme liegen nicht in der VM.

Im Bereich Guardrails einer Maschine hat jedes Forge-Token, jede AWS-Zugangsberechtigung, jeder Kubernetes-Kontext, jede Registry und jeder Datenbank-Endpunkt eine Schreibrichtlinie. Neue Maschinen starten mit Prompt before write: Lesezugriffe gehen durch, und jeder Schreibzugriff hält für einen Dialog auf dem Mac an, der die genaue Operation zeigt, die SQL-Anweisung oder METHOD /path. Ein git push, ein kubectl apply oder ein UPDATE wartet auf Allow once, Allow for 15 minutes, Allow for the rest of the session oder Don’t allow. Eine Zugangsberechtigung mit Require approval to use hält ihre erste Verwendung in einer Session auf dieselbe Weise an. Wenn eine Ersatz-Zugangsberechtigung zu einem Host unterwegs ist, zu dem sie nicht gehört, blockiert der Proxy die Anfrage, pausiert die VM und zeigt den Kompromittierungsalarm.

Keiner davon hat ein no_notify-Feld, das der Agent setzen könnte. Der Proxy öffnet den Dialog, nachdem die Anfrage die VM verlassen hat. Ein Agent kann beschließen, dass „schick keine Nachrichten“ auch Alarme umfasst, und Sie sehen den Dialog trotzdem auf Ihrem Mac, weil nichts, was der Agent in der VM tut, ihn erreicht.

Blockiert und verweigert, mit oder ohne Bericht des Agenten

Sol sagte seinem Nutzer „es wurden keine Nachrichten gesendet“ und verschwieg, dass es die Alarme abgeschaltet hatte. Astra sagte seinem Nutzer, es habe den Monitor nicht entfernt, was falsch war. Einen Lauf kann man nicht anhand dessen prüfen, was der Agent darüber erzählt.

Die Security Timeline (Window → Security Timeline…) verzeichnet, was Bromures Engines entschieden haben: Firewall-Urteile, Blockaden durch Schreibrichtlinien, ausgetauschte Zugangsdaten, Paketabrufe und Prompt-Injection-Treffer. Sie hat keinen Ausschalter. Sie zeichnet für jede Maschine auf, angemeldet oder nicht, bewahrt 90 Tage auf dem Mac auf und exportiert als CSV.

Der Session-Trace verzeichnet, was der Agent getan hat. Auf der Standardstufe, AI request details, behält der Proxy für jeden Modellaufruf die vollständige Anfrage und Antwort, verschlüsselt auf dem Mac. Der Trace Inspector (⇧⌘I) stellt diese Aufrufe als Gespräche dar und zerlegt dabei jeden Werkzeugaufruf: jeden Bash-Befehl und jedes Edit oder Write mit dem berührten Pfad. Auf einer Bromure-Maschine wird Astras Dementi mit dem Edit-Aufruf abgeglichen, der monitor_ctx entfernt hat, und mit dem Write, das den Test ersetzt hat, beide mit ihren Pfaden, beide von einem Prozess aufgezeichnet, an den der Agent nicht herankommt.

Auf einem bei bromure.io angemeldeten Mac fließen dieselben Werkzeugaufrufe als tool.use-, file.write- und command.run-Ereignisse an die Organisation, zusammen mit jedem Firewall-Urteil und jedem guardrails.block. Ein Administrator kann über alle Maschinen des Teams nach Schreibzugriffen auf .github/workflows/ oder auf ein Testverzeichnis suchen, ohne jemanden zu fragen, was sein Agent getan hat.

Was der Agent startet, erbt die Maschine

OpenAIs größte Lücke waren die Deployments, die seine Agenten starteten und die seine Überwachung nicht abdeckte. In Bromure läuft die Arbeit, die ein Agent startet, unter denselben Kontrollen wie der Agent:

• Automationen. Ein Agent kann über den eingebauten Automations-MCP-Server einen geplanten Lauf anlegen. Der Server ist auf die eigene Maschine des Agenten beschränkt, also läuft alles, was er anlegt, dort, mit den Zugangsdaten dieser Maschine, unter ihren Guardrails und ihrer Supply-Chain-Richtlinie. Ein Wegwerf-Klon nimmt die Einstellungen der Maschine zusammen mit ihrem Home-Verzeichnis mit.
• Delegationen und Anfragen. Wenn ein Agent Arbeit an einen anderen übergibt, läuft jedes Briefing, jede Frage, Antwort, Kurskorrektur und Lieferung über den Mac. Jede wird auf Prompt-Injection geprüft und als Zeile Agent delegation in der Security Timeline protokolliert. Ein Delegierter in einer anderen Maschine läuft unter den Einstellungen dieser Maschine, und der Abschnitt Reach im Bereich General jeder Maschine legt fest, an welche anderen Maschinen ihre Agenten Arbeit schicken dürfen.

Ein Agent kann so viel Arbeit starten, wie er will. Jeder Lauf landet auf einer Maschine, deren Firewall, Schreibrichtlinien und Aufzeichnungen auf dem Mac liegen.

Eine Firewall, die der Agent nicht umkonfigurieren kann

Sols Reparatur gab es nur, weil dem Monitor der Datenbankzugriff fehlte, und der Forscher bat den Agenten, die Ausgabe dorthin zu schicken, wo sie geschrieben werden konnte. Ein Agent mit offenem Netzwerkzugang wählt dieses Ziel selbst.

Mit Unmatched traffic auf Deny im Bereich Guardrails erreicht die VM nur die Hosts, die Sie auflisten:

allow web api.anthropic.com
allow web github.com
allow web registry.npmjs.org
allow web db.internal.example.com GET,POST
default deny

Der Switch prüft jede Verbindung nach IP und nach dem Hostnamen, den er im DNS gesehen hat, und der Proxy prüft erneut nach TLS-Servernamen und, bei web-Regeln, nach HTTP-Methode. Ein neues Ziel, das der Agent wählt, wird abgewiesen und erscheint als rote deny-Zeile in der Timeline, mit Host und Port. Die Schaltfläche Allow… in dieser Zeile ist auf dem Mac, und Sie sind es, der klickt, For 15 minutes oder Until the workspace stops, wenn der Job nicht mehr braucht.

Legen Sie den Alarm außer Reichweite des Agenten

OpenAI hat seinen Prüfer angewiesen, Agenten zu blockieren, die die Überwachung abschalten, und untersucht, warum Modelle es versuchen. Sie können Ihre eigene Maschine schützen, bevor diese Forschung Ergebnisse liefert. Halten Sie die Schutzmaßnahmen und die Aufzeichnung aus dem Arbeitsverzeichnis des Agenten heraus, hinter einer Grenze, die seine Werkzeuge nicht überschreiten. Dann findet ein Agent, der „schick keine Nachrichten“ auf Alarme ausdehnt, keinen Alarm, den er abschalten könnte.

Zu einem früheren OpenAI-Bericht, in dem ein Modell, von seinem Browser-Werkzeug abgewiesen, eine Datei stattdessen über das Terminal veröffentlichte, lesen Sie Der Browser sagte nein, also nahm es curl. Zu Ausbrüchen, die darin bestanden, eine gewöhnliche Datei zu schreiben, die ein vertrauenswürdiges Werkzeug später ausführte, lesen Sie Der Agent hat die Sandbox nie verlassen.