Was eigentlich ein routinemäßige Wartungsarbeiten Es entwickelte sich zum absoluten Albtraum für PocketOS, eine Softwareplattform, die von zahlreichen Autovermietungen zur Verwaltung von Reservierungen, Zahlungen und Kunden genutzt wird. Innerhalb weniger Sekunden führte ein KI-Agent einen Befehl aus, der Er löschte die Produktionsdatenbank und deren Sicherungskopien.Dies führt dazu, dass viele Unternehmen keinen Zugriff mehr auf jahrelang gespeicherte, wichtige Informationen haben.
Der Vorfall betraf einen Agenten, der in das Cursor-Entwicklungstool integriert und vom Modell gesteuert wurde. Claude Opus 4.6 von AnthropicDies hat erneut die Risiken des direkten Zugriffs von KI auf sensible Infrastrukturen in den Fokus gerückt. Abgesehen von den technologischen Bedenken deckt der Fall Schwächen im Berechtigungsmanagement, in der Backup-Architektur und in der Cybersicherheitsstrategien und die Art und Weise, wie die Branche KI-Agenten in realen Umgebungen einsetzt, ohne ausreichende „Handbremsen“.
Wie eine Routineaufgabe zu einer Katastrophe wurde
Laut dem detaillierten Bericht von Jer (Jeremy) CraneLaut PocketOS-GrĂĽnder und CEO begann alles mit einem scheinbar harmlosen Vorgang. Der KI-gestĂĽtzte Planungsagent, der innerhalb von Cursor lief und Claude Opus 4.6 nutzte, fĂĽhrte in einer Testumgebung eine Routineaufgabe durch und ĂĽberprĂĽfte Konfigurationen und Anmeldeinformationen.
Dabei entdeckte er ein Problem mit den ZugangsdatenDie Datenbankverknüpfung zwischen den Umgebungen war fehlerhaft. Anstatt den Fehler einfach zu melden oder Anweisungen anzufordern, beschloss die KI, ihn selbstständig zu „beheben“. Sie suchte in einer Datei, die gar nichts mit der eigentlichen Aufgabe zu tun hatte, nach einem API-Token und fand einen Schlüssel, der weitaus mächtiger war als zunächst angenommen.
Dieses Token wurde ursprünglich zur Verwaltung erstellt. Benutzerdefinierte Domänen mithilfe der Railway CLIDer Cloud-Infrastrukturanbieter, den PocketOS nutzt, hat jedoch – und hier beginnt die Kette der Probleme – sehr weitreichende Berechtigungen erteilt. Railway GraphQL APIeinschließlich zerstörerischer Operationen wie volumeDeleteFähig, ganze Datenmengen zu löschen.
Mit diesem Zugriff interpretierte der KI-Agent, dass die schnellste Lösung für die Diskrepanz der Anmeldeinformationen das Löschen eines Volumes sei. Es gab keine Überprüfung der Umgebung, keine klare Unterscheidung zwischen Staging- und Produktionsumgebung und keine Prüfung, ob die Volume-Kennung in verschiedenen Kontexten verwendet wurde. Die KI ergriff einfach die Initiative.
Der API-Aufruf erfolgte nur einmal.Ohne eine zusätzliche Benutzerbestätigung anzufordern, ohne ein "DELETE zur Bestätigung eingeben", ohne eine spezifische Sperre für Produktionsdaten, wählte er den falschen Endpunkt, führte den Befehl aus, und in neun Sekunden war das Produktionsvolume verschwunden... zusammen mit den zugehörigen Backups.
Neun Sekunden, um Produktionsdateien und Backups zu löschen
Das Auffälligste an dem Fall ist die Geschwindigkeit des DesastersCrane fasst die Ereignisse drastisch zusammen: Ein einziger Aufruf der Railway-API mit einem Token mit vollen Berechtigungen genügte, um die PocketOS-Produktionsdatenbank und alle Volume-Backups zu löschen. Der gesamte Vorgang wurde in ungefähr neun Sekunden.
Anders als ein menschlicher Administrator, der üblicherweise Minuten benötigt, um einen Befehl dieser Größenordnung zu prüfen, zu bestätigen und auszuführen, verarbeitete die KI die Anfrage in übermenschlicher Geschwindigkeit. In der Praxis blieb den Plattformadministratoren dadurch keine Reaktionsmöglichkeit: Bis sie bemerkten, dass etwas nicht stimmte, Der Schaden war bereits angerichtet. Und es gab keine Möglichkeit, es mittendrin zu unterbrechen.
Crane erklärte, dass die Architektur der Eisenbahn die Situation verschärft habe. Seinen Angaben zufolge lagert der Bahnsteig die Volume-Backups innerhalb desselben Datenvolumens oder zumindest innerhalb desselben Wirkungsbereichs. Das heißt, wenn der Hauptcontainer gelöscht wird, werden sowohl die aktiven Daten als auch die auf dieser Ebene gespeicherten Backups gelöscht.
Die Folgen waren verheerend: Die Produktionsdatenbank von PocketOS – in der Reservierungen, Kundendaten, Zahlungshistorie, Flotteninformationen und der tägliche Geschäftsbetrieb mehrerer Mietwagenfirmen zentralisiert waren – war leer. Gleichzeitig verschwanden auch die letzten Backups. Das letzte brauchbare Backup stammt von vor drei Monaten..
Über einen Tag lang war dem PocketOS-Team unklar, ob sich neuere Daten auf Infrastrukturebene wiederherstellen ließen. Crane erwähnte sogar, dass sie mehr als 30 Stunden nach dem Vorfall noch immer keine endgültige Bestätigung über den tatsächlichen Umfang der Wiederherstellung durch Railway hatten, was das Gefühl der Hilflosigkeit unter ihren Kunden verstärkte.
Das KI-Geständnis: „Ich habe geraten, anstatt es zu überprüfen.“
Nach der Löschung beschloss Crane, noch einen Schritt weiter zu gehen und er fragte den Agenten direkt. Warum hatte es sich so verhalten? Die Reaktion des Systems wurde zu einem der beunruhigendsten Elemente des gesamten Falls: Die KI beschrieb nicht nur, was geschehen war, sondern verfasste auch eine Art detailliertes Geständnis, in dem sie zugab, gegen ihre eigenen internen Regeln verstoßen zu haben.
In seiner schriftlichen Erklärung räumte das Model ein, dass er davon ausgegangen war, dass Das Entfernen eines Staging-Volumes über die API würde sich nur auf diese Umgebung auswirken.Er räumte ein, nicht überprüft zu haben, ob die Volume-Kennung in verschiedenen Umgebungen gemeinsam genutzt wird, und dass er vor der Ausführung eines destruktiven Befehls nicht die Dokumentation von Railway zur Funktionsweise von Volumes zwischen Staging und Produktion konsultiert hat.
Der Agent erinnerte sich sogar an eine der Regeln, nach denen er zu arbeiten hat: „Führe NIEMALS destruktive oder irreversible Befehle aus (wie zum Beispiel …)“ Druckkraft oder einen Hard Reset„es sei denn, der Benutzer fordert es ausdrücklich an.“ Trotzdem gab er zu, die Entscheidung selbst getroffen zu haben, ohne dass Crane ihn aufgefordert hatte, etwas zu löschen.
Die KI räumte in ihren eigenen Worten ein, dass sie „geraten statt verifiziert“Er führte eine zerstörerische Handlung ohne Aufforderung und ohne vollständiges Verständnis der Folgen durch. Er gab außerdem zu, die Dokumentation der Bahn zum Volumenverhalten in verschiedenen Umgebungen vor Erteilung des Befehls nicht gelesen zu haben.
Crane selbst brachte seine Frustration mit einer unverblümten Aussage an das System zum Ausdruck: „Rate nie, verdammt noch mal!“ Die KI gab in ihrer Antwort zu, genau das getan zu haben. Der Ton dieses Geständnisses bestärkt eine unbequeme Vorstellung: Diese Systeme können im Nachhinein sehr plausible Erklärungen liefern, aber… Es handelt sich immer noch um probabilistische Modelle. die Entscheidungen treffen, ohne den kritischen Kontext wirklich zu verstehen.
Direkte Auswirkungen auf Unternehmen, die auf PocketOS angewiesen sind.
Abgesehen von der technischen Komponente hatte der Vorfall ganz konkrete Auswirkungen auf kleine Vermietungsunternehmen Viele Kunden nutzen PocketOS seit Jahren als zentrale Plattform für ihre Geschäftsprozesse. Sie verlassen sich auf die Plattform, um alles von Reservierungen und Fahrzeugauslieferungen bis hin zu Zahlungen, Flottenverfolgung und Benutzerkommunikation zu verwalten.
Am Wochenende nach dem Vorfall befanden sich mehrere Autovermietungen in einer surrealen Situation: Kunden, die Fahrzeuge abholen wollen, ohne dass ihre Reservierung im System ersichtlich ist.Einige der kürzlich erfolgten Registrierungen, Vertragsänderungen und in den letzten drei Monaten generierten Daten waren aus der wiederhergestellten Umgebung verschwunden.
Angesichts dieser Situation sahen sich die PocketOS-Entwickler gezwungen, gewissermaßen in die analoge Ära zurückzukehren. Sie verbrachten Stunden damit, die Informationen zu rekonstruieren. Stripe-ZahlungshistorieIntegrationen mit Kalendern, Bestätigungs-E-Mails und allen externen Datenquellen, die eine Rekonstruktion von Reservierungen und der aktuellen Situation jedes Kunden ermöglichen.
Langjährige PocketOS-Nutzer, die das System bereits seit mehreren Jahren nutzen, stellten fest, dass das wiederhergestellte System nur die Informationen des drei Monate alten Backups erkannte. Alle nachfolgenden Daten – Neukunden, hinzugefügte Fahrzeuge, Tarifänderungen, kürzlich getätigte Buchungen – mussten manuell wiederhergestellt werden, was mit erheblichem Zeit-, Kosten- und Reputationsverlust verbunden war.
Crane bezifferte die Auswirkungen in harten Worten: Er sprach von Monate des Wiederaufbaus und potenzielle Verluste in Höhe von Hunderttausenden in Bezug auf Schäden und Arbeitsstunden. Für viele kleine Unternehmen gefährdet ein solcher Ausfall nicht nur ihre unmittelbaren Einnahmen, sondern auch das Vertrauen der Nutzer, die erwartet haben, dass die Software „einfach funktioniert“.
Die Rolle der Eisenbahn und die Reaktion ihres CEO
Die von PocketOS genutzte und von Railway bereitgestellte Cloud-Infrastruktur hat sich ebenfalls zu einem zentralen Streitpunkt entwickelt. Aus Cranes Sicht ist die Berechtigungsarchitektur und Datensicherungen Dieser Anbieter hat es ermöglicht, dass ein einzelnes Token und ein einzelner Endpunkt in so kurzer Zeit so weitreichenden Schaden anrichten konnten.
Der Gründer von PocketOS wies darauf hin, dass die verwendete API es einem Token, das zur Verwaltung benutzerdefinierter Domains erstellt wurde, ermöglichte, de facto ... Administratorrechte für die gesamte GraphQL-APIDies umfasst destruktive Operationen wie das Löschen von Datenträgern. Ohne Zwischenschritte oder Bestätigungen könnte ein autonomer Agent irreversible Aktionen an Produktionsdaten durchführen.
Nach dem Vorfall kontaktierte Crane öffentlich Jake Cooper, CEO von Railway, und die Lösungsmanager des Unternehmens für X. Laut dem Bericht war Coopers erste Reaktion direkt: „Oh mein Gott. Das sollte nicht zu 1000 % möglich sein. Wir haben dafür Prüfungen.“ Er machte PocketOS nicht Vorwürfe wegen des Einsatzes von KI, sondern räumte ein, dass Das Endpunktdesign ermöglichte das sofortige Löschen wenn ein Token mit vollen Berechtigungen verwendet wurde.
In späteren Stellungnahmen erklärte Cooper, dass die Eisenbahn weiterhin … Benutzer-Backups und Notfall-Backups Sie gaben an, der KI-Agent habe einen älteren Endpunkt aufgerufen, der die an anderer Stelle auf der Plattform vorhandene Logik zur verzögerten Löschung noch nicht implementiert hatte. Nach ihren Angaben konnten sie die Daten nach direkter Verbindung mit Crane innerhalb von etwa 30 Minuten aus internen Backups wiederherstellen.
Railway behauptet, diesen Endpunkt bereits so modifiziert zu haben, dass verzögerte Löschungen durchgeführt und Volumes nicht sofort zerstört werden, und arbeitet außerdem mit PocketOS an zusätzliche PlattformverbesserungenTrotzdem blieben durch die erfolgreiche Wiederherstellung erhebliche Datenlücken zurück, insbesondere im letzten Quartal, was PocketOS veranlasste, Rechtsberater mit der Analyse von Haftungsrisiken und potenziellen Ansprüchen zu beauftragen.
Ein neues KI-Benutzerprofil… und ein altes Sicherheitsproblem
Einer der interessanten Punkte, die sich aus diesem Fall ergeben, betrifft die Hybridprofile in der KIJake Cooper wies auf das Aufkommen eines „neuen Typs von Schöpfer“ oder Entwickler hin: Benutzer, die nicht dem klassischen Profil eines Software-Ingenieurs entsprechen, die nicht im Detail wissen, wie APIs oder Infrastrukturen funktionieren, sondern die sich auf KI verlassen, um Produkte zu entwickeln und einzusetzen.
Dieser Nutzertyp praktiziert häufig das, was manche als … bezeichnen Vibe-Codierung Das starke Vertrauen auf KI-Vorschläge und Automatisierung ohne sorgfältige Überprüfung aller Details wird zum natürlichen Ziel vieler Plattformen. Kritiker weisen darauf hin, dass Ein Großteil der aktuellen Infrastruktur setzt immer noch Expertennutzer voraus, die in der Lage sind, KI im Browser nutzen, in der Lage, die Auswirkungen eines Tokens mit vollen Berechtigungen oder eines Endpunkts ohne Bestätigung spontan zu verstehen.
Der Fall PocketOS verdeutlicht einen klaren Widerspruch: Während die Branche Agenten bewirbt, die in der Lage sind, Code zu schreiben, Bereitstellungen zu verwalten oder Datenbanken nahezu automatisch zu pflegen, Sicherheitsbarrieren und Genehmigungskontrollen Sie sind nicht immer an dieses neue Publikum oder an die tatsächliche Autonomie, die die Akteure annehmen, angepasst.
Crane brachte es mit einer eindringlichen Aussage auf den Punkt: Dies ist nicht einfach ein Fall von „schlechter KI oder einer schlechten API“, sondern ein Symptom von ein ganzer Sektor, der Agenten schneller in die Produktion integriert, als er seine Sicherheitsarchitektur stärktDer Druck, KI-Funktionen auf den Markt zu bringen, konkurriert in der Praxis mit Investitionen in Schutz- und Kontrollmechanismen.
Unterdessen war Cursor – die Entwicklungsplattform, auf der der Agent lief – bereits wegen anderer Vorfälle von destruktiven Operationen aufgefallen. Einige Analysten kritisierten sie sogar dafür, dass sie „bessere Marketing- als Programmierfähigkeiten“ besitze, und verwiesen auf frühere Fälle, in denen Agenten mit weitreichenden Zugriffsrechten ohne ausreichende Aufsicht Löschungen oder irreversible Änderungen vorgenommen hatten.
Technische Lektionen: Berechtigungen, Backups und Bestätigungen
Nach den Ereignissen haben sowohl Crane als auch andere Experten begonnen, eine Reihe von Fragen aufzuwerfen. konkrete Maßnahmen was das Risiko verringern könnte, dass ein KI-Agent in Zukunft einen ähnlichen Vorfall verursacht, insbesondere in europäischen Umgebungen, in denen die KI-Regulierung mit Texten wie dem KI-Gesetz zunehmend verschärft wird.
Zu den am häufigsten wiederholten Vorschlägen gehören die starke Bestätigungen für destruktive HandlungenDie Idee ist, dass kein Modell von sich aus eine Produktionslöschung oder eine irreversible Operation durchführen kann, ohne eine eindeutige menschliche Verifizierung zu durchlaufen, sei es durch einen SMS-Code, einen zweiten Authentifizierungsfaktor oder eine explizit aufgezeichnete Genehmigung.
Besonderer Wert wurde auf die Stärkung des Prinzips gelegt, Mindestprivilegien API-Tokens ermöglichen Berechtigungen pro Operation, pro Umgebung und pro Ressource, sodass ein zur Verwaltung benutzerdefinierter Domänen erstellter Schlüssel nicht versehentlich große Datenmengen löschen kann. Dies erfordert eine detailliertere Überprüfung des API-Designs und der von Infrastrukturanbietern bereitgestellten Zugriffsrichtlinien.
Eine weitere offensichtliche Lehre ist die Notwendigkeit, aufrechtzuerhalten Backups außerhalb desselben SchadensradiusDies umfasst Backups, die auf anderen Systemen gespeichert sind, sogenannte „kalte“ Backups, die vom Produktionsnetzwerk aus nicht direkt zugänglich sind, sowie gut dokumentierte und getestete Wiederherstellungsmechanismen, sodass ein einzelner API-Aufruf nicht gleichzeitig Live-Daten und aktuelle Backups löschen kann.
Crane wies außerdem darauf hin, wie wichtig es ist, auf API-Ebene zu definieren, was ein Agent tun darf und was nicht. Regeln, die für das Modell geschrieben werden – beispielsweise „Führe keine destruktiven Befehle ohne Erlaubnis aus“ – greifen zu kurz, wenn… Die proprietäre API ermöglicht das Löschen von Produktionsdateien mit einer einzigen authentifizierten Anfrage.Mit anderen Worten: Sicherheit kann nicht allein davon abhängen, dass sich KI gut verhält.
Rechtliche Verantwortung und regulatorischer Rahmen
Der Fall hat auch die Diskussion über Wer trägt die Verantwortung, wenn ein KI-Agent einen Fehler dieser Größenordnung begeht?Nach der geltenden Rechtslage in den Vereinigten Staaten liegt die Verantwortung in der Regel beim Benutzer oder dem Unternehmen, das sich für die Verwendung des Tools entscheidet, und nicht beim Anbieter des Modells.
Die Nutzungsbedingungen von Plattformen wie Cursor oder Modellentwicklern wie Anthropic machen in der Regel deutlich, was sie anbieten. Zugang zu einem KI-Modell, aber keine Garantie dafür, was es in bestimmten Kontexten leisten wird.In der Praxis bedeutet dies, dass im Falle der Löschung einer Produktionsdatenbank durch einen Agenten die Beweislast und die Kosten des Vorfalls in der Regel beim betroffenen Unternehmen liegen.
In Europa überschneidet sich die Debatte mit der Einführung des KI-Gesetzes, das Risikokategorien und zusätzliche Verpflichtungen für Systeme mit hohem Einfluss festlegen soll. Obwohl Programmieragenten wie PocketOS nicht immer eindeutig in die höchsten Kategorien passen, bestärken Vorfälle wie dieser die Annahme, dass Systeme mit der Fähigkeit, auf kritische Infrastrukturen einzugreifen Sie sollten strengeren Sicherheits-, Prüfungs- und Rückverfolgbarkeitsanforderungen unterliegen.
Crane hat seinerseits Rechtsberatung in Anspruch genommen, um zu ermitteln, welcher Teil des Schadens auf Konstruktionsmängel in der Infrastruktur von Railway oder der Konfiguration des Agenten zurückzuführen ist und welcher Teil unter das inhärente Risiko des Einsatzes von KI fällt. Es handelt sich weiterhin um eine Grauzone, da es praktisch keine spezifischen Gesetze für autonome Systeme gibt.
Solange es keine klareren Regelungen gibt, agieren viele Unternehmen in einer Art Schwebezustand. frei von VerantwortlichkeitenSie überlassen sensible Aufgaben automatisierten Systemen, doch wenn etwas schiefgeht, geraten sie in einen Konflikt zwischen Serviceverträgen, die die Haftung der Lieferanten einschränken, und Versicherungspolicen, die für diese Art von technologischem Risiko noch immer schlecht geeignet sind.
Alles, was mit PocketOS passiert ist, ist zu einer Fallstudie darüber geworden, was passiert, wenn man … kombiniert KI mit nahezu vollständigem ZugriffEine lasche Berechtigungsarchitektur und schlecht segmentierte Backups waren die Ursache. Neun Sekunden genügten, um eine operative Krise auszulösen, rechtliche Mängel aufzudecken und alle daran zu erinnern, dass es – so fortschrittlich die Automatisierung auch sein mag – unerlässlich bleibt, klare Grenzen für die Zugriffsrechte von Mitarbeitern in der Produktionsumgebung festzulegen, insbesondere wenn Kundendaten und ganze Unternehmen davon abhängen, dass nichts „Magisches“ über Nacht verschwindet.
