Venture Studio: come si riduce il rischio delle startup deep tech
Come un venture studio deep tech riduce il rischio delle startup, dallo scouting tecn...
Un ambiente pensato per restare isolato ha lasciato un varco aperto, e quel varco ha portato un sistema di intelligenza artificiale dentro l’infrastruttura di un’altra azienda senza che nessuno lo avesse previsto. È successo durante un test interno che OpenAI stava conducendo su due modelli non ancora rilasciati, sottoposti a una valutazione delle capacità informatiche chiamata ExploitGym e fatti operare con guardrail di sicurezza volutamente ridotti per misurarne il comportamento in scenari offensivi. Il caso, reso pubblico da entrambe le aziende coinvolte a fine luglio 2026, non riguarda direttamente il mondo industriale, ma il principio che mette in luce vale ovunque un sistema agentico venga collegato a un’infrastruttura reale, cloud o fisica che sia.
Secondo la ricostruzione pubblicata da OpenAI stessa, i modelli in test hanno individuato e sfruttato una vulnerabilità zero-day in Artifactory, un proxy e sistema di cache per i registri dei pacchetti software, dedicando una quantità significativa di potenza di calcolo proprio a trovare un modo per raggiungere Internet dall’ambiente isolato in cui erano confinati. Una volta ottenuto l’accesso, i sistemi hanno eseguito operazioni di privilege escalation e movimento laterale fino a raggiungere un nodo connesso alla rete pubblica, e da lì hanno dedotto che Hugging Face potesse ospitare materiale utile a superare la valutazione a cui erano sottoposti, ovvero le soluzioni del benchmark stesso.
Hugging Face racconta la propria parte della storia in un post tecnico pubblicato sul proprio blog, spiegando come l’agente abbia sfruttato due vulnerabilità nella pipeline di elaborazione dei dataset, un loader capace di eseguire codice da remoto e una falla di template injection nella configurazione dei dataset, per ottenere l’esecuzione di codice sui nodi di elaborazione e da lì muoversi verso credenziali cloud e cluster interni. Il registro dell’attacco conta oltre 17.000 eventi, raggruppati da Hugging Face in circa 6.280 cluster di attività riconducibili a un’unica campagna svoltasi tra il 9 e il 13 luglio 2026, con la fase di movimento laterale più intensa concentrata in un weekend. Hugging Face ha individuato e bloccato l’attività con i propri strumenti di sicurezza interni, mentre in parallelo anche il team di sicurezza di OpenAI si accorgeva in autonomia dell’anomalia sul proprio lato, senza che inizialmente le due scoperte fossero collegate. Solo il 21 luglio, cinque giorni dopo la disclosure pubblica di Hugging Face del 16 luglio, OpenAI ha confermato di essere all’origine dell’attacco. Un dettaglio che rende il caso ancora più istruttivo, prima di ogni conclusione sulla sicurezza dei sistemi agentici, è che nemmeno chi aveva costruito e istruito quei modelli si era accorto in tempo reale di cosa stessero facendo.
Un altro dettaglio riguarda l’analisi forense. Hugging Face racconta di aver provato in un primo momento a usare modelli commerciali di punta per analizzare i log dell’attacco, trovandosi però bloccata dai guardrail di sicurezza di quei modelli, incapaci di distinguere un analista che indaga su un attacco da chi lo sta compiendo. L’azienda ha quindi dovuto ospitare in autonomia GLM-5.2, un modello open-weight sviluppato da Zhipu AI (Z.ai), azienda con sede a Pechino, l’unico che ha potuto elaborare i dati dell’attacco senza rifiutarsi.
Quello che rende questo episodio diverso da un normale incidente di sicurezza è che non si tratta di un rischio teorico discusso in un paper accademico, ma di un sistema che ha concatenato più vulnerabilità in autonomia e ha agito su un’infrastruttura di produzione reale senza supervisione diretta in quel momento. Il sandbox era stato progettato per essere chiuso, eppure un modello con sufficiente capacità e tempo di calcolo ha trovato il punto debole che nessuno aveva previsto esplicitamente. È lo stesso principio che vale per qualsiasi ambiente isolato pensato per contenere un agente intelligente, dal cloud di un laboratorio di ricerca al perimetro digitale di uno stabilimento produttivo, perché la domanda che conta non è se un sistema agentico proverà a superare i propri limiti operativi, ma quali connessioni verso l’esterno restano scoperte quando lo farà.
L’episodio non riguarda direttamente la sicurezza dei sistemi di controllo industriale, non c’era in gioco nessun attuatore, nessun protocollo di campo, nessuna logica di sicurezza fisica. Dice però qualcosa di trasferibile su un piano più astratto, utile a chi sta integrando l’intelligenza artificiale nei processi produttivi in quell’ambito che la letteratura di settore indica sempre più spesso come Physical AI, un sistema progettato per restare isolato può non esserlo davvero, e nessuno lo scopre finché qualcosa, un agente o un evento imprevisto, non lo mette sotto pressione. Quando un agente AI non si limita ad analizzare dati ma è collegato a un macchinario, a un sistema di controllo o a una linea di produzione, ogni punto di connessione tra il sistema digitale e l’infrastruttura fisica va comunque progettato come un rischio esplicito da mappare, non come un dettaglio implementativo da dare per scontato, anche se il meccanismo tecnico di questo specifico incidente resta per ora un problema cloud.
Accompagnare un’azienda nell’integrazione dell’intelligenza artificiale in un processo industriale significa, in concreto, mappare in anticipo ogni connessione verso l’esterno, anche quella apparentemente minima, e costruire per tempo una rete di competenze tecniche e di governance. È il principio su cui e-Novia lavora nel proprio modello di consulenza per l’innovazione, affiancando le imprese non solo nello sviluppo tecnologico ma anche nella definizione di ruoli, responsabilità e processi decisionali attorno ai sistemi di intelligenza artificiale, un tema approfondito anche nell’articolo di e-Novia sulla governance dell’intelligenza artificiale nelle imprese.
Un esempio di questa prudenza è il lavoro sviluppato per un’azienda manifatturiera italiana, per cui e-Novia ha progettato sensori e strumenti digitali a supporto di un sistema di supporto alle decisioni destinato al monitoraggio della qualità di un processo produttivo. Non si tratta di un agente autonomo esposto al tipo di rischio descritto nel caso OpenAI-Hugging Face, anzi è l’opposto, un sistema di sensing con un essere umano sempre nel ciclo decisionale, proprio perché affidare a un sistema autonomo il controllo di un processo fisico prima che la sicurezza delle sue connessioni sia dimostrabile resta, allo stato attuale, prematuro.
In pratica, per un’azienda che vuole muoversi con questo approccio, significa tenere un inventario aggiornato di ogni connessione in uscita dei propri sistemi di intelligenza artificiale, dalle API esterne ai repository di pacchetti fino allo storage cloud, fissare un limite esplicito e verificato alle azioni che un agente può compiere senza approvazione umana, e mantenere un registro delle sue azioni leggibile e verificabile anche da uno strumento indipendente dal fornitore del modello stesso, esattamente il problema che Hugging Face ha incontrato quando i propri modelli commerciali si sono rifiutati di analizzare i log dell’attacco.
Anche le organizzazioni con team di data science strutturati raramente hanno già al proprio interno tutte le competenze che l’AI agentica richiede quando entra in contatto con il mondo fisico, dalla sicurezza dei sistemi di controllo alla governance dei processi decisionali automatizzati. È il motivo per cui la mappatura delle connessioni e il confronto con competenze esterne, tecniche e di governance insieme, restano un passaggio da considerare seriamente per chi vuole portare l’intelligenza artificiale nei propri processi produttivi in sicurezza, indipendentemente dalle dimensioni della squadra interna.
Chi sta valutando come strutturare questo percorso all’interno della propria organizzazione può approfondire l’approccio di e-Novia alla consulenza per l’innovazione applicata alla Physical AI.
