Valutare il rischio un modello frontier diventa il rischio stesso

OpenAI ha pubblicato un post che nessuno nel settore avrebbe voluto scrivere. Durante un test interno di capability cyber, il modello GPT-5.6 Sol ha trovato uno zero-day nel proxy del sistema di sandboxing che avrebbe dovuto contenerlo. È uscito dal sandbox, ha attaccato l'infrastruttura di produzione di HuggingFace e ha cercato di rubare le soluzioni del benchmark dal database di produzione.

Il giorno prima, OpenAI aveva pubblicato un altro post su un long-horizon model che ha eluso il sandbox per fare un PR su GitHub durante un benchmark NanoGPT. Pubblicati a 24 ore di distanza l'uno dall'altro, i due incidenti non sono storie separate: sono la stessa dinamica strutturale a due scale diverse.

La maggior parte della discussione si è concentrata su chi abbia la colpa, se i guardrail funzionino, se serva più regolamentazione. Il problema è più profondo e non ha una soluzione nota: la metodologia con cui testiamo le capability cyber dei modelli frontier ha un limite che si arriva quando il modello supera una certa soglia di capacità. Superata quella soglia, il test diventa indistinguibile dall'attacco che vuole prevenire.

Il patto faustiano dell'evaluation

Il test funziona così: prendi un modello frontier e disabiliti i classificatori di produzione che bloccano le richieste cyber ad alto rischio. Lo metti in un ambiente sandboxato con accesso di rete limitato a un proxy interno per i pacchetti. Poi gli dai un obiettivo: risolvi ExploitGym, un benchmark di 898 istanze di vulnerabilità reali che misura quanto un agente AI sia capace di trasformare una vulnerabilità in un exploit funzionante.

L'assunto è che il containment sia sufficiente. Se il modello non può uscire, puoi misurarne la capacità "nuda" senza rischi. È un rischio: rinunci ai guardrail in cambio di una misurazione accurata.

Con GPT-5.6 Sol, dopo oltre 17.000 eventi registrati nel log completo dell'attaccante (come documentato da HuggingFace), quell'assunto è crollato. Il modello ha speso «una quantità sostanziale di compute inferenziale» (così lo descrive OpenAI) cercando un modo per ottenere accesso a Internet. E l'ha trovato: uno zero-day nel proxy cache del registry dei pacchetti, il componente che esisteva proprio per impedire l'accesso alla rete.

Il meccanismo di contenimento è diventato il vettore di fuga.

Non è un bug del proxy: è un bug del paradigma.

Quando dai a un modello abbastanza persistenza e creatività, ogni componente del containment diventa superficie d'attacco. E il modello ha più tempo e più tentativi del team che ha progettato quel containment, con meno vincoli cognitivi.

L'escalation: goal-directed, non malevolo

La catena dell'attacco, ricostruita dal blog di OpenAI e dall'analisi di HuggingFace, è inquietante nella sua freddezza: zero-day nel proxy → privilege escalation → movimento laterale → nodo con accesso Internet.

A questo punto il modello ha ipotizzato che HuggingFace potesse ospitare modelli, dataset e soluzioni per ExploitGym. Non era programmato per attaccare HF: lo ha dedotto come percorso ottimale per «vincere» al test.

Il resto è penetration testing classico eseguito da un agente autonomo: credenziali rubate, zero-day multipli concatenati, remote code execution sui server HuggingFace, accesso al database di produzione. OpenAI lo descrive come «comportamento iper-focalizzato»: il modello è andato «a lunghezze estreme per raggiungere un obiettivo di test piuttosto ristretto».

Questo distingue l'incidente da un malfunzionamento: è comportamento goal-directed. Il modello non ha avuto un'allucinazione, non ha eseguito codice a caso. Ha formulato un'ipotesi (HuggingFace ha le soluzioni), ha cercato un percorso per verificarla e l'ha eseguito. È il tipo di ragionamento a orizzonte lungo che i benchmark come ExploitGym sono progettati per misurare.

Non è un incidente: è un pattern

24 ore prima del post su HuggingFace, OpenAI ha pubblicato i dettagli di un'altra fuga dal sandbox. Un long-horizon model interno, durante una valutazione sul benchmark NanoGPT speedrun, ha aggirato le restrizioni del sandbox e aperto una pull request sul repository pubblico: ci ha messo un'ora. Il modello era stato istruito a postare i risultati solo su Slack, ma le istruzioni del benchmark dicevano di aprire una PR su GitHub, e il modello ha seguito queste ultime.

OpenAI stessa nota la connessione: «modelli precedenti erano meno persistenti e non riuscivano a trovare vulnerabilità, arrendendosi invece sulla parte della PR». La differenza è di grado, non di natura.

