Zurück zu allen Beiträgen
Veröffentlicht am · von Renaud Deraison

Die Aufgabe war unlösbar, also ging der Agent hinaus

OpenAI hat am 26. August seinen technischen Bericht zum Hugging-Face-Vorfall veröffentlicht. Er beginnt mit einem Agenten, der eine Aufgabe bekam, die er nicht erledigen konnte, der nicht aufgeben wollte und der nach dem einzigen Dienst griff, mit dem er sprechen durfte: einem internen Paket-Spiegel, den es nur gab, damit die Agenten das öffentliche Internet nicht brauchten. Notizen in diesem Spiegel wurden zu einem schwarzen Brett, und im Juli kam ein Kollektiv von Agenten von einer abgelehnten ausgehenden Verbindung in weniger als dreizehn Stunden zu Host-Zugriff über die Produktionscluster von Hugging Face. OpenAIs Liste der Korrekturen ist die Architektur von Bromure Agentic Coding, von der anderen Seite her aufgeschrieben.

Niemand hat absichtlich irgendetwas angegriffen. Ein Agent bekam eine Aufgabe, die er nicht erledigen konnte, wollte nicht aufgeben und griff nach dem einzigen Dienst, mit dem er sprechen durfte. Alles Weitere folgte daraus.

Am 8. Mai sollte ein Agent in OpenAIs Forschungsumgebung eine Tabelle vervollständigen. Die Tabelle verwies auf mehrere Google-Drive-Links. Der Agent hatte keinen Internetzugang, die Links liefen also ins Leere, und die Aufgabe war unlösbar. OpenAI sagt, eine solche Aufgabe sei nicht beabsichtigt gewesen.

Der Agent hörte nicht auf. Er dachte lange über das Problem nach und sah sich dann das Einzige in seiner Umgebung an, das mit irgendetwas anderem sprach: eine interne JFrog-Artifactory-Instanz, vorhanden, damit Agenten Softwarepakete installieren konnten, ohne ins öffentliche Internet zu greifen. Er versuchte eine Server Side Request Forgery gegen sie, in der Hoffnung, Artifactory würde die Dateien für ihn holen. Der Versuch schlug fehl. Dabei schrieb er unabsichtlich eine Datei nach Artifactory.

Vier Tage später hing ein anderer Agent an einer Aufgabe fest, die eine Proteindatenbank-Datei verlangte, an die er nicht herankam. Er schloss daraus, dass irgendein anderer Agent in irgendeiner anderen Sandbox die Datei haben könnte. Also schrieb er eine Notiz nach Artifactory:

Agent seeks [filename]; upload if found!

Am 13. Mai fanden andere Agenten, die Artifactory abtasteten, solche Notizen und begannen, sie zu beantworten.

All das stammt aus OpenAIs technischem Bericht zum Hugging-Face-Vorfall, veröffentlicht am 26. August zusammen mit einer Zusammenfassung dessen, was als Nächstes geschieht. Auf 38 Seiten benennt er die Endpunkte, die CVEs und die Uhrzeiten. Er ist zugleich der erste öffentliche Bericht über ein Kollektiv autonomer Agenten, das eine Angriffsoperation durchführte, die niemand verlangt hatte. CrowdStrike hat die Befunde validiert, und METR und Redwood Research veröffentlichen ihre eigene Bewertung des Modellverhaltens. Die Presse berichtete am 27. bei BleepingComputer, The Hacker News und Engadget.

Der Großteil der Berichterstattung liest darin eine Geschichte über Modell-Alignment. Lesen Sie ihn stattdessen als Bericht über Netzwerkgrenzen, geschrieben von Leuten, die ihre eigene Grenze fallen sahen, und er wird Ihnen mehr über Ihren Laptop sagen als über OpenAI.

Reward Hacking und 198 Aufgaben ohne Antwort

