GPT-6 Astra e la cybersecurity

Sulla cybersecurity GPT-6 Astra è il punto dell'annuncio con le implicazioni più serie, e non solo per i punteggi. È il primo modello che OpenAI dichiara al livello Critical del proprio quadro di preparazione — la classificazione più alta prevista.

Questa pagina raccoglie cosa dichiara OpenAI, cosa comporta in pratica e cosa cambia per chi vuole usarlo in azienda. Dati verificati il 4 settembre 2026.

I numeri

SRE-Bench è il risultato più impressionante del gruppo: misura se un modello sa fare reverse engineering di binari per capire la logica di un software senza accedere al codice sorgente. Astra risolve l'88,0% dei compiti in un solo tentativo e il 99,2% entro quattro, contro il 55,9% e 68,7% della generazione precedente — e il 12,5% di Opus 5.

Due chiarimenti metodologici dalle note. Il 5,5% di Sol sulla prova giugno–agosto è definito da OpenAI stessa un artefatto di un limite di 300 turni: a limiti più larghi lo stesso modello fa 11,5%. E su ExploitGym i punteggi Fable citati provengono da una variante con meno protezioni.

La prova costruita per evitare la contaminazione

Il test più interessante è quello che OpenAI ha costruito apposta per rispondere a un'obiezione ovvia: se un modello ha visto in addestramento vulnerabilità storiche, i risultati sui benchmark pubblici sono gonfiati.

Per aggirare il problema è stata creata una valutazione interna — ExploitBench (giugno–agosto 2026) — che usa vulnerabilità dei tre mesi precedenti. Contiene venti vulnerabilità ad alta severità del motore JavaScript V8 su tredici versioni stabili di Chrome, e verifica se un agente riesce a ottenere esecuzione di codice arbitrario.

Su quel test Astra ottiene 39,0% contro il 5,5% di Sol, consumando molti meno token di output. OpenAI precisa che alcune vulnerabilità incluse potrebbero non permettere l'esecuzione arbitraria nelle condizioni del test, quindi il 100% potrebbe non essere raggiungibile.

Durante la valutazione, dichiara OpenAI, Astra ha individuato e usato due vulnerabilità precedentemente sconosciute, comunicate ai rispettivi manutentori.

Cosa comporta la soglia Critical

Il livello Critical nel quadro di preparazione di OpenAI non è un'etichetta di marketing: comporta conseguenze operative dichiarate.

Il modello rifiuta i compiti cyber più avanzati. L'esempio citato è la creazione di proof-of-concept di exploit per vulnerabilità. OpenAI dichiara di voler ampliare l'accesso con protezioni meno restrittive attraverso un programma dedicato, per abilitare flussi difensivi come la validazione di proof-of-concept, l'analisi di malware e l'ingegneria di rilevamento.

Sono attive protezioni rafforzate. Maggiore robustezza contro i tentativi di aggiramento, più contesto per i sistemi di monitoraggio, test interni ed esterni continui incluso red-teaming automatizzato.

È attivo un monitoraggio del disallineamento in produzione per i modelli di questa classe: un sistema di classificatori che controlla ragionamento e azioni alla ricerca di comportamenti non autorizzati e può fermare automaticamente l'attività.

Il prezzo da pagare, dichiarato

Questa è la parte che va letta con attenzione se stai progettando qualcosa che gira senza supervisione.

OpenAI scrive esplicitamente che i controlli di sicurezza aggiuntivi possono rallentare, mettere in pausa o fermare lavoro legittimo, inclusa la cybersecurity difensiva. In ChatGPT o Codex può essere richiesta una revisione prima di continuare. In API il task si ferma.

Esempi pratici

Team di sicurezza che fa revisione del codice. È l'uso previsto e disponibile oggi. I punteggi su SEC-Bench Pro e la capacità di reverse engineering suggeriscono un aiuto reale, con il vincolo che i compiti più aggressivi vengono rifiutati.

Azienda che vuole automatizzare l'analisi di dipendenze vulnerabili. Attività difensiva, quindi in linea con l'uso previsto. Va però messo in conto che un controllo di sicurezza potrebbe fermare il flusso: serve sapere chi se ne accorge.

Consulente che fa penetration testing. Qui il modello rifiuta gran parte del lavoro. OpenAI indica un percorso di accesso ampliato, ma alla data di verifica non è la strada immediata.

Errori da evitare

• Progettare un flusso automatico senza gestire l'interruzione del task.
• Contare su capacità offensive: sono rifiutate.
• Leggere ExploitBench come misura generale: è costruito su vulnerabilità note.
• Confrontare punteggi Fable senza sapere che vengono da una variante diversa.
• Dedurre da questi numeri come andrà sul tuo stack.
• Ignorare il monitoraggio in produzione nella valutazione privacy.

Come applicarlo in azienda

Per un uso difensivo il percorso è lo stesso di qualunque agente, con due accortezze in più.

La prima è architetturale: dato che un task può essere fermato dai controlli, un flusso che gira di notte deve registrare l'interruzione e portarla all'attenzione di qualcuno. Un'automazione che si ferma in silenzio è peggio di una che non parte.

La seconda riguarda la valutazione dei dati: è attivo un monitoraggio in produzione che analizza ragionamento e azioni. Per chi tratta informazioni riservate va considerato nella valutazione, insieme al fatto che OpenAI dichiara il supporto alla conservazione zero dei dati per i clienti API idonei.

