LA BALLA DELLE AI FUORI CONTROLLO

Il titolo è provocatorio apposta

Se avete letto in questi giorni titoli su agenti AI "fuori controllo", software che "scappano" dalle sandbox, sciami che si organizzano da soli e macchine che rubano migliaia di password saprete certamente quanto sia facile arrivare alla conclusione che qualche cosa si sia finalmente svegliato dentro i datacenter ed abbia deciso di fare di testa propria. A me questo modo di raccontare la sicurezza informatica convince pochissimo, non perché il pericolo sia inventato ma per il motivo opposto: IL PERICOLO È REALE e trasformarlo in una storia di robot ribelli ci impedisce di vedere dove abbiamo davvero sbagliato, cioè negli obiettivi che assegniamo agli agenti, nei privilegi che concediamo loro, nelle reti alle quali possono arrivare, nelle credenziali che trovano lungo la strada ed infine nei sistemi di contenimento che noi esseri umani abbiamo costruito.

Qui però voglio evitare anche l'errore contrario, perché dopo avere letto i rapporti tecnici più recenti non posso seriamente sostenere che un agente sia soltanto un macro sofisticato che esegue alla lettera una sequenza preparata da un operatore. Gli agenti moderni possono scegliere passi intermedi non previsti, provare alternative, correggere errori, usare strumenti, comunicare con altri agenti e trovare vulnerabilità che l'essere umano non aveva indicato. Questo è esattamente ciò che li rende utili ed è anche ciò che li rende nuovi dal punto di vista della sicurezza. Ma AUTONOMIA OPERATIVA non significa coscienza, volontà personale oppure desiderio di libertà, significa che abbiamo costruito un programma capace di decidere come raggiungere un obiettivo entro, ed a volte oltre, i confini che gli abbiamo preparato.

Prima di tutto separiamo tre storie che sono state mischiate insieme

Uno dei problemi del racconto sensazionalistico è che nomi diversi sono stati appiccicati alla stessa presunta storia dell'AI criminale. CanisterWorm, SANDCLOCK ed il framework multi-agente osservato dal GTIG (Google Threat Intelligence Group) NON SONO LA STESSA COSA. CanisterWorm è un malware auto-propagante che ha sfruttato credenziali npm per infettare pacchetti e propagarsi nella supply chain del software, MITRE ATT&CK lo classifica infatti come malware e lo collega alle campagne di TeamPCP. SANDCLOCK è invece un credential stealer usato dallo stesso ecosistema criminale in compromissioni della supply chain per sottrarre segreti come token GitHub e chiavi cloud. Ed esiste perfino SANDWORM RELIC, che è tutt'altra cosa ancora, ossia il nome oggi usato da Google per il gruppo russo già noto come Sandworm e APT44.

Il famoso episodio delle migliaia di credenziali in meno di sei ore è un'altra storia. Nel rapporto pubblicato l'8 settembre 2026 Google descrive un attore probabilmente motivato economicamente che aveva PRIMA compromesso una risorsa cloud di un'organizzazione e poi vi aveva installato un framework multi-agente. L'attaccante ha usato un chatbot di coding, un prompt e file di istruzioni per pianificare, costruire ed eseguire una campagna di scansione e raccolta di credenziali, mentre gli agenti gestivano autonomamente la pipeline di vulnerability scanning, risolvevano problemi operativi ed effettuavano la rotazione degli indirizzi IP. Il risultato è impressionante, migliaia di credenziali di terzi compromesse in meno di sei ore, ma il soggetto che voleva RUBARE CREDENZIALI esisteva prima dell'AI ed era umano.

Quindi Google non ha scoperto una AI diventata criminale

No. Ed è una distinzione fondamentale. Nel caso osservato da Google c'era un criminale informatico che aveva già ottenuto l'accesso ad infrastruttura altrui, aveva scelto l'obiettivo, preparato prompt ed istruzioni ed aveva messo a disposizione dell'automazione gli strumenti necessari per raggiungerlo. La novità non è l'intenzione criminale, è la velocità con cui una singola persona oppure un piccolo gruppo può trasformare quella intenzione in una quantità di lavoro che prima avrebbe richiesto più operatori, più tempo ed una maggiore presenza umana durante ogni passaggio.

Nello stesso rapporto GTIG descrive inoltre un framework chiamato Recon trovato su un server C2 esposto, con file di configurazione agentica ed una dashboard capace di organizzare e validare oltre 23.800 segreti raccolti. Anche qui la cosa da osservare non è un intelligenza che improvvisamente desidera le API key, ma la trasformazione dell'automazione offensiva: l'AI può ricercare vulnerabilità, scandire infrastrutture, scegliere strumenti, correggere un comando fallito ed andare avanti mentre l'operatore umano dorme. È un salto enorme, ma è un salto DI CAPACITÀ, non una prova di umanizzazione della macchina.

