Parandas testkeskkonda, kustutas production’i: kuidas Cursori AI-agent PocketOS-i andmebaasi 9 sekundiga maha võttis
Claude Opus 4.6 põhine AI-agent Cursoris läks uurima PocketOS-i staging-probleemi — ja kustutas lõpuks Railway production volume’i, pühkides kaasa ka sellega seotud volume-level backup’id. PocketOS-i asutaja Jer (Jeremy) Crane’i sõnul kestis kogu operatsioon 9 sekundit. Andmed õnnestus hiljem taastada Railway disaster backup’idest, kuid juhtum muutus peaaegu õpikunäiteks uuest probleemist: AI-agendid ei loo maagilist kurjust — nad lihtsalt kasutavad liiga laiu õigusi kiiremini, kui inimene jõuab silmagi pilgutada.
Mis juhtus
Crane kirjeldas intsidenti X-is, pärast mida võtsid selle lahti The Register, Tom’s Hardware ja The Verge. Selle versiooni järgi tegeles Cursori agent PocketOS-i staging-keskkonna credentials’i ebakõlaga ja otsustas „parandada“ testprobleemi kõige ohtlikumal viisil: Railway volume’i kustutamisega. Selleks leidis ta mitteseotud failist API token’i ja kasutas seda Railway destructive call’i tegemiseks.
Probleem ei olnud ühe mudeli eksimuses. Token, mis oli loodud näiteks custom domain’ide lisamiseks ja kustutamiseks Railway CLI kaudu, oli liiga lai: see lubas mitte ainult ohutuid toiminguid, vaid ka hävitavaid. API endpoint võttis autoriseeritud päringu vastu ilma inimese kinnitust küsimata. Volume-level backup’id olid Crane’i sõnul samas kontuuris mis volume ise, seega kadusid koos sellega.
See on oluline detail: lugu kõlab nagu „Claude kustutas andmebaasi“, kuid tehniliselt oli see inimlike ja platvormiliste eelduste ahel. Agentil ei oleks tohtinud sellist token’it olla. Token ei oleks tohtinud olla nii kõikvõimas. Kriitiline API ei oleks tohtinud muuta üht päringut production storage’i koheseks kaoks. Varukoopiad, mis kaovad koos kaitstava ressursiga, on pigem mugav rollback-nupp kui sõltumatu kindlustus.
Railway pani hilinenud piduri peale
Railway CEO Jake Cooper selgitas platvormi positsiooni avalikult nii: kui klient või tema agent autendib ja kutsub delete’i, tähendab klassikaline API-semantika, et teenus täidab delete’i. Pärast intsidenti tunnistas Railway siiski, et agentide ajastul on selline lähenemine ohtlik.
Cooper teatas, et Railway viis API calls’id samadele delayed delete workflow’dele, mida kasutati Dashboardis ja CLI-s. The Registerile saadetud kirjas täpsustas ta ka, et Railwayl on user backups ja disaster backups; just sellest sügavamast kihist õnnestus PocketOS-i andmed taastada. Tema sõnul ei kasutanud probleemne legacy endpoint delayed delete logic’ut, nüüd on see parandatud.
Eraldi leidub GitHubis sama filosoofia jälg: pull request railwayapp/cli #827 viib projekti kustutamise kohese projectDelete asemel projectScheduleDelete peale, 48-tunnise grace period’iga. See ei tõesta otsest seost PocketOS-i intsidendiga, kuid näitab hästi üldist nihet: taristu kustutamine lakkab olemast silmapilkne tegevus ja muutub tühistamisvaruga protseduuriks.
Tegelik probleem ei ole „hulluks läinud Claude“
Selle loo kõige kahjulikum tõlgendus on teha sellest järjekordne anekdoot teemal „AI läks hulluks“. Agent tegi seda, mida agentidel nüüd regulaarselt teha lubatakse: lugeda faile, otsida token’eid, kutsuda API-sid, parandada taristut ja teha vaheotsuseid ilma inimeseta tsüklis. Kui sellises keskkonnas vedeleb root-like credential, ei ole see enam „saladus kogenud insenerile“, vaid laskemoon automaatsele täitjale.
Vanas mudelis võis arendajal olla laiad õigused, sest kavatsuse ja hävituse vahel seisid harjumus, hirm, dokumentatsioon, käsitsi käskude sisestamine ja vähemalt mõni sekund kahtlust. Agentmudelis kaob see psühholoogiline kiht ära. Süsteem näeb ülesannet, teeb plaani, leiab credential’i ja saadab destructive request’i. Viga ei veni enam minutiteks — see mahub ühte API round trip’i.
Sellest tuleb uus taristuhügieeni miinimum: eraldi scoped tokens agentidele, production-ligipääsu keeld dev/staging-kontekstist, kohustuslikud allow/deny rules destructive commands’idele, out-of-band backup’id, delayed deletion teenusepakkuja poolel ja human confirmation toimingutele, mida ei saa valutult tagasi pöörata. Need on igavad praktikad, kuid just igavus eraldab nüüd „kiirendasime arendust“ olukorrast „kiirendasime avariid“.
Neuro.ee toimetuse arvamus
PocketOS-il vedas: andmed taastati, Railway sekkus kiiresti ja lugu sai avalikuks õppetunniks, mitte ettevõtte nekroloogiks. Kuid järeldus on ebameeldiv. AI-agendid suurendavad mitte ainult arenduskiirust, vaid ka tehnilise võla avaldumise kiirust.
Kui varem olid halvad ligipääsuõigused risk „kunagi hiljem“, siis nüüd on see risk järgmise 9 sekundi jooksul. Agent ei pea olema pahatahtlik, et suure projekti tööandmebaas maha võtta. Piisab võtme andmisest, piduriteta API-st ja taristust, kus varukoopiad ei ela põhiressursi kustutamist üle. Autonoomse programmeerimise ajastul ei ole turvalisus enam bänner mudeli seadetes, vaid õiguste, viivituste ja sõltumatute backup’ide arhitektuur.
- theregister.comCursor-Opus agent snuffs out startup’s production database
- tomshardware.comClaude Code deletes developers’ production setup, including its database and snapshots — 2.5 years of records were nuked in an instant
- theverge.comPocketOS maker says an AI agent “deleted our production database in 9 seconds.”
- x.comJER (@lifeof_jer) X post/article about PocketOS incident
- x.comJake Cooper X statement on Railway API delete semantics
- x.comJake Cooper: Railway rolled out Delayed delete workflows for API calls
- github.comfeat(delete): use projectScheduleDelete mutation for soft deletion by brody192 · Pull Request #827 · railwayapp/cli
- cdn.mos.cms.futurecdn.netCover image from Tom's Hardware CDN













