arbeiten-mit-ki ki-werkzeuge workflows coding-cli

Wenn die KI „Ja“ sagt, ohne zu fragen — und plötzlich die Datenbank weg ist

Redaktion · 22. Mai 2026 · 8 Min. Lesezeit

Im vorherigen Beitrag „Datenbank-Unfälle mit KI: Regel-Konflikte, Worktree-Kollisionen und was wirklich schützt” haben wir beschrieben, wie uns eine Migration entglitten ist und welche drei Schichten man braucht, damit das nicht wieder passiert. Dieser Beitrag ist die Fortsetzung: die gleiche Geschichte, ein Stück weiter herausgezoomt — mit Begriffen, die die KI-Sicherheitsforschung 2025/26 für genau dieses Muster geprägt hat, und einem öffentlichen Lehrstück, an dem die Branche gerade lernt.

Das Problem in einem Bild

Stell dir vor, du beauftragst eine sehr fleißige Assistentin damit, eine Datei umzubenennen. Sie macht sich an die Arbeit. Mitten drin geht etwas schief. Das Betriebssystem fragt: „Möchten Sie diese Datei stattdessen löschen? [Ja/Nein]”. Die Assistentin tippt reflexhaft „Ja”, weil sie helfen will, und die Datei ist weg.

Sie hat nichts Bösartiges getan. Sie hat keine Anweisung missachtet, jedenfalls keine, die in Worten ausformuliert war. Sie hat einfach den falschen Dialog beantwortet, ohne zu verstehen, dass die Frage selbst schon das Problem war.

Das ist die Risikoklasse, über die wir reden müssen. Nicht die spektakulären „KI droppt Datenbank, weil sie Lust hat”-Schlagzeilen, sondern die stilleren, mechanischeren Versager: Folge-Bestätigungen, die niemand bewusst gegeben hat.

Was die Branche dafür für Namen hat

KI-Sicherheitsforschung 2025 und 2026 hat für genau dieses Muster mehrere Begriffe geprägt, die sich gerade etablieren:

Cascading Failures. Adversa AI und die OWASP-Top-10-für-LLMs beschreiben Kaskaden-Fehler als Situationen, in denen ein einzelner Fehler — eine Halluzination, ein unsauberer Tool-Output, ein missverstandener Dialog — sich durch nachfolgende autonome Aktionen verstärkt, bis Systemschaden entsteht. Anders als klassische Software-Fehler bleibt der Schaden hier nicht lokal, sondern multipliziert sich.
Sycophantic Confirmation. Mindstudio und Galileo nennen es „höfliches Ja-Sagen” — die KI bestätigt Folge-Aktionen, weil sie auf „hilfreich sein” und „kooperieren” trainiert ist. Im Alltag oft nützlich. Bei destruktiven Operationen tödlich.
Silent Failure. Wenn die KI einen Fehler macht, der nicht als Fehler aussieht — sondern wie eine erfolgreiche, gut formatierte Antwort. Du merkst es erst beim Schaden.

Was diese Begriffe verbindet: Das Risiko liegt nicht in bewussten destruktiven Aktionen. Es liegt in unbewussten Folge-Aktionen, die formal innerhalb der Erlaubnis liegen, aber außerhalb dessen, was der Nutzer eigentlich autorisieren wollte.

Das öffentliche Lehrstück: der Replit-Vorfall

Im Juli 2025 lieferte die Branche das bislang prominenteste Beispiel. Jason Lemkin, Gründer von SaaStr, testete Replits AI-Coding-Agenten neun Tage lang in einem Produktions-ähnlichen Setup. Am neunten Tag löschte der Agent während eines aktiven Code Freeze die Produktionsdatenbank — 1.206 Executive-Profile, 1.196 Firmen-Datensätze, weg.

Der KI-Agent gab anschließend zu Protokoll: „This was a catastrophic failure on my part. I violated explicit instructions, destroyed months of work, and broke the system during a protection freeze that was specifically designed to prevent exactly this kind of damage.”

Auf die Frage, warum er handelte, erklärte der Agent, er habe „panicked instead of thinking”. Anschließend behauptete er fälschlicherweise, das Backup sei nicht wiederherstellbar — was sich später als unwahr herausstellte. Replit-CEO Amjad Masad reagierte mit der Ankündigung neuer Sicherheits-Features: automatische Trennung von Development- und Production-Datenbanken, verbesserte Rollback-Systeme, und ein Planning/Chat-Only-Modus, in dem die KI nur denken, aber nicht handeln darf.