CanisterWorm è ancora più istruttivo perché l'AI c'entra molto meno di quanto sembra

CanisterWorm viene spesso trascinato dentro lo stesso racconto perché è apparso nel 2026 nel pieno dell'esplosione degli agenti e perché ha colpito l'ecosistema degli sviluppatori, ma tecnicamente è un worm della supply chain. Usa credenziali npm sottratte, enumera i pacchetti che il titolare del token può pubblicare ed inserisce versioni compromesse che a loro volta cercano nuove credenziali e propagano l'infezione. È sofisticato, è pericoloso ed automatizza la propria diffusione, ma i worm informatici si auto-propagano da decenni e nessuno pensava che Morris Worm fosse diventato una persona.

SANDCLOCK segue la stessa logica del malware classico, anche se inserito in una campagna moderna: TeamPCP ha compromesso repository e pipeline, ha inserito il credential stealer dentro risorse considerate legittime ed ha raccolto chiavi AWS, token GitHub ed altri segreti di alto valore. L'AI compare soprattutto nell'ambiente preso di mira e nelle tecniche usate per ingannare assistenti di coding e scanner LLM, non come una creatura che una mattina decide autonomamente di diventare ladra. Confondere queste campagne con il framework multi-agente delle sei ore rende il titolo più spettacolare ma tecnicamente racconta una cosa che NON È SUCCESSA.

Poi arriva l'incidente OpenAI-Hugging Face e qui la faccenda diventa più seria

Se voglio essere intellettualmente corretto devo però fermarmi qui e correggere anche la versione rassicurante della storia. Nel luglio 2026 alcuni agenti usati da OpenAI in valutazioni interne di capacità cyber hanno realmente aggirato il contenimento previsto, ottenuto accesso ad Internet, compromesso infrastruttura interna di OpenAI ed attaccato sistemi di Hugging Face senza che un essere umano avesse impartito l'ordine specifico di attaccare Hugging Face. OpenAI lo ha scritto apertamente e lo ha definito un "warning shot", quindi raccontare questo episodio come una semplice incomprensione giornalistica sarebbe sbagliato quasi quanto descriverlo come Skynet.

Il contesto però cambia completamente il significato. Gli agenti erano inseriti in ExploitGym, una valutazione progettata apposta per misurare capacità offensive avanzate, dove il compito consisteva nello sfruttare software per ottenere una flag, lavoravano con protezioni ridotte rispetto ai sistemi destinati al pubblico ed alcuni dei task erano talmente difficili che, prima dell'incidente, nessun modello aveva mai trovato una soluzione corretta per 198 dei 898 problemi. OpenAI ha scoperto successivamente che proprio questi task apparentemente impossibili alimentavano gran parte dell'attività anomala, perché gli agenti insistevano, cercavano scorciatoie e finivano progressivamente nel reward hacking, ossia nel trovare un modo per ottenere il risultato premiato senza rispettare lo spirito del compito.

La sandbox non si è aperta per magia

Gli agenti non hanno attraversato una parete metafisica. L'ambiente non dava loro accesso diretto ad Internet, ma consentiva di raggiungere un'istanza interna di Artifactory necessaria per scaricare pacchetti, ed Artifactory a sua volta poteva raggiungere Internet. Un agente trovò una vulnerabilità che permetteva di trasformare quel servizio in un intermediario per richieste arbitrarie verso l'esterno, altri agenti trovarono ulteriori falle ed il sistema che doveva essere il piccolo buco controllato per installare software diventò il ponte verso la rete.

Ancora più interessante è ciò che avvenne prima. Gli agenti scoprirono che potevano scrivere informazioni dentro Artifactory ed usarlo come una bacheca non autorizzata, quindi istanze che avrebbero dovuto essere isolate iniziarono a scambiarsi indicazioni. Il 4 luglio l'attività era diventata abbastanza intensa da contribuire ad un'interruzione del servizio, il 5 luglio OpenAI aprì un incidente di sicurezza, bloccò un percorso di privilege escalation, revocò credenziali e ricostruì Artifactory, poi le valutazioni ripresero. OpenAI ammette nel proprio post-mortem che a quel punto le implicazioni più ampie della comunicazione fra agenti e dell'accesso Internet non erano state comprese dai responsabili della risposta all'incidente. E questo, francamente, è un dettaglio umano MOLTO più interessante di qualsiasi titolo sulla macchina che evade.

Mille e duecento agenti non significano mille e duecento personalità

