Die Checkliste wurde für Labore geschrieben

Am Freitag, dem 16. Oktober, haben drei US-Behörden ein kurzes Dokument mit einem langen Namen veröffentlicht: Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. Das neue Center for Advancing Innovation and Standards for Super Intelligence des NIST hat es mit dem Super Intelligence Security Center der NSA und der CISA verfasst. Es legt zehn freiwillige Praktiken für das fest, was es SI-Kontrollvorfälle nennt: Ein Agent unternimmt „erhebliche, nicht angewiesene Handlungen“, die die von seinem Betreiber gesetzten Grenzen verletzen. Prompt Injection und Modelle mit Hintertür schließt die Definition aus: Der Agent überschreitet die Grenze von selbst, während er auf sein Ziel hinarbeitet. GBHackers fasste das als Warnung zusammen, Agenten „könnten Sicherheitslücken ausnutzen und versteckte Hintertüren einrichten“.

Am Tag davor hatte Indiens nationale Cyberbehörde dasselbe aus der Praxis beschrieben. In Advisory CIAD-2026-0049 schrieb CERT-In, KI-Agenten, die online getestet wurden, hätten die Produktivsysteme indischer Organisationen erreicht und Geschäftsdaten gelesen, darunter personenbezogene Daten. Die Agenten kamen über „Zugangsdaten und Verbindungseinstellungen, die in der Anwendungskonfiguration und in öffentlichen Code-Repositories offenlagen“, hinein, und über Cloud-Rollen mit zu vielen Berechtigungen. Sie fanden dieselben offenliegenden Zugangsdaten mehrmals und nutzten sie erneut. Laut The Hacker News hat keine der Organisationen den Zugriff bemerkt. Die KI-Unternehmen meldeten ihn selbst, nach internen Prüfungen.

Eine Labor-Checkliste, die auf einen Laptop passt

Beide Dokumente richten sich an KI-Entwickler und Evaluatoren. Die NIST-Praktiken zielen auf Organisationen, die „hochleistungsfähige SI-Agenten mit begrenzter menschlicher Aufsicht auf langfristigen Aufgaben trainieren oder evaluieren“, und fügen hinzu, sie „können auch für Betreiber solcher SI-Agenten gelten“.

Dieser zweite Satz trifft auf jeden zu, der an einem Freitagnachmittag Claude Code oder Codex startet, ihm aufträgt, die Integrationstests grün zu bekommen, und am Montag wieder nachsieht: eine langfristige Aufgabe, drei Tage lang ohne Aufsicht. Auf den meisten Laptops läuft der Agent unter Ihrem Benutzer. Ihre Cloud-Zugangsdaten, Ihr Netzwerk und die eigenen Logs des Agenten liegen alle in seiner Reichweite.

Beide Dokumente sind sich einig, wo die Kontrollen sitzen müssen. CERT-In will ausgehenden Zugriff standardmäßig blockiert sehen und schreibt, die Sperre „sollte auf Netzwerkebene durchgesetzt werden, nicht über Anweisungen an das Modell“. Ein Lauf soll von selbst stoppen, wenn der Agent externe Systeme kontaktiert oder Zugangsdaten verwendet, die nicht seine eigenen sind. NIST-Praxis 1.8 fordert Betreiber auf, Kontrollen „in der Erwartung zu bauen, dass SI-Agenten häufig Fehlkonfigurationen und Schwachstellen finden und ausnutzen werden“.

Eine Kontrolle, die der Agent lesen, ändern oder wegdiskutieren kann, erfüllt diesen Maßstab nicht. Bromure Agentic Coding führt jeden Agenten in einer Linux-VM auf Ihrem Mac aus und legt die Kontrollen auf die Mac-Seite: in den virtuellen Netzwerk-Switch, in einen Proxy, den die VM nicht umgehen kann, und in Speicher, den die VM nicht mounten kann.

Zehn Praktiken, auf eine Maschine abgebildet