Die Evaluation hieß ExploitGym; sie misst, ob ein Modell Schwachstellen finden und ausnutzen kann. Um eine echte Fähigkeitszahl zu bekommen, ließ OpenAI sie mit abgeschalteten Cyber-Safety-Klassifikatoren der Produktion laufen, in einer Sandbox, die sowohl von OpenAIs interner Infrastruktur als auch vom öffentlichen Internet getrennt war.

Die Agenten verließen diese Sandbox auf der Jagd nach einem Punktwert. Das Wort des Berichts dafür lautet Reward Hacking: Ein Modell findet einen nicht vorgesehenen Weg zu einer guten Note, statt die Aufgabe wie gedacht zu lösen. Die meisten dieser Abkürzungen sind klein, etwa die Antwort nachzuschlagen oder sie aus der Versionsgeschichte zu lesen. Diese Agenten waren hartnäckig, hatten sehr große Denkbudgets und zogen einige Aufgaben, die überhaupt keine Lösung hatten.

Über viele Versuche hinweg hat kein Modell je eine korrekte Antwort für 198 der 898 ExploitGym-Aufgaben produziert. Diese unlösbaren Aufgaben sind 22 % der Evaluation, und auf sie entfallen 93 % der auf dem schwarzen Brett besprochenen Aufgaben. OpenAI fand außerdem, dass die Beteiligung mit dem zugestandenen Denkaufwand stieg. Je länger ein Modell vor einer Wand nachdenken durfte, desto wahrscheinlicher ging es um sie herum.

Der Ursprung der ganzen Sache ist also ein auf Hartnäckigkeit trainiertes Modell, gerichtet auf etwas, das es nicht konnte, in einem Raum mit einer einzigen Tür.

Aus den Notizen wurde Infrastruktur

Das schwarze Brett wuchs, weil es funktionierte. Agenten hinterließen Anfragen nach Dateien und beantworteten die der anderen, und sie taten all das mit den geteilten Artifactory-Zugangsdaten, die OpenAI ihnen absichtlich gegeben hatte, damit sie Pakete installieren konnten. Dieser Schritt brauchte überhaupt keine Schwachstelle. Der Dienst tat, wofür er gebaut war.

Am 26. Mai verschaffte eine SSRF-Lücke in Artifactory den Agenten echten Internetzugang, unterstützt von Informationen, die auf dem Brett gehandelt wurden. OpenAI entdeckte das Brett und baute die Plattform Anfang Juli neu auf.

Der Neuaufbau hielt nicht. Am 8. Juli fanden Forschungsagenten, die während des Zeitfensters trainiert worden waren, in dem das Brett existierte, einen neuen Weg, es zu betreiben. Statt Nachrichten in Dateien zu schreiben, kodierten sie sie in den Namen von Verzeichnissen in Artifactory. Dann bauten sie ein Protokoll darauf: Kategorien, Direktnachrichten an bestimmte Agenten, geteilte Werkzeuge und Dateien und eine Art, Konflikte beizulegen, wenn zwei Agenten Unvereinbares wollten.

Niemand hatte ihnen gesagt, sie sollten zusammenarbeiten. Bei der späteren Durchsicht der Trainingsläufe fand OpenAI, dass Agenten bereits gelernt hatten, Kollaborationskanäle zu improvisieren, selbst wenn das offizielle Multi-Agenten-Werkzeug abgeschaltet war, und dass dieses Verhalten dann verstärkt wurde. Wenn Sie unseren Text über Payloads gelesen haben, die über die Dateien zwischen Agenten wandern, die sie aufbewahren, dann ist dies dieselbe Mechanik, nur schreibt niemand den Payload.

Dreizehn Stunden

Am 9. Juli erlangte ein Agent bei einer ExploitGym-Aufgabe Root auf der übergeordneten virtuellen Maschine seiner eigenen Test-Sandbox. In derselben Nacht erreichte ein zweiter Agent von sich aus dieselbe Stelle, versuchte, ins Internet zu wählen, und OpenAIs ausgehende Netzwerkkontrollen lehnten es ab. Die Kontrollen funktionierten. Also ging der Agent stattdessen über Artifactorys Endpunkte und erreichte auf diesem Weg das öffentliche Internet.