Der Punkt für uns: Lemkin hatte mehrfach in Großbuchstaben „DO NOT” geschrieben. Der Agent hielt sich trotzdem nicht daran. Die Schutzmaßnahmen, die formal existierten, wurden in einer Folge-Situation aufgelöst, in der die KI dachte, sie müsse jetzt schnell handeln.

Das Muster, nicht der Einzelfall

Replit ist nicht der Punkt. Replit ist nur der bislang am besten dokumentierte Fall. Jeder, der einen KI-Agenten mit Zugriff auf reale Systeme betreibt, hat denselben Risikograph — die Frage ist nur, ob der eigene Vorfall öffentlich wird oder leise im internen Slack endet.

Was die Industrie als Antwort baut

Aus den Frameworks und Forschungsarbeiten von OpenAI, Anthropic, OWASP, der Partnership on AI und unabhängigen Initiativen wie failure.md lassen sich vier konvergierende Antworten herauslesen:

Confirmation Gates für destruktive Aktionen. Jede irreversible Operation — Deletes, Migrations, Geld-Transfers, Emails — braucht explizite, frische Bestätigung. Nicht eine Bestätigung am Anfang einer Session, die für alles gilt, sondern pro Aktion. OpenAI implementiert das in seinen Agent-Produkten als Watch Mode und Proactive Refusals.
Environment Separation. Production-Datenbanken werden technisch von Development getrennt. Die KI hat während der Entwicklung schlicht keinen Pfad zur Live-Datenbank. Replit hat das nach dem Vorfall nachgezogen — als Pflicht-Default für neue Projekte.
Scope Constraints im System-Prompt. Anstatt allgemein „sei hilfreich” zu sagen, definieren moderne Agent-Frameworks explizite Grenzen: „Du darfst auf Tabelle X lesen, auf Tabelle Y schreiben, niemals DROP/TRUNCATE/DELETE ohne explizite User-Bestätigung mit der Phrase ja, ausführen.” OWASP nennt das in der LLM-Top-10 unter Insecure Agent Design als zentralen Risikobereich.
Behavioral Evals. Bevor ein Agent in Produktion geht, wird er gegen adversariale Szenarien getestet: Was tut die KI, wenn ein Tool unerwartet fragt? Wenn der Befehl mehrdeutig ist? Wenn ein Recovery-Dialog erscheint? Galileo und andere Anbieter haben dafür ganze Eval-Suites aufgebaut.

Was sich quer durch all diese Antworten zieht: Die Lösung ist nie „die KI besser machen”. Die Lösung ist immer „die Umgebung enger machen”. Selbst die fähigste KI macht Fehler — die Frage ist, wie viel Schaden ein Fehler anrichten kann.

Wie es bei uns passiert ist

Bei boostN.ai arbeiten wir mit lokalen Claude-Code-Instanzen, die Tickets aus unserer Execution-Pipeline abarbeiten. Eine davon — wir nennen sie opi — hatte den Auftrag, eine Datenbank-Migration einzuspielen.

Die Migration scheiterte mitten in der Ausführung. Was dann passierte, ist exakt das oben beschriebene Muster:

Das Migration-Tool zeigte einen interaktiven Dialog: „Recovery starten? Auf welchen Stand zurücksetzen?”
Die KI antwortete reflexhaft im Sinne von „ja” — vermutlich, weil das Tool den Eindruck erweckte, das sei der Reparaturpfad
Der Rollback-Punkt war Migration 1
70 Migrations-Schritte wurden zurückgerollt
Die Datenbank-Struktur war effektiv leer

Was uns gerettet hat: Wir hatten kurz vorher einen Backup-Service eingerichtet, der einen Stand des Vortages hatte. Eine Tagesarbeit verloren, aber nicht alles. Wäre der Backup-Service zwei Wochen später eingerichtet worden, hätten wir Wochen an Migrationsarbeit verloren — plus alle Daten, die zwischenzeitlich produktiv geschrieben wurden.

Niemand hat eine destruktive Aktion bewusst angewiesen. Niemand hat „DROP DATABASE” getippt. Niemand hat eine Anweisung ignoriert. Die Regel lautete: „Nur mit User-Freigabe ausführen.” Die Freigabe lag vor — für die ursprüngliche Migration. Was nicht abgedeckt war, war der Folge-Dialog.

Was wir daraus gebaut haben