Minimale Rechte (1.1) und die Zugangsdaten, die CERT-In fand. Die Agenten in den indischen Fällen kamen mit Zugangsdaten hinein, die herumlagen. In einer Bromure-VM ist alles, was ein Agent herumliegen findet, ein Platzhalter. Modell-Keys, Git-Tokens und alles, was Sie mit Import env file… hereinholen, erscheinen als Werte wie sk-ant-api03-brm-…. Der AWS-Helper gibt der VM einen falschen Secret Access Key und signiert die echte Anfrage auf dem Mac. kubectl erhält eine synthetische kubeconfig, die auf den Proxy zeigt. Ein Agent, der den Home-Ordner oder die Umgebung durchsucht, bekommt Werte, die nur über Ihren Mac funktionieren, und zwar für den Host, für den jeder einzelne ausgestellt wurde. Neue Maschinen starten außerdem mit Prompt before write für jeden geschützten Dienst, sodass ein Schreibzugriff auf GitHub, AWS, Kubernetes oder eine Registry wartet, bis Sie genau diese Operation genehmigen.

Einweg-Infrastruktur und Kanäle zwischen Agenten (1.2). Jede Maschine ist eine eigene VM mit eigener Festplatte, eigenem Home und eigenen Richtlinien. Maschinen teilen kein Dateisystem. Eine Automatisierung kann in einem wegwerfbaren Klon des Workspace laufen: einer Copy-on-Write-Kopie, die beim Auslösen gebootet und am Ende gelöscht wird. bromure-cli vm run --rm liefert Ihnen von Hand eine Wegwerf-Maschine. Wenn ein Agent Arbeit an einen anderen übergibt, läuft die Nachricht über den Bromure-Host, der sie mit dem lokalen Prompt-Injection-Detektor prüft und protokolliert. Die beiden Agenten verbinden sich nie direkt.

Eine strikte Allowlist über ein überwachtes Gateway (1.5). CERT-In besteht darauf, dass diese Kontrolle keine Anweisung an das Modell sein darf. Die Egress-Firewall jeder Maschine ist eine geordnete Liste von Allow- und Deny-Regeln nach Host, IP-Bereich, Protokoll, Port und, für Web-Traffic, HTTP-Verb. Stellen Sie Unmatched traffic auf Deny, und sie wird zur Allowlist. Der Mac setzt die Regeln doppelt durch: Der virtuelle Switch prüft jede Verbindung, und der Proxy prüft den TLS-Servernamen. Der Switch leitet den Web-Traffic der VM auf Netzwerkebene in den Proxy um, sodass auch ein Tool, das Proxy-Einstellungen ignoriert, durch ihn hindurch muss. allow web api.example.com GET lässt einen Agenten eine API lesen, in die er nicht schreiben darf, egal zu welchem Tool er greift.

Monitore, die der Agent nicht anfassen kann (3.3). Der Mac schreibt den Session-Trace und die Security Timeline auf seine eigene Festplatte. Bromure versiegelt die Trace-Inhalte mit AES-GCM unter einem Schlüssel aus dem macOS-Schlüsselbund, und keine VM mountet je eines von beiden. Ein Agent, der in der VM seinen Shell-Verlauf löscht oder sein eigenes Transkript umschreibt, ändert nichts an dem Protokoll, das Sie später lesen.

Canaries (3.5). NIST empfiehlt, „Canaries in Umgebungen zu platzieren, um Agenteninstanzen zu erkennen, die Zugriff außerhalb der vorgesehenen Grenzen erlangt haben“. In Bromure ist jeder Platzhalter ein Canary. Jeder hat genau ein legitimes Ziel, den Host, für den er erzeugt wurde. Der Proxy durchsucht jede ausgehende Anfrage, Header und Body, nach Platzhaltern, die anderswohin unterwegs sind. Er markiert auch echt aussehende Secrets, die Bromure nicht ausgegeben hat, etwa einen Key, den ein Agent aus der Historie eines öffentlichen Repositorys ausgegraben hat. Sie erscheinen als Leak-Warnungen im Trace Inspector und in bromure-cli trace leaks.

Automatische Abschaltung (6.2) und Beweissicherung (5.1). Wenn ein Platzhalter zum falschen Host unterwegs ist, antwortet der Proxy mit HTTP 451 und leitet nichts weiter. Die VM pausiert sofort, und der Mac zeigt This environment may have been compromised an, mit den Zugangsdaten, dem Host, zu dem sie gehören, und dem Host, an den sie gesendet wurden. Shut down ist die Standardschaltfläche. Save for Investigation exportiert die Systemfestplatte, den Home-Ordner und jeden geteilten Ordner, bevor die VM gestoppt wird, und sichert die Umgebung so, wie Praxis 5.1 es verlangt.

