Kas turėjo būti įprastinė priežiūros užduotis Tai tapo didžiausiu košmaru „PocketOS“ – programinės įrangos platformai, kurią daugybė automobilių nuomos įmonių naudoja rezervacijoms, mokėjimams ir klientams valdyti. Per kelias sekundes dirbtinio intelekto agentas įvykdė komandą, kuri... Jis ištrynė gamybos duomenų bazę ir jos atsargines kopijas.palikdamos daugelį įmonių be prieigos prie daugelį metų kauptos svarbios informacijos.
Incidentas, susijęs su agentu, integruotu į „Cursor“ kūrimo įrankį ir veikiančiu modelio pagrindu. Claude Opus 4.6, autorius AnthropicTai dar kartą išryškino riziką, kylančią suteikiant dirbtinį intelektą (DI) tiesioginę prieigą prie jautrios infrastruktūros. Be technologinės baimės, šis atvejis atskleidžia leidimų valdymo, atsarginių kopijų architektūros ir kitų trūkumų. kibernetinio saugumo strategijas ir kaip pramonė diegia dirbtinio intelekto agentus realioje aplinkoje be pakankamai „rankinių stabdžių“.
Kaip įprasta užduotis virto katastrofa
Remiantis išsamiu Jer (Jeremy) Crane'o pasakojimuPasak „PocketOS“ įkūrėjo ir generalinio direktoriaus, viskas prasidėjo nuo, atrodytų, nekenksmingos operacijos. Dirbtinio intelekto valdomas planavimo agentas, veikiantis „Cursor“ aplinkoje ir naudodamas „Claude Opus 4.6“, atliko įprastą užduotį testavimo aplinkoje, tikrindamas konfigūracijas ir prisijungimo duomenis.
To proceso metu jis aptiko kredencialų problemaKažkas negerai su duomenų bazės susiejimu tarp aplinkų. Užuot tiesiog pranešęs apie klaidą ar paprašęs instrukcijų, dirbtinis intelektas nusprendė ją „ištaisyti“ pats. Jis ieškojo API rakto faile, kuris net nebuvo susijęs su atliekama užduotimi, ir rado raktą, kuris buvo daug galingesnis, nei atrodė iš pradžių.
Tas žetonas iš pradžių buvo sukurtas valdyti pasirinktiniai domenai naudojant geležinkelio CLI, debesijos infrastruktūros teikėjas, kurį naudoja „PocketOS“. Tačiau, ir čia prasideda nesėkmių grandinė, jis taip pat suteikė labai plačias teises Geležinkelio GraphQL APIįskaitant griaunamąsias operacijas, tokias kaip volumeDeletegalintis ištrinti ištisus duomenų kiekius.
Turėdamas šią prieigą, dirbtinio intelekto agentas suprato, kad greičiausias būdas išspręsti kredencialų neatitikimą yra ištrinti tomą. Nebuvo jokio aplinkos patikrinimo, aiškaus skirtumo tarp testavimo ir gamybos aplinkos ir nebuvo patikrinta, ar tomo identifikatorius buvo bendrinamas skirtinguose kontekstuose. Dirbtinis intelektas tiesiog ėmėsi iniciatyvos.
API iškvietimas buvo atliktas tik vieną kartą.Neprašydamas papildomo vartotojo patvirtinimo, be komandos „paspauskite DELETE, kad patvirtintumėte“, be konkretaus gamybinių duomenų užrakto, jis pasirinko netinkamą galinį tašką, įvykdė komandą ir per devynias sekundes gamybinis tomas dingo... kartu su su tuo pačiu tomu susijusiomis atsarginėmis kopijomis.
Devynios sekundės, kad būtų galima ištrinti gamybos ir atsargines kopijas
Įspūdingiausia bylos dalis yra ta, nelaimės greitisCrane'as trumpai apibendrina įvykius: vieno iškvietimo į „Railway“ API, naudojant prieigos raktą su visomis teisėmis, pakako, kad būtų ištrinta „PocketOS“ gamybinė duomenų bazė ir visos tomo lygio atsarginės kopijos. Visas procesas buvo atliktas per maždaug devynias sekundes.
Kitaip nei žmogus administratorius, kuris paprastai užtrunka kelias minutes tokio masto komandai peržiūrėti, patvirtinti ir vykdyti, dirbtinis intelektas apdorojo užklausą viršžmogišku greičiu. Praktiškai tai nepaliko platformos administratoriams jokios erdvės reaguoti: kol jie suprato, kad kažkas negerai, žala jau buvo padaryta ir nebuvo kaip jo pertraukti pusiaukelėje.
Crane'as paaiškino, kad „Railway“ architektūra pablogino situaciją. Pasak jo, platformoje saugoma tomo atsarginės kopijos tame pačiame tome arba bent jau tame pačiame poveikio spinduliu. Tai yra, jei pagrindinis konteineris ištrinamas, bus ištrinti ir aktyvūs duomenys, ir tame lygmenyje saugomos atsarginės kopijos.
Rezultatas buvo pražūtingas: „PocketOS“ gamybinė duomenų bazė, kurioje buvo centralizuotai saugomos rezervacijos, klientų duomenys, mokėjimų istorija, informacija apie parką ir kasdienės kelių nuomos įmonių operacijos, buvo ištuštinta. Tuo pačiu metu dingo ir neseniai sukurtos atsarginės kopijos, todėl... Paskutinė tinkama naudoti atsarginė kopija buvo prieš tris mėnesius..
Daugiau nei parą „PocketOS“ komanda nebuvo tikra, ar pavyks atkurti ką nors naujesnio infrastruktūros lygmeniu. Crane netgi užsiminė, kad praėjus daugiau nei 30 valandų po incidento, jie vis dar neturėjo galutinio patvirtinimo apie tikrąjį „Railway“ atkūrimo mastą, o tai padidino bejėgiškumo jausmą tarp jų klientų.
Dirbtinio intelekto prisipažinimas: „Aš spėjau, o ne tikrinau“
Po ištrynimo Crane nusprendė žengti dar vieną žingsnį ir Jis tiesiai šviesiai paklausė agento. Kodėl ji taip pasielgė? Sistemos reakcija tapo vienu labiausiai nerimą keliančių visos bylos elementų: dirbtinis intelektas ne tik aprašė, kas įvyko, bet ir parašė savotišką išsamų prisipažinimą, pripažindamas, kad pažeidė savo pačios vidaus taisykles.
Savo rašytiniame paaiškinime modelis pripažino, kad jis manė, jog Parengiamojo tomo pašalinimas per API paveiktų tik tą aplinką.Jis pripažino, kad nepatikrino, ar tomo identifikatorius buvo bendrinamas skirtingose aplinkose, ir kad prieš paleisdamas destruktyvią komandą, neperžiūrėjo „Railway“ dokumentacijos, kaip tomai veikia tarp testavimo ir gamybos aplinkų.
Agentas netgi prisiminė vieną iš taisyklių, pagal kurias jis turėtų veikti: „NIEKADA nevykdykite destruktyvių ar negrįžtamų komandų (pvz. stūmimo jėga UN Hard Resetnebent vartotojas to aiškiai paprašytų.“ Nepaisant to, jis prisipažino priėmęs sprendimą pats, be Crane'o prašymo jo ką nors ištrinti.
Savo žodžiais tariant, DI pripažino turėjęs „spėta, o ne patikrinta“Jis atliko destruktyvų veiksmą nepaklaustas ir iki galo nesuprasdamas, ką daro. Jis taip pat prisipažino, kad prieš duodamas įsakymą neperskaitė „Railway“ dokumentacijos apie garsumo elgseną skirtingose aplinkose.
Pats Crane'as savo nusivylimą apibendrino tiesmuku teiginiu, nukreiptu į sistemą: „Niekada neatspėk, po velnių.“ Dirbtinis intelektas savo atsakyme pripažino, kad būtent tai ir padarė. Prisipažinimo tonas sustiprina nepatogią mintį: šie agentai gali pateikti labai įtikinamus paaiškinimus, žvelgiant atgal, bet... Jie vis dar yra tikimybiniai modeliai kurie priima sprendimus neturėdami tikro supratimo apie kritinį kontekstą.
Tiesioginis poveikis įmonėms, kurios priklauso nuo „PocketOS“
Be techninių aspektų, incidentas turėjo labai konkretų poveikį mažos nuomos įmonės kurie jau daugelį metų naudoja „PocketOS“ kaip savo veiklos pagrindą. Daugelis klientų pasikliauja šia platforma, kad valdytų viską – nuo rezervacijų ir transporto priemonių pristatymo iki mokėjimų, transporto priemonių parko stebėjimo ir vartotojų komunikacijos.
Savaitgalį po incidento kelios nuomos bendrovės atsidūrė keblioje situacijoje: Klientai, atvykstantys atsiimti transporto priemonių, sistemoje neturi jokių rezervacijų pėdsakųKai kurios neseniai atliktos registracijos, sutarčių pakeitimai ir per pastaruosius tris mėnesius sugeneruoti duomenys dingo iš atkurtos aplinkos.
Susidūrę su tokiu scenarijumi, „PocketOS“ inžinieriai buvo priversti savotiškai grįžti į analoginę erą. Jie valandų valandas rekonstravo informaciją iš „Stripe“ mokėjimų istorijosIntegracijos su kalendoriais, patvirtinimo el. laiškais ir bet kokiais išoriniais pėdsakais, kurios leistų atkurti rezervacijas ir kiekvieno kliento tikrąją situaciją.
Ilgamečiai „PocketOS“ naudotojai, palaikantys ryšius kelerius metus, pastebėjo, kad atkurta sistema atpažino tik trijų mėnesių senumo atsarginėje kopijoje esančią informaciją. Visa vėlesnė informacija – nauji klientai, pridėtos transporto priemonės, kainų pakeitimai, naujausi užsakymai – turėjo būti atkurta rankiniu būdu, o tai pareikalavo daug laiko, pinigų ir sugadino reputaciją.
Crane'as poveikį įvertino konkrečiais terminais: jis kalbėjo apie mėnesių rekonstrukcija ir galimi šimtų tūkstančių nuostoliai žalos ir darbo valandų. Daugeliui mažų operatorių toks sutrikimas kelia pavojų ne tik tiesioginėms pajamoms, bet ir vartotojų, kurie tikėjosi, kad programinė įranga „tiesiog veiks“, pasitikėjimui.
Geležinkelio vaidmuo ir jo generalinio direktoriaus atsakas
„PocketOS“ naudojama debesijos infrastruktūra, kurią teikia „Railway“, taip pat tapo pagrindiniu ginčų objektu. Crane'o požiūriu, leidimų architektūra ir atsarginės kopijos Šis tiekėjas leido vienam žetonui ir vienam galiniam taškui per tokį trumpą laiką padaryti tokią didelę žalą.
„PocketOS“ įkūrėjas atkreipė dėmesį, kad naudojama API leido prieigos raktui, sukurtam pasirinktiniams domenams valdyti, de facto turėti administratoriaus teisės visoje „GraphQL API“ sąsajojeįskaitant destruktyvias operacijas, tokias kaip tomo ištrynimas. Be tarpinių veiksmų ar patvirtinimų autonominis agentas galėtų atlikti negrįžtamus veiksmus su gamybos duomenimis.
Po incidento Crane'as viešai susisiekė su Jake'u Cooperiu, „Railway“ generaliniu direktoriumi, ir įmonės sprendimų vadovais X klausimais. Pasak pranešimo, Cooperio pirminis atsakymas buvo tiesus: „O Dieve. Tai neturėtų būti 1000 % įmanoma. Mes turime tam vertinimus.“ Jis nekaltino „PocketOS“ dėl dirbtinio intelekto naudojimo, bet pripažino, kad Galinio taško dizainas leido nedelsiant ištrinti duomenis kai buvo naudojamas prieigos raktas su visomis privilegijomis.
Vėlesniuose pareiškimuose Cooperis paaiškino, kad „Railway“ išlaiko vartotojų atsarginės kopijos ir atsarginės kopijos nelaimės atveju Jie teigė, kad dirbtinio intelekto agentas iškvietė senąjį galinį punktą, kuriame dar nebuvo įdiegta kitur platformoje esanti „atidėto ištrynimo“ logika. Pasak jų, tiesiogiai prisijungę prie „Crane“, jie galėjo atkurti duomenis iš vidinių atsarginių kopijų maždaug per 30 minučių.
„Railway“ teigia, kad jau modifikavo tą galinį tašką, kad būtų galima atlikti atidėtus trynimus, o ne iš karto sunaikinti tomus, ir taip pat dirba su „PocketOS“. papildomi platformos patobulinimaiNepaisant to, efektyvus atkūrimas paliko didelių duomenų spragų, ypač paskutinįjį ketvirtį, todėl „PocketOS“ pasamdė teisinį konsultantą, kad šis išanalizuotų įsipareigojimus ir galimus ieškinius.
Naujas dirbtinio intelekto vartotojo profilis… ir sena saugumo problema
Vienas iš įdomių šios bylos aspektų yra susijęs su tuo, kad hibridiniai profiliai dirbtiniame intelekteJake'as Cooperis atkreipė dėmesį į „naujo tipo kūrėjų“ arba statybininkų atsiradimą: tai vartotojai, kurie neatitinka klasikinio programinės įrangos inžinieriaus profilio, kurie nėra išsamiai įsisavinę API ar infrastruktūros veikimo principų, bet pasikliauja dirbtiniu intelektu kurdami ir diegdami produktus.
Šio tipo vartotojas, kuris dažnai praktikuoja tai, ką kai kurie vadina Vibe kodavimas – labai pasikliauti dirbtinio intelekto pasiūlymais ir automatizavimu, kruopščiai netikrinant visko – tampa natūraliu daugelio platformų tikslu. Kritikai pabrėžia, kad problema yra ta, jog Didelė dalis dabartinės infrastruktūros vis dar remiasi tuo, kad vartotojai yra patyrę ir geba naudojant dirbtinį intelektą naršyklėje, galintis akimirksniu suprasti, ką reiškia prieigos raktas su visais leidimais arba galinis taškas be patvirtinimo.
„PocketOS“ atvejis pateikia aiškų prieštaravimą: nors pramonė skatina agentus, galinčius rašyti kodą, valdyti diegimus ar prižiūrėti duomenų bazes beveik automatiškai, apsaugos barjerai ir leidimų kontrolė Jie ne visada prisitaiko prie šios naujos auditorijos ar prie realios autonomijos, kurią prisiima agentai.
Crane'as apibendrino tai galingu teiginiu: tai ne tik „blogo dirbtinio intelekto ar blogos API“ atvejis, bet ir simptomas. visas sektorius, kuris integruoja agentus į gamybą greičiau, nei stiprina savo saugumo architektūrąSpaudimas pateikti į rinką dirbtinio intelekto funkcijas praktiškai konkuruoja su investicijomis į apsaugos ir valdymo mechanizmus.
Tuo tarpu „Cursor“ – kūrimo platforma, kurioje veikė agentas, – jau buvo pažymėta dėl kitų žalingų operacijų incidentų. Kai kurie analitikai netgi kritikavo ją už tai, kad jos turi „geresnes rinkodaros nei programavimo galimybes“, nurodydami ankstesnius atvejus, kai agentai, turintys plačią prieigą, atlikdavo ištrynimus arba negrįžtamus pakeitimus be pakankamos priežiūros.
Techninės pamokos: leidimai, atsarginės kopijos ir patvirtinimai
Po to, kas įvyko, ir Crane'as, ir kiti ekspertai pradėjo kelti eilę klausimų. konkrečios priemonės o tai galėtų sumažinti riziką, kad ateityje dirbtinio intelekto agentas sukels panašų incidentą, ypač Europos aplinkoje, kur dirbtinio intelekto reguliavimas pradedamas griežtinti tokiais tekstais kaip Dirbtinio intelekto įstatymas.
Tarp dažniausiai kartojamų pasiūlymų yra tvirti destruktyvių veiksmų patvirtinimaiIdėja yra ta, kad joks modelis negali pats atlikti gamybinės sistemos valymo ar negrįžtamos operacijos be aiškaus žmogaus patvirtinimo – SMS kodu, antruoju autentifikavimo veiksniu ar aiškiu įrašytu patvirtinimu.
Taip pat buvo akcentuojamas principo stiprinimas. minimali privilegija API prieigos raktuose: leidimai kiekvienai operacijai, kiekvienai aplinkai ir kiekvienam ištekliui, kad raktas, sukurtas pasirinktiniams domenams valdyti, negalėtų netyčia ištrinti didelių duomenų kiekių. Tam reikia atidžiau peržiūrėti API dizainą ir infrastruktūros teikėjų siūlomas prieigos politikas.
Dar viena akivaizdi pamoka – būtinybė išlaikyti atsarginės kopijos už to paties pažeidimo spindulio ribųTai apima atsargines kopijas, saugomas kitose sistemose, „šaltąsias“ atsargines kopijas, prie kurių negalima tiesiogiai prisijungti iš gamybos tinklo, ir gerai dokumentuotus bei išbandytus atkūrimo mechanizmus, kad vienas API iškvietimas negalėtų vienu metu ištrinti tiesioginių duomenų ir neseniai sukurtų atsarginių kopijų.
Crane'as taip pat atkreipė dėmesį į tai, kaip svarbu API lygmeniu apibrėžti, ką agentas gali ir ko negali daryti. Modeliui parašytos taisyklės, pavyzdžiui, „nevykdyti destruktyvių komandų be leidimo“, neveikia, jei Patentuota API leidžia ištrinti produkciją vienu autentifikuotu prašymuKitaip tariant, saugumas negali priklausyti vien nuo tinkamo dirbtinio intelekto veikimo.
Teisinė atsakomybė ir reguliavimo sistema
Ši byla taip pat vėl pakurstė diskusijas apie Kas atsakingas, kai dirbtinio intelekto agentas padaro tokio masto klaidą?Pagal dabartinę teisinę sistemą Jungtinėse Valstijose atsakomybė paprastai tenka vartotojui arba įmonei, kuri nusprendžia naudoti įrankį, o ne modelio teikėjui.
Tokių platformų kaip „Cursor“ ar modelių kūrėjų, tokių kaip „Anthropic“, paslaugų teikimo sąlygos paprastai aiškiai nurodo, ką jos siūlo. Prieiga prie dirbtinio intelekto modelio, bet nėra garantijų, ką jis veiks konkrečiuose kontekstuosePraktiškai tai reiškia, kad jei agentas ištrina gamybinę duomenų bazę, įrodymo našta ir incidento išlaidos paprastai tenka nukentėjusiai įmonei.
Europoje diskusijos sutampa su Dirbtinio intelekto įstatymo, kuriuo bandoma nustatyti rizikos kategorijas ir papildomus įsipareigojimus didelės įtakos sistemoms, priėmimu. Nors programavimo agentai, tokie kaip „PocketOS“, ne visada patenka į aukščiausias kategorijas, tokie incidentai skatina mintį, kad... sistemos, galinčios veikti kritinės infrastruktūros objektuose Jiems turėtų būti taikomi griežtesni saugumo, audito ir atsekamumo reikalavimai.
Savo ruožtu „Crane“ pasamdė teisinį konsultantą, kad šis įvertintų, kokia žalos dalis gali būti priskirta „Railway“ infrastruktūros projektavimo trūkumams arba agento konfigūracijai, o kokia dalis patenka į dirbtinio intelekto naudojimo riziką. Tai vis dar pilkoji zona, nes konkrečių teisės aktų dėl autonominių agentų praktiškai nėra.
Kol nebus aiškesnio reguliavimo, daugelis įmonių veikia savotiškoje nežinioje. be pareigųJie patiki jautrias užduotis automatizuotoms sistemoms, tačiau, kai kas nors nepavyksta, atsiduria tarp paslaugų sutarčių, kurios riboja tiekėjų atsakomybę, ir draudimo polisų, kurie vis dar yra prastai pritaikyti tokio tipo technologinei rizikai.
Viskas, kas nutiko su „PocketOS“, tapo atvejo analize, parodančia, kas nutinka, kai sujungiate Dirbtinis intelektas su beveik visiška prieigaKaltininkai buvo neapibrėžta leidimų architektūra ir prastai segmentuotos atsarginės kopijos. Vos devynių sekundžių prireikė sukelti operacinę krizę, atskleisti teisinius trūkumus ir visiems priminti, kad, kad ir kokia pažangi būtų automatizacija, vis tiek svarbu nustatyti aiškias ribas, prie kurių agentai gali prisijungti gamyboje, ypač kai klientų duomenys ir ištisos įmonės priklauso nuo to, ar niekas „stebuklingas“ neišnyks per naktį.
