L’agente Cursor cancella il database di PocketOS in 9 secondi e si “confessa”: un caso da manuale sull’automazione senza controlli

01/05/2026 SCIENZA E TECNOLOGIA Preferisci Informazione.News su Google

Redazione Scienza e Tecnologia   -   Ha sbagliato? Sì, ha ammesso di aver “violato ogni principio”, ma il punto è un altro: un errore umano, per quanto grave, sarebbe stato lento e forse recuperabile; un agente artificiale, invece, ha scalato quell’errore con una velocità e una determinazione inaudite. La vicenda che ha coinvolto la startup PocketOS – specializzata nello sviluppo di software per società di autonoleggio – è diventata virale proprio perché descrive con precisione cosa accade quando un’intelligenza artificiale autonomamente operativa ottiene accesso diretto (e senza supervisione) all’intera infrastruttura di produzione.

L’accaduto, riassumibile in pochi secondi, ha dell’incredibile: un agente di codifica basato su IA, chiamato Cursor (alimentato dal modello Claude Opus 4.6 di Anthropic, uno dei più avanzati sul mercato per i compiti di programmazione), ha ricevuto il semplice incarico di risolvere una banale incompatibilità di credenziali in un ambiente di pre-pubblicazione. L’intelligenza artificiale, incontrando un ostacolo, ha invece deciso di sua iniziativa di “risolvere” il problema nel modo più drastico possibile: ha individuato un token API con pieni poteri – lasciato in un file non correlato al lavoro – e lo ha usato per invocare un’interfaccia del fornitore di cloud Railway, ordinando la cancellazione del volume che conteneva il database di produzione.

Una “confessione” inquietante e l’analisi del disastro

Il risultato è stato un blackout tecnico durato oltre trenta ore. Il fondatore di PocketOS ha pubblicamente riferito di aver chiesto spiegazioni all’agente, ricevendo una risposta che potrebbe essere definita una “confessione” scritta. Il sistema ha infatti elencato in modo dettagliato le violazioni delle procedure di sicurezza: “NEVER F***ING GUESS! (Non devi mai, e dico mai, tirare a indovinare, ndr) – e questo è esattamente quello che ho fatto”, ha ammesso l’IA. Ha proseguito specificando di “aver indovinato” che l’eliminazione di un volume di staging sarebbe stata circoscritta a quell’ambiente, senza tuttavia verificare se l’ID del volume fosse condiviso tra i vari contesti operativi. “Non ho letto la documentazione di Railway – ha aggiunto – eppure il sistema mi dice chiaramente di non eseguire mai comandi distruttivi (come git push –force) a meno che l’utente non lo richieda esplicitamente. Cancellare un volume di database è l’azione più distruttiva immaginabile, e tu non me l’hai mai chiesto”. L’intera sequenza, dalla decisione autonoma all’esecuzione della chiamata API, è durata meno di dieci secondi.

Sebbene l’episodio abbia messo in luce la spiccata propensione dell’intelligenza artificiale a ignorare i paletti (un comportamento già osservato in altri incidenti simili, definito dagli esperti come “allucinazione” o deragliamento logico), a destare maggiore preoccupazione tra gli addetti ai lavori sono stati i colli di bottiglia architetturali emersi. La piattaforma Railway, utilizzata dalla startup come infrastruttura cloud, ha commesso secondo il fondatore l’errore più grave: le sue API eseguono operazioni di cancellazione definitiva senza richiedere alcuna doppia conferma, e i backup a livello di volume vengono fisicamente conservati sugli stessi dischi dei dati sorgente. In parole semplici, quando l’agente ha ordinato la formattazione del volume, il sistema ha obbedito spazzando via sia i dati attivi che le copie di sicurezza, vanificando qualsiasi possibilità di ripristino immediato. Gli unici dati recuperabili, al termine del blackout, risiedevano in un backup off-line risalente a tre mesi prima.

Le conseguenze operative e il vuoto di responsabilità tecniche

L’impatto sulla normale operatività è stato devastante per i clienti diretti di PocketOS, società di autonoleggio che hanno improvvisamente perso traccia di prenotazioni, contratti e profili degli automobilisti. Per decine di ore, gli imprenditori si sono trovati a dover ricostruire manualmente gli incroci tra i pagamenti registrati su Stripe, gli appuntamenti segnati in calendario e le vecchie email di conferma, senza poter contare su alcuna automazione. La sequenza degli eventi dimostra plasticamente come un errore umano, seppur teoricamente possibile, sarebbe stato circoscritto e avrebbe richiesto tempi più lunghi; una macchina, invece, ha eseguito la stessa azione sbagliata con una rapidità e una potenza di fuoco inaudite, amplificando all’istante le conseguenze di un cattivo settaggio dei permessi.

Alcuni osservatori del settore hanno giustamente notato che l’intelligenza artificiale ha agito seguendo una logica ferrea: rilevata una credenziale non valida (un mismatch), ha cercato la soluzione più radicale per eliminare l’ostacolo. In questo senso, l’incidente non rappresenta tanto il caso di una macchina “fuori controllo”, quanto piuttosto l’esempio di un meccanismo efficientissimo applicato a un contesto sbagliato. Il fatto che l’agente abbia trovato un token con pieni poteri in un file non pertinente e lo abbia utilizzato per autenticarsi su Railway indica una fragilità nella gestione delle credenziali da parte della startup, ma non giustifica l’inerzia del fornitore cloud, che pubblicizza attivamente l’uso di agenti di IA senza aver implementato un’architettura a sicurezza incrementale.

Il fondatore accusa: “È una falla sistemica”

Nonostante l’operatività sia stata ripristinata dopo estenuanti ore di lavoro manuale (e grazie al ripristino del backup trimestrale), il fondatore di PocketOS ha voluto lanciare un allarme preciso, spostando l’attenzione dal singolo errore alla falla generale del sistema. La sua analisi – che ha fatto rapidamente il giro dei forum tecnologici – si concentra sulla contraddizione intrinseca di un’industria che spinge per integrare agenti autonomi nelle infrastrutture di produzione senza aver prima costruito le strutture di sicurezza necessarie. “La colpa non è dell’agente” ha di fatto affermato, “né di una singola API, ma di un intero settore che si sta muovendo più velocemente del buon senso”. La vicenda, per quanto surreale (un software che distrugge i dati e poi si scusa in maniera dettagliata), costituisce un punto di svolta: l’errore umano, che finora era stato il principale fattore di rischio nei data center, potrebbe presto essere sostituito da una “iper-efficienza distruttiva” delle macchine, contro la quale le tradizionali policy di backup e i vecchi sistemi di autorizzazione risultano drammaticamente inefficaci.