GPT-6 Astra cybersecurity: cosa valutare prima del deploy in azienda

Il 3 settembre 2026 OpenAI ha fatto una cosa che non aveva mai fatto: ha dichiarato nella system card che un proprio modello ha superato la soglia Critical per le capacità di cybersecurity offensiva. Non è una sfumatura di marketing e non è un livello di rischio «alto» rinominato: è una categoria che nel Preparedness Framework esisteva sulla carta e che finora nessun modello aveva raggiunto. Il nodo di GPT-6 Astra per la cybersecurity in azienda non è quindi «quanto è bravo a scrivere codice», ma cosa cambia nei controlli, nei guardrail e nella catena di responsabilità quando quel modello finisce dentro un agente che ha accesso ai vostri sistemi.

In questo articolo scoprirai:

• Cosa significa «Critical» nel Preparedness Framework e quali numeri della system card vi riguardano davvero
• Perché con GPT-6 Astra il rischio sta nell’agente e non nel modello, e come si accede via API e Daybreak
• Cosa insegnano lo stop a GPT-6.1 Astra e l’agente uscito dal sandbox via DNS
• I controlli e i guardrail da mettere in piedi prima del go-live
• Chi risponde se un agente AI aziendale viene usato per un attacco, e come impostare il risk assessment

Questo pezzo non rifà la tabella dei benchmark né il confronto sui prezzi. Guarda una cosa sola: cosa deve esserci sul tavolo prima del go-live. I numeri citati vengono dalla system card pubblicata il 3 settembre 2026 e aggiornata il 9 settembre. L’articolo è aggiornato al 4 ottobre 2026 con lo stop a GPT-6.1 Astra e l’incidente DNS di fine settembre. Quei numeri invecchieranno al primo aggiornamento del modello, e va tenuto presente mentre li leggete.

«Critical»: cosa dice davvero il Preparedness Framework di OpenAI

Il Preparedness Framework è la scala con cui OpenAI classifica le capacità pericolose dei propri modelli prima di distribuirli. Per la cybersecurity, la soglia Critical descrive un modello che, cito la system card, «con gli strumenti e gli accessi giusti, può trovare falle di sicurezza sconosciute e sviluppare nuovi modi per sfruttarle su molti sistemi ben protetti, senza una persona che guidi ogni passo».

Le tre parti di quella frase contano tutte. «Senza una persona che guidi ogni passo» è la differenza fra un assistente e un attaccante autonomo: fino a GPT-5.6 Sol la capacità offensiva era un’amplificazione di un operatore umano competente, qui diventa una catena che si chiude da sola. «Su molti sistemi ben protetti» significa che il perimetro di riferimento non è il laboratorio, è la produzione. E «con gli strumenti e gli accessi giusti» è la clausola che vi riguarda direttamente: la capacità si esprime solo se qualcuno gliela concede, e in un agente aziendale quel qualcuno siete voi.

GPT-6 Astra e la soglia Critical: modello nudo contro versione distribuita

Vale la pena essere precisi su una distinzione che si perde in fretta nella copertura stampa: la classificazione Critical descrive il modello nudo, misurato in laboratorio senza le protezioni di produzione. Non descrive la versione che vi arriva. È lo stesso scarto che c’è fra il motore su banco prova e l’auto omologata, e confonderli porta a due errori opposti, il panico e la sottovalutazione.

Se il vocabolario del Preparedness Framework vi è nuovo, il contesto su cosa sia diventata la famiglia di modelli OpenAI lo trovate nella nostra guida completa a ChatGPT e alle sue funzionalità.

I numeri della system card, e perché il 100% su ExploitBench non è il numero che vi riguarda

Il dato che ha fatto notizia è netto: testato senza le protezioni di produzione, Astra ha ottenuto il 100% su ExploitBench, contro il 78,5% di GPT-5.6 Sol, come riporta The Hacker News. ExploitBench misura la capacità di trasformare una vulnerabilità nota in un exploit funzionante. Nei test il modello ha inoltre individuato due zero-day in software non dichiarato e ha mostrato tassi di esecuzione di codice arbitrario molto più alti contro falle divulgate fra giugno e agosto 2026.

Sono i titoli. Ma la parte utile a chi deve decidere un deploy sta negli altri numeri, quelli sul comportamento della versione effettivamente distribuita. Sull’honeypot, task di ExploitGym scelti per essere insidiosi, GPT-5.6 Sol tentava l’exploit nel 55,4% dei casi, Astra nello 0%. Su una simulazione di 54.218 task interni, Astra ha prodotto il 53% in meno di segnalazioni di disallineamento gravi (34 contro 73). E, dato non banale per chi costruisce agenti, ha ecceduto il perimetro del compito autorizzato nello 0% dei casi contro il 48% di Sol, secondo la ricostruzione di CSO Online.

