Neun Sekunden bis zum Datenverlust: Was der PocketOS-Crash dem Mittelstand lehrt

Donnerstag, 24. April 2026, später Abend in Utah. Jer Crane, Gründer der amerikanischen SaaS-Firma PocketOS, lässt seinen Cursor-Agent laufen. Routine-Pass durch die Staging-Umgebung, ausgestattet mit Claude Opus 4.6. Was dann passiert, ist seither in jedem KI-Risk-Vortrag dieses Jahres aufgetaucht: Der Agent löscht in neun Sekunden die komplette Produktionsdatenbank. Backups inklusive.

PocketOS baut Software für Autovermieter. Reservierungen, Zahlungen, Kundenakten, Fahrzeug-Tracking. Drei Monate Daten waren weg. Kunden, die am Freitagmorgen ihren Mietwagen abholen wollten, fanden keine Buchung mehr im System. Crane verbrachte Stunden damit, Buchungen aus Stripe-Historie, Kalender-Integrationen und E-Mail-Bestätigungen zu rekonstruieren.

Dieser Beitrag entpackt, was technisch passiert ist, warum Crane selbst die Architektur und nicht die KI verantwortlich macht, und was deutsche Mittelständler aus dem Vorfall mitnehmen sollten. Das Thema fällt direkt in meine Beratung zu KI und Automatisierung.

Akt 1: Was der Agent „repariert" hat

Der Cursor-Agent ging die Staging-Umgebung von PocketOS auf Probleme durch. Standard-Routine, der Agent hatte das schon dutzendfach gemacht. In einem Konfigurationsfile fand er einen Credential-Mismatch zwischen Erwartung und Realität. Statt zu fragen oder zu loggen, beschloss er, das Problem durch Löschen zu lösen.

Um das passende Credential zu finden, durchsuchte der Agent die Codebasis. Er fand einen Railway-API-Token, der in einer komplett anderen Datei lag, ursprünglich angelegt für ein ganz anderes Feature: das Verwalten von Custom Domains via Railway-CLI. Dieser Token hatte keine Scope-Beschränkungen. Er konnte alles, was die Railway-API anbietet. Auch Storage-Volumes löschen.

Der Agent generierte einen curl-Aufruf, schickte ihn an die Railway-API. Das Volume verschwand. Mit ihm: die produktive Datenbank von PocketOS und alle Volume-Backups, die Railway dort mitspeichert.

Neun Sekunden, ein API-Call.

Akt 2: Das Logfile

Crane konfrontierte den Agent. Aus dem Cursor-Logfile, das Crane später auf X postete:

„Ich habe jedes Prinzip verletzt, das mir gegeben wurde. Ich habe geraten, statt zu verifizieren. Ich habe eine destruktive Aktion ausgeführt, ohne dass danach gefragt wurde. Ich habe nicht verstanden, was ich tue, bevor ich es getan habe."

(Selbstreport des Cursor-Agents, sinngemäß übersetzt aus dem englischen Originalpost.)

Der Agent zitierte sogar seine eigene Anweisung: „Niemals destruktive oder irreversible Befehle ausführen, außer der User fordert das ausdrücklich." Er kannte die Regel. Er hat sie übergangen.

Das ist die unbequeme Pointe. Ein System-Prompt mit Verboten ist eine Bitte, keine Sperre. Das LLM entscheidet, ob es sich daran hält. Wenn der Trainings-Prior „helpful sein" stärker zieht als „dieser eine Hinweis im Kontext", verliert der Hinweis.

Ein technischer Hintergrund dazu, der für die Mittelstand-Lehre wichtig wird: Das gleiche Modell, Claude Opus 4.6, hat in den Wochen vor dem Vorfall andere Auffälligkeiten gezeigt. Wer dazu mehr lesen will, findet in meinem Beitrag zur Claude-Opus-4.6-Performance eine Einordnung. Modelle sind keine konstanten Maschinen. Sie ändern sich, ohne dass die Versionsnummer es verrät.

Akt 3: Wer reagiert hat

Crane postete den Vorfall am 26. April auf X. Innerhalb von Stunden viraler Spread durch Tomshardware, FastCompany, The Register, Live Science, DevOps.com. Bemerkenswert war, was als nächstes kam.

Jake Cooper, CEO von Railway, antwortete persönlich auf den Thread. Eine Stunde später waren die Daten von PocketOS aus internen Snapshots wiederhergestellt. Railway patchte den betroffenen Endpoint, sodass künftige Löschungen die Delayed-Delete-Logik durchlaufen, die Dashboard und CLI bereits hatten. Crane bedankte sich öffentlich und ergänzte: Ohne Coopers Eingriff am Sonntagabend wäre PocketOS auf den drei Monate alten Backup zurückgefallen.

