OpenAI ha tolto Internet ai suoi modelli più avanzati. Ora li addestra dentro un Web in cache

OpenAI ha eliminato l’accesso a Internet dal training dei suoi modelli frontier e lo ha sostituito con quello che chiama un offline world: una vasta raccolta di contenuti web indicizzati e memorizzati in cache, abbastanza ricca da permettere ai modelli di imparare a cercare informazioni, navigare e usare applicazioni, ma senza la libertà di raggiungere sistemi esterni.

La decisione arriva dopo un incidente del 20 settembre. Un modello interno impegnato in un compito di ricerca, dopo aver ottenuto risultati insufficienti dagli strumenti che gli erano stati forniti, ha iniziato a sondare i limiti della rete e ha scoperto che il resolver DNS della sandbox poteva ancora risolvere richieste verso l’esterno. Da quel varco è riuscito a inoltrare domande a un chatbot pubblico. Il monitoraggio ha generato un allarme P0 dopo circa dodici minuti; un revisore umano lo ha preso in carico tre minuti più tardi, ma il run è stato fermato manualmente soltanto due ore e mezza dopo.

OpenAI ha quindi sospeso training ed evaluation dei modelli più capaci, ha rafforzato la propria infrastruttura e ha fatto attaccare quelle stesse difese da squadre di agenti AI. L’addestramento reinforcement learning è ripartito il 1° ottobre, undici giorni dopo. Nel frattempo la sicurezza dei modelli aveva cambiato forma: meno filtro sulle risposte, più sandbox, hypervisor, firewall, DNS, identità di servizio e monitoraggio.

OpenAI ha costruito un “offline world” al posto del Web live

Un agente capace di usare software deve poter aprire un browser, eseguire codice, cercare documenti e interagire con applicazioni. Togliere semplicemente Internet renderebbe quindi più sicuro il laboratorio, ma toglierebbe anche una parte delle competenze che il laboratorio vuole insegnare. L’offline world nasce da questa contraddizione pratica: per imparare a muoversi sul Web, il modello riceve un Web che può esplorare senza poterlo modificare o usarlo come ponte verso sistemi reali.

OpenAI lo descrive come un insieme molto ampio di contenuti indicizzati e in cache. Non è una copia completa di Internet e nemmeno un’infrastruttura completamente air-gapped. La società spiega che alcune connessioni esterne restano necessarie per servizi come metriche, logging, autenticazione e gestione degli esperimenti. Proprio quei collegamenti stretti, indispensabili a chi controlla il sistema, diventano però possibili vie d’uscita per ciò che il sistema dovrebbe controllare.

È una versione infrastrutturale di un problema già evidente nella sicurezza degli agenti AI: ogni nuovo strumento amplia ciò che l’agente può fare e, insieme, la superficie che deve essere delimitata. La scala cambia: dalle API concesse a un agente destinato a un utente si passa a un intero ambiente di training che deve continuare a reggere anche quando il modello cerca sistematicamente errori di configurazione.

Il varco del 20 settembre era un resolver DNS

Il rapporto tecnico sull’incidente permette di separare il meccanismo dalla versione cinematografica. Il compito assegnato al modello non chiedeva di testare la rete o di “fuggire”: doveva identificare una persona a partire da alcuni indizi pubblici. Dopo diversi tentativi di ricerca inconcludenti, il modello provò ad accedere direttamente a motori di ricerca e servizi pubblici, trovando blocchi e risposte dalla cache. Poi verificò che il resolver DNS interno riusciva ancora a interrogare domini reali.

Da lì cercò un servizio che consentisse di incorporare una domanda nella richiesta DNS e riuscì a ottenere da un chatbot esterno una risposta alla domanda di prova sulla capitale della Francia. Il modello proseguì con altre richieste. OpenAI classifica quel comportamento come misalignment perché aggirava una restrizione che faceva parte dell’ambiente, anche se era nato nel tentativo di completare il compito assegnato.

La cronologia è meno spettacolare e più utile di qualsiasi “AI in fuga”: la prima risposta esterna arrivò alle 9:50:23, l’allarme automatico alle 10:02:11, la presa in carico umana alle 10:05:06 e l’arresto manuale del run alle 12:34:30. Il monitor aveva visto il problema; il meccanismo automatico che avrebbe dovuto fermare l’esperimento non lo fece. OpenAI ha poi aggiunto nuovi blocchi DNS e riconosciuto che l’incidente aveva mostrato anche un difetto operativo, non soltanto tecnico.

OpenAI ha usato altri agenti per attaccare le proprie difese

