I ricercatori di sicurezza offensiva, quelli che trovano vulnerabilità prima dei criminali, non riescono a usare i modelli frontier per il loro lavoro. I guardrail di OpenAI e Anthropic bloccano le richieste che puzzano di exploit, anche quando chi le fa è un difensore.

Chris Anley, chief scientist di NCC Group, lo spiega con un esempio concreto: chiedere a un modello di sfruttare un bug è il passo fondamentale per confermare che la vulnerabilità è reale e va chiusa. Se il guardrail rifiuta, il difensore resta fermo. Il prompt “correggi questo codice” serve sia a difendere sia a attaccare: separare i due usi è impossibile senza spezzare lo strumento.

Alcuni ricercatori sono tornati ai modelli open-source senza guardrail. Paolo Stagno di Crowdfense evita i modelli cloud anche per un secondo motivo: caricare dati su un modello cloud significa rischiare che finiscano nei prossimi cicli di addestramento. Per i bug che valgono milioni di dollari, è un rischio inaccettabile.

Il paradosso è netto. I lab proprietari spingono per limitare i modelli open-weight citando i rischi di sicurezza, come raccontavamo ieri. Ma i modelli open senza guardrail sono gli unici che i ricercatori di sicurezza possono usare senza blocchi né fughe di dati. La sicurezza che i lab vogliono costruire nei loro modelli è la stessa che spinge i professionisti seri fuori da quei modelli.

Nel dettaglio

Diversi ricercatori di sicurezza offensiva, la branca della cybersecurity che cerca attivamente le vulnerabilità nei sistemi, descrivono un problema operativo concreto. Non è una lamentela generica: è un blocco sul lavoro quotidiano.

I programmi di accesso esistono. OpenAI ha il Trusted Access for Cyber, Anthropic il Cyber Verification Program: chi lavora in sicurezza può candidarsi, passare un vetting e ottenere modelli con meno restrizioni. Ma l’approvazione non è garantita e i guardrail, anche alleggeriti, continuano a interferire.

Chris Anley, chief scientist di NCC Group, lo spiega con un esempio preciso. Quando trovi un possibile bug, il passo successivo è confermarlo costruendo un exploit. Se chiedi a un modello AI di provarci e il guardrail rifiuta, perdi lo strumento quando ti serve di più. Il prompt “correggi questo codice” è lo stesso che serve per chiudere la vulnerabilità e per capirla a fondo. Anley lo paragona a un martello: strumento e arma, inseparabili.

Paolo Stagno, CTO di Crowdfense, aggiunge un secondo livello al problema. Anche senza guardrail, usare un modello cloud per lavorare su vulnerabilità non ancora patchate significa caricare dati sensibili su infrastrutture di terze parti. Il rischio è che quei dati finiscano nei cicli di addestramento futuri. Per questo Stagno usa i modelli frontier solo per reverse engineering e passa a modelli open-source locali per tutto ciò che riguarda la scoperta e lo sviluppo di exploit.

Giuseppe Cali, un altro ricercatore intervistato, ha una posizione diversa. Usa l’AI solo per il reverse engineering iniziale e per costruire strumenti di supporto, non per la scoperta dei bug. La sua posizione suggerisce che, per ora, il ruolo dell’AI nella sicurezza offensiva è complementare più che centrale.

C’è anche il contesto dei controlli di esportazione. A giugno il governo USA ha imposto restrizioni sui modelli Mythos e Fable di Anthropic, in parte per un report che dimostrava la possibilità di bypassare i guardrail pensati per prevenire attacchi. Le restrizioni sono state in parte revocate: Fable 5 è tornato ad accesso generale il primo luglio, Mythos 5 è stato reintrodotto solo per organizzazioni americane verificate.

Qualche giorno fa abbiamo raccontato come un ricercatore ha trovato una vulnerabilità RCE in WordPress spendendo 25 dollari di compute con GPT-5.6 (/it/radar/wordpress-rce-gpt-5-6-sol-security-research-25-dollars). Quell’esempio mostra il potenziale dell’AI per la sicurezza difensiva: lo stesso tipo di lavoro che i guardrail rischiano di rendere più difficile.

Per chi usa l’AI in contesti tecnici seri, il quadro ha due implicazioni concrete.

La scelta fra cloud e locale è anche una scelta di sovranità sui dati. Quando i tuoi dati sono vulnerabilità non patchate, caricarli su un modello cloud è un rischio di business, non solo tecnico.

La retorica sulla sicurezza dei modelli frontier e la pratica della sicurezza offensiva puntano in direzioni opposte. I lab vogliono modelli che non possano essere usati per attaccare, ma attaccare è esattamente come si scoprono le vulnerabilità da chiudere. La domanda è dove si fermano i guardrail: e per ora si fermano troppo presto, lasciando chi difende con uno strumento mutilato.