La soglia 'Critical' sul cyber: cosa ha appena innescato OpenAI con Astra
Il 7 agosto 2026 OpenAI ha pubblicato un post intitolato "Responding to the next frontier of critical cyber capabilities" e ha comunicato alla stampa che stava mettendo in pausa parti dello sviluppo interno del suo modello inedito Astra. Il motivo: le valutazioni preliminari degli ultimi giorni hanno portato OpenAI a concludere di non poter attualmente escludere che Astra abbia raggiunto il livello Critical di capacità di cybersicurezza del proprio Preparedness Framework.
È una prima volta. Il Preparedness Framework esiste da dicembre 2023. Nessun modello di frontiera — né GPT-4, né GPT-4o, né GPT-5.6 Sol, né alcun modello Anthropic o Google finora sottoposto a benchmark pubblici — ha in precedenza spinto il proprio laboratorio ad alzare la bandiera Critical. GPT-5.6 Sol si è collocato a High sul cyber ed è stato distribuito con mitigazioni. Astra è il primo candidato che ha spinto OpenAI a dire, per iscritto, forse non possiamo distribuirlo come distribuiamo tutto il resto.
Questa pagina è la spiegazione pratica che (al momento in cui scriviamo) nessun altro ha ancora scritto. Non un rimbalzo giornalistico. Cosa significa Critical come definizione tecnica, cosa succede operativamente quando un laboratorio lo dichiara, perché conta anche se non toccherai mai Astra, e come si allinea al framework parallelo di Anthropic, così da leggere il prossimo annuncio simile senza bisogno di un traduttore.
- Capire i quattro livelli di capacità del Preparedness Framework (Low / Medium / High / Critical) e cosa fa scattare una rivalutazione
- Conoscere la definizione esatta di 'Critical cyber' — è molto più stretta e specifica di 'il modello è bravo a fare hacking'
- Vedere la risposta operativa concreta applicata da OpenAI ad Astra: ambienti isolati, esecuzione in sandbox, cifratura dei pesi, monitoraggio della chain-of-thought, lavoro in pausa
- Mappare il Preparedness Framework di OpenAI sulla Responsible Scaling Policy / livelli ASL di Anthropic per ragionare sui due nelle stesse unità
- Portare a casa tre cose che chi costruisce sopra modelli di frontiera dovrebbe davvero cambiare questa settimana
Cosa è successo davvero, in un paragrafo
Tra circa il 1 e il 7 agosto 2026 OpenAI ha eseguito una serie di valutazioni interne di cybersicurezza e agentic coding su Astra — la famiglia di modelli anticipata il 1 agosto con dieci dimostrazioni matematiche formalizzate in Lean-4. Le valutazioni hanno mostrato salti ampi rispetto ai modelli precedenti. Abbastanza ampi da portare il team Preparedness di OpenAI a concludere di non poter attualmente escludere che Astra si collochi al livello Critical di capacità cyber. OpenAI ha annunciato pubblicamente che stava ampliando i test di sicurezza, irrigidendo i controlli di sicurezza e mettendo in pausa una parte del lavoro interno che non rispettava i nuovi controlli. Ha anche detto che intende svolgere ulteriori test con agenzie governative e organizzazioni indipendenti di AI safety prima di un rilascio ampio. Astra non è cancellato. Il suo rilascio è condizionato al fatto di abbassare la capacità stimata, oppure di mettere in piedi le mitigazioni che il framework richiede per un modello di livello Critical.
Per il contesto sul modello stesso vedi OpenAI Astra: la field note della preview.
Il Preparedness Framework in 90 secondi
Il Preparedness Framework di OpenAI — la versione live attuale è la v2 — è un documento che dice: prima di distribuire un modello di frontiera, lo valutiamo in un insieme di domini di capacità tracciati, e ogni dominio ha quattro livelli. I livelli sono comuni ai vari domini:
| Livello | Significato (semplificato) |
|---|---|
| Low | Baseline. Il modello non aumenta in modo significativo la capacità dell'attaccante. |
| Medium | Miglioramento non banale per gli attaccanti. Si distribuisce con mitigazioni standard. |
| High | Miglioramento serio. Si distribuisce solo con i controlli di sicurezza e distribuzione "High" (isolamento dei pesi, restrizioni di deployment, monitoraggio). |
| Critical | Il modello può portare a termine autonomamente operazioni end-to-end nel dominio contro bersagli reali induriti. Non distribuire senza che sia prima in atto uno specifico insieme di salvaguardie pre-impegnate. |
I domini attualmente tracciati da OpenAI sotto Preparedness v2 includono (parafrasando): cyber, biologico / chimico, auto-miglioramento dell'AI e autonomia del modello. Ognuno ha le proprie definizioni per i quattro livelli. Quindi un modello può essere, per esempio, Medium sul cyber e High sul bio.
Il framework è un impegno sul processo, non la promessa che il modello non sarà mai cattivo su qualcosa. Chiunque può leggere il PDF corrente su cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf.
Perché il livello sotto Critical (High) qui non basta
GPT-5.6 Sol è stato collocato a High sul cyber ed è stato distribuito con i controlli standard di livello High — gating di deployment, monitoraggio dei misuse, niente fine-tuning su tradecraft offensivo, sicurezza dei pesi. Quell'insieme di controlli è calibrato su un modello che assiste in modo significativo un attaccante che deve comunque fare la maggior parte del lavoro.
Critical è un regime diverso. Un modello cyber di livello Critical è uno in cui l'umano non è nel loop per la parte interessante dell'attacco. I controlli per un modello High sono strutturalmente insufficienti perché assumono che l'umano sia il collo di bottiglia.
Cosa significa davvero "Critical" sulla traccia cyber
Questa è la frase che sui giornali stanno leggendo male. L'inquadramento di OpenAI è stretto:
Un modello capace di scoprire e sviluppare zero-day funzionanti per molti sistemi critici reali e induriti senza aiuto umano, oppure di ideare ed eseguire strategie di cyberattacco end-to-end e nuove contro bersagli induriti a partire da un solo obiettivo di alto livello.
Due cose da notare.
Primo, non è "il modello è molto bravo nelle CTF". Le CTF sono enigmi pre-progettati con soluzioni previste. Critical richiede attacchi nuovi end-to-end contro sistemi reali induriti (patchati, monitorati, difesi). Quella è la classe di lavoro solitamente attribuita ai red team di stato.
Secondo, "senza aiuto umano" pesa moltissimo. Un modello che può aiutare un operatore esperto a rilasciare uno zero-day funzionante più velocemente non è automaticamente Critical — quello è pienamente territorio High. La soglia Critical è l'autonomia: il modello pianifica, scopre il bug, lo weaponizza e lo mette a segno, dato solo un obiettivo come "recupera ed esfiltra il database clienti da questo URL."
Con questa definizione, "non possiamo attualmente escludere Critical" è un'affermazione molto più forte di "il modello è bravo in sicurezza." Significa: le nostre valutazioni hanno trovato capacità pari o vicine al livello in cui un avversario competente potrebbe puntare questa cosa a un bersaglio indurito e ricevere shell access senza alcun ulteriore input umano.
La risposta operativa, passo per passo
Quando un laboratorio pronuncia queste parole, cosa succede in ufficio ha questo aspetto. Il post di OpenAI e i report successivi descrivono le seguenti azioni concrete:
- Astra si sposta in ambienti di sviluppo isolati con accesso di rete e ai tool ristretto. La superficie di tool-use che un modello di livello Critical userebbe per *dimostrare* il rischio (accesso arbitrario a internet, shell, installazione di pacchetti) è esattamente la superficie che viene tagliata per prima.
- Protezione e cifratura più forti dei pesi del modello. Non è un'invenzione del Preparedness — è il classico threat model di 'furto interno' che i grandi laboratori applicano a qualsiasi peso considerato strategicamente sensibile — ma Critical lo eleva esplicitamente a requisito duro.
- Ogni azione che il modello compie in qualsiasi ambiente sandboxed viene loggata. 'Universale' qui significa che il monitoraggio copre tutto l'uso interno, non solo i clienti esterni. Vengono flaggati sia i segnali di alignment sia quelli di misuse.
- La chain-of-thought (CoT) è usata come segnale, non solo come output. Il post di OpenAI chiama esplicitamente in causa la valutazione della CoT che può innescare security review — un modo per intercettare il modello che ragiona su, per esempio, come eludere il proprio safety training prima che il piano arrivi a un'azione.
- Qualsiasi team interno che usa Astra il cui ambiente non rispetta i nuovi controlli smette di usarlo. Questo è il costo concreto che il laboratorio è disposto a pagare in produttività degli sviluppatori per preservare l'opzione di distribuire il modello.
- Il prossimo giro di valutazioni si svolge con agenzie governative statunitensi (implicito: enti della linea CAISI / NIST AISI) e un piccolo numero di organizzazioni indipendenti di AI safety, non solo il team Preparedness interno di OpenAI. È il controllo che impedisce che la valutazione sia un correggere i propri compiti.
- Uno di tre esiti. (a) Le valutazioni esterne concludono che il modello è in realtà High, non Critical — si distribuisce con controlli di livello High. (b) Il modello è Critical, ma con mitigazioni specifiche (es. niente tool shell diretto, niente browsing su URL arbitrari, disclosure forzata per prompt security-adjacent) il rischio residuo è accettabile — si distribuisce un deployment vincolato. (c) Nessuna delle due funziona — il modello non viene distribuito nella sua forma attuale. Nulla nel post di OpenAI si impegna sull'esito (c); il linguaggio riguarda deliberatamente come verrà distribuito, non se.
OpenAI vs Anthropic: stessa forma, vocabolario diverso
Anthropic gestisce un framework parallelo chiamato Responsible Scaling Policy (RSP), attualmente alla v3.0. Invece di Low/Medium/High/Critical per dominio, Anthropic usa AI Safety Levels (ASL) globali: da ASL-1 ad ASL-5. I due framework provano a risolvere lo stesso problema e si sovrappongono all'incirca livello per livello, anche se non uno-a-uno.
L'allineamento approssimativo, per come si può dirlo senza che nessuno dei due laboratori avalli la mappatura:
| Livello Preparedness di OpenAI | Zona ASL di Anthropic | Cosa viene distribuito |
|---|---|---|
| Low | ASL-1 / ASL-2 | Qualsiasi cosa, con le policy d'uso standard. |
| Medium | ASL-2 | Si distribuisce con le mitigazioni di default odierne. |
| High | ASL-3 | Servono sia i controlli lato deployment sia quelli lato pesi. Anthropic ha attivato le protezioni ASL-3 per Claude Opus 4 a maggio 2025. |
| Critical | ASL-4 (approssimativamente) | Il livello che Anthropic sta attivamente rifinendo perché risulta genuinamente difficile da specificare in anticipo. La RSP v3 riconosce esplicitamente che le definizioni ASL-4/5 sono la parte dura. |
La sfumatura interessante è che la posizione pubblica di Anthropic su ASL-4 è stata "non abbiamo ancora pronto l'insieme di salvaguardie da distribuire per un modello che chiaramente soddisfi le soglie ASL-4" — che è più o meno quello che OpenAI ha appena detto a voce alta su Astra, con parole diverse. Quando leggi entrambi i framework d'ora in poi, la traduzione mentale è:
"Critical cyber" (OpenAI) ≈ "capacità autonoma tipo ASL-4" (Anthropic) ≈ "le salvaguardie che abbiamo già non sono le salvaguardie di cui questo ha bisogno".
Nessuno dei framework è magico. Sono impegni di processo. Il valore non è che impediscano la capacità — non lo fanno — ma che costringano il laboratorio a un punto di decisione esplicito e visibile pubblicamente invece di una deriva di default verso il rilascio.
Tre takeaway non ovvi per chi costruisce
Non stai (ancora) distribuendo Astra. Stai distribuendo sopra Claude, GPT-5.6, Gemini o qualcosa in locale. Ecco cosa cambia davvero per te.
1. I rilasci di frontiera resteranno indietro rispetto ai loro stessi annunci di capacità
L'evento Astra è l'istanza concreta di un pattern che diventerà più comune. I laboratori annunceranno una capacità (dimostrazioni matematiche, un punteggio a un eval, una demo) settimane prima che il modello sia distribuibile a quella capacità, perché i processi in stile Preparedness forzano un divario tra "abbiamo i pesi" e "siamo a nostro agio a spedire i pesi". Mettilo in roadmap: se un vendor pre-annuncia un modello di frontiera, non progettare la data di lancio del tuo prodotto attorno a quello. Progetta attorno al modello attualmente distribuito, tratta quello nuovo come un percorso di upgrade.
2. La tua superficie di tool è la mitigazione
Quando una capacità di livello Critical sta dietro una superficie di tool ristretta, il modello può comunque essere distribuito — semplicemente non può fare I/O di rete arbitrario o shell arbitraria. Quella è esattamente la forma di deployment verso cui i laboratori già spingono per altri motivi (sicurezza, costo, determinismo). Se stai costruendo un agente, la stessa igiene sulla superficie di tool che lo rende debuggabile lo rende anche distribuibile nel mondo in cui il modello sottostante è Critical-su-qualcosa. Concretamente: tool nominati, tipizzati, con allow-list strette battono "dagli una shell." Cross-link a Vetting agent skills e MCP tool poisoning e rug pulls.
3. Questo alza il valore dei tuoi eval, non di quelli del vendor
Gli eval Preparedness / RSP dei vendor riguardano il caso peggiore — questa cosa può attaccare autonomamente sistemi induriti. Quella è la domanda sbagliata per il tuo prodotto. Il rischio del tuo prodotto non è "il modello può sviluppare zero-day," è "il modello fa quello che i miei utenti hanno bisogno sul mio specifico workflow, senza produrre output che il mio dominio considera dannosi." Gli eval dei vendor non risponderanno a quello. La risposta più sana quando senti "Critical" è raddoppiare gli sforzi sui tuoi eval dei tuoi flow, così che qualunque cosa il vendor finisca per spedire (vincolata, ritardata o altro), tu possa fare regression test del cambiamento sul tuo prodotto il primo giorno. Vedi Supabase evals: agent benchmark per un pattern concreto.
Un esempio elaborato: come potrebbe apparire un deployment "Critical-con-mitigazioni"
Se le valutazioni esterne confermano Critical ma OpenAI vuole comunque distribuire, la forma del deployment è altamente prevedibile. Qualcosa di simile a:
Vincoli ipotetici di deployment per Astra (illustrativi)
- No raw shell / arbitrary code execution tool exposed to third-party developers - Browsing restricted to allow-listed content classes (docs, GitHub, package registries) and blocked from arbitrary URL fetch on request - All "security research" adjacent requests routed through a stricter refusal policy with mandatory logging and human review sampling - Fine-tuning API disabled for the Critical-tier model - API-only, no download, no on-device version, no self-hosted variant - Rate-limited and gated behind explicit enterprise agreements with reporting requirements - Independent monitoring org receives redacted misuse signals
Niente di tutto questo è confermato per Astra. È la forma di come deve apparire un deployment Critical-con-mitigazioni per soddisfare gli impegni stessi del framework. Se il rilascio finale assomiglia a grandi linee a questo, quello è il framework che funziona. Se non assomiglia per niente a questo, quello è un segnale che la classificazione, dopo tutto, è tornata sotto Critical.
Errori di lettura comuni da evitare
- "OpenAI ha cancellato Astra." No. Ha messo in pausa il lavoro interno che non rispettava i nuovi controlli ed esteso i test di sicurezza. Non c'è alcuna cancellazione.
- "Astra può hackerare qualsiasi cosa." No. La soglia non è "può hackerare." È "può portare a termine autonomamente attacchi end-to-end contro bersagli induriti a partire da un obiettivo di alto livello." Anche l'annuncio usa "non possiamo attualmente escludere," non "confermato."
- "Vuol dire che l'AI è ora troppo pericolosa da rilasciare." No. L'intero punto del framework è una risposta graduata. Critical non significa non distribuibile, significa non distribuibile senza i controlli specifici che Critical richiede.
- "Il Preparedness Framework è un moat." No. Nulla nel Preparedness limita il modello di qualcun altro. I laboratori open-weight (Meta, Mistral, DeepSeek, Qwen, MiniMax) hanno le proprie capacità, le proprie scelte e nessun obbligo di adottare il Preparedness. Il framework vincola il laboratorio che l'ha firmato, non il campo.
Cosa guardare dopo
- Se la prossima revisione del Preparedness Framework di OpenAI dividerà il cyber-Critical in bande più fini (es. Critical-Autonomous vs Critical-Assisted). In questo momento la definizione pesa molto su "senza aiuto umano" e la realtà è uno spettro.
- Se Anthropic mapperà esplicitamente e pubblicamente i suoi livelli RSP v3.0 sui livelli Preparedness. I ricercatori indipendenti già lo fanno informalmente.
- Se il prossimo grande rilascio di frontiera di qualsiasi laboratorio (Anthropic, Google, xAI, DeepSeek) innescherà un pattern inverso — un laboratorio che dice "abbiamo valutato per Critical cyber e non è scattato, ecco i numeri."
- Se la forma di deployment vincolato abbozzata sopra diventerà il template di default per la spedizione dei modelli di frontiera in generale, non solo per i modelli di livello Critical.
Verifica rapida
Check yourself
0/5Flashcard
Fonti e approfondimenti
- OpenAI — Responding to the next frontier of critical cyber capabilities (annuncio del 7 ago 2026)
- OpenAI — Preparedness Framework v2 (PDF) — la fonte delle definizioni dei livelli Low / Medium / High / Critical
- Anthropic — Responsible Scaling Policy e annuncio RSP v3.0
- Anthropic — Attivazione delle protezioni AI Safety Level 3 (contesto per il confronto High / ASL-3)
- Reportage: TestingCatalog, Interesting Engineering, Crypto Briefing, StartupHub.ai
- Cross-link AILmanac: OpenAI Astra: la field note della preview · Anthropic cyber eval escapes · Hardening autonomous runs · Vetting agent skills