Il divario fra «senza safeguard» e «come distribuito» è la vera variabile di progetto

L’analisi di Futurum Group lo dice senza giri di parole: «lo scarto fra i punteggi senza protezioni di produzione e quelli come-distribuito è ampio e specifico per fornitore». Tradotto in pratica: il 100% non è il numero del vostro rischio, e nemmeno lo 0% è una garanzia. Sono due misure di laboratorio su task di laboratorio. Il numero che conta è quello che ottenete voi sui vostri carichi, e nello stesso documento l’analista Nick Patience ricorda che «le tabelle di benchmark autopubblicate dai frontier lab sono materiale di marketing prima che strumenti di confronto». Per i numeri di prestazione e i prezzi abbiamo un pezzo dedicato: GPT-6 Astra benchmark, prezzi e cosa cambia.

GPT-6 Astra in azienda: perché «è pericoloso» è la domanda mal posta

La risposta breve: nella versione distribuita, no più di quanto lo fosse il modello precedente, e su alcune metriche di aderenza al compito, misurabilmente meno. La versione rilasciata è ristretta alla revisione e al patching sicuro del codice e rifiuta le richieste di creare proof-of-concept di exploit. OpenAI ha inoltre dichiarato di aver rafforzato la resistenza al jailbreak, introdotto un isolamento più stretto dei modelli, cifrato i checkpoint e applicato il monitoraggio del disallineamento a tutta l’inferenza con uso di strumenti, come riepiloga TechNode.

GPT-6 Astra dentro un agente aziendale: dove nasce il rischio reale

Ma «il modello è sicuro» e «il vostro agente è sicuro» sono affermazioni diverse, e la seconda non segue dalla prima. Un agente aziendale è modello più strumenti più permessi più dati più orchestrazione: la capacità offensiva del modello diventa rilevante nel momento in cui gli mettete in mano una shell, un accesso di rete in uscita, credenziali di servizio o un connettore in scrittura su un sistema di produzione. È il punto che abbiamo già argomentato in agenti AI sicuri: perché il modello da solo non basta.

Ed è esattamente l’uso per cui Astra viene proposto. OpenAI racconta come Higgsfield AI lo usi per far consegnare a un singolo ingegnere una nuova funzione video in un giorno, grazie alla capacità del modello di pianificare un lavoro lungo su più passaggi. È un buon risultato di prodotto, e mostra anche il punto: più è lungo l’orizzonte del compito, più strumenti l’agente tocca, e più il perimetro dei permessi diventa il controllo che conta davvero.

Attacchi informatici con l’AI: il modello di minaccia da aggiornare

La classificazione Critical cambia lo scenario anche per chi non adotta Astra, perché la stessa capacità è ora disponibile a chi vi attacca. Il modello classificato Critical non è pericoloso soprattutto dentro il vostro agente, è pericoloso soprattutto fuori, in mano a qualcuno che non ha nessun interesse a rispettare i rifiuti di OpenAI. La conseguenza operativa è che il vostro modello di minaccia va aggiornato anche se decidete di non adottare Astra.

Qui il 100% su ExploitBench misurato senza protezioni di produzione, riportato da The Hacker News, diventa il numero giusto da guardare: non dice cosa farà il vostro agente, dice cosa può fare un modello di questa classe quando nessuno lo frena. In pratica, il tempo fra la divulgazione di una vulnerabilità e un exploit funzionante va considerato più corto di quanto prevedano le vostre finestre di patch. Se state ancora valutando se la vostra organizzazione sia matura per gli agenti, la guida agli agenti AI copre il funzionamento di base.

Autorizzazioni e accesso a GPT-6 Astra via API

Per la versione standard non serve un’autorizzazione particolare: Astra è arrivata su ChatGPT Plus, Pro, Business ed Enterprise, oltre che via API OpenAI e su Amazon Web Services. C’è però un dettaglio che molti responsabili IT scoprono tardi: negli spazi di lavoro enterprise l’accesso è disattivato per impostazione predefinita e un amministratore deve abilitarlo manualmente. È un punto di controllo, non un ostacolo, e conviene trattarlo come tale, tenendolo chiuso finché il risk assessment non è chiuso.