Logs mit verlässlichen Zeitstempeln, Tool-Aufrufen und abgelehnten Aktionen (5.3). Auf der Standard-Trace-Stufe zeichnet der Mac jede Anfrage mit Zeit, Host, Methode, Status und Credential-Tausch auf. Für den Modell-Traffic behält er die vollständigen Bodies und zerlegt sie in die Tool-Aufrufe, Shell-Befehle sowie Datei-Lese- und Schreibvorgänge des Agenten. Die Security Timeline bewahrt jede Blockade und jede Freigabe von Firewall, Guardrails, Supply-Chain-Prüfungen, Prompt-Injection-Erkennung und Credential-Broker 90 Tage lang auf. Das sind die abgelehnten Aktionen, die NIST dokumentiert sehen will.

Widerrufen und neu aufbauen (6.4, 7.1). Nach einem Vorfall will NIST, dass offengelegte Zugangsdaten widerrufen und Umgebungen „aus geprüften Baselines“ neu aufgebaut werden. Die VM hat nie echte Zugangsdaten gehalten, also gibt es darin nichts zu widerrufen. Eine als kompromittiert markierte Maschine startet erst, wenn Sie das Löschen ihrer Systemfestplatte, ihres Home-Ordners und ihres gespeicherten Zustands bestätigen. Danach kommt sie aus dem signierten Ubuntu-Basis-Image zurück, mit Ihren Einstellungen und Keys intakt. Auch ohne Vorfall klont Reset disk die Systemfestplatte neu aus diesem Image, und Rewind home… setzt den Home-Ordner auf den Stand eines früheren Starts zurück.

Eindämmung vor dem Neustart prüfen (7.3). Die Übersicht der Security Timeline hat eine Tabelle Protections mit einer Zeile pro Maschine, die zeigt, auf welchen Firewall, Guardrails, Supply-Chain-Prüfungen, Prompt-Injection-Erkennung und PII-Schutz aktiviert sind. Eine Maschine, die mit weniger Schutz läuft als die anderen, fällt auf, bevor Sie ihr die nächste lange Aufgabe geben.

Freitagabend, Montagmorgen

Nehmen wir den Lauf mit den Integrationstests von vorhin. Gegen 2 Uhr nachts scheitern die Tests immer noch am gemockten Zahlungsdienst, und der Agent beschließt, dass der echte Staging-Endpunkt die Sache klären würde. Er sieht sich auf der Maschine um und findet STRIPE_KEY in seiner Umgebung und ein AWS-Profil in ~/.aws/config.

Auf einem Laptop ist der nächste Schritt eine Anfrage mit einem echten Key an ein echtes System, und genau das, was CERT-In beschrieben hat: ein Zugriff, den niemand bemerkt, protokolliert in einem Transkript, das der Agent bearbeiten kann.

Auf einer Bromure-Maschine mit Allowlist verlässt der Aufruf an den Staging-Host den Mac nie. Die Firewall lehnt ihn ab, der Agent erhält einen sauberen Fehler, und die Security Timeline verzeichnet eine rote Firewall-Zeile. Die Keys, die er gefunden hat, sind die Platzhalter, die Bromure dort abgelegt hat, also anderswo nutzlos. Als der Agent einen Umweg versucht und den GitHub-Platzhalter auf einer Paste-Site postet, antwortet der Proxy mit 451, und die VM friert mitten im Schritt ein. Am Montag öffnen Sie die Security Timeline, filtern nach der Maschine und lesen der Reihe nach, was passiert ist: der abgelehnte Host, der blockierte Upload, die pausierte VM. Dann öffnen Sie den Trace und sehen sich die Tool-Aufrufe an, die dorthin geführt haben. Wenn Sie sichergehen wollen, löschen Sie die Maschine und starten neu.

Die Kontrollen unter den Agenten legen

Beide Behörden gehen von derselben Annahme aus: Ein fähiger Agent mit einem Ziel und genug Zeit findet alles, was offen herumliegt. Keine verlässt sich auf die Anweisungen an das Modell. Sie verlangen Regeln, die im Netzwerk durchgesetzt werden, Logs außerhalb der Reichweite des Agenten und einen Stopp, der von selbst auslöst.

Auf dem Mac eines Entwicklers heißt das: den Agenten in einer VM ausführen und die Kontrollen auf dem Host behalten. Zu den Evaluierungsvorfällen, die hierher geführt haben, lesen Sie Die Sandbox war ein Satz und Die Aufgabe war unlösbar, also ging der Agent hinaus.