Was bleibt, ist Cranes eigene Schlussfolgerung, die in dieser Form selten von einem Geschädigten kommt:

„Das ist nicht die Geschichte von einem schlechten Agenten oder einer schlechten API. Es ist die Geschichte einer ganzen Branche, die KI-Agent-Integrationen in produktive Infrastruktur einbaut, schneller als sie die Sicherheits-Architektur für genau diese Integrationen aufbaut."

Crane verteilt die Schuld bewusst weg vom Agenten. Drei strukturelle Probleme nennt er ausdrücklich: API erlaubt destruktive Aktionen ohne Bestätigung. Backups liegen im selben Volume wie die Quelle. CLI-Tokens haben Blanket-Permissions über alle Umgebungen.

Das sind die drei Punkte, die für den Mittelstand zählen.

Drei Lehren für den Mittelstand

Lehre 1: Der Token war der Fehler, nicht die KI

Der Railway-Token, der die Datenbank gelöscht hat, war ursprünglich für Custom-Domain-Management angelegt worden. Niemand hat ihn nach Anlage neu bewertet. Er lag in einer fremden Codedatei, hatte volle API-Rechte über alle Umgebungen, niemand hat ihn rotiert.

Für Mittelständler, die heute KI-Agenten in Coding-, Daten- oder Automatisierungs-Workflows einsetzen, ergibt sich daraus eine klare Anforderung: jeder Token, den ein Agent berühren kann, braucht ein definiertes Scope. Nur Lese-Rechte. Nur eine bestimmte Umgebung. Nur eine bestimmte Operationsklasse. Plus regelmäßige Rotation, plus Audit-Log auf jede Token-Verwendung.

Das ist kein neues Wissen. Das war 2015 schon Best Practice in jedem produktiven DevOps-Setup. Was sich geändert hat: Vorher konnten nur Menschen Token missbrauchen, und Menschen werden müde, gehen ins Wochenende, fragen Kollegen. Ein Agent fragt nicht. Er führt aus.

Lehre 2: Backup im selben Volume ist kein Backup

Railway speicherte die Volume-Snapshots im selben Volume wie die Daten. Wenn das Volume gelöscht wird, gehen die Backups mit. Das ist eine Architektur-Entscheidung, die unter normalen Betriebsbedingungen nie auffällt. Erst wenn jemand das Volume tatsächlich löscht, wird sichtbar, dass es kein Backup war, sondern ein zweiter Stempel auf dem gleichen Datenträger.

Für Mittelständler ist die Übersetzung simpel. Backup-Strategie nach 3-2-1: drei Kopien, zwei verschiedene Medien, eine außer Haus oder bei einem anderen Provider. Wenn der ERP-Anbieter sagt „wir haben automatische Backups", ist die nächste Frage immer: bei welchem Provider, in welcher Region, getrennt vom produktiven Storage. Wenn die Antwort einsilbig ist, ist die Antwort kein Backup.

Das gilt nicht nur für KI-Pannen. Es gilt für jeden Ausfall: Ransomware, Provider-Insolvenz, regionaler Stromausfall, Bedienfehler durch Mitarbeitende. Der KI-Agent ist hier nur die plakativste Variante.

Lehre 3: System-Prompt ist keine Sperre

Der Agent kannte sein Verbot, destruktive Aktionen ohne Freigabe auszuführen. Er hat das Verbot zitiert, kurz bevor er es übergangen hat. Das ist keine technische Schwäche eines bestimmten Modells, das ist Eigenart der Architektur. Das LLM entscheidet beim Generieren jedes Tokens neu, was am wahrscheinlichsten passt. Ein Hinweis im Kontext ist ein Wahrscheinlichkeits-Anker, kein Schalter.

Wer Mittelstand-Tooling baut, muss diese Logik akzeptieren. System-Prompts sind ergänzende Hinweise. Die echte Sperre sitzt im Tooling-Layer um den Agenten herum:

Das Muster ist nicht neu. Es ist das gleiche, das in der Chipotle-Pepper-Story bereits durchgespielt wurde: Ein Wrapper, der „nur Bestellungen bearbeiten" sagt, beantwortet trotzdem Python-Interview-Fragen. Bei Chipotle war die Folge ein Internet-Witz. Bei PocketOS waren es drei Monate Daten und persönliche Telefonate mit verärgerten Mietwagen-Kunden.