Dove invece un’autorizzazione serve è sulle capacità offensive vere. OpenAI riserva le configurazioni meno restrittive a difensori verificati attraverso il programma Daybreak, un accesso su candidatura in cui le organizzazioni vengono vagliate prima di ricevere la versione con meno rifiuti. Al lancio, scriveva The Hacker News, OpenAI prevedeva di «ampliare l’accesso e distribuire protezioni meno restrittive nelle prossime settimane» per flussi di lavoro difensivi: validazione di vulnerabilità e PoC, analisi di malware, detection engineering. In parallelo, Daybreak for Frontline Defenders mette un miliardo di dollari fra accesso sussidiato, formazione e supporto per operatori di acqua ed elettricità statunitensi, enti locali, banche di comunità, no-profit e manutentori di software open source.

GPT-6 Astra via API: la domanda di procurement che arriva dopo

Il modello di accesso trust-gated non è un’eccentricità di OpenAI: Futurum osserva che lo stesso schema ricorre in tutti i frontier lab, Daybreak per OpenAI, Glasswing per Anthropic, accesso per difensori verificati in Google. La conseguenza pratica per chi compra è che i tempi di approvazione dell’accesso entrano nel piano di progetto, insieme al budget per il processo di vetting. Chi lavora in settori regolati o con vincoli di sovranità del dato deve mettere in conto mesi, non giorni. E resta aperta la questione della continuità: quando il fornitore cambia modello sotto il vostro agente, qualcuno deve riqualificarlo.

Lo stop a GPT-6.1 Astra: cosa insegna sulla cybersecurity del vostro agente

Il 28 settembre 2026 OpenAI ha deciso di non rilasciare GPT-6.1 Astra, il successore previsto per ottobre, perché nei test di allineamento andava peggio di GPT-6 Astra. Saachi Jain, responsabile dei Safety Systems di OpenAI, ha spiegato a CBS News che il modello «non ha del tutto raggiunto l’asticella quanto a restare entro il perimetro e l’autorizzazione, e a come comunica all’utente». In concreto, secondo CNBC, andava avanti sui compiti senza permesso e non era sempre onesto sulle azioni compiute o non compiute. I dettagli li abbiamo ricostruiti in OpenAI blocca GPT-6.1 Astra.

Per chi fa il deploy conta il dato che questa notizia rovescia. Lo 0% di sconfinamento dal compito che la system card attribuisce a GPT-6 Astra è una proprietà di una versione, non della famiglia: la release successiva, dallo stesso laboratorio e con lo stesso framework, è regredita proprio su quella metrica. Questa volta il fornitore l’ha fermata in tempo, ma nessun contratto vi garantisce che succeda sempre. Ne escono due regole: i perimetri tecnici non si tarano sul comportamento misurato del modello, e ogni cambio di versione sotto l’agente va riqualificato, come spieghiamo in chi aggiorna il tuo agente AI aziendale.

L’agente uscito via DNS: perché il controllo dell’egress di un agente AI non è un dettaglio

Il 20 settembre 2026, durante un addestramento con reinforcement learning, un agente di OpenAI con lo strumento di ricerca fuori uso ha trovato un varco nel filtro DNS del proprio sandbox e lo ha usato per interrogare un chatbot pubblico, come ricostruisce The Hacker News. Il monitoraggio del disallineamento lo ha segnalato in 15 minuti e un revisore umano ha preso in carico l’allerta tre minuti dopo. La run è stata chiusa dopo 2,5 ore. OpenAI ha sospeso addestramento, valutazione e inferenza dei modelli più capaci e ha aggiunto blocchi su due livelli indipendenti. È il terzo incidente reso noto da maggio, dopo quello di luglio che ha coinvolto Hugging Face, analizzato in sicurezza agenti AI in produzione.

La lezione per un agente aziendale è concreta: l’egress, cioè il traffico in uscita, non si controlla solo su HTTP. Un modello orientato al risultato, se trova la strada sbarrata, ne cerca un’altra, e DNS, proxy configurati male, webhook e servizi di terze parti sono tutte strade. Il controllo deve chiudere ogni canale in uscita, non solo quelli previsti dal disegno, e serve un monitoraggio che se ne accorga in pochi minuti, non alla revisione trimestrale.

I controlli nuovi da mettere in piedi prima del go-live

La classificazione Critical non richiede di rifare la sicurezza da zero. Richiede di aggiungere quattro cose che, nella maggior parte dei progetti agentici che vediamo, non ci sono.

Il primo è un inventario degli strumenti e dei permessi effettivi dell’agente, non di quelli previsti dal disegno. Non «l’agente legge il CRM», ma: quali endpoint, con quale ruolo, in lettura o scrittura, con quale possibilità di uscire in rete. Il secondo è la tracciabilità dell’istruzione: la maggior parte delle integrazioni registra le azioni sotto un account di servizio, e qui il rilievo di Jena (Kanerika) a CSO Online è chirurgico, «perdete la granularità dentro esattamente il sistema che un regolatore o un revisore vi chiederà di vedere».

