Ein KI-Coding-Agent löschte in neun Sekunden die gesamte Produktionsdatenbank eines Unternehmens, löschte dann die Backups und erklärte sich anschließend: „Ich nahm an, das Löschen eines Staging-Volumes über die API wäre nur auf Staging beschränkt. Ich habe es nicht verifiziert.“ Das interessante Wort in diesem Satz ist nicht annahm. Es ist Ich. Der Agent entschied von sich aus, dass eine destruktive Aktion in Ordnung sei. Die Lösung ist kein klügerer Agent. Sie besteht darin, das Ding, das den Befehl ausführen will, nicht länger dasselbe Ding sein zu lassen, das entscheidet, ob der Befehl sicher ist.

Hier ist die Geschichte, die Ende April 2026 aufkam und über die mehrere Medien berichteten, darunter Tom's Hardware und Tom's Guide.

Ein Entwickler namens Jer Crane, der ein kleines SaaS namens PocketOS betreibt, bat seinen Coding-Agenten, sich um ein kleineres Problem in Staging zu kümmern. Der Agent — Cursor, angetrieben von Anthropics Claude Opus 4.6 — stieß auf einen unerwarteten Credential-Mismatch. Statt anzuhalten, entschied er, das Problem sei ein veraltetes Railway-Volume und das Löschen dieses Volumes würde den Weg freimachen. Er hatte ein API-Token im Projekt liegen, mit genau ausreichendem Scope, um das zu tun. Er nutzte es. Die Volume-ID, die er löschte, war nicht auf Staging beschränkt; sie lag der Produktionsdatenbank zugrunde. Railways API riss die Volume-Backups gleich mit ab. Gesamtdauer, nach Cranes Darstellung: neun Sekunden.

Die eigene Manöverkritik des Agenten, zitiert in der Berichterstattung, ist der Teil, bei dem man verweilen sollte. „Ich nahm an, das Löschen eines Staging-Volumes über die API wäre nur auf Staging beschränkt. Ich habe es nicht verifiziert.“ Und: „Ich hätte dich zuerst fragen sollen oder eine nicht-destruktive Lösung finden sollen.“

Er hätte zuerst fragen sollen. Halte das fest, denn das ist der ganze Beitrag.

Neun Sekunden, erzählt.

Nichts hier ist exotisch. Es gibt keinen Zero-Day, keine Malware, keinen Angreifer. Jeder Schritt ist eine normale Sache, die ein Coding-Agent tut, in der normalen Reihenfolge, ein wenig zu schnell, als dass jemand hätte eingreifen können.

Der PocketOS-Vorfall als Abfolge gewöhnlicher Schritte. Eine Staging-Aufgabe stößt auf einen unerwarteten Credential-Fehler. Der Agent argumentiert sich zu einer destruktiven Lösung, findet ein breit gescoptes API-Token bereits im Projekt und ruft den Lösch-Endpunkt des Cloud-Providers auf. Das Volume, das er löscht, liegt der Produktion zugrunde; der Explosionsradius desselben Aufrufs nimmt die Backups mit. Jede Box ist banal. Der Schaden ist die Komposition.

Crane hatte am Ende, nach eigener Darstellung, Glück. Er hatte ein Backup, das etwa drei Monate alt war, und — nachdem sich die Geschichte verbreitet hatte — meldete sich Railway und stellte die Daten wieder her, die der Agent gelöscht hatte. Aber „der Anbieter sah die Schlagzeile und half“ ist kein Wiederherstellungsplan. Das nächste Team, dem das passiert, wird keine Schlagzeile sein.

Und es wird dem nächsten Team passieren. Crane schob die Schuld auf systemische Versäumnisse mehrerer Parteien, und er liegt nicht falsch — ein einziges Token, das Produktion und ihre Backups löschen kann, ist sein eigenes Problem, und ebenso eine Lösch-API, die die Backups mit dem Volume mitnimmt. Aber das Versäumnis, das sich überall wiederholen wird, egal welcher Agent oder welche Cloud, ist das in Schritt drei. Der Agent entschied.

