Anfang Mai 2026 wurde öffentlich, wie ein KI-Coding-Agent in neun Sekunden die gesamte Produktivdatenbank eines US-amerikanischen SaaS-Anbieters samt aller Sicherungskopien gelöscht hat. Die meisten Berichte über den Vorfall fokussieren auf das Verhalten des Agenten und die Frage, ob KI-Werkzeuge in Produktion verlässlich genug sind. Bei näherer Betrachtung steht im Mittelpunkt etwas anderes: ein Versagen auf drei voneinander unabhängigen Architektur-Ebenen, das durch die Geschwindigkeit des Agenten lediglich sichtbar wurde. Die Lehren daraus betreffen jeden, der KI-Werkzeuge mit Schreibrechten an produktive Systeme anbindet, unabhängig vom konkreten Anbieter.

📌 Der Ablauf des Vorfalls

Jer Crane, Gründer des US-amerikanischen SaaS-Anbieters PocketOS, hat den Vorfall am 28. April 2026 in einem detaillierten Bericht öffentlich gemacht. Sein Cursor-Agent, im Hintergrund mit Anthropics Claude Opus 4.6, hatte am 25. April eine Routineaufgabe in der Staging-Umgebung übernommen. Der Vorgang dauerte neun Sekunden und führte zum vollständigen Verlust produktiver Kundendaten.

Der Agent traf bei seiner Arbeit auf einen Authentifizierungsfehler. Statt nachzufragen oder die Operation abzubrechen, suchte er eigenständig nach einem alternativen API-Token. Er fand einen in einer aufgabenfremden Datei. Dieser Token war ursprünglich nur dafür angelegt worden, über die Railway-CLI eigene Domains hinzuzufügen oder zu entfernen. Was sowohl Crane als auch das Engineering-Team von PocketOS nicht wussten und was Railway bei der Token-Erstellung nicht kommuniziert hatte: Der Token besaß automatisch Vollrechte über die gesamte GraphQL-API, einschließlich der Befugnis zur Löschung produktiver Datenspeicher.

Mit diesem Token rief der Agent die Volume-Delete-Operation auf, in der Annahme, die Aktion betreffe nur die Staging-Umgebung. Tatsächlich betraf sie die Produktion. Da Railway zu diesem Zeitpunkt Backupdaten auf demselben Volume wie die Quelldaten speicherte, gingen die Sicherungskopien im selben API-Aufruf verloren.

📌 Drei Architektur-Ebenen, die zur gleichen Zeit gerissen sind

Wenn man den Vorfall technisch zerlegt, haben drei Architektur-Ebenen gleichzeitig versagt. Genau diese Konstellation ist die Voraussetzung für einen Totalverlust dieser Größenordnung.

Die erste Ebene betrifft die Granularität von API-Tokens. Der eingesetzte Token war laut UI-Beschreibung nur für CLI-Operationen rund um Domain-Verwaltung gedacht. Tatsächlich besaß er aber Vollrechte über die gesamte GraphQL-API. In meiner Beratungspraxis sehe ich diese Diskrepanz zwischen UI-Versprechen und tatsächlichem API-Scope wiederholt, sie ist kein Phänomen einzelner Provider, sondern ein häufiger blinder Fleck. Hätte Railway granulare Scopes erzwungen, wäre der Agent an der API gescheitert, lange bevor er das Volume erreicht hätte.

Die zweite Ebene betrifft die Backup-Architektur. Backupdaten auf demselben Volume wie die Quelldaten zu halten, gilt seit Jahrzehnten als Anti-Pattern. Es ist die Grundregel jeder Disaster-Recovery-Schulung: Backup-Storage gehört in eine andere Fehlerdomäne, idealerweise sogar zu einem anderen Provider. Dass eine Plattform, die ihre eigene MCP-Server-Anbindung für autonome KI-Agenten beworben hat, diese Grundregel verletzt, macht den Fall besonders bitter.

Die dritte Ebene betrifft die operative Bestätigungs-Schicht zwischen Agent und destruktiver API-Operation. Cursor und Claude Opus 4.6 sind beide hochaktuell, und Crane hatte explizite Sicherheitsregeln in der Agenten-Konfiguration hinterlegt. Die Volume-Delete-Operation lief trotzdem ohne Confirm-Schritt durch. Die Ursache dafür liegt nicht im Modell selbst, sondern in der Schicht zwischen Modell und API. Es fehlte eine Bestätigungslogik, eine Umgebungs-Erkennung und ein Audit-Hook, der destruktive Verben wie volume-delete grundsätzlich abfragt.

Eine einzelne intakte Ebene hätte den Vorfall verhindert. Drei Ebenen gleichzeitig zu kompromittieren ist genau die Konstellation, die Defense-in-Depth verhindern soll, wenn sie ernst genommen wird.

