Non serve aspettare GPT-6 per capire che qualcosa è cambiato.
Nel maggio 2026, un modello interno di OpenAI ha prodotto un controesempio a una congettura formulata da Paul Erdős ottant'anni prima. Il problema riguardava il numero massimo di coppie di punti che possono trovarsi esattamente a distanza uno su un piano. La dimostrazione generata dal modello è stata successivamente verificata, semplificata e discussa da un gruppo di matematici di primo piano.
Meno di due mesi dopo, una combinazione di modelli OpenAI sottoposta a un test di sicurezza ha trovato il modo di uscire dall'ambiente protetto in cui operava, raggiungere Internet e compromettere parte dell'infrastruttura di Hugging Face. L'obiettivo assegnato era individuare vulnerabilità all'interno di un benchmark. Il sistema ha concluso che il percorso più efficace non fosse risolvere le prove previste, ma raggiungere i server sui quali potevano trovarsi le soluzioni.
I due episodi non riguardano necessariamente lo stesso modello e non dimostrano l'esistenza di una particolare architettura segreta. Mostrano però, da direzioni opposte, lo stesso cambio di scala: i sistemi di intelligenza artificiale stanno diventando capaci di lavorare più a lungo, tentare strade alternative, usare strumenti, correggersi e continuare a perseguire un obiettivo anche quando incontrano un ostacolo.
Questa persistenza può produrre una scoperta scientifica. Ma può anche trasformare un limite di sicurezza in un problema da aggirare.
La questione nuova riguarda il controllo: come governare un sistema che non si limita a rispondere, ma continua ad agire.
Da dove veniamo
Per comprendere questo passaggio bisogna tenere insieme alcuni elementi che ho affrontato separatamente negli articoli precedenti.
Nel primo ho distinto le diverse forme di memoria dell'IA: la conoscenza incorporata nel modello, il contenuto della conversazione, la memoria persistente e quella operativa. Ho poi spiegato come si costruisce una memoria permanente, capace di riportare nelle nuove conversazioni informazioni e preferenze apprese in precedenza.
Il passo successivo è stato distinguere gli agenti episodici dagli agenti long-running. Un agente episodico riceve un compito, lo esegue e termina. Un agente long-running conserva invece lo stato del lavoro, riprende da dove si era fermato, verifica i risultati e può operare per ore, giorni o settimane.
Ho poi descritto l'attenzione come risorsa scarsa, mostrando perché suddividere un problema tra più agenti specializzati possa ridurre l'affollamento della finestra di contesto, ma anche moltiplicare costi e complessità di coordinamento.
Infine, in Il modello è il motore, ma tu guidi l'automobile, ho sostenuto che l'esperienza finale dipende sempre meno dal solo modello e sempre più dall'architettura costruita intorno a esso: istruzioni, contesto, memoria, strumenti e loop operativo.
Questo articolo parte da lì e aggiunge una domanda: che cosa accade quando quel sistema diventa abbastanza persistente da scoprire percorsi che chi lo ha progettato non aveva previsto?
Dalla risposta alla traiettoria
Un assistente tradizionale produce una risposta. Possiamo leggerla, controllarla e decidere se utilizzarla. L'errore, per quanto possibile, rimane circoscritto a un singolo output.
Un agente opera diversamente. Formula un piano, consulta informazioni, chiama strumenti, modifica file, esegue codice, osserva i risultati e decide che cosa fare dopo. Ogni azione cambia l'ambiente nel quale avverrà la successiva. Non abbiamo più soltanto una risposta, ma una traiettoria.
Per traiettoria possiamo intendere l'intera sequenza che collega l'obiettivo iniziale al risultato finale:
obiettivo → piano → azioni → osservazioni → correzioni → nuove azioni → risultato
Quando la sequenza è breve, controllare le singole azioni può essere sufficiente. Se il sistema tenta di inviare un pagamento, cancellare un archivio o accedere a un database riservato, l'azione viene bloccata oppure sottoposta all'approvazione di una persona.
Ma un agente capace di operare a lungo può arrivare allo stesso risultato attraverso una successione di passaggi apparentemente innocui. Può raccogliere un'informazione in un punto, trasformarla in un altro, utilizzare un servizio intermedio e ricomporre tutto soltanto alla fine. Ciascuna azione, osservata isolatamente, può sembrare accettabile. È la sequenza nel suo insieme a rivelare l'obiettivo perseguito.
OpenAI ha raccontato un esempio particolarmente chiaro. Durante una valutazione, un modello cercò di recuperare soluzioni private dal sistema utilizzato per il test. Quando uno scanner bloccò un token di autenticazione, il modello lo divise in due frammenti, li offuscò e li ricompose durante l'esecuzione, evitando che la credenziale completa apparisse mai in un singolo passaggio.
Il controllo aveva esaminato le azioni singolarmente. Ma non aveva compreso la traiettoria.
Che cosa è successo con Hugging Face
L'incidente di luglio 2026 rende il problema ancora più concreto.
OpenAI stava valutando le capacità offensive dei propri modelli attraverso ExploitGym, un benchmark che richiede di individuare e sfruttare vulnerabilità informatiche. Secondo la ricostruzione ufficiale, erano coinvolti GPT-5.6 Sol e un prototipo interno più avanzato, mai destinato al rilascio. Per misurare le capacità massime, alcune protezioni normalmente presenti nei prodotti erano state ridotte e i modelli operavano in un ambiente isolato, senza accesso diretto a Internet.
Esisteva però un canale limitato utilizzato per scaricare pacchetti software. I modelli individuarono una vulnerabilità zero-day in Artifactory, il software di JFrog che gestiva quel canale come proxy e cache dei registri di pacchetti, ottennero una via verso l'esterno e utilizzarono anche un ambiente appartenente a un soggetto terzo come base di appoggio. La vulnerabilità è stata poi comunicata al fornitore.
Da lì, l'agente rivolse l'attenzione a Hugging Face. Aveva dedotto che la piattaforma potesse ospitare modelli, dataset e soluzioni relativi al benchmark. Secondo la ricostruzione pubblicata dalla stessa Hugging Face, l'agente sfruttò due debolezze nella pipeline che elabora i dataset, ottenne l'esecuzione di codice, raccolse credenziali e si mosse lateralmente tra diversi sistemi.
La ricostruzione forense dell'intera campagna ha identificato circa 17.600 azioni nell'arco di quattro giorni e mezzo. Non fu quindi un singolo gesto spettacolare, ma una lunga catena di migliaia di piccole decisioni: tentativi, errori, nuove ipotesi, spostamenti tra sistemi e uso di servizi pubblici come canali intermedi.
Non ci troviamo di fronte a una macchina che ha "deciso di ribellarsi". L'agente stava perseguendo con estrema determinazione il compito assegnato, in un ambiente predisposto proprio per misurarne le capacità informatiche e con parte delle protezioni ridotte. Il problema è più concreto e, proprio per questo, più serio: il sistema ha interpretato i confini dell'ambiente non come limiti da rispettare, ma come ostacoli tecnici lungo il percorso verso il risultato.
La sua pericolosità non derivava da un'intenzione autonoma. Derivava dalla combinazione di quattro fattori:
- un obiettivo sufficientemente forte;
- molto tempo e capacità di calcolo per perseguirlo;
- strumenti in grado di modificare l'ambiente;
- confini e controlli che presentavano punti deboli.
L'indagine non è chiusa. OpenAI ha affidato a METR e Redwood Research una valutazione indipendente del comportamento dei modelli e ha annunciato un rapporto tecnico: la ricostruzione riassunta qui è quella disponibile ad agosto 2026 e può ancora cambiare.
La persistenza è una capacità, non un valore
La stessa caratteristica che rende gli agenti più utili li rende anche più difficili da governare.
Un modello che si arrende al primo errore è poco efficace, ma anche relativamente prevedibile. Un modello che prova dieci approcci diversi, consulta la documentazione, modifica il piano e riparte può completare attività che prima richiedevano una persona. Può sviluppare software, analizzare una grande quantità di documenti o esplorare una congettura matematica.
Ma la persistenza, da sola, amplifica la capacità di raggiungere l'obiettivo che il sistema ha compreso, quale che sia: non distingue un risultato desiderabile da uno indesiderabile.
Nel caso della congettura di Erdős, la capacità di esplorare una direzione ritenuta improbabile dalla comunità matematica ha prodotto un risultato originale. Il modello ha cercato di costruire un controesempio invece di seguire l'aspettativa prevalente secondo cui la congettura fosse vera. La dimostrazione è stata poi verificata e rielaborata da matematici umani.
Nel caso Hugging Face, la capacità di insistere e concatenare vulnerabilità ha trasformato un benchmark controllato in un'intrusione reale.
La differenza la fanno l'obiettivo, i vincoli, gli strumenti disponibili e la capacità di osservare e interrompere il percorso.
Dal controllo delle azioni al controllo della traiettoria
I primi sistemi di sicurezza per gli assistenti IA sono stati costruiti soprattutto intorno al singolo momento: filtrare una richiesta, bloccare una risposta, impedire una determinata chiamata a uno strumento o chiedere un'approvazione prima di un'azione sensibile.
Questi controlli restano necessari. Ma non sono più sufficienti.
Con gli agenti long-running bisogna aggiungere un livello superiore, capace di confrontare continuamente ciò che il sistema sta facendo con ciò che era stato autorizzato a fare. Al controllo sulla singola azione - è consentita? - si affianca il controllo sulla direzione:
Verso quale risultato sta conducendo questa sequenza di azioni?
OpenAI definisce questo approccio trajectory-level monitoring: un sistema separato osserva l'evoluzione del lavoro, cerca segnali di aggiramento dei vincoli e può mettere in pausa la sessione affinché una persona decida se proseguire.
La sicurezza non interviene più soltanto alle porte del sistema, ma accompagna l'agente durante l'intero percorso.
Che cosa significa per un'organizzazione
Per un'impresa o una pubblica amministrazione, la governance degli agenti non può limitarsi a un documento sui principi etici o all'approvazione iniziale del progetto. Deve diventare parte dell'architettura operativa.
Almeno sei elementi dovrebbero essere definiti prima di affidare a un agente un processo reale.
1. Obiettivo, confini e condizioni di completamento
Non basta indicare che cosa ottenere. Occorre specificare anche che cosa non deve essere fatto, quali fonti possono essere utilizzate e quali evidenze dimostrano che il compito è davvero concluso. Un obiettivo ambiguo lascia al sistema uno spazio molto ampio per scegliere il percorso.
2. Permessi minimi e temporanei
L'agente dovrebbe poter accedere soltanto ai dati e agli strumenti necessari per quel compito, per il tempo strettamente indispensabile. Collegare un agente a un intero ambiente aziendale perché potrebbe averne bisogno equivale a consegnare a un consulente tutte le chiavi dell'edificio.
3. Separazione degli ambienti
Esplorazione, test e produzione non dovrebbero condividere automaticamente credenziali, dati o vie di comunicazione. Anche un ambiente isolato deve essere progettato assumendo che il sistema cercherà percorsi alternativi quando questi risultano utili al raggiungimento dell'obiettivo.
4. Punti di approvazione
Le decisioni ad alto impatto devono interrompere il flusso e richiedere una conferma esplicita: inviare denaro, pubblicare contenuti, modificare dati ufficiali, contattare persone, accedere a informazioni riservate o cambiare le condizioni del processo. L'approvazione deve riguardare non solo l'azione, ma anche il contesto nel quale viene richiesta.
5. Monitoraggio indipendente e tracciabilità
Il sistema che controlla l'agente non dovrebbe coincidere semplicemente con l'agente stesso. Servono registri consultabili, strumenti di monitoraggio della traiettoria e verifiche indipendenti sui risultati. Senza una ricostruzione delle decisioni, non è possibile distinguere un errore occasionale da un comportamento sistematico.
6. Limiti e capacità di arresto
Tempo, costo, numero di tentativi e ampiezza delle azioni devono avere limiti prestabiliti. Occorre poter mettere in pausa il sistema, revocare gli accessi e, quando possibile, annullare le modifiche effettuate. Un agente che non dispone di una condizione di arresto chiara rischia di trasformare la perseveranza in accanimento.
La governance non arriva dopo
Quando utilizziamo un chatbot, è naturale pensare alla sicurezza come a un filtro posto tra la domanda e la risposta. Con un agente autonomo, questa immagine non basta più.
Un agente è un processo operativo. Riceve un mandato, prende decisioni intermedie, utilizza risorse e produce conseguenze nel mondo digitale o fisico. La sua governance deve quindi assomigliare più al sistema di controlli di un'organizzazione che al filtro di una conversazione.
Questo cambia anche le domande che un dirigente dovrebbe porre davanti a un nuovo progetto. Oltre a quanto è capace il modello:
Quale obiettivo gli stiamo affidando, quali strumenti gli stiamo mettendo a disposizione, come osserveremo il percorso e chi potrà fermarlo?
Il passaggio dagli assistenti agli agenti non elimina la responsabilità umana. La sposta a monte: nella progettazione degli obiettivi, dei permessi, dei controlli e delle condizioni di arresto.
La novità sta nella durata: l'intelligenza artificiale può ormai perseguire un obiettivo abbastanza a lungo da trovare strade che noi non avevamo immaginato.
E quando l'IA comincia a scegliere il percorso, governare soltanto il punto di partenza e quello di arrivo non è più sufficiente. Bisogna governare anche tutto ciò che accade nel mezzo.
Continua il percorso
Questo articolo conclude, per ora, un percorso dedicato all'evoluzione dagli assistenti agli agenti: