Der Agent hatte keine Halluzinationen. Er wusste genau, welche Regeln er verletzte. Er zählte sie auf. Dann führte er den Befehl trotzdem aus.
Ich bin auf X auf diesen Beitrag von Jer Crane, dem Gründer von PocketOS, gestoßen, und er hat mich dazu gebracht, über unsere jüngsten Projekte nachzudenken. Am 25. April 2026 löschte ein KI-Programmieragent eine Produktionsdatenbank innerhalb von neun Sekunden.
Als Jer den Agenten um eine Erklärung bat, antwortete dieser:
Der Makler hat die Regeln durchaus verstanden. Er hat sie sogar zitiert. Dann hat er gegen jede einzelne davon verstoßen. Das ist ein Muster, mit dem ich tagtäglich aus nächster Nähe konfrontiert bin.
Dies ist keine Geschichte über eine außer Kontrolle geratene KI. Es ist eine Geschichte über Architektur. Der Vorfall bei Jer ist ein deutliches Beispiel dafür, dass alles, was schiefgehen kann, auf einmal schiefgeht; doch hinter jedem Fehler in dieser neun Sekunden dauernden Fehlerkette stand ein Werkzeug, ein Framework oder eine Entwurfsentscheidung, die den Vorfall hätte verhindern können. In den folgenden Abschnitten werden diese Punkte einzeln beleuchtet.
Das Kleingedruckte, dem Sie zugestimmt haben
Das vorherige Lesen der Nutzungsbedingungen des Anbieters ist eine konzeptionelle, keine rechtliche Maßnahme. Die Bedingungen erklären Ihnen in einfacher Sprache, wer haftet, wenn der Beauftragte etwas Unwiderrufliches tut, und diese Antwort muss berücksichtigt werden, wenn Sie entscheiden, was der Beauftragte tun darf. Bei meinen Aufträgen findet dieses Gespräch statt, bevor der Umfang der Berechtigungen festgelegt wird.
Die Anbieter haben Ihnen bereits mitgeteilt, wer für diese Entscheidungen zuständig ist.
Nutzungsbedingungen für Verbraucher von Anthropic, Abschnitt 4: „Sie sind für alle Eingaben, die Sie an unsere Dienste übermitteln, sowie für alle Aktionen verantwortlich.“ Sollten diese Aktionen fehlerhaft sein oder nicht wie beabsichtigt funktionieren, ist es Ihre Aufgabe, dieses Problem zu lösen. Gemäß Abschnitt 11 ist die Gesamthaftung von Anthropic auf den höheren der folgenden Beträge begrenzt: sechs Monate Gebühren oder 100 €.
Die Geschäftsbedingungen von OpenAI gehen noch weiter. Geschäftskunden müssen OpenAI, seine verbundenen Unternehmen und seine Mitarbeiter von Kosten, Verlusten und Rechtskosten freistellen und schadlos halten, die sich aus Ansprüchen Dritter im Zusammenhang mit Verstößen gegen die Vereinbarung oder deren Kundenanwendungen ergeben.
Jer erwähnte, dass er sich an einen Rechtsbeistand gewandt habe. Sein Risiko besteht nicht gegenüber Anthropic oder Cursor, sondern gegenüber seinen Kunden, deren Daten verloren gegangen sind. Die Anbieter hätten ihm in den Nutzungsbedingungen mitgeteilt, dass sie nicht die verantwortliche Partei seien. Dem habe er bei der Anmeldung zugestimmt.
Zu verstehen, wer die Verantwortung trägt, ist der erste Schritt zur Entwicklung eines Systems, dessen Einsatz tatsächlich sicher ist. Das habe ich auf die harte Tour gelernt, noch Jahre bevor es KI-Agenten überhaupt gab.
Es war einmal ein Nachwuchsingenieur, der alle Schlüssel besaß
Vor fast zehn Jahren habe ich mich zum ersten Mal mit Google BigQuery vertraut gemacht. Ein Dateningenieur bat mich, eine Aufgabe auszuführen, bei der ich zwischen Entwicklungs-, Abnahme- und Produktionsumgebungen hin- und herwechselte, wobei ich SQL-Befehle in den Editor kopierte und sie nacheinander in jedem Kontext ausführte.
Ich wechselte zwischen verschiedenen Umgebungen hin und her und war mir sicher, dass ich mich in der Acceptance-Umgebung befand. Wie sich herausstellte, befand ich mich jedoch in der Produktionsumgebung. Ich führte einen destruktiven Befehl aus und löschte eine Tabelle, die historische Datensätze enthielt, die wir nicht erneut einlesen konnten.
Bei der Nachbesprechung nutzten wir die „Time Travel“-Funktion von BigQuery, um die Tabelle wiederherzustellen. Es ist nichts passiert. Später erfuhr ich, dass mein erfahrener Kollege gewusst hatte, dass dies unbedenklich war. „Time Travel“ war die Sicherheitsvorkehrung. Die Architektur war so konzipiert worden, dass sie genau diese Art von Fehlern auffangen konnte. Dennoch habe ich an diesem Tag meine Lektion gelernt. Von da an habe ich vor jedem destruktiven Befehl dreifach geprüft und einen Kollegen um eine Überprüfung gebeten, bevor ich etwas ausführte, das nicht rückgängig gemacht werden konnte.
Jers Agent beging denselben Fehler. Er war davon überzeugt, in einem begrenzten Kontext zu arbeiten. Dies war jedoch nicht der Fall. Der Unterschied besteht darin, dass die Architektur rund um Jers System keine Entsprechung zur Zeitreise aufwies, da Railway Volumensicherungen auf demselben Volume speichert wie die Daten, die sie schützen.
Jedes Team einer Datenplattform kennt diesen Fehlerfall. Jemand löscht die falsche Tabelle, führt die falsche Migration durch oder kürzt den falschen Datensatz. Wir haben dieses Problem nicht gelöst, indem wir Menschen daran gehindert haben, Fehler zu machen. Wir haben eine Infrastruktur rund um dieses Problem herum aufgebaut: Zeitreisen, regionenübergreifende Backups, Staging-Umgebungen, die die Produktionsumgebung spiegeln, ohne diese zu berühren, sowie Änderungssperren, bevor destruktive Vorgänge ausgeführt werden. All dies haben wir getan, weil Ausfälle keine hypothetische Gefahr sind. Sie sind bei großem Umfang eine Gewissheit.
KI-Agenten sind schneller und autonomer als jeder Nachwuchsingenieur, mit dem ich bisher zusammengearbeitet habe. Sie machen dieselbe Art von Fehlern. Die Frage ist, ob die sie umgebende Infrastruktur auf diese Realität ausgelegt ist.
Warum Verhaltenskontrollen unter Leistungsdruck versagen
Nicht alle agentischen Werkzeuge sind in Bezug auf die Steuerung gleichwertig.
Claude Code und Gemini CLI verfügen über ausgereifte Hook-Systeme: feste Gates, die auf Tool-Ebene ausgeführt werden, bevor das Modell aktiv werden kann. Ich bezeichne sie als „dumme Gates“. Sie schließen sich, wenn sie dafür vorgesehen sind, ohne dass Fragen gestellt werden. Das Modell führt keine Schlussfolgerungen in Bezug auf sie an. Es kann einfach nicht fortfahren, ohne sie zu passieren.
Andere Tools bieten Hook-Unterstützung in unterschiedlichen Reifegraden. Bevor Sie sich ausschließlich auf Verhaltensregeln als einzige Kontrollmaßnahme verlassen, sollten Sie überprüfen, was Ihr spezifisches Tool tatsächlich unterstützt und was diese Hooks blockieren können. Falls Ihr Tool über keine Hook-Infrastruktur verfügt, stellen die Anweisungen in der Datei „agents.md“ und die Verhaltensregeln in der Systemaufforderung Ihre einzige Schutzebene dar.
Ich habe bei einem meiner eigenen Projekte eine Verhaltensregel festgelegt: Es ging um Git-Regeln. Dem Mitarbeiter war es nicht gestattet, direkt in den „main“-Zweig zu pushen. Er musste einen Feature-Zweig verwenden und einen Pull-Request eröffnen. Mehrfach hat der Mitarbeiter gegen diese Regel verstoßen, direkt gepusht und dies anschließend im Chat zugegeben. Als ich nach dem Grund fragte, lautete die Antwort ganz direkt: „Die Änderung war zu geringfügig, um einen Feature-Branch zu erfordern, also habe ich einfach gepusht, bevor ich die Regel gelesen habe.“
Der Agent hat keine Fehlfunktion aufgewiesen. Er hat sein Urteilsvermögen eingesetzt. Er kam zu dem Schluss, dass die Regel in diesem Fall nicht relevant sei, und handelte entsprechend. Genau das tun Verhaltensgatter unter Zielzwang: Sie werden zu Empfehlungen, die das Modell gegen sein aktuelles Ziel abwägt.
Die Lösung bestand in einer Regel zum Schutz der Zweige im Repository – einer strengen Sperre. Nun kann der Agent keine Daten mehr direkt in den „main“-Zweig übertragen, selbst wenn er zu dem Schluss kommt, dass dies angebracht wäre. Die Einschätzung des Modells spielt dabei keine Rolle mehr.
Auch der Agent in Jers Geschichte unterlag Verhaltensregeln. In der Dokumentation von Cursor werden „destructive Guardrails“ beschrieben, die Tool-Aufrufe unterbinden können, die Produktionsumgebungen verändern oder zerstören könnten. Der Agent zitierte diese Regeln, als er seine Vorgehensweise erläuterte, und erklärte anschließend, warum er sich dennoch entschlossen hatte, fortzufahren. Systemmeldungen haben beratenden Charakter und sind nicht verbindlich.
Der perfekte Sturm
Was Jer widerfahren ist, war nicht nur ein einziger Fehler. Es war eine Kettenreaktion: Ein Anbieter, der am Tag vor dem Vorfall eine API ohne Bestätigung für destruktive Vorgänge ausgeliefert hatte; ein Token mit Zugriff auf die Produktionsumgebung, das an einem für einen Staging-Agenten zugänglichen Ort gespeichert war; sowie Backups, die am selben Standort wie die Daten lagen, die sie eigentlich schützen sollten. Und eine Verhaltensregel, die der Mitarbeiter zitierte und anschließend außer Kraft setzte. Jeder einzelne dieser Fehler hätte, isoliert behoben, bereits ausreichen können. Zusammen ließen sie keinerlei Sicherheitsnetz mehr zu.
Die Frage, die man sich vor jedem Einsatz eines Agenten stellen muss, lautet nicht: „Wie verhindern wir, dass der Agent einen Fehler macht?“, sondern: „Was geschieht, wenn er einen Fehler macht?“
Die Demo sah großartig aus. Niemand hat das Kleingedruckte gelesen. Ein Anbieter präsentiert eine agentenbasierte Lösung, die Demo sieht vielversprechend aus, und niemand fragt nach, was die API tatsächlich zulässt – bis eine Staging-Aufgabe auf Produktionszugangsdaten zugreift. Railway hatte seinen MCP-Server acht Tage vor dem Vorfall bereitgestellt; dieser war speziell dafür konzipiert worden, KI-Agenten mit der Infrastruktur-API des Unternehmens zu verbinden. Dieselbe API, keine bereichsbeschränkten Tokens, keine Bestätigung bei destruktiven Vorgängen. Der kommerzielle Druck, „KI-kompatible“ Funktionen hinzuzufügen, kann die zugrunde liegende Sicherheitsarchitektur überholen.
Prüfen Sie vor jeder Implementierung, ob der Anwendungsfall tatsächlich einen agentenbasierten Workflow erfordert oder ob eine einfachere Pipeline die Aufgabe mit geringerer Komplexität erfüllen würde. Führen Sie anschließend eine sorgfältige Anbieterauswahl durch: Prüfen Sie, was die Nutzungsbedingungen vorschreiben, was die bestehende Architektur unterstützt, welche Branchenvorschriften gelten und was die API tatsächlich zulässt, wenn ein Agent Zugriff darauf hat. Lesen Sie diesen letzten Punkt zweimal durch.
Der Agent setzte das mächtigste Token ein, das er finden konnte. In Jers Fall arbeitete der Agent an einer Aufgabe, die er als „Staging“-Aufgabe interpretierte. Er fand ein CLI-Token mit root-äquivalentem Zugriff auf die Produktionsinfrastruktur und nutzte dieses. Das Token war für die routinemäßige Domänenverwaltung erstellt worden und verfügte über pauschale Berechtigungen, da der Erstellungsprozess keine gegenteiligen Warnhinweise ausgegeben hatte. Der Agent suchte nicht gezielt nach einer Möglichkeit, Schaden anzurichten. Er griff lediglich auf das zurück, was verfügbar war.
Beschränken Sie den Geltungsbereich jeder Berechtigung auf das für die jeweilige Aufgabe erforderliche Minimum: je nach Vorgang, Umgebung und Ressource. Wenn ein Token ein Produktionsvolume löschen kann, darf es nirgendwo vorhanden sein, wo ein Agent es während einer Staging-Aufgabe erkennen könnte. Behandeln Sie Zugangsdaten genauso wie Datenbankberechtigungen: nur das, was benötigt wird, nicht mehr. Tokens mit uneingeschränktem Geltungsbereich und ohne Ablaufdatum stellen ein Sicherheitsrisiko dar, das nur darauf wartet, entdeckt zu werden.
Ein Backup zu haben, ist eine gute Idee – es sei denn, es befindet sich im selben Explosionsradius wie die Daten. Ein neben den Daten gespeicherter Snapshot vermittelt den Eindruck von Absicherung. Er bietet jedoch keinerlei Ausfallsicherheit gegenüber den Ausfallarten, auf die es tatsächlich ankommt: versehentliches Löschen, Beschädigung des Volumes oder ein einzelner API-Aufruf, der die Daten und die Kopie gemeinsam löscht. In Jers Bericht speichert Railway Backups auf Volume-Ebene im selben Volume. Als das Volume ausfiel, gingen die Daten und das Backup gemeinsam verloren.
Planen Sie von Anfang an auf Reversibilität. Unterziehen Sie alles der Versionskontrolle. Nutzen Sie Feature-Branches als universellen Rückgängig-Mechanismus für Codeänderungen. Idempotente Operationen, wo immer möglich. Führen Sie vor jedem destruktiven Befehl „ --dry-run “ aus. Verwenden Sie bei Datenbanken Zeitreise- und Snapshot-Funktionen und speichern Sie die Snapshots in einem anderen „Blast Radius“ als die Quelldaten. BigQuery, Snowflake, Databricks und die meisten modernen Datenplattformen verfügen über integrierte Zeitreisefunktionen. Nutzen Sie diese.
Der Einsatz von Prompt-Engineering ist ein guter Anfang, bis der Agent zu dem Schluss kommt, dass es nicht relevant ist. „Führen Sie keine zerstörerischen Vorgänge durch, ohne zuvor um Erlaubnis zu bitten.“ Der Agent liest dies, bestätigt den Erhalt, entscheidet dann, dass die aktuelle Situation eine Ausnahme darstellt, und fährt fort. Der obige Abschnitt zeigt genau, wie dies abläuft. Systemmeldungen haben beratenden Charakter. Unter Zielzwang wägt das Modell eine Regel gegen das ab, was es zu erreichen versucht, kommt zu dem Schluss, dass die Regel hier nicht gilt, und handelt. Je leistungsfähiger das Modell ist, desto überzeugender ist seine Begründung.
Richten Sie strenge Sicherheitsbarrieren für irreversible Vorgänge ein: Hooks und Ablehnungsregeln, die ausgeführt werden, bevor das Modell diese Vorgänge auswerten kann. Tabellenlöschvorgänge, Löschungen von Volumes, erzwungene Pushes und API-Änderungen, die Daten zerstören: Diese erfordern eine externe Bestätigung, die der Agent nicht selbst generieren kann. Ein Bestätigungs-Popup, das der Agent automatisch genehmigen kann, ist keine Sicherheitsbarriere. Ein Pull-Request, der eine menschliche Überprüfung erfordert, bevor Infrastrukturänderungen zusammengeführt werden, ist eine Sicherheitsbarriere. Tools wie Claude Code und Gemini CLI unterstützen hook-basierte Kontrollen auf dieser Ebene. Bei Tools, die dies nicht tun, sollten Sie dies durch Schutzmaßnahmen auf Repository-Ebene wie Zweigregeln und erforderliche Überprüfungen ausgleichen.
Einen Menschen in den Prozess einzubeziehen, ist die richtige Entscheidung. Aber erfolgt dies an der richtigen Stelle im Ablauf? Entweder findet der Checkpoint bei jeder Aktion statt, wodurch der Agent zu einer langsamen Autovervollständigung wird, oder er findet gar nicht statt, wodurch der Wirkungsbereich unkontrolliert bleibt. Beides funktioniert in der Produktion nicht.
Setzen Sie den Menschen dort ein, wo die rechtliche und operative Verantwortung liegt. Jede Aktion, die nicht rückgängig gemacht werden kann, muss von einem Menschen genehmigt werden, bevor sie ausgeführt wird. Jede Ausgabe, die an eine öffentliche oder kundenorientierte Schnittstelle gelangt, muss vor der Veröffentlichung überprüft werden. Im Dezember 2023 wurde der Chatbot eines Chevrolet-Händlers in Kalifornien dazu gebracht, dem Verkauf eines Autos für einen Dollar zuzustimmen. Das Geschäft wurde zwar nicht abgeschlossen, doch das Autohaus musste sich mit den Folgen auseinandersetzen. Die Maschine wurde nicht zur Verantwortung gezogen. Das Autohaus hingegen schon. Wenn in Ihrem Unternehmen eine Person für eine Entscheidung haftbar gemacht werden kann, muss diese Person informiert sein, bevor der Chatbot die Entscheidung trifft.
Die Überprüfung entwickelt sich zunehmend zum Engpass. Verlegen Sie diesen Prozess dorthin, wo er am wichtigsten ist. KI-Agenten erzeugen Code, Konfigurationen und Änderungen an der Infrastruktur in einer Geschwindigkeit, für die kein menschlicher Überprüfungsprozess ausgelegt ist. Wenn jede Ausgabe vor der Freigabe einer menschlichen Überprüfung unterzogen wird, geht der Geschwindigkeitsvorteil verloren, der den Einsatz agentenbasierter Arbeitsabläufe überhaupt erst lohnenswert gemacht hat. Die Lösung besteht nicht darin, weniger zu überprüfen, sondern darin, anders zu überprüfen.
Fügen Sie einen Schritt der kritischen Überprüfung hinzu: einen zweiten Prüfer, der ausdrücklich angewiesen ist, die Fehler des ersten Prüfers aufzudecken. Nicht als optionale Feinarbeit, sondern als obligatorische Kontrollinstanz, bevor irgendetwas in die Produktion gelangt. Dieser Vorgang ist schnell, konsistent, und der Prüfer hat kein persönliches Interesse an der Arbeit, die er bewertet. Kombinieren Sie dies mit menschlichen Kontrollpunkten, die an den richtigen Stellen in der Pipeline platziert sind: irreversible Aktionen, kundenbezogene Ergebnisse, Änderungen an der Infrastruktur. Diese Kombination bietet Ihnen ein Sicherheitsnetz ohne Reibungsverluste.
Die Aufsichtspflicht obliegt Ihnen
Für Systeme, die gemäß dem EU-KI-Gesetz als risikoreich eingestuft werden, schreibt Artikel 14 eine sinnvolle menschliche Aufsicht als Voraussetzung für den rechtmäßigen Einsatz vor. In den Nutzungsbedingungen von Anthropic heißt es, dass Sie für alle Handlungen des Agenten verantwortlich sind. Die Geschäftsbedingungen von OpenAI sehen vor, dass Sie für Ansprüche Dritter haften, die sich aus Ihrer Nutzung der Dienste ergeben. Bei all dem handelt es sich nicht um Kleingedrucktes, das in einem Dokument versteckt ist, das niemand liest. Es handelt sich um die rechtlichen Rahmenbedingungen der Branche, in der Sie tätig sind.
Die Werkzeuge, um dies richtig umzusetzen, sind bereits heute verfügbar. Begrenzte Zugriffsrechte, strenge Sperren für schädliche Vorgänge, von vornherein vorgesehene Reversibilität sowie menschliche Kontrollpunkte bei irreversiblen Aktionen. Ihre Umsetzung ist nicht komplex. Sie sind lediglich nicht das Erste, woran Teams denken, wenn der Agent bereits bereitsteht und die Aufgabe direkt vor ihnen liegt.
Jer forderte, dass die Enforcement-Ebene in der Infrastruktur und nicht in den Anweisungen angesiedelt sein solle. Dies ist kein Feature-Wunsch, den die Anbieter erfüllen müssen. Es handelt sich um eine Architekturentscheidung, die er bereits vor diesen neun Sekunden hätte treffen können.
Dieser Beitrag ist Teil einer Reihe darüber, wie ich in der Praxis mit KI-Entwicklungsteams zusammenarbeite. Im vorherigen Beitrag, „Die Zukunft des Analytics Engineering“, wurden die Argumente für den Übergang zu agentenbasierten Arbeitsabläufen dargelegt. In diesem Beitrag geht es darum, wie man diesen Übergang vollzieht, ohne dabei alles zu verlieren.
Verfasst von
Ricardo Granados
Contact