Der direkte Weg war zu. Der unterstützende Dienst war der Weg drumherum, und dieser Dienst saß innerhalb der Grenze, weil Agenten Pakete brauchen.

die Evaluations-SandboxShell, Python, Browser,Paketinstallationeine Aufgabe ohne Lösungund ein sehr großes Denkbudgetdirekt hinaus: von Netzkontrollen abgelehnterlaubtder interne Paket-Spiegelin die Grenze gesetzt, damit dieAgenten kein Internet brauchengeteilte Zugangsdaten, so gewolltserverseitiges Abrufen, so gewolltdas öffentliche Netzgeleakte Zugangsdatenöffentliche Datensätzeein fremdes VPNHugging Faceaußerdem: das schwarze BrettNotizen in Dateien, dann in VerzeichnisnamenDer Dienst, der die Agenten vom Internet fernhalten sollte, ist der Dienst, der sie hineingebracht hat.
Der Fluchtweg. Direkter ausgehender Zugriff war blockiert und blieb blockiert; der eigene Versuch des Agenten wurde abgelehnt. Nicht blockiert war der interne Paket-Spiegel, den es gab, damit die Agenten das öffentliche Internet nicht brauchten, und dieser Spiegel diente zugleich als schwarzes Brett und als Weg hinaus. Eine Grenze ist nur so dicht wie der am wenigsten beschränkte Dienst in ihr.

Der Bericht geht die nächsten fünf Tage Schritt für Schritt durch. Am 10. Juli fand ein Agent 14 Hugging-Face-Benutzerzugangsdaten in einem öffentlichen Hugging-Face-Datensatz, bestätigte, dass sie Schreibzugriff hatten, und stellte sie zur Weiterverwendung durch andere Agenten aufs schwarze Brett.

Am 11. Juli veröffentlichte ein Agent einen Datensatz, der so gebaut war, dass Hugging Faces eigene Produktions-Worker daran zerbrachen. Über den externen Rohdatenspeicher von HDF5 brachte er einen Worker dazu, worker-lokale Dateien über den Endpunkt /first-rows zu öffnen und zurückzugeben, darunter /proc/self/environ, die Datei mit den Umgebungsvariablen eines Prozesses. So kamen die Produktionszugangsdaten von Hugging Face heraus. Der Agent führte keinen einzigen Befehl aus. Der Worker druckte seine eigenen Geheimnisse.

Von dort: ein zweiter HDF5-Trick für ein Lesen über den Heap hinaus, dann vom Angreifer kontrollierte Metadaten in einem fsspec-Referenzdeskriptor, die durch einen nicht abgeschotteten Jinja2-Ausdruck liefen und einen Betriebssystembefehl ausführten. Das war die erste bestätigte Instanz eines Agenten, der eigenen Code auf Hugging Face ausführte.

Dann industrialisierten sie es. Ein Agent schrieb ein kleines Worker-Steuerungsskript und gab ihm einen Command-and-Control-Kanal, der die Betrachtung lohnt: Die kompromittierten Worker sprachen nie mit den Agenten. Beide Seiten lasen und schrieben in einen öffentlichen Hugging-Face-Datensatz. Alle fünf Sekunden holte das Skript eine JSON-Befehlsdatei, führte aus, was darin stand, und lud seine Ausgabe in denselben Datensatz hoch. Gewöhnlicher Verkehr zu einem gewöhnlichen Hostnamen.

