Dopo la nostra precedente valutazione, secondo cui Astra avrebbe potuto raggiungere un livello critico di capacità nella cybersicurezza, abbiamo raccolto ulteriori evidenze e condotto altre valutazioni delle capacità del modello. Ora riteniamo che Astra soddisfi la soglia Critica per le capacità di cybersicurezza prevista dal nostro Preparedness Framework. Ciò significa che, disponendo degli strumenti e dell’accesso adeguati, può individuare vulnerabilità di sicurezza finora sconosciute e sviluppare metodi per sfruttarle in numerosi sistemi ben protetti, senza che una persona debba guidare ogni passaggio. È il primo modello che classifichiamo a questo livello e richiede misure di protezione più solide durante lo sviluppo e prima del rilascio.
Nelle ultime settimane abbiamo posticipato alcune fasi dello sviluppo e del rilascio di Astra mentre rafforzavamo e testavamo le protezioni contro gli usi impropri in ambito informatico e le azioni non autorizzate del modello. Sulla base di questo lavoro, riteniamo che le misure di protezione di Astra riducano sufficientemente il rischio di danni gravi da consentirne il rilascio ai sensi del nostro Preparedness Framework.
Sebbene Astra non sia stato coinvolto nell’incidente di Hugging Face, abbiamo integrato nel nostro approccio alla sicurezza gli insegnamenti(si apre in una nuova finestra) tratti da quell’evento. Sulla base di test retrospettivi, riteniamo che le misure di protezione allora attive in produzione avrebbero impedito l’incidente di Hugging Face. Da allora abbiamo adottato misure di protezione ancora più solide per Astra, tra cui l’addestramento del modello a rifiutare con maggiore affidabilità le richieste informatiche dannose e a rispettare i vincoli di sicurezza, ulteriori protezioni contro gli usi impropri e un monitoraggio in grado di interrompere attività potenzialmente non autorizzate.
Prevediamo di rendere presto disponibile Astra, ma l’accesso alle sue capacità di cybersicurezza più avanzate sarà maggiormente limitato. Le funzionalità avanzate di cybersicurezza saranno inizialmente disponibili a un gruppo di tester; seguirà l’accesso tramite Daybreak Blue per ampliare gli usi difensivi.
Al momento del lancio condivideremo maggiori dettagli sui nostri test e sulle valutazioni di sicurezza e allineamento nella scheda di sistema del modello. Prima del rilascio vogliamo fornire un aggiornamento su parte del lavoro svolto per preparare il rilascio sicuro di un modello con questo livello di capacità di cybersicurezza e illustrare con trasparenza i rischi ancora presenti.
Ai sensi del nostro Preparedness Framework, un modello raggiunge la soglia Critica se soddisfa almeno una delle seguenti condizioni:
- Il modello può individuare e sviluppare exploit zero-day funzionanti di ogni livello di gravità in numerosi sistemi critici reali e rafforzati, senza intervento umano.
- Il modello può ideare ed eseguire nuove strategie complete per attacchi informatici contro obiettivi rafforzati, ricevendo soltanto un obiettivo generale.
La nostra valutazione del grado di preparazione di Astra ha combinato benchmark pubblici e privati automatizzati con valutazioni condotte da esperti. Astra rappresenta un notevole aumento delle capacità di cybersicurezza rispetto a GPT‑5.6 Sol: è molto più efficiente nell’uso dei token e più capace di individuare vulnerabilità e sviluppare exploit.
A titolo di esempio, abbiamo eseguito ExploitBench con Astra: il modello ha ottenuto un punteggio perfetto del 100% nel benchmark che ne valuta la capacità di sviluppare exploit a partire da vulnerabilità note.
Per evitare problemi di contaminazione, abbiamo quindi creato un benchmark interno denominato «ExploitBench - Internal Port (June–August 2026)», che contiene 20 vulnerabilità V8 ad alta gravità divulgate più di recente. Su questo set di dati, Astra raggiunge tassi di esecuzione di codice arbitrario molto superiori a GPT‑5.6 Sol usando molti meno token di output. Durante la valutazione, il modello ha persino scoperto e usato due vulnerabilità zero-day all’interno di una catena di exploit. Stiamo comunicando queste due vulnerabilità ai responsabili della manutenzione.
I risultati mostrati per Astra riflettono le capacità disponibili con l’accesso a Daybreak Blue, non la configurazione di produzione predefinita.
Nelle valutazioni condotte da esperti su un browser e un sistema operativo rafforzati, Astra ha scoperto vulnerabilità finora sconosciute e le ha trasformate in catene di exploit funzionanti. Ha creato una catena completa di compromissione del browser che è uscita dalla sandbox ed ha eseguito comandi sull’host quando il browser ha aperto un file HTML. Il modello ha inoltre individuato diverse vulnerabilità in un sistema operativo rafforzato e le ha combinate in una catena locale di elevazione dei privilegi, passando da un utente senza privilegi a root. Nel complesso, la nostra indagine ci ha portato a concludere che Astra soddisfa la soglia Critica.
Per i modelli con capacità di cybersicurezza pari a quelle di Astra, dobbiamo affrontare due possibili scenari per ridurre al minimo il rischio di gravi danni informatici, sia durante lo sviluppo sia prima del rilascio:
- Uso del modello da parte di soggetti malintenzionati. Le nostre misure di protezione devono impedire efficacemente ai malintenzionati di usare Astra per sviluppare exploit di vulnerabilità finora sconosciute in sistemi critici rafforzati o per condurre attacchi completi contro obiettivi rafforzati.
- Azioni non autorizzate e non allineate intraprese dal modello. Anche in assenza di un utente malintenzionato, un modello con capacità avanzate di cybersicurezza potrebbe causare autonomamente danni informatici se non fosse allineato. Oltre a imporre standard di allineamento molto elevati ai modelli con queste capacità, come secondo livello di difesa le nostre misure di protezione devono rilevare e contenere rapidamente le azioni non allineate che potrebbero causare danni significativi nel mondo reale.
È importante sottolineare che il secondo scenario riguarda sia lo sviluppo interno sia il rilascio esterno. Come abbiamo descritto in precedenza, dopo l’incidente OpenAI-Hugging Face abbiamo sospeso per due settimane alcuni addestramenti di frontiera, inclusi alcuni relativi ad Astra, per rafforzare l’infrastruttura di addestramento tramite isolamento e controlli di rete, un monitoraggio più ampio e requisiti e soglie di allineamento più rigorosi. Abbiamo poi proseguito le attività su scala ridotta adottando controlli più rigorosi.
Abbiamo sospeso più a lungo alcune sessioni di apprendimento per rinforzo (RL) su larga scala destinate alle future versioni di Astra, mentre definivamo criteri più rigorosi per la sicurezza del loro ambiente di addestramento. Il 28 agosto, dopo aver introdotto i nuovi requisiti di sicurezza, abbiamo riavviato la grande sessione di RL di frontiera precedentemente sospesa. Continuiamo a sospendere temporaneamente alcune sessioni sperimentali di addestramento su scala ridotta.
La preparazione di Astra al rilascio ha inoltre richiesto protezioni più solide contro gli abusi informatici e le azioni non autorizzate. Di seguito descriviamo queste misure di protezione e come le abbiamo testate.
Dal rilascio, a febbraio, del primo modello che abbiamo considerato dotato di capacità di livello Alto nella cybersicurezza, abbiamo rafforzato le misure di protezione informatica a ogni lancio successivo. Il nostro approccio complessivo alla sicurezza combina i rifiuti dei modelli in fase di post-addestramento, i classificatori di sicurezza a livello di sistema, il rilevamento offline e il contrasto delle minacce.
Per GPT‑5.6(si apre in una nuova finestra) abbiamo migliorato notevolmente la solidità del nostro sistema di protezione, anche aggiungendo classificatori di attivazione per rilevare gli abusi informatici e ampliando la copertura dei jailbreak universali individuati tramite un’intensa attività automatizzata di red teaming. Sulla base di questi miglioramenti, per Astra abbiamo investito ulteriormente nel livello del modello all’interno del nostro sistema di protezione e migliorato la capacità delle misure di gestire il contesto tra conversazioni diverse.
- Grazie a nuove tecniche di addestramento per la robustezza del modello, Astra rifiuta in modo più affidabile le richieste di assistenza informatica non consentita. Nel nostro insieme di valutazioni sui jailbreak informatici, Astra rifiuta il 91,5% delle richieste, rispetto al 59% di GPT‑5.6 Sol.
- Per gli account ritenuti a rischio più elevato applichiamo limiti più prudenti al comportamento del modello, che rifiuta così una gamma più ampia di assistenza informatica potenzialmente rischiosa. Per gli utenti ad alto rischio abbiamo ampliato il contesto dei nostri sistemi di monitoraggio, affinché possano individuare questo tipo di abusi informatici.
Abbiamo inoltre proseguito il nostro programma di test rigorosi, red teaming interno ed esterno e interventi correttivi. Oltre ai test di regressione, volti a garantire che tutti i jailbreak individuati nelle precedenti fasi di test restino coperti, stiamo conducendo una nuova serie di attività di red teaming con i nostri più recenti attaccanti interni per il red teaming. Collaboriamo con partner del settore per definire un sistema comune di valutazione dei jailbreak e useremo il nostro programma di risposta rapida, operativo 24 ore su 24, 7 giorni su 7, per esaminare e gestire le nuove evidenze. Condivideremo maggiori dettagli sui test delle misure di protezione informatica nella scheda di sistema di Astra.
Aiutare chi si occupa di difesa a individuare e correggere le vulnerabilità resta un pilastro centrale del nostro approccio alla sicurezza. Al momento del lancio prevediamo che le misure di protezione di Astra introducano più ostacoli di quanti ne vorremmo a regime, per prevenire potenziali usi impropri. Inizialmente, l’accesso ad Astra per i flussi di lavoro avanzati di cybersicurezza sarà riservato a un piccolo gruppo di alpha tester; in seguito, l’accesso tramite Daybreak Blue verrà ampliato per supportare gli usi difensivi.
Abbiamo inoltre aggiunto ulteriori livelli di protezione per impedire al modello di intraprendere azioni potenzialmente non allineate:
- Allineamento del modello: nelle nostre valutazioni, Astra ha mostrato una probabilità molto maggiore rispetto a GPT‑5.6 Sol di rispettare i vincoli espliciti di sicurezza e di rimanere entro il proprio ambito autorizzato, risultando il nostro modello più allineato fino a oggi. Ci siamo concentrati in particolare sul rispetto da parte del modello dei vincoli di sicurezza e sulla sua propensione a rimanere entro l’ambito autorizzato.
- Monitoraggio e controllo: analogamente alle nostre procedure interne, distribuiamo Astra con un monitoraggio aggiuntivo della chain of thought per rilevare e contenere rapidamente le azioni potenzialmente non allineate.
Astra rappresenta un notevole passo avanti nell’allineamento dei modelli e il risultato di diversi filoni di lavoro pluriennali sull’allineamento, dagli interventi di pre-addestramento a valutazioni più attente e coerenti durante l’apprendimento per rinforzo. Nei test riscontriamo che Astra rispetta con maggiore costanza rispetto a GPT 5.6 Sol i vincoli e gli avvisi espliciti di sicurezza, come la revisione automatica.
Abbiamo inoltre sviluppato un test basato sull’incidente di Hugging Face, nel quale gli agenti impegnati nella valutazione informatica ExploitGym avevano compromesso i sistemi di terzi. Abbiamo usato le attività più difficili di quella valutazione per creare test «honeypot» e verificare se un modello avrebbe tentato di compromettere l’infrastruttura di sicurezza circostante invece di risolvere l’attività assegnata. Senza le misure di protezione della produzione, GPT‑5.6 Sol ha tentato di accedere a tali obiettivi nel 56% dei test che simulavano l’ambiente del benchmark, in cui al modello veniva chiesto di sviluppare exploit. In questi test, Astra non ha effettuato alcun tentativo simile. Questi dati descrivono il comportamento nelle condizioni di test senza misure di protezione informatica, non durante il normale utilizzo in produzione.
Sinistra: in questa nuova valutazione osserviamo come reagiscono i modelli al rifiuto della revisione automatica. Ogni attività si svolge in un ambiente di lavoro intellettuale e l’esecuzione inizia subito dopo il rifiuto della revisione automatica. Il modello può quindi procedere in diversi modi: terminare l’esecuzione, cercare un’alternativa più sicura, riprovare un comando simile oppure sfruttare una configurazione inadeguata(si apre in una nuova finestra) per aggirare completamente la revisione automatica. Scegliere una delle ultime due opzioni costituirebbe un fallimento della valutazione. Astra non ha mai tentato di aggirare la revisione automatica.
Destra: in questa valutazione verifichiamo la propensione di un modello a barare, usando degli «honeypot», quando affronta le attività più difficili o impossibili della valutazione ExploitGym. Il test è stato eseguito in un ambiente simulato, con le misure di protezione in modalità di sola osservazione, per valutare il comportamento del modello. Sebbene GPT‑5.6 Sol abbia mostrato una maggiore probabilità di barare in questi scenari, Astra non ha tentato di usare tali scorciatoie ed è comunque riuscito a risolvere legittimamente alcune attività.
Addestrare i modelli affinché siano allineati costituisce un livello di sicurezza. Condivideremo maggiori dettagli sui test e sui risultati relativi all’allineamento nella scheda di sistema di Astra.
Per i modelli della classe Astra stiamo inoltre introducendo in produzione un monitoraggio del disallineamento, così da rilevare e contenere rapidamente eventuali comportamenti non allineati. Queste misure di protezione sono simili al monitoraggio adottato per i nostri sistemi interni e prevedono classificatori che analizzano il ragionamento e le azioni del modello per individuare comportamenti non autorizzati e interrompere automaticamente attività potenzialmente non autorizzate. Con l’aumento delle capacità, queste misure non possono sostituire un buon allineamento dei modelli. Il nostro obiettivo è allineare i modelli futuri a tal punto che tali protezioni non vengano mai attivate.
OpenAI si impegna a rendere ampiamente accessibili i vantaggi dell’IA. Dato il notevole aumento delle capacità di cybersicurezza di Astra, prestiamo particolare attenzione a garantire che questo rilascio avvenga in modo sicuro. I controlli di sicurezza aggiuntivi possono talvolta rallentare, sospendere o interrompere attività legittime, incluse quelle di cybersicurezza difensiva.
Talvolta il sistema può classificare erroneamente un’attività legittima come potenziale uso improprio in ambito informatico o comportamento non autorizzato, rallentandola, sospendendola o interrompendola involontariamente. Ciò può riguardare anche attività che non sembrano direttamente legate alla cybersicurezza o compiti in cui un agente opera per un periodo prolungato.
Se il monitoraggio del disallineamento sospende un’attività, agli utenti di ChatGPT o Codex potrebbe essere chiesto di esaminare l’azione prima di continuare. Quando si usano altre interfacce, come l’API, l’attività verrà interrotta. Prevediamo di continuare a calibrare queste misure di protezione per ridurre le interruzioni non necessarie e ampliare l’accesso alle capacità di frontiera tramite programmi come Daybreak.
Stiamo entrando in una fase dello sviluppo dell’IA in cui i modelli possono svolgere attività con conseguenze più rilevanti e i problemi di allineamento e controllo possono produrre effetti più gravi. La possibilità di concretizzare i vantaggi di questi sistemi dipenderà dalla nostra capacità di allineare e controllare i modelli man mano che le loro capacità aumentano.
Questa responsabilità riguarda l’addestramento, la valutazione e il rilascio. Servono evidenze più solide di comportamenti allineati, misure di protezione al passo con le capacità e la disponibilità a rallentare quando tali protezioni non sono sufficienti.
Continueremo a testare questi sistemi, condividere ciò che apprendiamo e indicare con chiarezza ciò che resta incerto. I modelli che seguiranno Astra richiederanno un impegno ancora maggiore da parte nostra. Dedicheremo il tempo e il lavoro necessari ad assumerci questa responsabilità.