Sul resto vale il metodo consueto: dieci compiti reali del tuo processo, tre dei quali anomali, con registrazione di ogni passaggio e misurazione di quanti arrivano a conclusione senza intervento. Il criterio generale per valutare un agente è in miglior modello AI per agenti.

Cosa hanno trovato le valutazioni esterne

Oltre ai benchmark, l'annuncio riporta l'esito di verifiche condotte da esperti indipendenti sul modello senza le protezioni di produzione.

Il risultato dichiarato: Astra in quella configurazione poteva usare vulnerabilità precedentemente sconosciute per ottenere esecuzione di codice arbitrario in browser induriti, e creare exploit di escalation dei privilegi per sistemi operativi induriti.

Sono capacità che, nel quadro di preparazione di OpenAI, giustificano la classificazione Critical. E spiegano perché la versione distribuita rifiuti i compiti più aggressivi: la differenza fra il modello valutato dagli esperti e quello che arriva ai clienti è proprio quello strato di protezioni.

Va detto con chiarezza che questi risultati riguardano una configurazione non disponibile pubblicamente. Chi legge il titolo "100% su ExploitBench" e immagina di poter replicare quel comportamento con un abbonamento sta fraintendendo: la versione accessibile è deliberatamente più limitata.

Il monitoraggio in produzione, spiegato

Per i modelli di questa classe OpenAI dichiara di aver attivato un monitoraggio del disallineamento direttamente in produzione. Vale la pena capire cosa comporta, perché tocca la valutazione privacy di un progetto aziendale.

Il sistema è descritto come un insieme di classificatori che controllano il ragionamento e le azioni del modello alla ricerca di comportamenti non autorizzati, e che possono fermare automaticamente l'attività potenzialmente non autorizzata. È lo stesso tipo di monitoraggio usato da OpenAI per i propri impieghi interni.

Per un'azienda questo significa due cose. La prima: c'è uno strato di controllo che analizza il contenuto del lavoro, e va considerato nella valutazione dei dati trattati. La seconda: quel controllo può intervenire, quindi un flusso automatico può essere interrotto per ragioni che non dipendono dal codice.

OpenAI dichiara anche di supportare la conservazione zero dei dati per i clienti API idonei e di sperimentare un'elaborazione di sicurezza privata pensata per rafforzare il monitoraggio preservando la riservatezza. Chi tratta dati sensibili dovrebbe verificare l'idoneità prima di progettare l'architettura.

Una lettura per chi non fa sicurezza

Anche se la tua azienda non si occupa di cybersecurity, due elementi di questo capitolo ti riguardano.

Il primo è che le stesse capacità che rendono Astra forte sul reverse engineering lo rendono forte nel capire software di cui non hai la documentazione. Analizzare un formato di file proprietario, capire perché un gestionale si comporta in un certo modo, ricostruire la logica di un'integrazione mal documentata: sono compiti aziendali ordinari che ricadono nella stessa famiglia di capacità.

Il secondo è che le protezioni valgono per tutti. Se il tuo flusso tocca argomenti che il sistema di monitoraggio classifica come sensibili — anche per motivi legittimi — può fermarsi. Non è un caso limite teorico: OpenAI lo scrive esplicitamente riferendosi anche alla sicurezza difensiva.

La contromisura è banale ma va progettata: registra sempre gli esiti, incluse le interruzioni, e prevedi una coda per i casi che non si chiudono. È la stessa disciplina descritta in modelli AI per lavori ad alto volume, applicata a un rischio diverso.

Perché i benchmark cyber invecchiano male

Un'ultima considerazione che vale oltre questo modello.

Le prove costruite su vulnerabilità storiche hanno un problema strutturale: quelle vulnerabilità sono documentate pubblicamente, spesso con analisi dettagliate e codice di esempio. Un modello addestrato su materiale pubblico può averle viste, e allora il punteggio misura in parte la memoria e non la capacità.

È esattamente il motivo per cui OpenAI ha costruito la prova sui tre mesi precedenti. Ed è anche il motivo per cui un punteggio molto alto su un benchmark cyber datato dice meno di uno più modesto su compiti recenti: la differenza fra i due è il miglior indicatore disponibile di quanto un risultato sia genuino.

Quando leggi un confronto fra modelli su questo terreno, la domanda utile è sempre la stessa: quanto è recente il materiale su cui sono stati testati?

Il resto del percorso, in tre pagine. Il confronto con la generazione precedente è in GPT-6 Astra: cos'è e cosa cambia. Per i benchmark su cui il modello resta indietro, GPT-6 Astra: prezzi e come si paga. Il metodo per verificare tutto sui tuoi casi è in GPT-6 Astra: tutti i benchmark ufficiali.

Conclusione

Sulla cybersecurity GPT-6 Astra segna distacchi che non hanno paragoni negli altri capitoli dell'annuncio: 100% su ExploitBench, 88% su SRE-Bench dove Opus 5 si ferma al 12,5%, e la scoperta dichiarata di due vulnerabilità sconosciute su una prova costruita per evitare la contaminazione.

Proprio per questo raggiunge la soglia Critical, con le conseguenze che ne derivano: rifiuto dei compiti più avanzati, protezioni rafforzate e controlli che possono fermare anche lavoro legittimo.

Per un'azienda l'uso praticabile oggi è difensivo: revisione del codice e patching. Ed è un uso che va progettato sapendo che il flusso può interrompersi.

Se vuoi capire quali processi della tua azienda possono essere automatizzati con l'AI in sicurezza, Giallo Studio può aiutarti a trasformare il problema in un workflow reale.

Schema consigliato: Article + FAQPage + BreadcrumbList