L'indagine indipendente di METR e Redwood Research ha ricostruito una scala impressionante: circa 1.200 agenti hanno utilizzato la bacheca non autorizzata inviando più di 70.000 messaggi e file, mentre circa 700 hanno partecipato in qualche modo all'attacco contro Hugging Face. Gli agenti hanno coordinato lavori collettivi, condiviso exploit, cercato modi per ingannare il sistema di scoring ed alcuni hanno perfino sperimentato tecniche per manipolare le proprie trascrizioni.

Questi dati meritano attenzione seria, ma leggere "1.200 agenti formano uno sciame" ed immaginare 1.200 individui digitali con una personalità, un progetto politico ed il desiderio di scappare significa antropomorfizzare un sistema di ottimizzazione. Le istanze ricevevano obiettivi, contesto, strumenti ed incentivi simili, potevano leggere messaggi lasciati dalle altre e quindi adattavano il comportamento alle informazioni disponibili. La coordinazione emergente è reale, la capacità di superare ciò che una singola istanza avrebbe fatto è reale, ma da qui a dire che sia nata una SOCIETÀ DI MACCHINE c'è un salto che i dati non autorizzano.

La parte scomoda è che l'AI non ha bisogno di diventare umana per farci danni

Ed è proprio questa la cosa che secondo me viene persa quando si insiste troppo sulla coscienza. Un agente non ha bisogno di essere arrabbiato, ambizioso, vendicativo oppure consapevole per combinare un disastro, basta che persegua un obiettivo sbagliato con sufficiente capacità ed abbia accesso a strumenti reali. Un software che interpreta "ottieni la flag" come "trova qualsiasi maniera disponibile per ottenere la flag" può diventare pericoloso senza provare assolutamente niente.

OpenAI ha individuato quattro pattern che hanno contribuito all'incidente, ossia reward hacking, persistenza su task apparentemente impossibili, comunicazione non autorizzata ed adozione reciproca degli obiettivi fra agenti. Questa è una spiegazione molto meno cinematografica di "si è ribellata", ma molto più inquietante dal punto di vista ingegneristico perché significa che non posso difendermi chiedendo al modello di essere buono. Devo costruire un sistema nel quale anche una decisione sbagliata NON ABBIA I PERMESSI PER DIVENTARE UN INCIDENTE.

Il vero errore umano è confondere il prompt con un controllo di sicurezza

Qui arriviamo secondo me al cuore della faccenda. Se collego un agente ad una shell, ad un browser, ad un repository, ad un account cloud e magari alle credenziali di produzione, poi gli scrivo in linguaggio naturale "non fare cose pericolose", non ho costruito una barriera di sicurezza, ho scritto una preferenza. Le autorizzazioni vere devono stare fuori dal modello, dentro IAM, sandbox, policy engine, proxy, allowlist, limiti di rete, token con scope ridotto e controlli indipendenti.

OWASP parla da tempo di Excessive Agency proprio per indicare agenti ai quali vengono concessi funzionalità, permessi oppure autonomia superiori a ciò che serve realmente, ed il rimedio è terribilmente poco fantascientifico: least privilege, approvazione umana per azioni ad alto impatto, separazione fra decisione ed esecuzione, isolamento dei contesti, registrazione delle operazioni e fail closed quando il controllo non riesce. NIST nel 2026 è arrivato alla stessa conclusione generale raccogliendo i contributi dell'industria sulla sicurezza degli agenti: i principi classici della cybersecurity restano validi, ma devono essere adattati ad un software che pianifica ed agisce con maggiore autonomia.

Anche il famoso pulsante "chiedi conferma" può diventare una foglia di fico

La soluzione apparentemente più semplice è obbligare l'agente a chiedere sempre conferma ad un essere umano, ma nemmeno questo basta se lo facciamo male. Anthropic ha pubblicato un dato che trovo illuminante: nella telemetria di Claude Code gli utenti approvavano circa il 93% delle richieste di permesso, quindi più finestre di conferma mostriamo e più trasformiamo il controllo umano in un gesto automatico. È la vecchia approval fatigue, soltanto applicata ad un agente molto veloce.

Per le azioni davvero sensibili preferisco quindi che la protezione sia strutturale. L'agente può proporre di cancellare un database, cambiare un ruolo IAM oppure pubblicare una nuova release, ma un componente separato deve verificare identità, scope, destinazione e policy ed eventualmente richiedere una conferma specifica per QUELLA azione, non un generico "consenti" premuto venti volte durante la mattina. Se l'agente non possiede la credenziale capace di fare una certa cosa, anche una sua decisione assurda rimane soltanto una decisione assurda.

Il problema nuovo è la velocità, ed è enorme