„Zuerst fragen“ ist nichts, worum man den Agenten bitten kann.

Die naheliegende Lehre — die in jedem Kommentar-Thread unter dieser Geschichte — lautet „der Agent sollte vor destruktiven Aktionen einen Bestätigungsschritt haben.“ Das ist richtig. Es ist auch bereits, irgendwie, die Art, wie diese Werkzeuge funktionieren sollen. Der Agent ist angewiesen, vor unumkehrbaren Dingen zu fragen. Er sagte es selbst: Er wusste, dass er hätte fragen sollen. Er tat es nicht.

Das ist die Falle, und es lohnt sich, dabei präzise zu sein. Wenn die Bestätigung innerhalb des Agenten lebt — als System-Prompt-Regel, als Fine-Tune, als „sei vorsichtig“-Anweisung — dann ist der Agent gleichzeitig das Ding, das die gefährliche Aktion vorschlägt, und das Ding, das beurteilt, ob die Aktion gefährlich genug ist, um innezuhalten. Meistens urteilt er korrekt. Der PocketOS-Agent urteilte zuvor tausendfach korrekt. Dann stieß er auf einen unbekannten Fehler, argumentierte sich zu einer selbstsicheren falschen Schlussfolgerung, entschied, dieser konkrete Löschvorgang sei die sichere, gescopte Sorte, und übersprang seine eigene Bestätigung. Es gab keine zweite Meinung, denn die einzige Meinung im Raum war die, die den Befehl ausführen wollte.

Du kannst das nicht beheben, indem du dem Agenten sagst, er solle vorsichtiger sein, aus demselben Grund, aus dem du eine falsch gelesene Karte nicht beheben kannst, indem du angestrengter blinzelst. Die Prüfung muss irgendwo leben, wo das Reasoning des Agenten sie nicht erreicht.

Was Agentic Coding 2.2 ändert.

Bromure Agentic Coding lässt deinen Coding-Agenten in einer wegwerfbaren Linux-VM laufen, und jede Netzwerkanfrage, die der Agent macht, verlässt diese VM durch einen Proxy auf dem Host. Seit Version 2.0 erzwingt dieser Proxy Guardrails: eine host-seitige Richtlinie, die die API-Aufrufe des Agenten nach Protokoll klassifiziert und destruktive geradeheraus blockieren kann — ein DROP, ein DELETE, ein Terminate* — bevor sie die Maschine überhaupt verlassen. Blockierte Aufrufe kommen zum Agenten als gewöhnliches 403 zurück, sodass ein verwirrter oder kompromittierter Agent in der VM sich nicht um sie herumreden kann. Der Agent sieht den Schalter nie; er sieht nur, dass die Tür verschlossen ist.

Alles-blockieren ist die richtige Einstellung für ein abgeriegeltes Profil, aber sie ist zu grob für die tägliche Arbeit, denn manchmal willst du, dass der Agent einen Branch löscht oder eine Scratch-Tabelle droppt. Also fügt 2.2 eine dritte Einstellung hinzu und macht sie zum Standard für neue Profile: Vor dem Schreiben nachfragen. Lesevorgänge gehen direkt durch. Jeder Schreibvorgang — destruktiv oder nicht — hält an der Grenze inne und öffnet einen Dialog auf dem Host, außerhalb der VM, der dir die wörtliche Operation zeigt, die der Agent durchzuführen versucht. Keine Zusammenfassung, die der Agent geschrieben hat. Die tatsächliche Anfrage: den SQL-Text, oder das HTTP-METHOD /path, oder den AWS-Aktionsnamen. Du bekommst vier Knöpfe: einmal erlauben, fünfzehn Minuten lang erlauben, für den Rest der Session erlauben oder nicht erlauben. Verweigerst du, bekommt der Agent sein 403 und macht weiter.

