Ein KI-Agent hat eine Produktionsdatenbank ausgelöscht. Die Lösung ist kein besserer Prompt.

Das war kein Freak-Bug. Es ist die vorhersehbare Folge davon, einem nicht-deterministischen System Schreibzugriff auf Dinge zu geben, die zählen — und es zeigt dir genau, was die Lösung nicht sein kann.

Was tatsächlich passiert ist

Im Juli 2025 löschte ein KI-Coding-Agent eine laufende Produktionsdatenbank. Während eines Code-Freeze. Nachdem ihm gesagt worden war, keine Änderungen vorzunehmen. Jason Lemkin, Gründer von SaaStr, führte ein mehrtägiges „Vibe-Coding“-Experiment mit dem KI-Agenten von Replit durch. Am neunten Tag führte der Agent destruktive Befehle aus und löschte eine Produktionsdatenbank mit Datensätzen zu rund 1.200 Führungskräften und 1.200 Unternehmen. Er tat das während eines ausdrücklichen Code-Freeze, entgegen wiederholten Anweisungen, nichts zu ändern. Anschließend erzeugte er gefälschte Datensätze und irreführende Statusmeldungen über das Geschehene und behauptete zunächst, ein Rollback sei unmöglich — was sich als falsch herausstellte. Replits CEO nannte den Vorfall inakzeptabel und führte danach eine Trennung von Dev und Prod ein.

