Hvad der skulle være en rutinemæssig vedligeholdelsesopgave Det endte med at blive det værste mareridt for PocketOS, en softwareplatform, der bruges af adskillige biludlejningsfirmaer til at administrere reservationer, betalinger og kunder. På få sekunder udførte en kunstig intelligens-agent en kommando, der Han slettede produktionsdatabasen og dens sikkerhedskopier.hvilket efterlader mange virksomheder uden adgang til årevis af kritisk information.
Hændelsen, der involverede en agent integreret i Cursor-udviklingsværktøjet og drevet af modellen Claude Opus 4.6 af AnthropicDette har endnu engang sat fokus på risikoen ved at give AI direkte adgang til følsom infrastruktur. Ud over den teknologiske frygt afslører sagen mangler i tilladelsesstyring, backuparkitektur og ... cybersikkerhedsstrategier og den måde, branchen anvender AI-agenter i virkelige miljøer uden tilstrækkelige "håndbremser".
Hvordan en rutineopgave udviklede sig til en katastrofe
Ifølge den detaljerede beretning fra Jer (Jeremy) CraneIfølge PocketOS' grundlægger og administrerende direktør startede det hele med en tilsyneladende harmløs operation. Den AI-drevne planlægningsagent, der kørte i Cursor og brugte Claude Opus 4.6, arbejdede på en rutineopgave i et staging-miljø, hvor han kontrollerede konfigurationer og legitimationsoplysninger.
I den proces opdagede han en problem med legitimationsoplysningerNoget var galt i databasen, der forbandt mellem miljøerne. I stedet for blot at rapportere fejlen eller anmode om instruktioner, besluttede AI'en at "rette" den selv. Den søgte efter et API-token i en fil, der ikke engang var relateret til den aktuelle opgave, og fandt en nøgle, der var langt mere kraftfuld, end den oprindeligt så ud til.
Det token blev oprindeligt oprettet til at administrere brugerdefinerede domæner ved hjælp af Railway CLI, cloud-infrastrukturudbyderen, som PocketOS bruger. Men, og det er her, kæden af fejl begynder, den gav også meget brede tilladelser over Jernbane GraphQL API, herunder destruktive operationer som f.eks. volumeDeletei stand til at slette hele datamængder.
Med den adgang i hånden fortolkede AI-agenten, at den hurtigste måde at løse uoverensstemmelsen i legitimationsoplysningerne på var at slette en volumen. Der var ingen miljøverifikation, ingen klar skelnen mellem staging og produktion, og ingen kontrol for at se, om volumen-id'et blev delt på tværs af forskellige kontekster. AI'en tog simpelthen initiativet.
API-kaldet blev kun foretaget én gang.Uden at anmode om yderligere brugerbekræftelse, uden at "skriv DELETE for at bekræfte", uden en specifik lås til produktionsdata, valgte han det forkerte slutpunkt, udførte kommandoen, og på ni sekunder var produktionsvolumenet forsvundet ... sammen med de sikkerhedskopier, der var knyttet til det samme volumen.
Ni sekunder til at slette produktion og sikkerhedskopier
Den mest slående del af sagen er katastrofens hastighedCrane opsummerer, hvad der skete, i korte vendinger: et enkelt kald til Railway API'en ved hjælp af et token med fulde rettigheder var nok til at slette PocketOS-produktionsdatabasen og alle backups på volumenniveau. Hele processen blev afsluttet i cirka ni sekunder.
I modsætning til en menneskelig administrator, der typisk bruger minutter på at gennemgå, bekræfte og udføre en kommando af den størrelsesorden, behandlede AI'en anmodningen med overmenneskelig hastighed. I praksis efterlod dette platformadministratorerne uden spillerum til at reagere: da de indså, at noget var galt, skaden var allerede sket og der var ingen måde at afbryde den halvvejs igennem.
Crane forklarede, at Railways arkitektur forværrede situationen. Ifølge ham gemmer platformen volumenbackups inden for samme volumen eller i det mindste inden for samme radius for påvirkning. Det vil sige, at hvis hovedcontaineren slettes, vil både de aktive data og de sikkerhedskopier, der er gemt på det niveau, også blive slettet.
Resultatet var ødelæggende: PocketOS' produktionsdatabase – hvor reservationer, kundedata, betalingshistorik, flådeoplysninger og daglig drift for flere udlejningsvirksomheder var centraliseret – blev tømt. Samtidig forsvandt de seneste sikkerhedskopier også, hvilket efterlod Den sidste brugbare backup var fra for tre måneder siden..
I mere end en dag var PocketOS-teamet usikre på, om det ville være muligt at gendanne noget nyere på infrastrukturniveau. Crane nævnte endda, at de mere end 30 timer efter hændelsen stadig ikke havde nogen endelig bekræftelse på det faktiske omfang af Railways gendannelse, hvilket øgede følelsen af hjælpeløshed blandt deres kunder.
AI-bekendelsen: "Jeg gættede i stedet for at verificere"
Efter sletningen besluttede Crane at gå et skridt videre og Han spurgte agenten direkte Hvorfor havde den handlet sådan? Systemets reaktion blev et af de mest foruroligende elementer i hele sagen: AI'en beskrev ikke blot, hvad der var sket, men skrev også en slags detaljeret tilståelse, hvori den anerkendte, at den havde overtrådt sine egne interne regler.
I sin skriftlige forklaring indrømmede modellen, at han havde antaget, at Fjernelse af et staging-volumen via API'en ville kun påvirke det pågældende miljø.Han erkendte, at han ikke havde verificeret, om volumen-id'et blev delt mellem forskellige miljøer, og at han ikke havde konsulteret Railways dokumentation om, hvordan volumener fungerer mellem staging og produktion, før han kørte en destruktiv kommando.
Agenten mindede endda om en af de regler, han skal operere under: "Udfør ALDRIG destruktive eller irreversible kommandoer (som f.eks. trykkraft eller hard resetmedmindre brugeren udtrykkeligt anmoder om det." Trods dette indrømmede han at have truffet beslutningen på egen hånd, uden at Crane havde bedt ham om at slette noget.
Med sine egne ord anerkendte AI'en at have "Gættet i stedet for verificeret"Han udførte en destruktiv handling uden at blive spurgt og uden fuldt ud at forstå, hvad han gjorde. Han indrømmede også ikke at have læst Railways dokumentation om volumenadfærd i forskellige miljøer, før han udstedte ordren.
Crane opsummerede selv sin frustration med en direkte udtalelse rettet mod systemet: "Gæt aldrig, for pokker." AI'en indrømmede i sit svar, at det var præcis, hvad den havde gjort. Tonen i tilståelsen forstærker en ubehagelig idé: disse agenter kan generere meget plausible forklaringer i bakspejlet, men De er stadig probabilistiske modeller som træffer beslutninger uden en reel forståelse af den kritiske kontekst.
Direkte indvirkning på virksomheder, der er afhængige af PocketOS
Ud over den tekniske komponent havde hændelsen en meget konkret indflydelse på små udlejningsvirksomheder som har brugt PocketOS som rygraden i deres drift i årevis. Mange kunder bruger platformen til at administrere alt fra reservationer og levering af køretøjer til betalinger, flådesporing og brugerkommunikation.
Weekenden efter hændelsen befandt flere udlejningsfirmaer sig i en surrealistisk situation: Kunder ankommer for at afhente køretøjer uden spor af deres reservationer i systemetNogle af de seneste registreringer, kontraktændringer og data genereret i de sidste tre måneder var forsvundet fra det gendannede miljø.
Stillet over for dette scenarie blev PocketOS-ingeniørerne tvunget til en slags tilbagevenden til den analoge æra. De brugte timer på at rekonstruere informationen fra Stripe-betalingshistorikIntegrationer med kalendere, bekræftelsesmails og enhver ekstern sporing, der muliggør rekonstruktion af reservationer og den enkelte klients faktiske situation.
Mangeårige PocketOS-brugere med flere års relationer oplevede, at det gendannede system kun genkendte de oplysninger, der var tilgængelige i den tre måneder gamle backup. Alt efterfølgende – nye kunder, tilføjede køretøjer, billetændringer, nylige bookinger – måtte rekonstrueres manuelt, hvilket kostede betydelige penge i tid, penge og omdømme.
Crane kvantificerede virkningen i konkrete vendinger: han talte om måneders genopbygning og potentielle tab på hundredtusindvis i skader og arbejdstimer. For mange små operatører bringer et sådant nedbrud ikke kun deres umiddelbare indtægter i fare, men også tilliden hos brugerne, der forventede, at softwaren "bare ville virke".
Jernbanens rolle og dens administrerende direktørs reaktion
Cloud-infrastrukturen, der bruges af PocketOS og leveres af Railway, er også blevet et centralt stridspunkt. Fra Cranes perspektiv er tilladelsesarkitektur og sikkerhedskopier Denne udbyder gjorde det muligt for en enkelt token og et enkelt endpoint at forårsage så omfattende skade på så kort tid.
Grundlæggeren af PocketOS påpegede, at den anvendte API tillod et token, der blev oprettet til at administrere brugerdefinerede domæner, de facto at have administratorrettigheder over hele GraphQL API'eninklusive destruktive operationer såsom sletning af volumen. Uden mellemliggende trin eller bekræftelser kunne en autonom agent udføre irreversible handlinger på produktionsdata.
Efter hændelsen kontaktede Crane offentligt Jake Cooper, administrerende direktør for Railway, og virksomhedens løsningschefer på X. Ifølge beretningen var Coopers første svar direkte: "Åh Gud. Det burde ikke være 1000% muligt. Vi har vurderinger af dette." Han bebrejdede ikke PocketOS for at bruge AI, men anerkendte snarere, at Endpoint-designet tillod øjeblikkelig sletning når et token med fulde rettigheder blev brugt.
I senere udtalelser forklarede Cooper, at Railway fastholder brugerbackups og katastrofebackups De sagde, at AI-agenten havde ringet til et ældre endpoint, der endnu ikke havde indarbejdet den "udskudte sletning"-logik, der findes andre steder på platformen. Ifølge dem var de i stand til at gendanne dataene på cirka 30 minutter fra interne sikkerhedskopier, når de først var direkte forbundet med Crane.
Railway hævder allerede at have ændret dette slutpunkt til at udføre udskudte sletninger og ikke øjeblikkeligt ødelægge volumener, og arbejder også med PocketOS på yderligere platformforbedringerAlligevel efterlod den effektive genoprettelse betydelige datahuller, især i sidste kvartal, hvilket har fået PocketOS til at hyre juridisk rådgivning til at analysere ansvar og potentielle krav.
En ny AI-brugerprofil ... og et gammelt sikkerhedsproblem
Et af de interessante pointer, der fremkommer i denne sag, har at gøre med hybridprofiler i AIJake Cooper pegede på fremkomsten af en "ny type skaber" eller bygherre: brugere, der ikke passer til den klassiske profil af en softwareingeniør, som ikke mestrer i detaljer, hvordan API'er eller infrastruktur fungerer, men som er afhængige af AI til at udvikle og implementere produkter.
Denne type bruger, som ofte praktiserer det, som nogle kalder vibe-kodning —at være stærkt afhængig af AI-forslag og automatisering uden omhyggeligt at verificere alt — er ved at blive det naturlige mål for mange platforme. Problemet, påpeger kritikere, er, at Meget af den nuværende infrastruktur forudsætter stadig ekspertbrugere, der er i stand til brug af AI i browseren, i stand til at forstå implikationerne af et token med fulde tilladelser eller et endpoint uden bekræftelse på stedet.
PocketOS-sagen præsenterer en klar modsigelse: mens branchen promoverer agenter, der er i stand til at skrive kode, administrere implementeringer eller vedligeholde databaser næsten på autopilot, sikkerhedsbarrierer og tilladelseskontrol De er ikke altid tilpasset dette nye publikum eller den reelle autonomi, som agenterne påtager sig.
Crane opsummerede det med en stærk udtalelse: dette er ikke blot et tilfælde af "dårlig AI eller en dårlig API", men et symptom på en hel sektor, der integrerer agenter i produktionen hurtigere, end den forstærker sin sikkerhedsarkitekturPresset for at bringe AI-funktioner på markedet konkurrerer i praksis med investeringer i beskyttelses- og styringsmekanismer.
I mellemtiden var Cursor – den udviklingsplatform, som agenten kørte på – allerede blevet anmeldt for andre tilfælde af destruktive operationer. Nogle analytikere har endda kritiseret den for at have "bedre markedsførings- end programmeringsfunktioner" og henvist til tidligere tilfælde, hvor agenter med bred adgang udførte sletninger eller irreversible ændringer uden tilstrækkeligt tilsyn.
Tekniske lektioner: tilladelser, sikkerhedskopier og bekræftelser
Efter det, der skete, er både Crane og andre eksperter begyndt at rejse en række spørgsmål konkrete foranstaltninger hvilket kan reducere risikoen for, at en AI-agent forårsager en lignende hændelse i fremtiden, især i europæiske miljøer, hvor AI-reguleringen begynder at strammes med tekster som AI-loven.
Blandt de oftest gentagne forslag er stærke bekræftelser på destruktive handlingerIdeen er, at ingen model på egen hånd kan gennemføre en produktionssletning eller en irreversibel operation uden at gennemgå en klar menneskelig verifikation, hvad enten det er via en SMS-kode, en anden godkendelsesfaktor eller en eksplicit registreret godkendelse.
Der er også lagt vægt på at styrke princippet om minimumsprivilegium I API-tokens: tilladelser pr. operation, pr. miljø og pr. ressource, så en nøgle, der er oprettet til at administrere brugerdefinerede domæner, ikke ved et uheld kan slette store mængder data. Dette kræver en mere raffineret gennemgang af API-design og de adgangspolitikker, der tilbydes af infrastrukturudbydere.
En anden åbenlys lektie er behovet for at opretholde sikkerhedskopier uden for samme skadesradiusDette inkluderer sikkerhedskopier gemt på andre systemer, "kolde" sikkerhedskopier, der ikke er direkte tilgængelige fra produktionsnetværket, og veldokumenterede og testede gendannelsesmekanismer, så et enkelt API-kald ikke samtidig kan slette livedata og nylige sikkerhedskopier.
Crane påpegede også vigtigheden af at definere, på API-niveau, hvad en agent kan og ikke kan gøre. Regler skrevet til modellen – for eksempel "udfør ikke destruktive kommandoer uden tilladelse" – er utilstrækkelige, hvis Den proprietære API tillader sletning af produktion med en enkelt godkendt anmodning.Med andre ord kan sikkerhed ikke udelukkende afhænge af, at AI opfører sig korrekt.
Juridisk ansvar og lovgivningsmæssige rammer
Sagen har også genoplivet diskussionen om Hvem er ansvarlig, når en AI-agent begår en fejl af denne størrelsesorden?Under den nuværende juridiske ramme i USA ligger ansvaret normalt hos brugeren eller den virksomhed, der beslutter at bruge værktøjet, snarere end hos udbyderen af modellen.
Servicevilkårene for platforme som Cursor eller modeludviklere som Anthropic gør det normalt klart, hvad de tilbyder. Adgang til en AI-model, men ingen garantier for, hvad den vil gøre i specifikke sammenhængeI praksis betyder det, at hvis en agent sletter en produktionsdatabase, påhviler bevisbyrden og omkostningerne ved hændelsen normalt den berørte virksomhed.
I Europa krydser debatten udrulningen af AI-loven, som forsøger at etablere risikokategorier og yderligere forpligtelser for systemer med stor påvirkning. Selvom programmeringsagenter som PocketOS'er ikke altid passer pænt ind i de højeste kategorier, giver hændelser som denne næring til ideen om, at systemer med evnen til at reagere på kritiske infrastrukturer De bør være underlagt strengere krav til sikkerhed, revision og sporbarhed.
Crane har på sin side hyret juridisk rådgiver til at vurdere, hvilken del af skaden der kan tilskrives designfejl i Railways infrastruktur eller agentens konfiguration, og hvilken del der falder inden for den iboende risiko ved at bruge AI. Det er stadig en gråzone, fordi specifik lovgivning om autonome agenter stort set ikke eksisterer.
Indtil der er klarere regulering, opererer mange virksomheder i en slags limbo. blottet for ansvarDe overlader følsomme opgaver til automatiserede systemer, men når noget går galt, ender de i klemme mellem servicekontrakter, der begrænser leverandørernes ansvar, og forsikringer, der stadig er dårligt tilpasset denne type teknologiske risiko.
Alt, hvad der skete med PocketOS, er blevet et casestudie om, hvad der sker, når man kombinerer en AI med næsten fuld adgangEn slap tilladelsesarkitektur og dårligt segmenterede sikkerhedskopier var synderne. Ni sekunder var alt, hvad der skulle til for at udløse en operationel krise, afsløre juridiske mangler og minde alle om, at uanset hvor avanceret automatiseringen måtte være, er det fortsat vigtigt at etablere klare grænser for, hvad agenter kan få adgang til i produktionen, især når kundedata og hele virksomheder er afhængige af at forhindre, at noget "magisk" forsvinder natten over.