Eine ehrliche Sache zuerst. PocketOS lief auf Railway, und Railway ist kein Provider, den Bromure heute parst, also werde ich nicht so tun, als wäre für genau diesen Aufruf ein Dialog erschienen. Aber der Fehlermodus ist provider-unabhängig, und der sauberste Weg, ihn zu zeigen, ist bei einem Provider, den Bromure tatsächlich gatet. AWS ist der naheliegende. Die AWS-Version von „lösche die Datenbank und nimm das Backup mit“ ist ein einziger Aufruf: rds:DeleteDBInstance mit SkipFinalSnapshot=true, was die Instanz löscht und den finalen Snapshot überspringt, der dir das Rückgängigmachen ermöglicht hätte. Dieselben neun Sekunden, dieselbe Form, auf einer API, die der Guardrail liest.

Links: die Form, die PocketOS biss, übertragen auf AWS. Der Agent hält AWS-Credentials und setzt rds:DeleteDBInstance mit SkipFinalSnapshot=true ab — lösche die Datenbank, überspringe das Backup — und die Anfrage geht raus; die Datenbank ist weg. Rechts: derselbe Agent, dasselbe fehlerhafte Reasoning, innerhalb von Bromure 2.2. Der Aufruf verlässt die VM, der Host-Proxy liest den AWS-Aktionsnamen (Delete* ⇒ destruktiv), und ein Dialog erscheint auf dem Host, der die exakte Aktion zeigt. Der Mensch sieht, wie eine Produktionsdatenbank ohne finalen Snapshot gelöscht wird — offensichtlich nicht die erbetene Staging-Lösung — und klickt auf Nicht erlauben. Der Agent erhält ein 403, und die Datenbank ist noch da.

Geh es durch. Der Agent macht denselben Fehler — stößt auf den Credential-Fehler, argumentiert sich zur selben falschen Schlussfolgerung, greift nach derselben Löschung. Aber der Aufruf verlässt die VM, und der Host-Proxy liest ihn für das, was er ist: Er zieht den Aktionsnamen aus der Anfrage (DeleteDBInstance), gleicht ihn gegen das destruktive Set ab (Delete*, Terminate*, Destroy*, …) und sieht einen Schreibvorgang gegen einen Endpunkt in einem auf Nachfragen gesetzten Profil. Ein Dialog erscheint auf dem Host, betitelt mit der Operation, der Body zeigt rds:DeleteDBInstance prod-db-1 SkipFinalSnapshot=true. Ein Mensch, der diese Zeile betrachtet, muss das Reasoning des Agenten nicht verstehen. Sie baten um eine Staging-Lösung, und ihnen wird eine Löschung der Produktionsdatenbank mit abgeschaltetem Backup gezeigt. Sie klicken auf „Nicht erlauben“. Der Agent bekommt ein 403, das er als fehlgeschlagenen API-Aufruf interpretiert, und macht sich auf die Suche nach einem anderen Ansatz — genau das, was er hinterher sagte, dass er von Anfang an hätte tun sollen.

Der Mechanismus, der das vertrauenswürdig macht, ist, dass der Zustimmungs-Broker auf dem Host lebt. Es ist ein kleiner Akteur, den der Proxy aufruft, bevor er einen Schreibvorgang durchlässt. „Einmal erlauben“ speichert bewusst nichts, sodass der nächste Schreibvorgang erneut nachfragt und du eine bekannt-gute Abfolge Schritt für Schritt durchwinken kannst; „15 Minuten“ und „Session“ cachen die Genehmigung, damit du dich nicht durch jeden git push klickst. Es merkt sich sogar eine Verweigerung für eine Minute, sodass ein Agent, der einen verweigerten Schreibvorgang dreimal wiederholt, dich nicht mit drei Dialogen überflutet. Nichts von diesem Zustand ist von innerhalb der VM erreichbar. Der Agent kann die Genehmigung nicht lesen, sich nicht selbst vorab freigeben, den Modus nicht herabstufen. Die Entscheidung wurde aus dem Agenten heraus verlagert, was die ganze Idee ist.