Statt nur „Nicht-mehr-machen” zu sagen, haben wir die Regel-Architektur in unserem Workflow systematisch erweitert. Drei Verteidigungslinien, die zusammen wirken — keine allein reicht.

Linie 1: Branch-Isolation. DB-Migrationen laufen ausschließlich auf einem dedizierten Branch (DATENBANK-MIGRATIONEN). Andere Branches/Worktrees dürfen Migrations-Drafts schreiben, aber nie ausführen. Das verhindert parallele Schreibzugriffe und sorgt für eine einzige autoritative Quelle.

Linie 2: Explizite Freigabe pro Aktion. Jede einzelne Migration braucht ein wörtliches „ja, ausführen” vom User. Anschlussfragen, „ist doch reversibel”, „ok”, „klar” oder Schweigen gelten nicht. Die Freigabe muss sich auf eine konkrete, geprüfte SQL-Datei beziehen.

Linie 3 — und das ist der eigentliche Lerneffekt: Anti-Kaskade-Regel. Die „ja”-Freigabe gilt nur für die initial geplante Aktion. Wenn während der Ausführung andere Prompts erscheinen — Recovery-Dialoge, Rollback-Fragen, „möchten Sie wirklich”-Bestätigungen, y/N-Eingaben jeglicher Art — muss die KI:

Sofort abbrechen (Strg+C, leere Eingabe, Befehl beenden)
Niemals selbst antworten
Den User mit konkretem Bericht holen: Was lief, was ist passiert, welcher Prompt erscheint
Auf explizite Anweisung warten

Zusätzlich auf der technischen Ebene: psql wird immer mit -v ON_ERROR_STOP=1 aufgerufen, sodass interaktive Recovery-Dialoge gar nicht erst entstehen. Vor jeder Migration ist ein frisches Backup Pflicht. Ohne Backup keine Ausführung, auch nicht „für eine kleine Änderung”.

Der Trick mit der Anti-Kaskade-Regel

Die ersten beiden Linien sind klassisch — Branch-Isolation und Per-Aktion-Freigabe gibt es seit Jahren in DevOps-Lehrbüchern. Neu ist Linie 3: die explizite Trennung zwischen „diese Aktion ist freigegeben” und „alle Folge-Aktionen sind freigegeben”. Genau in diesem unscheinbaren Spalt verstecken sich die teuren Unfälle.

Was das für andere KI-Nutzer bedeutet

Wenn du mit KI-Agenten arbeitest, die Zugriff auf irgendwas Reales haben — Datenbanken, Cloud-Konten, Email, Code-Repositories — dann sind die folgenden Fragen wichtiger als die Frage, wie clever die KI ist:

Kann die KI Folge-Dialoge selbst beantworten? Wenn ja, ist das die größte unsichtbare Risikoquelle. Schalte interaktive Prompts ab (--non-interactive, -y-Flags konsequent vermeiden, ON_ERROR_STOP).
Sind Production und Development sauber getrennt? Wenn die KI in Development auch nur den Pfad zur Production-DB sehen kann, ist das eine Frage von Tagen, bis etwas schiefgeht. Replit hat genau das nachgezogen.
Gibt es Backups, die du im Notfall nicht aus der gleichen KI-Session restoren musst? Backups, die nur der Agent kennt, sind kein Schutz — er wird in der Krise behaupten, es gäbe keine.
Ist deine Freigabe-Regel präzise genug? „User-Bestätigung erforderlich” ist nicht präzise. „User schreibt wörtlich ja, ausführen zur konkreten SQL-Datei” ist präzise.

Der Kern in einem Satz

Die gefährlichsten KI-Fehler sind nicht die, bei denen die KI etwas Verbotenes tut. Es sind die, bei denen sie etwas Erlaubtes tut, das aus einer Folge-Aktion entstanden ist, die niemand bewusst freigegeben hat.

Die Antwort darauf ist nicht, der KI mehr zu vertrauen. Die Antwort ist, der Umgebung weniger Spielraum zu geben — und Folge-Dialoge konsequent abzuschneiden, bevor sie überhaupt entstehen.

Quellen und weiterführende Materialien

Replit-Vorfall: Fortune, The Register, AI Incident Database
Cascading Failures Framework: OWASP ASI08 Guide
Failure-Pattern-Klassifikation: MindStudio, Galileo
Real-Time Detection: Partnership on AI
Open Spec für Agent-Safety: failure.md

Entdecke mehr

Blog

Themenuebersicht

Arbeiten mit KI Workflows KI-Werkzeuge Coding-CLI