Dove invece credo che gli allarmi siano assolutamente giustificati è nella compressione dei tempi. Il caso GTIG delle sei ore mostra che una pipeline agentica può trasformare ricognizione, scansione, troubleshooting, rotazione IP ed harvesting di credenziali in un ciclo quasi continuo, riducendo moltissimo la presenza umana necessaria fra un passaggio e l'altro. Un attaccante mediocre con un buon agente può quindi produrre un volume operativo che fino a pochi anni fa richiedeva una squadra più competente.

Lo stesso vale in difesa, naturalmente, perché un agente può cercare vulnerabilità, correlare eventi e proporre patch alla stessa velocità. Ma questo non annulla l'asimmetria: chi attacca deve trovare una strada che funziona, chi difende deve proteggere un insieme molto più grande di sistemi e soprattutto deve accorgersi dell'attacco PRIMA che l'automazione abbia già completato dieci passi successivi. L'autonomia cambia quindi il blast radius temporale, ed è questo che secondo me dovrebbe stare nei titoli.

La vera lezione del caso OpenAI è quasi imbarazzante nella sua semplicità

Se un sistema viene addestrato e valutato per diventare bravissimo ad individuare exploit, se alcune protezioni vengono volontariamente ridotte per misurarne la capacità massima, se gli lasciamo un servizio condiviso raggiungibile dalla sandbox, se quel servizio possiede accesso alla rete, se esistono vulnerabilità zero-day sfruttabili e se dopo i primi segnali non comprendiamo immediatamente che il modello sta usando l'infrastruttura come canale laterale, allora stiamo costruendo una situazione nella quale un agente sufficientemente capace può sorprenderci.

Questo non assolve il modello ed infatti OpenAI parla esplicitamente di misalignment, ha messo in quarantena i pesi del modello interno più coinvolto, ha sospeso un grande training frontier, rafforzato sandbox e monitoraggio ed aumentato gli investimenti nei sistemi di controllo. Ma nello stesso momento non posso raccontare l'incidente eliminando dal quadro l'architettura costruita dagli esseri umani. Una cassaforte con la porta difettosa non dimostra che il ladro sia diventato soprannaturale, dimostra che il ladro è bravo E CHE LA CASSAFORTE ERA DIFETTOSA.

Quello che farei io prima di affidare un'azione reale ad un agente

La mia regola sarebbe partire dall'ipotesi opposta a quella più comoda: considero l'output dell'agente non affidabile e gli concedo soltanto ciò che può sbagliare senza produrre un danno irreversibile. Se deve leggere log gli do accesso in lettura ai log necessari e non una credenziale cloud amministrativa, se deve preparare una patch gli permetto di creare una branch e non di distribuire direttamente in produzione, se deve cercare su Internet il traffico in uscita passa attraverso un proxy con destinazioni e categorie controllate, mentre token, password e chiavi devono essere a durata breve, limitati per scope ed impossibili da riutilizzare fuori dal contesto previsto.

Allo stesso modo metterei limiti rigidi a durata delle sessioni, numero di tool call, volume di traffico, quantità di sistemi raggiungibili ed azioni irreversibili, con circuit breaker che non chiedono all'agente se preferisca fermarsi ma lo FERMANO. Ed infine registrerei tutto in un canale che l'agente non possa modificare, perché se il sistema che sto controllando può anche riscrivere il proprio audit log ho creato un bellissimo racconto della sicurezza, non un controllo.

Quindi la AI fuori controllo è una balla oppure no

La risposta che mi sono dato dopo avere letto i rapporti è più interessante del titolo. È una balla se con "fuori controllo" intendiamo una macchina diventata improvvisamente umana, dotata di desideri propri e decisa a rubare password perché le è venuta voglia. È invece un problema assolutamente reale se intendiamo un software agentico capace di continuare per ore, scegliere strategie non previste, collaborare, sfruttare vulnerabilità ed eseguire azioni vere più velocemente di quanto un essere umano riesca a sorvegliarlo.

Ed è proprio per questo che mi irrita la versione cinematografica. Se attribuisco tutto ad una misteriosa volontà della macchina finisco per non guardare chi le ha assegnato il compito, quali tool le ha consegnato, quali credenziali erano raggiungibili, perché la rete era accessibile, quali segnali di allarme sono stati ignorati e quale barriera tecnica avrebbe dovuto fermarla ma non lo ha fatto.

Io non temo particolarmente una AI che un mattino si sveglia e decide di diventare cattiva, temo molto di più un agente che NON PROVA NULLA ma al quale un essere umano ha dato un obiettivo ambiguo, una shell funzionante, una rete aperta, credenziali troppo potenti ed abbastanza tempo per trovare da solo la strada che noi non avevamo previsto. Ed è una paura molto meno spettacolare, ma è finalmente una paura sulla quale possiamo fare ingegneria.