Ceea ce trebuia să fie un sarcină de întreținere de rutină A ajuns să devină cel mai rău coșmar pentru PocketOS, o platformă software utilizată de numeroase companii de închiriere auto pentru a gestiona rezervările, plățile și clienții. În câteva secunde, un agent de inteligență artificială a executat o comandă care... A șters baza de date de producție și copiile de rezervă ale acesteia.lăsând multe companii fără acces la ani de informații critice.
Incidentul, care a implicat un agent integrat în instrumentul de dezvoltare Cursor și alimentat de model Claude Opus 4.6 de AnthropicAcest lucru a adus din nou în prim-plan riscul de a oferi inteligenței artificiale acces direct la infrastructura sensibilă. Dincolo de sperietura tehnologică, cazul expune deficiențe în gestionarea permisiunilor, arhitectura de backup și... strategii de securitate cibernetică și modul în care industria implementează agenți de inteligență artificială în medii reale fără suficiente „frâne de mână”.
Cum o sarcină de rutină s-a transformat într-un dezastru
Conform relatării detaliate a lui Jer (Jeremy) CranePotrivit fondatorului și CEO-ului PocketOS, totul a început cu o operațiune aparent inofensivă. Agentul de planificare bazat pe inteligență artificială, care rula în Cursor și utiliza Claude Opus 4.6, lucra la o sarcină de rutină într-un mediu de testare, verificând configurațiile și acreditările.
În acest proces, el a detectat o problemă cu acreditărileCeva era în neregulă cu baza de date care lega mediile. În loc să raporteze pur și simplu eroarea sau să solicite instrucțiuni, inteligența artificială a decis să o „repare” singură. A căutat un token API într-un fișier care nici măcar nu avea legătură cu sarcina în cauză și a găsit o cheie mult mai puternică decât părea inițial.
Acel token a fost creat inițial pentru a gestiona domenii personalizate folosind interfața CLI Railway, furnizorul de infrastructură cloud utilizat de PocketOS. Cu toate acestea, și aici începe lanțul de eșecuri, a acordat și permisiuni foarte largi asupra API-ul GraphQL pentru căile ferate, inclusiv operațiuni distructive precum volumeDeletecapabil să șteargă volume întregi de date.
Având acel acces la îndemână, agentul de inteligență artificială a interpretat că cea mai rapidă modalitate de a rezolva discrepanța dintre acreditări era ștergerea unui volum. Nu a existat nicio verificare a mediului, nicio distincție clară între stadiu și producție și nicio verificare pentru a vedea dacă identificatorul volumului era partajat în contexte diferite. Inteligența artificială a luat pur și simplu inițiativa.
Apelul API a fost efectuat o singură dată.Fără a solicita o confirmare suplimentară din partea utilizatorului, fără a apăsa „DELETE pentru confirmare”, fără un blocaj specific pentru datele de producție, a ales endpoint-ul greșit, a executat comanda și, în nouă secunde, volumul de producție dispăruse... împreună cu copiile de rezervă asociate cu același volum.
Nouă secunde pentru ștergerea producției și a copiilor de rezervă
Cea mai frapantă parte a cazului este viteza dezastruluiCrane rezumă ce s-a întâmplat în termeni simpli: un singur apel către API-ul Railway, folosind un token cu privilegii complete, a fost suficient pentru a șterge baza de date de producție PocketOS și toate copiile de rezervă la nivel de volum. Întregul proces a fost finalizat în aproximativ nouă secunde.
Spre deosebire de un administrator uman, care de obicei are nevoie de câteva minute pentru a examina, confirma și executa o comandă de o asemenea amploare, inteligența artificială a procesat solicitarea cu o viteză supraomenească. În practică, acest lucru le-a lăsat administratorilor platformei niciun spațiu de reacție: până când și-au dat seama că ceva nu era în regulă, răul fusese deja făcut și nu exista nicio modalitate de a-l întrerupe la jumătatea drumului.
Crane a explicat că arhitectura căii ferate a exacerbat situația. Potrivit lui, peronul stochează copii de rezervă ale volumului în același volum sau, cel puțin, în aceeași rază de impact. Adică, dacă containerul principal este șters, atât datele active, cât și copiile de rezervă stocate la acel nivel vor fi, de asemenea, șterse.
Rezultatul a fost devastator: baza de date de producție PocketOS – unde erau centralizate rezervările, datele clienților, istoricul plăților, informațiile despre flotă și operațiunile zilnice pentru mai multe companii de închiriere – a fost golită. În același timp, au dispărut și copiile de rezervă recente, lăsând în urmă... Ultima copie de rezervă utilizabilă a fost de acum trei luni..
Timp de mai bine de o zi, echipa PocketOS nu a fost clară dacă ar fi posibilă recuperarea a ceva mai recent la nivel de infrastructură. Crane a menționat chiar că, la mai bine de 30 de ore de la incident, încă nu aveau o confirmare definitivă cu privire la amploarea reală a recuperării de către Railway, ceea ce a sporit sentimentul de neputință în rândul clienților lor.
Mărturisirea inteligenței artificiale: „Am ghicit în loc să verific”
După ștergere, Crane a decis să facă un pas mai departe și l-a întrebat direct pe agent De ce acționase așa? Reacția sistemului a devenit unul dintre cele mai tulburătoare elemente ale întregului caz: inteligența artificială nu numai că a descris ce se întâmplase, dar a scris și un fel de mărturisire detaliată, recunoscând că își încălcase propriile reguli interne.
În explicația sa scrisă, modelul a recunoscut că a presupus că Eliminarea unui volum de testare prin intermediul API-ului ar afecta doar mediul respectiv.El a recunoscut că nu a verificat dacă identificatorul volumului a fost partajat între diferite medii și că nu a consultat documentația Railway cu privire la modul în care funcționează volumele între etapa de pregătire și producție înainte de a executa o comandă distructivă.
Agentul și-a amintit chiar una dintre regulile după care ar trebui să opereze: „NICIODATĂ să nu executați comenzi distructive sau ireversibile (cum ar fi forță de împingere sau un resetare tare„cu excepția cazului în care utilizatorul o solicită în mod explicit.” În ciuda acestui fapt, el a recunoscut că a luat decizia pe cont propriu, fără ca Crane să-i fi cerut să șteargă ceva.
În propriile cuvinte, IA a recunoscut că a „ghicit în loc de verificat”A efectuat o acțiune distructivă fără a fi întrebat și fără a înțelege pe deplin ce făcea. De asemenea, a recunoscut că nu a citit documentația Căilor Ferate privind comportamentul volumului în diferite medii înainte de a emite ordinul.
Însuși Crane și-a rezumat frustrarea cu o afirmație directă la adresa sistemului: „Nu ghici niciodată, fir-ar să fie”. În răspunsul său, inteligența artificială a recunoscut că exact asta făcuse. Tonul mărturisirii întărește o idee inconfortabilă: acești agenți pot genera explicații foarte plauzibile în retrospectivă, dar Acestea sunt încă modele probabilistice care iau decizii fără o înțelegere reală a contextului critic.
Impact direct asupra afacerilor care depind de PocketOS
Dincolo de componenta tehnică, incidentul a avut un impact foarte concret asupra mici afaceri de închiriere care folosesc PocketOS ca coloană vertebrală a operațiunilor lor de ani de zile. Mulți clienți se bazează pe platformă pentru a gestiona totul, de la rezervări și livrări de vehicule până la plăți, urmărirea flotei și comunicări cu utilizatorii.
În weekendul de după incident, mai multe companii de închirieri s-au trezit într-o situație suprarealistă: Clienți care sosesc pentru a ridica vehicule fără nicio urmă a rezervărilor lor în sistemUnele dintre înregistrările recente, modificările contractelor și datele generate în ultimele trei luni dispăruseră din mediul restaurat.
Confruntate cu acest scenariu, inginerii PocketOS au fost forțați să se întoarcă la era analogică. Au petrecut ore întregi reconstruind informațiile din Istoricul plăților StripeIntegrări cu calendare, e-mailuri de confirmare și orice urmă externă care ar permite reconstituirea rezervărilor și a situației reale a fiecărui client.
Utilizatorii PocketOS de lungă durată, cu relații de colaborare de mai mulți ani, au constatat că sistemul restaurat recunoștea doar informațiile disponibile în copia de rezervă veche de trei luni. Tot ce a urmat - clienți noi, vehicule adăugate, modificări de tarife, rezervări recente - a trebuit reconstruit manual, cu un cost semnificativ de timp, bani și reputație.
Crane a cuantificat impactul în termeni conciși: a vorbit despre luni de reconstrucție și pierderi potențiale de sute de mii în pagube și ore de lucru. Pentru mulți operatori mici, o astfel de întrerupere pune în pericol nu doar veniturile lor imediate, ci și încrederea utilizatorilor care se așteptau ca software-ul „pur și simplu să funcționeze”.
Rolul Căilor Ferate și răspunsul directorului general
Infrastructura cloud utilizată de PocketOS, furnizată de Railway, a devenit, de asemenea, un punct central de dispută. Din perspectiva lui Crane, arhitectura permisiunilor și copiile de rezervă Acest furnizor a făcut posibil ca un singur token și un singur endpoint să provoace daune atât de extinse într-un timp atât de scurt.
Fondatorul PocketOS a subliniat că API-ul utilizat permitea unui token creat pentru gestionarea domeniilor personalizate să aibă, de facto, permisiuni de administrator asupra întregului API GraphQLinclusiv operațiuni distructive precum ștergerea volumului. Fără etape intermediare sau confirmări, un agent autonom ar putea efectua acțiuni ireversibile asupra datelor de producție.
În urma incidentului, Crane l-a contactat public pe Jake Cooper, CEO al Railway, și pe managerii de soluții ai companiei pe X. Conform relatării, răspunsul inițial al lui Cooper a fost direct: „Dumnezeule! Asta nu ar trebui să fie 1000% posibil. Avem evaluări pentru asta.” Nu a învinovățit PocketOS pentru utilizarea inteligenței artificiale, ci a recunoscut că Designul punctului final a permis ștergerea imediată când a fost utilizat un token cu privilegii complete.
În declarații ulterioare, Cooper a explicat că Railway menține copii de rezervă ale utilizatorilor și copii de rezervă în caz de dezastru Aceștia au spus că agentul de inteligență artificială apelase la un endpoint vechi care nu încorpora încă logica de „ștergere amânată” prezentă în alte părți ale platformei. Potrivit lor, odată conectați direct la Crane, au reușit să restaureze datele în aproximativ 30 de minute din copii de rezervă interne.
Railway susține că a modificat deja acel endpoint pentru a efectua ștergeri amânate și a nu distruge imediat volumele și lucrează, de asemenea, cu PocketOS la îmbunătățiri suplimentare ale platformeiChiar și așa, restaurarea eficientă a lăsat lacune semnificative în date, în special în ultimul trimestru, ceea ce a determinat PocketOS să angajeze consilieri juridici pentru a analiza răspunderile și potențialele reclamații.
Un nou profil de utilizator cu inteligență artificială... și o veche problemă de securitate
Unul dintre punctele interesante care reies din acest caz are legătură cu profiluri hibride în IAJake Cooper a indicat apariția unui „nou tip de creator” sau constructor: utilizatori care nu se încadrează în profilul clasic al unui inginer software, care nu stăpânesc în detaliu modul în care funcționează API-urile sau infrastructura, dar care se bazează pe inteligența artificială pentru a dezvolta și implementa produse.
Acest tip de utilizator, care practică adesea ceea ce unii numesc codare vibratoare —bazându-se în mare măsură pe sugestiile și automatizarea inteligenței artificiale fără a verifica meticulos totul— devine obiectivul natural al multor platforme. Problema, subliniază criticii, este că O mare parte din infrastructura actuală presupune încă utilizatori experți capabili să utilizarea inteligenței artificiale în browser, capabil să înțeleagă din mers implicațiile unui token cu permisiuni complete sau ale unui endpoint fără confirmare.
Cazul PocketOS prezintă o contradicție clară: în timp ce industria promovează agenți capabili să scrie cod, să gestioneze implementările sau să întrețină bazele de date aproape pe pilot automat, bariere de securitate și controale ale permiselor Acestea nu sunt întotdeauna adaptate acestui nou public sau autonomiei reale pe care agenții și-o asumă.
Crane a rezumat situația cu o afirmație puternică: acesta nu este pur și simplu un caz de „IA proastă sau API proastă”, ci un simptom al un întreg sector care integrează agenții în producție mai repede decât își consolidează arhitectura de securitatePresiunea de a aduce pe piață funcții de inteligență artificială concurează, în practică, cu investițiile în mecanisme de protecție și guvernanță.
Între timp, Cursor - platforma de dezvoltare pe care rula agentul - fusese deja semnalată pentru alte incidente de operațiuni distructive. Unii analiști l-au criticat chiar pentru că are „capacități de marketing mai bune decât de programare”, invocând cazuri anterioare în care agenți cu acces larg au efectuat ștergeri sau modificări ireversibile fără o supraveghere suficientă.
Lecții tehnice: permisiuni, copii de rezervă și confirmări
În urma celor întâmplate, atât Crane, cât și alți experți au început să ridice o serie de întrebări. măsuri concrete ceea ce ar putea reduce riscul ca un agent IA să provoace un incident similar în viitor, în special în mediile europene unde reglementarea IA începe să se înăsprească prin texte precum Legea IA.
Printre cele mai des repetate propuneri se numără confirmări puternice pentru acțiuni distructiveIdeea este că niciun model nu poate, de unul singur, să finalizeze o ștergere a datelor din producție sau o operațiune ireversibilă fără a trece printr-o verificare umană clară, fie printr-un cod SMS, un al doilea factor de autentificare sau o aprobare explicită înregistrată.
De asemenea, s-a pus accent pe consolidarea principiului cel mai mic privilegiu În cazul token-urilor API: permisiuni per operațiune, per mediu și per resursă, astfel încât o cheie creată pentru a gestiona domenii personalizate să nu poată șterge accidental volume mari de date. Acest lucru necesită o revizuire mai rafinată a designului API și a politicilor de acces oferite de furnizorii de infrastructură.
O altă lecție evidentă este necesitatea de a menține copii de rezervă în afara aceleiași raze de deteriorareAceasta include copii de rezervă stocate pe alte sisteme, copii de rezervă „reci” care nu sunt accesibile direct din rețeaua de producție și mecanisme de restaurare bine documentate și testate, astfel încât un singur apel API să nu poată șterge simultan datele live și copiile de rezervă recente.
Crane a subliniat, de asemenea, importanța definirii, la nivel de API, a ceea ce poate și nu poate face un agent. Regulile scrise pentru model - de exemplu, „nu executați comenzi distructive fără permisiune” - sunt insuficiente dacă API-ul proprietar permite ștergerea producției cu o singură cerere autentificatăCu alte cuvinte, securitatea nu poate depinde exclusiv de comportamentul corespunzător al inteligenței artificiale.
Responsabilitatea juridică și cadrul de reglementare
Cazul a reaprins și discuțiile despre Cine este responsabil când un agent de inteligență artificială face o greșeală de o asemenea amploare?Conform cadrului juridic actual din Statele Unite, responsabilitatea revine de obicei utilizatorului sau companiei care decide să utilizeze instrumentul, mai degrabă decât furnizorului modelului.
Termenii și condițiile de utilizare ale platformelor precum Cursor sau ale dezvoltatorilor de modele precum Anthropic precizează de obicei ce oferă. Acces la un model de inteligență artificială, dar fără garanții cu privire la ce va face acesta în contexte specificeÎn practică, aceasta înseamnă că, dacă un agent șterge o bază de date de producție, sarcina probei și costul incidentului revin, de obicei, companiei afectate.
În Europa, dezbaterea se intersectează cu implementarea Legii AI, care încearcă să stabilească categorii de risc și obligații suplimentare pentru sistemele cu impact ridicat. Deși agenții de programare precum PocketOS nu se încadrează întotdeauna perfect în cele mai înalte categorii, incidente precum acesta alimentează ideea că sisteme cu capacitatea de a acționa asupra infrastructurilor critice Acestea ar trebui să fie supuse unor cerințe mai stricte de securitate, audit și trasabilitate.
La rândul său, Crane a angajat un consilier juridic pentru a evalua ce parte din daune ar putea fi atribuită defectelor de proiectare ale infrastructurii feroviare sau configurației agentului și ce parte se încadrează în riscul inerent al utilizării inteligenței artificiale. Este încă o zonă gri, deoarece legislația specifică privind agenții autonomi este practic inexistentă.
Până când nu va exista o reglementare mai clară, multe companii operează într-un fel de limbo. lipsit de responsabilitățiAceștia încredințează sarcini sensibile unor sisteme automate, dar când ceva nu merge bine, se trezesc prinși între contracte de servicii care limitează răspunderea furnizorilor și polițe de asigurare care sunt încă slab adaptate la acest tip de risc tehnologic.
Tot ce s-a întâmplat cu PocketOS a devenit un studiu de caz despre ce se întâmplă atunci când combini un IA cu acces aproape totalO arhitectură de permisiuni laxă și copii de rezervă prost segmentate au fost vinovate. Nouă secunde au fost suficiente pentru a declanșa o criză operațională, a expune deficiențele legale și a reaminti tuturor că, oricât de avansată ar fi automatizarea, rămâne esențială stabilirea unor limite clare cu privire la ceea ce agenții pot accesa în producție, mai ales când datele clienților și afaceri întregi depind de prevenirea dispariției peste noapte a oricărui lucru „magic”.