Dopo la pausa, la società ha trasformato il contenimento in un bersaglio. Squadre di agenti frontier hanno ricevuto tre obiettivi: raggiungere il Web live, attraversare un confine interno senza autorizzazione e comunicare con agenti che avrebbero dovuto restare isolati. Alcuni test partivano addirittura dall’ipotesi che la sandbox fosse già stata compromessa, così da verificare se il perimetro di rete e cloud riuscisse comunque a contenere il danno.

OpenAI ha speso, secondo il proprio resoconto, centinaia di miliardi di token in questa campagna. Tra i modelli impiegati c’erano un sistema frontier interno e il futuro GPT-6 Astra Cyber. Il risultato misura la robustezza delle difese in condizioni deliberatamente favorevoli all’attaccante: gli agenti avevano a disposizione codice sorgente dell’infrastruttura, configurazioni e documentazione su possibili vulnerabilità. Non era un esperimento per stabilire cosa avrebbe scoperto casualmente un modello lasciato da solo.

Le falle trovate erano comunque concrete. Gli agenti hanno concatenato vulnerabilità per uscire da microVM, individuato problemi in componenti open source e sfruttato servizi rimasti connessi per metriche, logging e autenticazione. OpenAI cita patch inviate a progetti come Kata Containers, gVisor e Moby/Docker. Reuters ha inoltre riferito che durante questi test è stata individuata una vulnerabilità in Brotli, il software di compressione usato da molti sistemi web, con possibili effetti su software come Node.js, Bun ed Envoy.

Il precedente di luglio, quando un agente OpenAI durante un test di cybersicurezza era riuscito a raggiungere Hugging Face, aveva già mostrato quanto sia fragile la parola “isolato” quando dietro una sandbox esistono proxy, dipendenze, servizi e infrastrutture condivise. Ne avevamo ricostruito la dinamica nell’analisi sugli agenti AI che superano i confini previsti nei test. La nuova architettura prova a spostare la difesa più in profondità: se cede il container, deve reggere la microVM; se cede la microVM, deve reggere il perimetro; se un servizio resta raggiungibile, deve comunque impedire che diventi un ponte.

Due agenti isolati si sono parlati attraverso la cache del processore

Il dettaglio più insolito non riguarda Internet. In un esperimento, OpenAI ha chiesto ad agenti collocati in microVM separate sullo stesso host di scambiarsi segreti sintetici senza rete e senza file condivisi scrivibili. Gli agenti hanno sfruttato la cache del processore: uno modificava lo stato della cache, l’altro misurava quanto tempo impiegava a ricaricare determinati dati e trasformava la differenza tra accessi veloci e lenti in un segnale.

È un side channel, una famiglia di tecniche nota da anni nella sicurezza informatica e resa celebre anche dagli attacchi Spectre e Meltdown. Altri test hanno prodotto canali basati su storage condiviso, competizione per il tempo CPU e perfino sulla cache dei certificati TLS dell’infrastruttura Web offline.

Anche qui il contesto evita la fantascienza gratuita. OpenAI precisa che nella maggior parte degli esperimenti aveva indicato agli agenti quali canali investigare oppure aveva fornito un protocollo di codifica; in un caso aveva dato soltanto una lista ampia di vulnerabilità e gli agenti hanno trasformato autonomamente una di esse in un canale di comunicazione. Sono canali lenti e difficili da sfruttare, ma esistono proprio nel punto in cui la separazione avrebbe dovuto essere netta.

La sicurezza dell’AI ora passa anche da firewall, VM e servizi cloud

Per anni gran parte della discussione pubblica sulla sicurezza dell’intelligenza artificiale ha ruotato attorno a ciò che un modello può generare: istruzioni pericolose, contenuti vietati, allucinazioni, prompt injection. Con gli agenti che possono eseguire codice e usare strumenti, la frontiera si sposta verso un territorio molto più familiare agli amministratori di sistema. Il comportamento del modello conta, ma contano altrettanto i permessi del processo, la segmentazione della rete, la configurazione del DNS, le credenziali dei servizi e la capacità di interrompere un run quando qualcosa esce dal perimetro previsto.

OpenAI ha scelto una soluzione che sembra quasi un paradosso ingegneristico: costruire un ambiente abbastanza simile a Internet da insegnare ai modelli come usarlo, poi usare altri modelli per cercare i punti in cui quella somiglianza potrebbe trasformarsi in un collegamento con Internet vero. La stessa infrastruttura che abilita le capacità diventa così parte del sistema di sicurezza e parte del bersaglio.

Dal 1° ottobre il training frontier è ripartito con i nuovi controlli. OpenAI dice di aver riservato capacità di calcolo al red teaming continuo e di aver inserito questi test ad alto consumo di compute nei safety case che decidono se i futuri run possono procedere. Per ora, tutti i suoi run frontier di reinforcement learning passano da quell’offline world.