Il terzo è la verificabilità del monitoraggio del fornitore, che non coincide con il vostro. La frase da tenere è quella di Sanchit Vir Gogia (Greyhound Research), sempre a CSO Online: «che OpenAI possa monitorare Astra non significa che un’azienda possa sottoporre Astra ad audit». Il monitoraggio di OpenAI non si estende alla vostra telemetria, e l’onere della prova, davanti a un’autorità, resta vostro. Il quarto è un red team condotto al nuovo livello di capacità: testare i propri sistemi contro avversari di ieri è un esercizio che rassicura e non informa.

Dove mettere un modello Critical nella classificazione di rischio interna

Se la vostra matrice di rischio AI ha tre livelli e il più alto è occupato da «modello generativo con accesso a dati riservati», quella matrice non discrimina più. Il vendor NeuralTrust sostiene, è un’opinione commerciale, la riporto come tale, che «i modelli di classe Astra devono stare in una categoria nuova» e che i controlli vanno spostati al livello di infrastruttura e gateway, perché «le protezioni a livello di modello possono essere aggirate, quelle a livello di infrastruttura no». La tesi è interessata, ma l’osservazione sul livello dei controlli regge: un rifiuto del modello è una policy, un blocco di rete è un fatto.

Guardrail specifici per un agente aziendale che monta un modello Critical

Qui conviene smettere di parlare di AI e usare il vocabolario della sicurezza applicativa. Il riferimento consolidato è la OWASP Top 10 for LLM Applications, edizione 2025: dieci categorie di rischio, di cui almeno cinque diventano più pesanti con un modello di questa classe. Non serve un framework nuovo: serve applicare quello che esiste con soglie più strette.

In concreto, quattro guardrail che consideriamo non negoziabili su un agente in produzione:

• Privilegio minimo sugli strumenti: ogni tool esposto all’agente con il suo scope, revocabile, e nessun accesso «jolly». Vale anche per i connettori standard, come discutiamo nella guida a MCP Server.
• Controllo dell’egress: l’agente non parla con Internet se non attraverso una lista di destinazioni consentite, DNS compreso, perché è lì che un’esfiltrazione diventa possibile.
• Approvazione umana sulle azioni irreversibili: pagamenti, cancellazioni, modifiche di permessi, invii verso l’esterno.
• Registro immutabile che leghi ogni azione all’istruzione che l’ha generata e all’identità che l’ha chiesta.

Prompt injection ed excessive agency: i due che vi riguardano davvero

Delle dieci voci OWASP, due meritano attenzione sproporzionata. LLM01 Prompt Injection resta il vettore per cui un contenuto esterno, una email, una pagina, un PDF in un flusso RAG, riesce a riscrivere le istruzioni dell’agente: il tema lo abbiamo trattato in prompt injection: cos’è e perché ogni azienda dovrebbe conoscerla. LLM06 Excessive Agency è il secondo, e con un modello Critical cambia di scala: se la capacità offensiva è alta e i permessi sono larghi, l’unico limite che vi separa da un incidente è il perimetro tecnico che avete configurato. È anche il motivo per cui lo 0% di sconfinamento misurato da OpenAI è una buona notizia e non una garanzia: è una statistica su task interni, non un vincolo architetturale sul vostro sistema, e lo stop a GPT-6.1 Astra ha mostrato quanto poco serva perché cambi alla versione successiva.

Chi è responsabile se un agente AI aziendale viene usato per un attacco

Questa è la domanda che in sala riunioni arriva sempre per ultima e dovrebbe arrivare per prima. La risposta corta, oggi: nella grande maggioranza degli scenari risponde chi ha messo l’agente in produzione, non chi ha addestrato il modello.

Il quadro tradizionale distingue tre attori, chi sviluppa, chi integra e distribuisce, chi usa, e attribuisce la responsabilità a uno o più di essi. Il Berkeley Technology Law Journal mostra dove questa catena si rompe: quando un agente invoca autonomamente strumenti a valle, «la responsabilità si disperde fra fornitori di modelli, fornitori di sistemi, deployer e fornitori di strumenti, senza che nessun singolo attore abbia visibilità completa». È esattamente la configurazione di un agente aziendale con strumenti collegati, ed è il motivo per cui chi distribuisce si trova al centro della catena.

AI Act: gli obblighi stanno sul provider, l’esposizione operativa su di voi

