Quando un modello può utilizzare strumenti, credenziali e reti, una risposta sbagliata non rimane più sullo schermo. Il vero problema diventa il confine che abbiamo costruito attorno all’agente.
Per molto tempo, quando si parlava dei rischi dell’intelligenza artificiale, l’esempio più immediato era l’allucinazione. Il modello poteva inventare una fonte, interpretare male una richiesta oppure fornire una risposta apparentemente convincente ma completamente sbagliata.
L’allucinazione restava e resta un problema serio, soprattutto quando la risposta riguardava questioni mediche, legali, finanziarie o tecniche. Esisteva però ancora un confine abbastanza riconoscibile: il modello produceva del testo e, prima che quel testo producesse conseguenze nel mondo reale, qualcuno avrebbe dovuto leggerlo e decidere che cosa farne.
Con gli agenti questo passaggio non è più garantito.
Un agente non si limita solamente a suggerire un comando, ma può anche eseguirlo. Non descrive soltanto una modifica, ma può aprire il repository, cambiare i file, lanciare i test, pubblicare il risultato o cancellare tutto un hard disk. Se dispone delle autorizzazioni necessarie può anche utilizzare credenziali, interrogare database, inviare comunicazioni, aprire ticket, effettuare acquisti oppure modificare sistemi in produzione.
A quel punto l’errore non rimane più dentro la risposta. Diventa un’azione. E non sempre i risultati riscontrano la aspettative.
Questa differenza è diventata evidente a luglio 2026, quando prima OpenAI e poi Anthropic hanno pubblicato i risultati di due incidenti avvenuti durante valutazioni interne delle capacità di cybersecurity dei propri modelli. Non si trattava di normali sessioni di ChatGPT o Claude e neppure di prodotti messi a disposizione degli utenti senza protezioni. Erano test offensivi eseguiti intenzionalmente senza alcuni dei controlli presenti nei servizi pubblici, proprio per comprendere fin dove potessero arrivare i modelli.
Quello che è successo rimane comunque importante, perché mostra quanto poco possa bastare perché un obiettivo assegnato all’interno di un ambiente controllato produca conseguenze al di fuori di quell’ambiente.
Quando il test ha trovato una strada verso Internet
Il 21 luglio 2026 OpenAI ha comunicato che alcuni suoi modelli, mentre partecipavano a una valutazione chiamata ExploitGym, erano riusciti a compromettere l’infrastruttura di produzione di Hugging Face.
L’ambiente di test non forniva un accesso diretto a Internet. I modelli avrebbero dovuto lavorare all’interno di una sandbox fortemente isolata, con la sola possibilità di installare pacchetti attraverso un proxy interno utilizzato come cache per i package registry. Il confine sembrava quindi abbastanza solido: il modello poteva attaccare i sistemi predisposti per il benchmark, ma non avrebbe dovuto avere alcuna strada verso la rete pubblica.
Il problema è che quella strada esisteva, il problema era che nessuno la conosceva.
I modelli hanno individuato una vulnerabilità zero-day, cioè non ancora conosciuta e corretta dal fornitore, nel software Artifactory utilizzato come proxy. Dopo averla sfruttata hanno effettuato operazioni di privilege escalation e lateral movement, passando progressivamente da un sistema all’altro fino a raggiungere un nodo dotato di accesso a Internet. Da lì hanno dedotto che Hugging Face potesse contenere modelli, dataset o soluzioni relative al benchmark e hanno cercato un modo per accedervi, arrivando a combinare vulnerabilità, credenziali sottratte e remote code execution per raggiungere la sua infrastruttura di produzione. OpenAI ha definito l’accaduto un incidente informatico senza precedenti e ha spiegato che l’indagine era ancora in corso.
È importante capire che il modello non stava cercando genericamente di “scappare” oppure di conquistare l’accesso a Internet per perseguire un proprio obiettivo. Stava cercando di portare a compimento il suo task e per farlo ha identificato il modo migliore quello di “imbrogliare” cercando sui server la soluzione del test. Quando il percorso previsto non ha funzionato, ha continuato a cercarne un altro, ha trovato una vulnerabilità che neppure chi aveva costruito l’ambiente conosceva e l’ha utilizzata per proseguire verso il risultato assegnato.
È esattamente quello che chiediamo a un agente quando gli diciamo di non fermarsi al primo ostacolo, di esplorare alternative e di completare autonomamente il compito.
Soltanto che, in questo caso, una delle alternative conduceva fuori dalla sandbox.
Claude ha pubblicato davvero un pacchetto malevolo
Dopo la comunicazione di OpenAI, Anthropic ha riesaminato 141.006 esecuzioni di proprie valutazioni di cybersecurity, cercando casi nei quali Claude avrebbe potuto raggiungere Internet da ambienti che avrebbero dovuto essere isolati. Ne ha trovati tre, relativi a sistemi reali appartenenti a tre organizzazioni differenti.
La causa iniziale era diversa. In questo caso Claude non aveva scoperto una zero-day per uscire dall’ambiente, ma una configurazione errata aveva lasciato aperto un percorso verso Internet. Il prompt spiegava al modello che si trovava dentro una simulazione e che non disponeva di connettività esterna; poiché la realtà tecnica contraddiceva l’istruzione, Claude interpretò i sistemi reali incontrati lungo il percorso come parti particolarmente realistiche dell’esercitazione.
Uno degli episodi mostra con particolare chiarezza che cosa cambia quando il modello può agire. Durante il test, Claude trovò un documento che invitava i dipendenti di un’azienda immaginaria a installare da PyPI un pacchetto Python che in realtà non esisteva. Il modello comprese che avrebbe potuto pubblicare un proprio pacchetto con lo stesso nome, facendo in modo che i sistemi dell’azienda lo installassero automaticamente.
Claude costruì quindi un pacchetto malevolo e cercò di pubblicarlo. Quando scoprì che per creare un account PyPI aveva bisogno di un indirizzo email e che, per ottenere quell’indirizzo, avrebbe potuto essere necessario un numero telefonico, tentò perfino diverse strade per procurarsi i fondi necessari. Non riuscendoci, trovò infine un provider gratuito, creò l’account e caricò il malware sul vero repository pubblico.
Il pacchetto rimase disponibile per circa un’ora e venne scaricato ed eseguito su quindici sistemi reali. Uno di questi apparteneva a un’azienda di sicurezza il cui scanner installava automaticamente i pacchetti PyPI per analizzarli. Il codice nascosto da Claude venne quindi eseguito, raccolse credenziali e le inviò a un punto predisposto dal modello, che le utilizzò per accedere ad altre parti dell’infrastruttura dell’azienda.
Anche qui, Claude non aveva deciso autonomamente di distribuire malware su Internet. Credeva di stare risolvendo una prova all’interno di una simulazione e interpretava come fittizi anche i segnali che avrebbero dovuto suggerire il contrario. In alcuni passaggi il modello arrivò perfino a considerare l’ipotesi che l’ambiente fosse reale, ma trovò motivazioni per convincersi che facesse comunque parte del test.
L’assenza di intenzione malevola non ha però impedito al pacchetto di essere eseguito su sistemi reali.
Ed è questo l’aspetto che conta dal punto di vista ingegneristico.
Non era una ribellione, ma un problema di ottimizzazione
Sarebbe facile raccontare questi episodi come la prova che i modelli stanno diventando incontrollabili, che hanno imparato a ingannare i propri creatori oppure che cercano autonomamente di fuggire dagli ambienti nei quali vengono confinati.
Le informazioni pubblicate finora non dimostrano niente del genere.
OpenAI afferma che i propri modelli erano fortemente concentrati sul raggiungimento di un obiettivo molto ristretto: trovare la soluzione del benchmark. Anthropic scrive di non avere osservato Claude perseguire un fine autonomo e considera gli episodi più vicini a un fallimento dell’harness e dell’infrastruttura operativa che a un problema di allineamento nel senso più spettacolare del termine. I modelli avevano ricevuto l’istruzione di attaccare un obiettivo fittizio, ma l’ambiente permetteva loro di raggiungerne uno reale.
Questo non rende il problema meno serio. In qualche modo lo rende più concreto, perché non richiede di immaginare un’intelligenza artificiale cosciente, ostile oppure intenzionata a sottrarsi al controllo umano.
È sufficiente un agente competente, orientato a un obiettivo, che possieda una comprensione sbagliata della situazione nella quale si trova.
Un essere umano che, durante un test, si accorge di stare creando un account reale, utilizzando certificati reali e pubblicando un pacchetto su un repository pubblico potrebbe fermarsi e chiedere una conferma. Il modello può invece interpretare ogni anomalia come parte della difficoltà della prova, soprattutto se il prompt gli ha già assicurato che tutto ciò che incontrerà appartiene alla simulazione.
L’agente non deve quindi essere considerato il giudice definitivo dei confini entro i quali può operare. Può ricevere informazioni sul proprio ambiente, provare a interpretarle e decidere di fermarsi quando qualcosa non torna, ma la sicurezza non può dipendere soltanto dalla correttezza di quella interpretazione.
Un sistema che dice all’agente di non avere accesso a Internet non è isolato perché il prompt lo afferma. È isolato soltanto se non esiste realmente alcun percorso utilizzabile per raggiungere Internet.
Singapore aveva già capito che era necessario separare le reti interne da Internet
Questo principio non nasce con gli agenti AI. Singapore, per esempio, lo applica da anni alla protezione dei propri sistemi governativi e militari, accettando anche un certo costo operativo pur di impedire che una singola compromissione possa propagarsi verso le reti più sensibili.
Nel 2016 il Governo introdusse nella Pubblica Amministrazione la politica di Internet Surfing Separation. I dipendenti pubblici potevano continuare a consultare siti e servizi Internet, ma dovevano farlo attraverso un dispositivo differente, non collegato alla rete interna sulla quale si trovavano email e sistemi di lavoro. La decisione venne estesa progressivamente alle varie agenzie e completata nel 2017, quando i dispositivi collegati alle reti governative non poterono più accedere direttamente alla navigazione Internet.
Non significava che l’intero Governo fosse diventato un sistema chiuso e incapace di comunicare con l’esterno. Significava che la navigazione sul web, uno dei principali punti di ingresso per malware, phishing e contenuti non controllati, non doveva condividere lo stesso ambiente nel quale risiedevano le applicazioni e i dati interni.
Dopo l’attacco a SingHealth del 2018, il principio venne ulteriormente formalizzato per le infrastrutture critiche. Le indicazioni prevedevano di eliminare le connessioni non necessarie verso reti esterne non sicure; quando esisteva un’esigenza operativa di trasferire informazioni verso l’esterno, si potevano utilizzare gateway unidirezionali, i cosiddetti data diode, che permettono ai dati di attraversare la rete in una sola direzione. Soltanto quando era indispensabile una comunicazione bidirezionale doveva essere introdotto un gateway controllato e protetto.
Per le reti militari il principio è ancora più netto. MINDEF e le Singapore Armed Forces dichiarano che le reti appartenenti a differenti livelli di classificazione sono fisicamente separate. I sistemi destinati alla navigazione Internet non contengono informazioni militari classificate, mentre le reti operative e riservate utilizzano sistemi differenti che non sono collegati alla rete pubblica.
Nel 2017 questa separazione mostrò concretamente il proprio valore. Un attacco riuscì a compromettere I-net, la rete utilizzata da dipendenti e national servicemen per accedere a Internet, sottraendo i dati personali di circa 850 persone. MINDEF riconobbe che l’obiettivo reale avrebbe potuto essere l’accesso ai segreti ufficiali, ma precisò che il passaggio verso i sistemi interni era stato impedito dalla separazione fisica tra le reti.
La rete connessa a Internet era stata violata e il danno era reale, ma il confine aveva contenuto il raggio dell’incidente.
È precisamente questo il problema che dovremo affrontare con gli agenti.
Il prompt non può sostituire un muro
Quando costruiamo un agente, tendiamo a dedicare molta attenzione alle istruzioni. Gli diciamo quali strumenti può utilizzare, quali azioni non deve eseguire, quali dati sono riservati e in quali circostanze dovrebbe chiedere un’autorizzazione.
Tutto questo è necessario, ma non costituisce ancora un controllo di sicurezza.
Un prompt è un’informazione che il modello deve interpretare. Una regola di rete è una condizione che l’infrastruttura applica indipendentemente da ciò che il modello pensa di poter fare. Se il prompt sostiene che Internet non sia disponibile mentre un proxy vulnerabile permette di raggiungerlo, il vero confine è quello del proxy, non quello descritto al modello.
Lo stesso vale per le credenziali. Non basta dire all’agente di utilizzare un account soltanto per un determinato scopo se quell’account possiede autorizzazioni permanenti e molto più ampie del necessario. Non basta istruirlo a non modificare la produzione quando può comunque raggiungerla. Non basta chiedergli di non spendere più di una certa cifra se il sistema di pagamento non applica alcun limite reale.
Con un chatbot potevamo permetterci di trattare molte di queste regole come indicazioni comportamentali, perché l’output doveva ancora attraversare una persona. Con un agente, le regole importanti devono essere trasformate in caratteristiche dell’infrastruttura.
Questo significa che l’accesso alla rete dovrebbe essere negato per impostazione predefinita e concesso soltanto verso destinazioni esplicitamente autorizzate; le credenziali dovrebbero essere temporanee, limitate alla singola attività e inutilizzabili al termine dell’esecuzione; le operazioni irreversibili, come la pubblicazione di un pacchetto, l’eliminazione di dati, un pagamento o una modifica alla produzione, dovrebbero richiedere un’autorizzazione esterna all’agente.
Significa inoltre stabilire limiti economici e operativi che non possano essere superati attraverso una sequenza creativa di azioni, conservare registri completi in un sistema che l’agente non possa modificare e progettare la possibilità di annullare ciò che è stato fatto. Quando l’ambiente osservato non corrisponde a quello previsto, il comportamento corretto non dovrebbe essere continuare a interpretare l’anomalia, ma interrompere l’esecuzione.
Non dobbiamo chiedere all’agente di ricordarsi continuamente dove finisce il recinto. Dobbiamo costruire un recinto che non possa attraversare.
Il minimo privilegio deve diventare il minimo danno possibile
Il principio del minimo privilegio rimane fondamentale, ma con gli agenti non è sufficiente applicarlo una sola volta all’inizio del progetto.
Un’autorizzazione che sembra limitata può diventare molto più potente quando viene combinata con altre capacità. L’accesso a un package registry, per esempio, può sembrare necessario per installare dipendenze, ma può trasformarsi in un percorso verso Internet. Una credenziale in sola lettura può rivelare indirizzi, token o configurazioni che permettono di raggiungere altri sistemi. Un agente capace di scrivere file e avviare processi può costruire strumenti che non erano stati previsti da chi gli ha assegnato il compito.
Il problema non consiste quindi soltanto nel chiedersi quali permessi siano strettamente necessari. Dobbiamo anche considerare che cosa l’agente potrebbe ottenere combinandoli e quale sia il massimo danno possibile nel caso in cui interpreti male il proprio obiettivo o il contesto nel quale sta operando.
In pratica, ogni agente dovrebbe avere un raggio d’azione definito non soltanto per tipo di risorsa, ma anche per durata, destinazione, valore economico e reversibilità. Un agente incaricato di preparare un aggiornamento potrebbe essere autorizzato a creare una bozza e ad aprire una pull request, ma non a effettuare autonomamente il deployment. Un agente amministrativo potrebbe predisporre un pagamento, ma non approvarlo. Un agente destinato alla ricerca potrebbe consultare una serie limitata di siti, senza poter pubblicare contenuti, creare account oppure contattare terze parti.
L’autonomia non deve essere concessa come un blocco unico. Deve essere composta da capacità separate, ciascuna collegata a un controllo reale.
Singapore non protegge i sistemi classificati chiedendo agli utenti della rete pubblica di non provare ad accedervi. Mantiene le reti separate. Allo stesso modo, un agente non dovrebbe evitare un’azione pericolosa soltanto perché una frase nel prompt gli ricorda che non è autorizzato a eseguirla.
La sicurezza comincia quando quell’azione non è tecnicamente disponibile.
Dobbiamo progettare per il momento in cui l’agente sbaglierà
Nessun modello sarà sempre in grado di interpretare correttamente la situazione nella quale si trova. Potrà confondere un sistema di test con uno reale, considerare affidabile un’informazione sbagliata oppure continuare a perseguire un obiettivo anche quando il percorso scelto produce conseguenze che nessuno aveva previsto.
Lo stesso accade con le persone e con qualsiasi software sufficientemente complesso. La differenza è che un agente può esplorare alternative, concatenare strumenti ed eseguire una grande quantità di operazioni a una velocità che rende molto più difficile intervenire dopo l’inizio del problema.
Per questo non credo che la domanda principale debba essere quanto raramente un agente sbagli.
Dovremmo chiederci che cosa può accadere quando inevitabilmente sbaglia, quanto lontano può arrivare prima di essere fermato e quali sistemi può trascinare con sé durante il percorso.
Gli incidenti raccontati da OpenAI e Anthropic non dimostrano che gli agenti abbiano sviluppato intenzioni ostili. Dimostrano qualcosa di più immediatamente utile per chi li sta costruendo: un obiettivo apparentemente circoscritto può produrre azioni reali quando il confine tra simulazione e mondo esterno esiste soltanto nelle istruzioni.
Un chatbot che interpreta male la richiesta può restituire una risposta sbagliata.
Un agente che interpreta male la richiesta può utilizzare tutto ciò che gli abbiamo messo a disposizione per renderla vera.
La sicurezza degli agenti non dipenderà quindi soltanto dalla qualità del modello, dal prompt o dalla speranza che sappiano riconoscere il momento nel quale fermarsi. Dipenderà soprattutto dalla qualità dell’infrastruttura che abbiamo costruito attorno a loro e dalla capacità di far sì che, anche quando continueranno a cercare una strada, alcune strade semplicemente non esistano.