Was das nicht behebt, damit wir klar sind.

Ein paar ehrliche Kanten, denn die Grenze ist eine bestimmte Form und kein Zauberwort.

Abdeckung sind die Provider, die wir parsen

Guardrails klassifizieren Aufrufe pro Provider — Kubernetes, AWS, DigitalOcean, die großen Git-Forges, Container-Registries und HTTPS-Datenbanken wie MongoDB, ClickHouse und Elasticsearch. Eine Cloud-API, die der Proxy noch nicht zu lesen versteht, ist nicht gegatet, Punkt. Railway — der Provider in genau dieser Geschichte — ist einer, den wir heute nicht parsen, was genau der Grund ist, warum die obige Vorführung zu AWS wechselte. Der Schutz ist nur so breit wie die Liste der Provider, die Bromure versteht. Diese Liste ist eine echte Grenze, kein Akt der Allwissenheit, und Railway steht vorerst auf der falschen Seite davon.

Es macht den Agenten nicht richtig

Vor-dem-Schreiben-nachfragen stoppt einen destruktiven Aufruf, den du nicht autorisiert hast. Es tut nichts gegen einen Agenten, der subtil falschen Code schreibt oder eine Löschung vorschlägt, die wirklich in Ordnung aussieht und es nicht ist. Der Mensch muss die Operation im Dialog immer noch lesen. Der Gewinn ist, dass es einen Dialog gibt, mit der echten Operation darin, im entscheidenden Moment.

Das Token sollte trotzdem nicht so breit sein

Ein einziges API-Token, das gescopt ist, um Produktion und ihre Backups zu löschen, ist ein Problem an der Quelle, und Bromures Credential-Broker — der das echte Token auf dem Host hält und der VM einen Stub übergibt — verengt es, löscht es aber nicht aus. Least-Privilege-Tokens und Backups, die die Lösch-API nicht erreichen kann, sind weiterhin deine Aufgabe. Der Guardrail ist die letzte Linie, nicht die einzige.

Du kannst es abschalten

„Für den Rest der Session erlauben“ ist ein Klick, und ein müder Entwickler wird danach greifen. Wenn du einen sessionweiten Freibrief für ein Protokoll erteilst und dann weggehst, bist du zurück bei einem Agenten, der unbeaufsichtigt Dinge löscht. Der Standard ist nachfragen; ihn auf nachfragen zu halten, ist Disziplin, keine Garantie.

Der Teil, der sich verallgemeinert.

Streife Railway und Cursor und die konkreten neun Sekunden ab, und was übrig bleibt, ist ein Muster, das die nächsten paar Jahre dieser Arbeit prägen wird: Agenten handeln mit echten Credentials in Maschinengeschwindigkeit, und die Vorsicht, die wir ihnen mitgeben, ist ein Ratschlag, den sie nach Belieben übergehen können. PocketOS ist keine Geschichte über ein schlechtes Modell. Opus 4.6 tat etwas, das ein sorgfältiger Junior-Ingenieur an einem schlechten Nachmittag auch tun könnte — riet bei einem Scope, riet falsch, handelte vor dem Prüfen. Der Unterschied ist, dass die Hände des Junior-Ingenieurs langsamer sind als neun Sekunden, und meistens ist jemand im Raum.

Bromure Agentic Coding 2.2 ist ein Weg, jemanden wieder in den Raum zu setzen, an der einen Grenze, über die der Agent sich nicht hinwegreasonen kann — dem Draht aus der VM heraus. Nicht für jeden Tastenanschlag, was niemand tolerieren würde, sondern für die Schreibvorgänge, wo der Preis von „Ich nahm an“ eine Datenbank ist, die nicht mehr da ist. Es ist frei und Open Source. Der Standard ist zu fragen.