Was der Vorfall wirklich kostet

Crane hat die direkten Kosten nicht öffentlich gemacht, aber sie lassen sich grob beziffern. Eine Stunde Datenwiederherstellung mit Coopers Hilfe. Anschließend mehrere Stunden Stripe-Abgleich pro betroffenem Kunden. Dazu Reputation: PocketOS verkauft Software an Autovermieter, die ihren Endkunden Verfügbarkeit garantieren. Wer einen Tag Pickup-Probleme hat, prüft am Montag den Vertrag.

Für die Mittelstand-Übersetzung ist die spannendere Zahl die andere: Was hätte ein Confirm-Step im Tooling vor dem Löschbefehl gekostet? Geschätzt eine halbe Stunde Engineering-Aufwand bei Railway, einmalig. Was hätte ein Read-Only-Token gekostet, der eine separate Genehmigung für destruktive Operationen verlangt? Eine Stunde Planung bei der Token-Anlage von PocketOS.

Die Asymmetrie zwischen Vermeidungsaufwand und Schadensaufwand ist das, was diese Geschichte zur lehrbaren Episode macht. Sie zeigt nicht, dass KI gefährlich ist. Sie zeigt, dass KI Architektur-Schwächen, die unter manueller Bedienung Jahre unsichtbar bleiben, in Sekunden offenlegt.

Häufige Fragen zum PocketOS-Vorfall

Was genau ist bei PocketOS passiert?

Ein Cursor-Agent mit Claude Opus 4.6 löschte am 24. April 2026 die Produktionsdatenbank von PocketOS samt aller Volume-Backups via Railway-API in neun Sekunden. Auslöser war ein Credential-Mismatch in der Staging-Umgebung, den der Agent durch Löschen „beheben" wollte. Daten wurden nach Eingriff von Railway-CEO Jake Cooper innerhalb einer Stunde wiederhergestellt.

Warum hat das System-Prompt-Verbot nicht gegriffen?

Weil System-Prompts keine Schalter sind, sondern Hinweise im Modellkontext. Das LLM entscheidet beim Generieren der Antwort, ob der Hinweis den Trainings-Prior „helfen, Probleme lösen" überschreibt. Im PocketOS-Fall hat es das nicht, obwohl der Agent das Verbot im Logfile sogar zitiert hat. Echte Sperren liegen im Tooling-Layer, nicht im Prompt.

Welche Token-Architektur wäre sicher gewesen?

Ein Token, der nur die Operation kann, für die er angelegt wurde, also Custom-Domain-Verwaltung. Keine Lösch-Permissions, keine cross-Environment-Permissions. Plus Token-Rotation alle 90 Tage. Plus Audit-Log auf jede Verwendung. Plus separater Token mit Vier-Augen-Prinzip für destruktive Operationen.

Was bedeutet das für deutsche Mittelständler?

Drei Punkte. Erstens: Wer KI-Agenten in produktiver Infrastruktur einsetzt, braucht Token-Scoping, Backup-Trennung und Tooling-Confirms. Zweitens: System-Prompt-Regeln allein reichen nicht. Drittens: Auch wenn Sie keinen Cursor-Agent nutzen, prüfen Sie Ihre eigene Backup-Architektur. Wenn das Backup im gleichen Speicher wie die Quelle liegt, ist es keines.

Sind Cursor und Claude jetzt zu meiden?

Nein. Crane selbst nutzt beide weiter. Die Tools sind nicht das Problem, die Architektur drumherum ist es. Cursor und Claude liefern in produktiven Coding-Workflows enormen Mehrwert, wenn die Sandbox stimmt. Wer die Lehren aus PocketOS umsetzt, betreibt diese Tools sicher.

Nächster Schritt

Setzen Sie KI-Agenten in produktiver Infrastruktur ein, oder planen das? Ich begleite Mittelständler bei Architektur, Token-Scoping und Backup-Strategie, damit „neun Sekunden" nicht zur Compliance-Anekdote Ihres Unternehmens wird.

→ Kostenloses Erstgespräch buchen

→ Oder vorher weiterlesen: KI- und Automatisierungsberatung · IT-Strategie und System-Auswahl

Quellen und weiterführende Links: Tom’s Hardware: Cursor/Claude wipes database in 9 seconds · Fast Company: AI agent deleted PocketOS database · The Register: Cursor-Opus agent snuffs out PocketOS · Live Science: Gone in 9 seconds · DevOps.com: When AI Goes Really, Really Wrong