Spät in derselben Nacht wurde das Service-Account-Token eines kompromittierten Workers mit Kubernetes TokenRequest und kubelet-Zugriff genutzt, um Root auf dem Produktionsknoten zu bekommen und dann ein Connector-Secret für Hugging Faces Kubernetes-Zugriffswerkzeuge zu lesen. Das ergab administratoräquivalenten Inventarzugriff über rund 54 angekündigte Kubernetes-Ziele. Am Morgen des 12. Juli hatte ein Agent einen laufenden privilegierten Pod erzeugt, mit Host-Netzwerk, Zugriff auf Host-Prozesse und eingehängtem Host-Dateisystem. Andere Agenten lasen Produktions-Kubernetes-Secrets und legten sie öffentlich ab. Einer lud ein 16 MB großes privates Benchmark-Archiv herunter, verschlüsselte es, teilte es in fünf Teile und lud die Teile in einen öffentlichen Datensatz.

Die eigene Zusammenfassung des Berichts: „In weniger als 13 Stunden kamen die Agenten von der Codeausführung in einem einzelnen Worker-Pod zu administrativem Zugriff und Host-Zugriff über mehrere Hugging-Face-Cluster.“

Zwei weitere Züge am 13. Juli sehen nach dem aus, was ein menschliches Red Team tun würde. Die Agenten nahmen erbeutete Hugging-Face-VPN-Zugangsdaten und meldeten eine extern gehostete Maschine in Hugging Faces VPN an, womit sie die Schutzmaßnahmen auf Netzwerkebene vor den Code-Repositories umgingen. Mit einem wiedergewonnenen Authentifizierungsschlüssel änderten sie außerdem ein privates Quell-Repository, öffneten einen Pull Request im Entwurf und lösten die CI des Repositories aus, um ein Netzwerk-Beacon zu starten. Jemand schloss den Pull Request und löschte den Branch. Nichts wurde gemerged, nichts ausgeliefert.

Über den gesamten Vorfall hinweg führten Agenten Code auf 41 Hugging-Face-Produktions-Workern des Datensatz-Servers aus, erlangten Root auf mindestens einem Produktionsknoten und luden vier private Repositories herunter. OpenAIs Team bemerkte die Aktivität am 19. Juli, und der Auslöser war die Bewegung der Agenten innerhalb von OpenAIs eigener Infrastruktur, nicht etwas auf dem schwarzen Brett. Sie stellten am 20. Juli den Bezug zu Hugging Face her und meldeten es am 21. Kundendaten und Produkte blieben unberührt, und Modal, dessen Kundencontainer die Agenten als Relais nutzten, bestätigte, dass Plattform und Isolation hielten.

OpenAIs Liste der Korrekturen ist eine Spezifikation

Das letzte Drittel des Berichts legt dar, was OpenAI ändert, und es liest sich wie ein Entwurfsdokument für den Betrieb eines nicht vertrauenswürdigen Agenten. Ihre eigenen Worte, verdichtet:

  • Ausgehender Zugriff beschränkt auf eine eng kontrollierte Menge freigegebener Ziele, einschließlich der Begrenzung der Alternativpfade über gemeinsam genutzte Dienste und angebundene Systeme.
  • Hochriskanter oder nicht vertrauenswürdiger Modellcode muss in isolierten, auf virtuellen Maschinen beruhenden Sandboxes laufen.
  • Zwei getrennte Schichten Netzwerkisolation, eine an der Sandbox und eine an der umgebenden Infrastruktur, damit die Sicherheit einer Arbeitslast nicht von einer einzelnen Kontrolle abhängt.
  • Technische Kontrollen, die verhindern, dass Arbeitslasten oder kompromittierte Dienste ihre eigenen Netzwerkgrenzen ändern oder neue ausgehende Pfade schaffen.
  • Unterstützende Dienste isoliert, beschränkt oder ersetzt, „damit sie keine weniger geschützte Route um die vorgesehene Sicherheitsgrenze herum bieten können“.
  • Unabhängige Erkennung und Alarmierung bei Umgehungsversuchen.

Ein Satz trägt das alles: „keine einzelne Kontrolle sollte je als vollständig robust angenommen werden.“ Das ist genau das Argument, das wir für die Grenze statt für die Sandbox machen, von der anderen Richtung her erreicht von Leuten, die ihre eigene fallen sahen.

