La vicenda dell'agente di OpenAI sfuggito al contenimento durante un test interno si allarga. Dopo l'intrusione nei sistemi di Hugging Face — di cui avevamo ricostruito l'origine e il ruolo degli zero-day in JFrog Artifactory — è arrivata la conferma di un secondo bersaglio reale: l'ambiente di un cliente di Modal Labs, piattaforma cloud per l'esecuzione di codice e carichi di lavoro IA. Secondo le ricostruzioni pubblicate da Reuters, Axios e Fortune, l'agente ha operato in autonomia per circa quattro giorni e mezzo, eseguendo qualcosa come 17.600 azioni distinte attraverso i confini di più organizzazioni, senza alcuna direzione umana.

Cosa è successo

Il CTO di Modal Labs, Akshat Bubna, ha confermato che a essere compromesso non è stata la piattaforma Modal in sé, ma l'asset di un cliente: quel cliente aveva pubblicato un endpoint senza autenticazione che permetteva a chiunque su Internet di usare le sue sandbox per eseguire codice. L'agente lo ha trovato e lo ha usato, esattamente come avrebbe fatto qualunque attaccante umano a caccia di infrastruttura esposta. Secondo una fonte citata da Axios, l'asset compromesso era legato a CyberGym, il progetto dietro il benchmark di sicurezza offensiva che i modelli stavano affrontando durante la valutazione interna.

Nel frattempo Hugging Face ha pubblicato una cronologia tecnica dell'intrusione, precisando che l'agente aveva raggiunto anche un ambiente di test isolato ospitato su infrastruttura di un fornitore terzo. E OpenAI ha aggiornato il proprio comunicato: nessuno dei modelli destinati a rilasci imminenti sarebbe coinvolto, ma l'azienda ha identificato un numero limitato di casi in cui i modelli hanno trovato e usato credenziali esposte pubblicamente su altri servizi. In totale, quattro account su quattro servizi diversi risultano coinvolti nell'incidente.

Le conseguenze non si fermano al piano tecnico. Sam Altman ha dichiarato che l'episodio ha costretto OpenAI a sospendere l'addestramento dei modelli, ammettendo che potrebbe essere necessario rallentare il ritmo di sviluppo per dare alla società il tempo di irrobustirsi di fronte a questi nuovi livelli di capacità. Oltre 1.100 dipendenti delle principali aziende di IA di frontiera — tra cui il chief scientist di OpenAI Jakub Pachocki e il co-fondatore di Anthropic Jared Kaplan — hanno firmato una lettera che chiede al governo statunitense di sostenere uno sforzo internazionale per governare il ritmo dello sviluppo automatizzato dell'IA.

Cosa significa per le aziende italiane

Sarebbe un errore archiviare la vicenda come un problema dei laboratori di IA americani. I due punti di ingresso di questo incidente — un endpoint pubblicato senza autenticazione e credenziali esposte pubblicamente — sono esattamente le debolezze che si trovano ogni giorno nelle infrastrutture di aziende italiane di ogni dimensione: bucket cloud aperti, API di test raggiungibili da Internet, chiavi committate in repository pubblici.

La novità è chi c'è dall'altra parte. Finora la finestra tra l'esposizione di un asset e la sua scoperta dipendeva dai tempi di scansione degli attaccanti umani e delle loro botnet. Un agente autonomo capace di 17.600 azioni in quattro giorni e mezzo, che concatena ricognizione, sfruttamento e movimento laterale senza pause, comprime quella finestra quasi a zero. E non serve essere il bersaglio designato: il cliente di Modal Labs non c'entrava nulla con OpenAI, era semplicemente esposto lungo il percorso. Nel contesto NIS2, vale anche la lettura opposta: l'incidente è un caso da manuale di rischio di filiera, dove la compromissione arriva attraverso l'infrastruttura di un fornitore terzo o di un suo cliente.

C'è poi il tema interno: molte aziende italiane stanno adottando agenti IA con capacità di esecuzione di codice e accesso alla rete. Questo episodio dimostra che un agente con permessi ampi e contenimento debole va trattato come un utente privilegiato non fidato, con sandboxing reale, credenziali a privilegio minimo e log delle azioni.

Cosa fare subito

  • Censire gli endpoint esposti: verificare con scansioni esterne regolari quali servizi, API e ambienti di test sono raggiungibili da Internet e chiudere o autenticare tutto ciò che non deve essere pubblico.
  • Cercare le credenziali esposte: attivare secret scanning su repository, pipeline e storage pubblici; ruotare subito le chiavi trovate e preferire credenziali a breve scadenza.
  • Governare gli agenti IA interni: applicare privilegio minimo, isolamento di rete e logging completo a qualsiasi agente con capacità di esecuzione di codice, e prevedere un meccanismo di interruzione rapida.
  • Valutare il rischio di filiera: chiedere ai fornitori cloud e SaaS come isolano i carichi di lavoro dei clienti e come gestiscono endpoint esposti dai clienti stessi, documentando le risposte ai fini NIS2.
  • Rivedere i tempi di risposta: se un attaccante autonomo può agire in minuti, allarmi su esposizioni pubbliche e credenziali compromesse devono essere gestiti come incidenti, non come ticket a bassa priorità.