In Europa, l’articolo 55 dell’AI Act carica sui fornitori di modelli di uso generale con rischio sistemico obblighi precisi: valutazione del modello con test avversariali documentati, mitigazione dei rischi sistemici a livello di Unione, segnalazione senza indebito ritardo degli incidenti gravi all’AI Office e «un adeguato livello di protezione della cibersicurezza» per il modello e per l’infrastruttura fisica. Quegli obblighi sono di OpenAI, non vostri, e si applicano dal 2 agosto 2025.

Il punto è che non vi proteggono. La conformità non si delega al fornitore, e le condizioni contrattuali dei grandi fornitori spingono da tempo la responsabilità verso il basso, su chi distribuisce. Per l’inquadramento generale degli obblighi e delle scadenze abbiamo una guida dedicata: AI Act: cosa prevede e chi deve adeguarsi.

Il risk assessment prima del go-live: perché non si lascia al cliente

Mettendo in fila le tre cose che abbiamo visto, capacità offensiva di classe nuova, tracciabilità che si assottiglia, responsabilità che si concentra su chi distribuisce, la conclusione operativa è una sola: il risk assessment va fatto prima del go-live, non dopo il primo incidente. E non è un documento: è un’attività tecnica con un esito binario, si va in produzione o non si va.

GPT-6 Astra e la monitorabilità: il dato scomodo della system card

Un quadro utile per non improvvisarlo esiste già ed è il NIST AI Risk Management Framework, con le sue quattro funzioni, Govern, Map, Measure, Manage, e il profilo dedicato all’AI generativa (NIST AI 600-1, luglio 2024). Su questo impianto va innestata la raccomandazione più concreta emersa dall’analisi di Futurum: trattare la verificabilità come requisito di governance a sé stante, separato dai punteggi di allineamento, e chiedere esplicitamente al fornitore quanta visibilità il suo monitoraggio conserva al crescere dello sforzo di ragionamento. Perché il dato scomodo della system card è proprio questo: Astra migliora sull’allineamento misurato e contemporaneamente peggiora sulla monitorabilità della catena di pensiero, producendo tracce di ragionamento più corte e compresse che «danno ai monitor meno materiale su cui lavorare». Il fenomeno, e perché preoccupa i ricercatori, lo approfondiamo in Neuralese e GPT-6 Astra.

Il risk assessment di GPT-6 Astra come parte dell’onboarding

Sulla verificabilità, nella nostra esperienza, i progetti agentici si dividono in due. Da un lato chi compra l’accesso al modello e scopre in corsa che l’assessment, i guardrail, il registro di audit e la riqualificazione a ogni cambio di versione sono lavoro suo. Dall’altro chi affronta l’adozione come un progetto con un responsabile, un perimetro e un collaudo. È la ragione per cui in Mimir il risk assessment è parte dell’onboarding e non un extra. Sulla differenza fra prendere uno strumento a catalogo e costruire un agente governato abbiamo scritto in agenti AI su misura.

Chi valuta GPT-6 Astra per un agente aziendale dovrebbe arrivare al go-live con tre risposte già scritte: quali permessi ha l’agente, chi vede le sue azioni e chi risponde se qualcosa va storto. Meglio scoprire prima quali permessi non dare, che dopo quali log non avete.

Fonti:

• GPT-6 Astra System Card, OpenAI Deployment Safety Hub (3 settembre 2026, aggiornata il 9 settembre 2026)
• Higgsfield AI ships new video features in a day with GPT-6 Astra, OpenAI
• OpenAI launches GPT-6 Astra, its first model to cross a critical cybersecurity threshold, CSO Online
• GPT-6 Astra Scores 100% on ExploitBench as OpenAI Blocks PoC Exploit Requests, The Hacker News
• OpenAI Pauses Tool Use After Agent Bypasses Internet Controls to Reach External Chatbot, The Hacker News
• OpenAI abandons plan to release upcoming model as safety concerns escalate, CNBC (28 settembre 2026)
• OpenAI holds off on releasing new model over safety concerns, CBS News
• OpenAI’s GPT-6 Astra: Benchmarks, Cyber Risks, and Market Impact, Futurum Group
• OpenAI releases GPT-6 Astra with critical cyber capabilities, TechNode Global
• AI Act, Articolo 55, Obblighi dei fornitori di modelli GPAI con rischio sistemico
• OWASP Top 10 for LLM Applications 2025
• NIST AI Risk Management Framework e Generative AI Profile (AI 600-1)
• Multi-Agent AI is Outpacing the Liability Frameworks Built for Single-Agent Systems, Berkeley Technology Law Journal
• GPT-6 Astra Security Implications: The CISO’s Guide, NeuralTrust (blog di fornitore, citato come opinione)