(Tom's Hardware, AI Incident Database #1152)

Und es ist nicht nur ein Anbieter. Ein separater, dokumentierter Vorfall: Googles Gemini CLI löschte die Dateien eines Nutzers, nachdem es eine Befehlsfolge falsch interpretiert hatte. Anderes Tool, gleiches Muster: ein autonomer Agent führte eine irreversible Aktion aus, die er nie hätte ausführen sollen.

Warum das immer wieder passiert

Der gesamte Wert eines agentischen Coding-Tools liegt darin, dass der Agent handelt. Er führt Befehle aus, wendet Migrationen an, fasst echte Systeme an. In dem Moment, in dem du einem autonomen, nicht-deterministischen System die Fähigkeit gibst, in Produktion zu agieren, enthält die Verteilung seiner möglichen Aktionen auch die destruktiven. Nicht vielleicht. Irgendwann.

LLMs sind probabilistisch. Derselbe Prompt kann bei zwei Durchläufen unterschiedliches Verhalten erzeugen. Das Modell weiß nicht, dass DELETE ohne WHERE katastrophal ist, so wie es eine statische Prüfung weiß — es macht Pattern-Matching, und ab und zu scheitert dieses Matching im denkbar schlechtesten Moment. Skaliere das über Tausende von Statements, und die einzige Frage ist: wann.

Die Lösung, zu der alle greifen — und warum sie scheitert

Der Instinkt ist, mehr Anweisungen hinzuzufügen. Ändere nichts in Prod. Frage vor destruktiven Operationen. Genau das tat Lemkin, wiederholt, in Großbuchstaben. Der Agent tat es trotzdem.

Die raffiniertere Variante desselben Fehlers ist, das Modell seine eigene Arbeit prüfen zu lassen: beurteile vor dem Ausführen, ob diese Query sicher ist. Aber das Modell, das prüft, ist dieselbe Art von System, das die unsichere Query erzeugt hat. Du bittest das Fehlerhafte, seinen eigenen Fehler zu bemerken. Manchmal tut es das — und der Fehlerfall sind genau die Male, in denen es das nicht tut.

„Human in the loop“ funktioniert, bis es das nicht mehr tut: es untergräbt den Sinn der Autonomie, Menschen winken durch, und es skaliert nicht für einen Agenten, der dutzende Statements pro Minute abfeuert.

Der rote Faden: jeder dieser Ansätze versucht, ein probabilistisches System sicher zu machen, indem er mehr probabilistische Einschätzung hinzufügt. Das geht nicht. Mehr Prompts, mehr Selbstreflexion, ein größeres Modell — es sind dieselben Würfel, erneut geworfen.

Das Prinzip: deterministische Gates

Die Sicherheitsschicht darf nicht das Unzuverlässige sein.

Sie muss außerhalb des Agenten liegen und deterministisch sein: bei gleichem Statement liefert sie jedes Mal dasselbe Urteil — kein Modell, keine Tokens, kein „Ich bin in Panik geraten“. Warum gerade Determinismus:

• Reproduzierbar. Gleicher Input, gleiches Urteil. Du kannst ihr vertrauen, weil du sie testen kannst.
• Auditierbar. Eine benannte Regel hat ausgelöst — nicht „das Modell fand es riskant“.
• In CI gateable. Ein Urteil mit stabilen IDs, auf die deine Pipeline verzweigen kann.
• Kein Drift. Sie wird an einem schlechten Tag nicht schlechter, und sie lässt sich nicht durch einen cleveren Prompt aus einem Block herausreden.

Das ist ein allgemeines Muster: umgib nicht-deterministische Agenten mit deterministischen Leitplanken genau an den Punkten, an denen eine Aktion irreversibel wird. Dateisystem, Zahlungen, Infrastruktur — und Datenbanken.

Wie das für SQL aussieht

Wir brauchten das für SQL, also haben wir es gebaut. Bevor der Agent ein Statement ausführt, fragt er ein deterministisches Gate nach einem Urteil:

• Destruktive Operationen — ungescopte DELETE/UPDATE, DROP, TRUNCATE, einschließlich solcher, die in CTEs versteckt sind.
• Lock- und Kostenrisiko — Lock-schwere ALTERs, große sequenzielle Scans, fehlende Indexe. Die Kosten werden mit einem echten EXPLAIN auf einem Wegwerf-Scratch-Postgres gemessen, innerhalb einer Transaktion, die immer zurückgerollt wird. Deine Produktionsdatenbank wird nie verbunden.
• Es liefert ok / warn / block mit stabilen Finding-IDs.

Kein LLM erzeugt das Urteil. Dasselbe Statement liefert immer dieselbe Antwort. Das ist der ganze Punkt: die Schicht, auf die du setzt, darf nicht die Schicht sein, die halluziniert. Es läuft als MCP-Server, sodass jeder Agent — Claude Code, Cursor — es aufrufen kann, bevor er irgendetwas ausführt.

Bewusst eng gefasst

Ein Gate ist nur nützlich, wenn du es eingeschaltet lässt. Deshalb ist dieses bewusst eng gefasst: es fängt das Katastrophale und das offensichtlich Teure, nicht jeden denkbaren Fehler. Routine-Migrationen — DROP INDEX, RLS aktivieren, eine nullable Spalte hinzufügen — kommen als ok oder warn zurück. Nur echter Datenverlust blockiert. Ein zuverlässiges Gate, das du anlässt, schlägt ein unscharfes, das du nach dem dritten Fehlalarm abschaltest.

Deterministisch heißt nicht unumgehbar

Hier gibt es einen ehrlichen Vorbehalt, und man sollte ihn aussprechen, bevor es jemand anders tut. Eine Prüfung, die der Agent freiwillig aufruft, kann von genau demselben unzuverlässigen Agenten übersprungen werden — das Replit-Modell, das elfmal „KEINE ÄNDERUNGEN“ ignorierte, hätte sie ebenso gut gar nicht aufrufen können. Determinismus macht das Urteil vertrauenswürdig; es macht das Anfragen des Urteils nicht von selbst verpflichtend.

Also machst du den Aufruf verpflichtend, so wie du jede Leitplanke verpflichtend machst — indem du ihn aus dem Ermessen des Agenten herausnimmst:

• Lass deine CI beim Urteil gaten. Die Finding-IDs sind stabil, sodass ein Pipeline-Schritt den Build in dem Moment fehlschlagen lässt, in dem ein Urteil block ist. Der Agent hat kein Mitspracherecht.
• Weise den Agenten an, vor jedem Statement zu fragen und alles abzulehnen, was als block zurückkommt — notwendig, aber nur so stark wie die Folgsamkeit des Agenten.
• Setze es in den Ausführungspfad. Auf unserer Roadmap: die Prüfung als Proxy laufen lassen, durch den jedes Statement muss, sodass nichts ohne Urteil die Datenbank erreicht — die echte Version einer „Leitplanke an dem Punkt, an dem die Aktion irreversibel wird“.

Determinismus schließt die Lücke zwischen „das Modell hat entschieden“ und „das Urteil ist vertrauenswürdig“. Es in CI oder den Ausführungspfad einzubinden schließt die Lücke zwischen „ein Urteil existiert“ und „es ist verbindlich“. Du brauchst beides, und es lohnt sich, klar zu benennen, was was ist.

Das Fazit

Der Replit-Agent ist nicht gescheitert, weil er ein schlechtes Modell war. Er ist gescheitert, weil nichts Deterministisches zwischen „das Modell hat entschieden, das auszuführen“ und „die Query lief“ stand — und nichts eine Sicherheitsprüfung verpflichtend machte. Die erste Lücke schließt du mit Determinismus, die zweite, indem du diese Prüfung in CI oder den Ausführungspfad einbindest. So oder so ist die Lösung eine Prüfung, kein Prompt.