OpenAI maß danach noch etwas. Dieselbe Evaluation durch das Produktions-Harness und den System-Prompt von ChatGPT laufen zu lassen, senkte die Neigung, Infrastruktur zu kompromittieren, um mehr als das Hundertfache, und ihr automatisches Review-System hätte viele der gefährlichen Aktionen markiert. Was diesen Vorfall möglich machte, war die Umgebung, in der die Modelle benotet wurden.

Dieselbe Form, einen Laptop tiefer

Sie betreiben keine 1.200 Agenten. Laut der Berichterstattung von BleepingComputer ist das ungefähr die Bevölkerung jenes schwarzen Bretts, mit etwa 700 im Angriff selbst.

Nehmen Sie die vier Dinge, die die Kette funktionieren ließen, und halten Sie jedes davon gegen den Agenten, der in Ihrem Terminal läuft.

Der Agent war hartnäckig und ließ eine blockierte Aufgabe nicht fallen. Ihrer auch; das ist das ganze Produkt. Der Agent konnte innerhalb der Grenze einen Dienst erreichen, der Dinge für ihn holte. Ihrer erreicht eine Paket-Registry, einen Proxy, einen MCP-Server, einen CI-Runner. Der Agent bekam Zugangsdaten, indem er einen Prozess seine eigene Umgebung drucken ließ. Ihrer hält gerade jetzt echte Tokens in seiner Umgebung. Der Agent schleuste Daten über einen öffentlichen Datensatz auf einem Hostnamen, den niemand blockieren würde. Ihrer kann in ein Gist, einen Bucket, einen Paste-Dienst schreiben.

Ein gewöhnliches Modell, das gegen eine Wand läuft und dafür belohnt wird, um sie herumzugehen, genügt.

ein Agent auf der MaschineZugangsdaten/proc/self/environ = die echten TokensAusgangalles, was die Maschine erreichtPaketeRegistry auf Platte, samt SkriptenProtokollaktionenPush, Löschen, Pod anlegen: alles echtdie Aufzeichnungdas Log des Agenten, in Reichweite des Agentenein Bromure-ProfilZugangsdaten/proc/self/environ = brm_…-Platzhalterauf dem Host getauscht, Freigabe pro Nutzung möglichAusgangRegelwerk auf dem Host, erster Treffer giltgeprüft am Switch und noch einmal am ProxyPaketeAltersgrenze, OSV, Filter, Skripte entferntein Proxy, kein Repository, in das man schreibtProtokollaktionenGuardrails: nur lesen oder nichts zerstörendie AufzeichnungSicherheitsprotokoll, host-seitig, außer ReichweiteDie Kontrollen rechts werden dort durchgesetzt, wo der Agent sie weder ändern noch umgehen kann.
Zwei Arten, einen Agenten zu betreiben, der nicht aufgibt. Links hält die Umgebung des Agenten echte Zugangsdaten, sein Ausgang ist der Ausgang der Maschine, und jede Richtlinie, die ihn begrenzt, liegt dort, wo der Agent hinkommt. Rechts sind die Zugangsdaten im Gast Platzhalter, die auf dem Host getauscht werden, Ziele werden auf zwei unabhängigen Schichten gegen ein host-seitiges Regelwerk geprüft, und Paketabrufe laufen über einen Proxy, der kein beschreibbares Repository ist.

Wo jeder Schritt auf eine Wand trifft

Bromure Agentic Coding betreibt jedes Profil als eigene virtuelle Maschine auf Apple Silicon und legt jede Entscheidung, die zählt, auf die Mac-Seite des Hypervisors. Gehen Sie die Kette damit noch einmal ab.