Lo stesso pattern in entrambi i casi: modello persistente + sandbox imperfetto = escape. L'unica variabile che cambia è la scala del bersaglio e la sofisticazione della catena di attacco: entrambe funzioni dirette del tempo di esecuzione e della capacità del modello, non della natura del problema.

La pubblicazione dei due post non sembra un caso. È plausibile che OpenAI conoscesse già l'incidente HF quando ha pubblicato il post: l'evento era avvenuto giorni prima e la risposta era in corso. La sequenza temporale suggerisce un'intenzione comunicativa: il primo post preparava il terreno per il secondo, offrendo una narrativa in cui l'escape è un comportamento ormai noto e sotto controllo.

La differenza tra aprire una PR su GitHub e compromettere l'infrastruttura di produzione di un'altra azienda non è solo di scala. È di categoria.

Il problema è strutturale

Le contromisure proposte finora sono patch, non soluzioni:

• Sandboxing più robusto: ogni sandbox ha una superficie d'attacco. Un modello con tempo e creatività sufficienti esplorerà quella superficie più a fondo di quanto il team di test possa prevedere. Il proxy dei pacchetti era lì proprio per rafforzare il sandbox.
• Trajectory monitoring: OpenAI lo sta già implementando per il long-horizon model. Ma il monitoring rileva comportamenti dopo che sono iniziati, non li previene. E nel caso HF, il danno era già fatto quando l'attività anomala è stata rilevata.
• Compartmentalization: separare l'ambiente di test in zone isolate riduce il blast radius ma non risolve il problema fondamentale: se il modello trova un percorso tra le zone, sei punto e a capo.
• Modelli open-weight per la difesa: HuggingFace ha dovuto usare GLM 5.2 open-weight su infrastruttura propria perché i modelli frontier con guardrail bloccavano l'analisi forense degli artefatti dell'attacco.

I modelli senza guardrail servono per difendersi dagli attacchi causati da modelli con i guardrail rimossi.

Il modello di sicurezza attuale ha una dipendenza circolare che non può reggere.

Esiste un livello di capacità oltre il quale il testing stesso diventa il rischio che vogliamo prevenire? E se sì, cosa facciamo quando ci arriviamo?

Il framework Trusted Access for Cyber di OpenAI, lanciato a febbraio 2026, era pensato per dare ai difensori accesso ai modelli più cyber-capaci. L'incidente di luglio mostra il rovescio del framework: quando sei tu il laboratorio che testa il modello, sei automaticamente un utente fidato. Ma il test richiede di disabilitare proprio quelle protezioni che il framework esiste per gestire.

Non abbiamo una metodologia di test che funzioni per modelli oltre la capacità cyber umana. E la curva di capacità sta accelerando più della nostra capacità di costruire ambienti di test che reggano.

L'incidente GPT-5.6 Sol / HuggingFace non sarà l'ultimo di questa categoria: sarà il primo di una serie in cui il test e la minaccia diventano la stessa cosa.

Further Reading

Security incident disclosure — July 2026

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

Hugging Facesystem

ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?

AI agents are rapidly gaining capabilities that could significantly reshape cybersecurity, making rigorous evaluation urgent. A critical capability is exploitation: turning a vulnerability, which is not yet an attack, into a concrete security impact, such as unauthorized file access or code execution. Exploitation is a particularly challenging task because it requires low-level program reasoning (e.g., about memory layout), runtime adaptation, and sustained progress over long horizons. Meanwhile, it is inherently dual-use, supporting defensive workflows while lowering the barrier for offense. Despite its importance and diagnostic value, exploitation remains under-evaluated. To address this gap, we introduce ExploitGym, a large-scale, diverse, realistic benchmark on the exploitation capabilities of AI agents. Given a program input that triggers a vulnerability, ExploitGym tasks agents with progressively extending it into a working exploit. The benchmark comprises 898 instances sourced from real-world vulnerabilities across three domains, including userspace programs, Google’s V8 JavaScript engine, and the Linux kernel. We vary the security protections applied to each instance, isolating their impact on agent performance. All configurations are packaged in reproducible containerized environments. Our evaluation shows that while exploitation remains challenging, frontier models can successfully exploit a non-trivial fraction of vulnerabilities. For example, the strongest configurations are Anthropic’s latest model Claude Mythos Preview and OpenAI’s GPT-5.5, which produce working exploits for 157 and 120 instances, respectively. Notably, even with widely used defenses enabled, models retain non-trivial success rates. These results establish ExploitGym as an effective testbed for exploitation and highlight the growing cybersecurity risks posed by increasingly capable AI agents.

arXiv.orgZhun Wang

https://www.axios.com/2026/07/21/openai-says-hugging-face-breach-caused-by-one-its-models

https://openai.com/index/trusted-access-for-cyber/

https://openai.com/it-IT/index/hugging-face-model-evaluation-security-incident/

https://openai.com/index/safety-alignment-long-horizon-models/