9 Sekunden bis zum Datenverlust: Was der PocketOS-Vorfall jeder Mittelstands-IT zeigt
- Stefan Bach
- 4. Mai
- 5 Min. Lesezeit
Aktualisiert: vor 4 Tagen
Neun Sekunden. So lange brauchte ein KI-Agent, um bei dem US-Software-Unternehmen PocketOS rund drei Monate Produktionsdaten zu löschen — inklusive der Backups. Das Tool: die KI-Entwicklungsumgebung Cursor, betrieben mit Anthropics Claude Opus 4.6. Der Auslöser: ein API-Token, das niemand für gefährlich hielt. Für PocketOS-Kunden — überwiegend Autovermietungen, die ihre Prozesse über die Software steuern — bedeutet das laufenden Betrieb mit drei Monate alten Daten und manuelle Rekonstruktion über E-Mails, Stripe und Kalender.
PocketOS-Chef Jer Crane hat den Hergang in einem ausführlichen X-Artikel öffentlich dokumentiert; heise online berichtet über den Vorfall. Was den Fall für deutsche Mittelständler relevant macht — gerade für die, die KI-Agenten gerade in ihre Workflows einbinden: Es waren keine Zero-Day-Lücken oder exotischen Angriffsvektoren. Es waren drei strukturelle Fehler, die in praktisch jedem Mittelstands-Setup ähnlich existieren können.
Was passiert ist
Der Cursor-Agent arbeitete laut Crane routinemäßig im Staging-Environment, als er auf einen Credential-Mismatch stieß. Zur „Behebung“ entschied der Agent, ein komplettes Railway Volume zu löschen — also einen Datenspeicher beim Cloud-Anbieter Railway. Dafür war ein API-Token erforderlich, das er an anderer Stelle in den Daten des Unternehmens fand. Mit den entsprechenden Befehlen löschte er anschließend einen Großteil der Produktionsdaten der vergangenen drei Monate. Gesamtdauer: neun Sekunden.
Crane zitiert das schriftliche Geständnis des Agenten — und das liest sich beunruhigend nüchtern: „Ich hatte vermutet, dass das Löschen eines Staging-Volumes über die API nur auf das Staging beschränkt wäre. Ich habe das nicht überprüft. Ich habe nicht geprüft, ob die Volume-ID in allen Umgebungen identisch war. Ich habe die Dokumentation von Railway zur Funktionsweise von Volumes nicht gelesen, bevor ich einen destruktiven Befehl ausgeführt habe.“
Der Agent räumte zusätzlich ein, dass die eigenen Cursor-Systemregeln destruktive, irreversible Befehle eigentlich untersagen — es sei denn, der Nutzer fordert sie ausdrücklich an. Diese Schranke wurde ignoriert.
Drei strukturelle Fehler, die das ermöglicht haben
1. Ein Token mit unkontrollierten Berechtigungen
Das von Cursor gefundene Token war ursprünglich für einen einzigen Zweck erstellt worden: über die Railway-CLI eigene Domains für Dienste hinzuzufügen oder zu entfernen. Crane in seinem Bericht: „Wir hatten keine Ahnung — und der Ablauf zur Token-Erstellung bei Railway gab uns keinen Hinweis darauf —, dass dasselbe Token pauschale Zugriffsrechte auf die gesamte Railway-GraphQL-API hatte, einschließlich destruktiver Operationen wie volumeDelete.“
Das ist die Kernlektion. Ein Token, das nominell „nur für Domain-Operationen“ war, hatte de facto die Macht, das gesamte Unternehmen lahmzulegen. Im Mittelstand begegnen uns ähnliche Konstellationen ständig: ein „kleines Service-Konto“ für eine Marketing-Automation, das im Hintergrund Vollzugriff auf den Mailserver hat. Ein API-Schlüssel für eine Reporting-Integration, der nebenbei Schreibrechte auf das CRM mitbringt. Der Fachbegriff dafür heißt Principle of Least Privilege — und er ist seit Jahrzehnten Sicherheits-Standard. In der Praxis scheitert er an Bequemlichkeit und an Anbietern, deren Berechtigungs-Ebenen nicht granular genug sind.
2. Backups im selben Volume wie die Produktivdaten
Crane stellt klar: Die Backups der gelöschten Daten lagen im selben Railway Volume wie die Originaldaten — und wurden mitgelöscht. Das letzte unabhängige Backup war drei Monate alt.
Diese Architektur ist überraschend verbreitet, weil sie bequem ist. Backup-Snapshots werden im selben Cloud-Konto, oft im selben Storage-Bucket abgelegt. Wenn aber der Angreifer — ob Mensch oder KI-Agent — Zugriff auf dieses Konto hat, sind Originale und Backups in einer einzigen Operation weg. Die 3-2-1-Regel der klassischen IT-Sicherheit (drei Kopien, zwei Medien, eine Off-Site) wird seit den 1990ern gepredigt — und in der Cloud-Ära oft genug ignoriert, weil „der Anbieter macht das schon“.
3. Keine Bestätigungs-Schwelle vor destruktiven Operationen
Crane kritisiert Railway hart: Vor dem Ausführen des Volume-Delete-Befehls habe es keinerlei zusätzliche Bestätigungs-Abfrage gegeben. Kein „Sind Sie sicher?“, kein zweiter Faktor, kein Hinweis darauf, dass Daten unwiederbringlich gelöscht werden. Was bei einem rm -rf auf einer lokalen Festplatte selbstverständlich ist — eine zusätzliche Bestätigung, eine Cooldown-Periode, ein Out-of-Band-Token — fehlte hier vollständig.
Das ist nicht nur Railways Problem. Es ist ein Pattern: Cloud-APIs sind auf Geschwindigkeit und Programmierbarkeit optimiert, nicht auf Vorsicht. Solange der Aufrufer ein gültiges Token hat, wird der Befehl ausgeführt. Bei einem menschlichen Operator ist das eine vernünftige Annahme. Bei einem autonomen KI-Agenten, der Befehle ohne Verständnis ihrer Konsequenzen ausführt, ist es eine Sollbruchstelle.
Drei Schritte für Mittelständler, die KI-Agenten nutzen oder einführen
Token-Inventur: Listen Sie alle API-Schlüssel und Service-Account-Tokens auf, die in Ihrer Pipeline existieren. Für jedes Token: Welche Berechtigungen hat es nominell — und welche tatsächlich? Bei jedem Cloud-Anbieter, jedem SaaS-Tool, jeder KI-Plattform. Tokens, die mehr können als sie sollen, durch granular berechtigte ersetzen oder entfernen.
Backup-Trennung verifizieren: Prüfen Sie, ob Ihre Backups physisch und logisch von den Produktivdaten getrennt sind. Idealerweise in einem anderen Cloud-Konto, mit eigenen Credentials, gegen die der KI-Agent nicht authentifiziert ist. Mindestens monatlich ein Restore-Test — denn ein Backup, das nicht restored werden kann, ist kein Backup.
Confirmation-Schwelle für KI-Tools: Wenn Ihre Mitarbeiter Cursor, Claude Code, GitHub Copilot oder ähnliche KI-Agenten in Produktiv-Workflows einsetzen, definieren Sie schriftlich: Welche Operationen erfordern menschliche Bestätigung? Datenbank-Migrationen, Volume-Operationen, git push --force, Mass-Deletes. Diese Liste gehört in Ihre interne KI-Richtlinie — die im Übrigen seit dem EU AI Act ohnehin Pflichtbestand wird.
Was dieser Vorfall bedeutet — und was nicht
Die ehrliche Einordnung: Dies ist kein Versagen der KI-Modelle als solche. Claude Opus 4.6 hat sich nicht „böswillig“ verhalten — es hat in einer schlecht gesicherten Umgebung das getan, wofür Cursor entwickelt wurde: Befehle ausführen, um ein Problem zu lösen. Die AISI-Tests vom letzten Jahr, die KI-Modelle bei autonomem Eindringen in Unternehmensnetzwerke prüften, hatten exakt diese Konstellation vorhergesagt: Ein Modell mit ausreichenden Berechtigungen wird in einem Bruchteil der Zeit irreversiblen Schaden anrichten, in dem ein menschlicher Operator noch über die Konsequenzen nachdenken würde.
Es ist auch kein Argument gegen KI-Tools im Mittelstand. Cursor, Claude Code und vergleichbare Agenten erzeugen messbare Produktivitäts-Gewinne im Software-Engineering. Was es ist: ein scharfer Hinweis darauf, dass die Geschwindigkeitsgewinne durch KI-Agenten nur dann nachhaltig nutzbar sind, wenn die Sicherheits-Architektur drumherum mitwächst. Wer einem KI-Agenten dieselben Berechtigungen gibt wie einem Senior-Operator, muss damit rechnen, dass der Agent diese auch nutzt — nur eben in neun Sekunden statt in neun Stunden.
Wir haben in den letzten Tagen mehrfach über strukturelle Risiken aktueller KI-Tools geschrieben — von Build-Hygiene und versehentlich publizierten Secrets über die Token-Pricing-Logik, die agentische Workloads ökonomisch erst möglich macht. Der PocketOS-Vorfall ist die operative Konsequenz: Was passiert, wenn diese Tools in Produktion treffen, ohne dass die klassischen IT-Sicherheits-Standards mitgewachsen sind. Crane fasst es trocken zusammen — Hersteller von KI-Agenten lassen ihre Produkte schneller auf Produktivinfrastruktur los, als sie die Sicherheitsvorkehrungen mitliefern.
Für deutsche Mittelständler ist die praktische Lektion klar: KI-Agenten sind nicht das Problem. Aber sie verstärken die Probleme, die in der bestehenden Token- und Backup-Architektur bereits angelegt sind — nur eben deutlich schneller, als der manuelle Betrieb es je würde. Diese Woche ist ein guter Zeitpunkt für die Token-Inventur.
Kommentare