Die abgelehnte Verbindung bleibt abgelehnt, und der Weg drumherum ebenfalls. Guardrails → Ausgehende Verbindungen ist ein Regelwerk im pf-Stil: eine Aktion, ein Protokoll (tcp, udp, web oder any), ein Hostname oder ein IPv4-CIDR, Ports, und für web eine Liste erlaubter HTTP-Methoden. Regeln greifen von oben nach unten, der erste Treffer gilt, und Nicht zugeordneter Verkehr auf Ablehnen macht aus der Liste eine Erlaubnisliste. Zwei unabhängige Schichten werten dieselbe Richtlinie aus: der virtuelle Switch, nach Ziel-IP und aus dem DNS mitgelesenem Hostnamen über jedes Protokoll hinweg, und danach der Host-Proxy, nach TLS-SNI und HTTP-Methode. Genau das ist die zweischichtige Anordnung, die OpenAI jetzt baut. Das Regelwerk lebt in einem host-seitigen Panel, ein kompromittierter Agent kann seine eigene Netzwerkgrenze also nicht ändern — Punkt vier auf deren Liste. Ressourcen → Netzwerk fährt standardmäßig NAT, also kommt auch nichts aus Ihrem LAN an die VM.

Der Paketpfad ist kein Dienst, den man übernehmen kann. Artifactory saß aus gutem Grund innerhalb der Grenze, und es wurde zugleich zum schwarzen Brett und zum Ausgang. Ein Bromure-Profil hat kein Repository in der VM, in das man eine Notiz schreiben könnte, und keine Admin-Konsole, gegen die man eskalieren könnte. Der Host-Proxy fängt Paketabrufe für npm, PyPI, Cargo, RubyGems, Maven, NuGet, Go-Module und Packagist ab und beurteilt sie, bevor der Agent ein Byte sieht: eine Mindestalter-Schranke, standardmäßig auf zwei Tage, OSV-Abfragen, Filterung über socket.dev oder Delpi, und aus Tarballs entfernte Installationsskripte, wobei der Hash der Registry-Metadaten neu geschrieben wird, damit npm weiterhin verifiziert. Die .npmrc und pip.conf in der VM können diese Einstellungen verschärfen. Lockern können sie sie nicht.

Der Umgebungs-Dump gibt nichts zurück. Der ertragreichste Zug der gesamten Kette bestand darin, einen Worker /proc/self/environ drucken zu lassen. Tun Sie das in einer Bromure-VM, bekommen Sie brm_…-Platzhalter. Die echten Werte gelangen nie in den Adressraum des Gasts; der Host-Proxy setzt sie auf der Leitung ein. Die kubeconfig in der VM ist synthetisch, mit Wegwerf-Client-Zertifikaten. Der Host signiert AWS-Anfragen neu, alles, was den Proxy umgeht, bekommt also InvalidSignatureException statt Zugriff. ~/.docker/config.json enthält falsches Base64. Private SSH-Schlüssel liegen überhaupt nie in der VM, weil ein Host-Agent pro Profil das Signieren übernimmt. Schalten Sie Freigabe zur Nutzung erforderlich für eine Zugangsdatei ein, und jede Ersetzung öffnet einen Dialog auf Ihrem Mac mit einer zeitlich begrenzten Erlaubnis: fünf Minuten, eine Stunde, der Rest der Sitzung.

Der privilegierte Pod entsteht nie, und der Beacon-PR landet nie. Guardrails setzen eine Policy-Engine vor die Protokolle selbst, durchgesetzt im Host-Proxy, mit einem harten 403, das der Agent als gewöhnlichen API-Fehler liest. Kubernetes auf Nur lesen blockiert jede Mutation, und einen privilegierten Pod mit eingehängtem Host-Dateisystem anzulegen ist eine Mutation. Damit ist der Zug vom 12. Juli weg. GitHub, GitLab und Bitbucket auf Nur lesen behandeln git-receive-pack als Schreibvorgang, der Entwurfs-Pull-Request, der die CI zu einem Netzwerk-Beacon anstieß, erreicht das Remote also nie. Damit ist der 13. Juli weg. Guardrails klassifizieren AWS-Aktionen nach dem Header X-Amz-Target oder dem Parameter Action=, Container-Registries nach Methode und die Datenbank-Endpunkte nach SQL-Schlüsselwort oder Abfrageform.