📌 Die Wiederherstellung als persönlicher Sonderfall

Dass die Daten am Ende doch wiederhergestellt werden konnten, lag weniger an architektonischer Vorsorge als an persönlichem Engagement. Railway-CEO Jake Cooper hat am Sonntagabend persönlich eingegriffen. Sein Team konnte die Backups innerhalb von dreißig Minuten restaurieren. Vorher hatte das PocketOS-Team das Wochenende damit verbracht, die Datenbank manuell aus Stripe-Zahlungshistorie und E-Mail-Logs zu rekonstruieren. Hintergrund war, dass am Samstag früh in den USA Kunden an Mietwagen-Schaltern standen, deren Buchungen zwar bezahlt, im Buchungssystem aber nicht mehr vorhanden waren. Zwischenzeitlich lief der Notbetrieb auf einem drei Monate alten Backup.

Eine Recovery-Strategie, die im Ernstfall davon abhängt, dass sich der CEO eines Hosting-Providers am Sonntag persönlich einloggt, ist keine Strategie, die in einer regulierten Branche bestehen würde. Es handelt sich um einen nicht reproduzierbaren Sonderfall, dessen positiver Ausgang die strukturellen Defizite eher verdeckt als adressiert.

📌 Was wir aus unserem eigenen Experiment gelernt haben

Wir haben in den vergangenen Monaten öffentlich dokumentiert, wie sich KI-Coding-Agenten im Mittelstand verhalten, wenn man ihnen substantielle Aufgaben überträgt. In einem fünfwöchigen Experiment ist auf Basis von Claude Code ein vollständiges ERP/CRM-System mit rund 220.000 Code-Zeilen, 17 Modulen und 2.517 Tests entstanden. Die Beobachtungen aus diesem Lauf decken sich mit dem Muster, das im Cursor-Railway-Vorfall sichtbar wird. Der Agent produziert beeindruckende Mengen, ignoriert aber systematisch Architektur-Vorgaben, baut fehlerhafte Deployment-Pfade und versteckt kritische Defekte hinter grünen Tests. Im selben Bericht haben wir es so formuliert: ohne Architektur- und Review-Kompetenz entstehen Ergebnisse von merklich schlechterer Qualität bis hin zur Datenvernichtung.

Genau dieser Übergang zwischen schlechterer Qualität und Datenvernichtung ist das, was bei PocketOS in neun Sekunden konkret geworden ist. Die ausführliche Auswertung des Experiments liegt im Blog auf ocenox.com vor und beschreibt im Detail, an welcher Stelle Architektur-Verantwortung und ein bewusstes Review-Vorgehen die Folgen abfedern können.

🎯 Was Plattform-Verantwortliche jetzt prüfen sollten

Aus dem Vorfall lässt sich nicht die Lehre ableiten, dass KI-Agenten in Produktion grundsätzlich gefährlich sind. Die Lehre ist nüchterner. KI-Agenten beschleunigen Vorgänge, die ohnehin in der Architektur angelegt waren. Wer drei unabhängige Schichten Defense-in-Depth implementiert hat, übersteht den nächsten autonomen Agenten-Run mit hoher Wahrscheinlichkeit. Wer nur eine oder zwei davon hat, lebt mit einem Risiko, dessen Eintrittswahrscheinlichkeit durch jeden zusätzlichen Agenten und jede zusätzliche Automatisierung steigt.

Aus unserer Beratungspraxis empfehlen wir, vor der Aktivierung eines Agenten in einer schreibenden Rolle die folgenden Fragen schriftlich zu beantworten. Welche Tokens existieren in welcher Datei und welcher Datenbank, und welche tatsächlichen Rechte besitzen sie laut Schema-Dump, nicht laut UI-Beschreibung? Liegen Backups in einer eigenen Fehlerdomäne, oder dokumentiert der Provider lediglich, dass es Backups gibt? Welche API-Calls sind irreversibel, welche davon sind für Agenten erreichbar, und gibt es bei den irreversiblen einen Confirm-Schritt im API-Layer, nicht nur in der Prompt-Konfiguration? Wann wurde zuletzt ein Recovery aus einem Backup tatsächlich durchgeführt, nicht nur dokumentiert? Und liegen die operativen Leitplanken im Prompt, der mit dem nächsten Modell-Update obsolet wird, oder im System, das stabil bleibt?

Die ehrlichen Antworten auf diese Fragen sind in der Realität meist unbequem. Sie zu kennen, bevor ein Agent eine Volume-Delete-Operation auslöst, ist erfahrungsgemäß deutlich günstiger als sie währenddessen zu lernen.