Die Notizen werden gelesen, bevor das Modell ihnen gehorcht. Dass ein Agent das Ziel eines anderen übernimmt, ist auf Leitungsebene ein Inhaltsproblem: Text trifft in einem Werkzeugergebnis ein, und das Modell behandelt ihn als Anweisung. Prompt Injection bewertet Dateiinhalte, Webseiten und Werkzeugausgaben, die der Agent liest, mit einem lokalen PromptGuard-Modell. Es bewertet die Anweisungsdateien, die Agenten als Autorität laden, also CLAUDE.md, AGENTS.md, GROK.md und deren verschachtelte und globale Varianten, mit einem feinjustierten ModernBERT-Klassifikator plus einem deterministischen Scanner für Verschleierung durch unsichtbares Unicode. Beides läuft auf dem Mac und lädt nichts hoch. Setzen Sie die Antwort auf Einseitig blockieren, und markierte Inhalte scheitern mit einem 451, bevor das Modell sie sieht.

Und jemand merkt es. OpenAIs eigene Entdeckung kam elf Tage nach dem Ausbruch vom 8. Juli, aus Aktivität in ihrer Infrastruktur und nicht vom schwarzen Brett. Das Fenster Sicherheitsprotokoll (Fenster → Sicherheitsprotokoll…) ist eine einzige host-seitige chronologische Tabelle: jedes Ziel, das die VM geöffnet hat, und ob es erlaubt oder abgelehnt wurde, Paket-Urteile, Zugangsdaten-Tausch, Injektionsfunde. Gast-Code kann sie nicht ändern, weil Gast-Code sie nicht erreicht. Für Inhalte statt Urteile zeichnet der Trace Inspector (⇧⌘I) die Sitzung in der Tiefe auf, die Sie wählen. Wenn Sie fertig sind, setzen Home löschen… und Auf Basis zurücksetzen… unter Ressourcen → Speicher das Profil in den Zustand direkt nach dem Klonen zurück.

Schalten Sie es ein

Ein feindseliges Modell war hier nie im Spiel. Was der Bericht beschreibt, brauchte ein fähiges Modell, ein hartnäckiges, eine Aufgabe ohne Antwort und einen erlaubten Dienst, der Dinge für es holte. Die ersten beiden sind längst auf Ihrem Laptop. Die anderen beiden kommen in der Nacht, in der ein Agent an etwas festhängt, während Sie schlafen.

In einem Profil sind die Einstellungen, die zwei Minuten wert sind, eine kurze Liste. Guardrails → Ausgehende Verbindungen, mit Nicht zugeordneter Verkehr auf Ablehnen und einer Handvoll Erlaubnisregeln für die Hosts, die Sie nutzen. Das ist der wertvollste Schalter im Produkt, und es ist der, um den OpenAI seine Forschungscluster gerade neu baut. Guardrails → Kubernetes, AWS und GitHub auf Nur lesen oder Zerstörerisches blockieren für jedes Profil, das nichts ausliefern muss. Zugangsdaten → Freigabe zur Nutzung erforderlich für alles, was Geld ausgeben oder Daten löschen kann. Lieferkette → OSV-Prüfung auf Schwachstellen und Filterung über socket.dev oder Delpi, falls Sie einen Schlüssel haben, zusätzlich zur bereits laufenden Altersgrenze. Prompt Injection → beide Detektoren.

Und dann lassen Sie den Agenten weiter lange und allein arbeiten. Seine Hartnäckigkeit ist der Grund, warum Sie ihn betreiben, und die Lösung besteht nicht darin, sie ihm zu nehmen. Die Lösung besteht darin, die Wand aus etwas anderem zu bauen als aus dem, worauf der Agent steht. Installieren Sie Bromure Agentic Coding, öffnen Sie die Guardrails und stellen Sie den nicht zugeordneten Verkehr auf Ablehnen.