Daybreak: OpenAI ha spostato la sicurezza dai refusal al cancello d'accesso
Il 95% di completamento di GPT-5.6-Cyber non misura la capacità, misura la volontà. La sicurezza ora sta nel cancello d'accesso, non nel rifiuto.
Nel post del 10 agosto 2026 con cui ha esteso il programma Daybreak, OpenAI pubblica un numero inedito: il tasso di completamento delle richieste cyber. Non una capacità, non un benchmark di scoperta di vulnerabilità. La percentuale di volte in cui il modello risponde invece di rifiutare. GPT-5.6-Cyber completa il 95.0% dei task avanzati (exploit chain, bypass di autenticazione, escalation di privilegi), contro l'1.5% di GPT-5.6 Sol e il 2.0% dello stesso modello usato con i guardrail di Daybreak Blue (annuncio OpenAI).
Fino a poco tempo fa quel numero si chiamava tasso di refusal, e nelle system card si leggeva come indicatore di sicurezza: più alto, meglio era. Ora è una feature di prodotto, presentata con lo stesso tono con cui si annunciano i token di contesto. L'azienda ha spostato la sicurezza da ciò che il modello si rifiuta di fare a chi ha il permesso di chiederglielo.
L'annuncio: un modello addestrato a rifiutare meno
Il post introduce due tier d'accesso. Daybreak Blue dà ai difensori approvati i modelli generalisti di frontiera, GPT-5.6 Sol incluso, con guardrail "adattati al lavoro difensivo autorizzato": è il punto di partenza consigliato per la maggior parte dei team. Daybreak Red apre i modelli addestrati per la ricerca di vulnerabilità, la validazione di exploit e i test di sicurezza. GPT-5.6-Cyber, costruito su GPT-5.6 Sol, vive nel secondo tier e viene descritto con una formula che non lascia margini: "addestrato a ridurre i refusal per alcuni task cyber dual-use ad alto rischio".
Per misurare questo risultato OpenAI ha creato un'eval interna dedicata, l'Advanced Cybersecurity Completion Rate, e il confronto con la generazione precedente è impietoso: GPT-5.5-Cyber completava solo il 57.3% delle richieste, e il post cita esplicitamente il feedback dei ricercatori che si erano scontrati con rifiuti persistenti sul modello precedente. Il modello successivo arriva al 95.0%. Nei prompt di esempio, la richiesta di uno strumento per aggirare il Keychain di macOS e decifrare i cookie di Chrome ottiene da GPT-5.6-Cyber una risposta operativa che indica la strategia di attacco, e un rifiuto da tutte le altre configurazioni, GPT-5.5-Cyber incluso.
Il giorno dopo, l'11 agosto, OpenAI annuncia che Daybreak Blue e Daybreak Red sono disponibili su Amazon Bedrock con l'endpoint bedrock-mantle, dentro i workflow AWS esistenti. Il disegno è coerente: il modello è un prodotto, e il prodotto si vende attraverso il canale enterprise.
Un numero che misura la volontà, non la capacità
Il punto è che il 95.0% non dice nulla su quanto GPT-5.6-Cyber sia bravo a trovare vulnerabilità. Dice solo quante volte risponde. E lo stesso annuncio fornisce la prova che le due cose non coincidono.
Nell'eval interna Vulnerability Discovery and Report Writing, in cui un agente deve trovare vulnerabilità in un repo e consegnare un report, GPT-5.6-Cyber ottiene risultati peggiori di GPT-5.6 Sol. OpenAI attribuisce il risultato a report più corti e meno dettagliati. Su ExploitBench, il task che chiede di trasformare una vulnerabilità V8 in un exploit completo con il sandbox attivo, nel setting standard da 300 turni vince GPT-5.6 Sol (Daybreak Blue), più efficiente nei token; se si raddoppiano i turni a 600, il gap si riduce.
"Le versioni più recenti dei modelli concorrenti, successive a Opus 4.6, rifiutano di svolgere i task a causa dei guardrail di sicurezza integrati e per questo non sono mostrate": così Google DeepMind, presentando Gemini 3.5 Flash Cyber il 21 luglio, descrive i benchmark sulla pipeline di commit scanning di Chrome (post DeepMind).
I modelli che rifiutano vengono esclusi dai benchmark. Il rifiuto, da garanzia di sicurezza, è diventato un costo competitivo che i produttori di modelli cyber calibrano come una variabile di prodotto: OpenAI lo abbassa con l'addestramento, Google lo aggira distribuendo il modello solo a governi e partner fidati via CodeMender.
Messo in fila, il quadro dice una cosa che l'annuncio non dice: l'addestramento che abbassa i refusal ridistribuisce la capacità invece di aumentarla. Sulle richieste in cui il modello deve solo rispondere, il tasso sale dal 2.0% al 95.0%. Sui task in cui deve scavare in profondità e documentare, la versione specializzata perde contro la generalista da cui deriva. Il completamento e la competenza sono due assi diversi, e il primo è quello che viene pubblicizzato.
La sicurezza si sposta al cancello
Se il rifiuto non è più la garanzia, dove finisce la sicurezza? Nell'annuncio, tutta fuori dal modello. L'accesso a Daybreak è controllato da verifica dell'identità, restrizioni d'uso approvate, monitoraggio e attestazioni legali. E dal 1 settembre 2026 OpenAI richiede hardware security key per tutti gli account individuali Daybreak. Per le organizzazioni il cancello è doppio: i requisiti di sicurezza, governance e procurement dell'ambiente enterprise che il post AWS elenca come parte dell'offerta.
Il modello nel frattempo dimostra di che cosa è capace. Nell'annuncio, OpenAI riporta di aver usato GPT-5.6-Cyber per studiare V8, il motore JavaScript di Chrome, e di aver trovato due vulnerabilità incatenabili per corrompere la memoria ed evadere l'heap sandbox, segnalate a Google tramite disclosure coordinata. La prima è CVE-2026-15903: lettura e scrittura fuori dai limiti in V8, corretta in Chrome a partire dalla 150.0.7871.128, severità High con CVSS 3.1 di 8.8.
Il bug è un safety check saltato dall'optimizing compiler nella conversione di valori in interi, che produce un numero fuori scala usato come indice di array: il compilatore omette il bounds check e l'attaccante legge o sovrascrive memoria altrui. Per uscire dal heap sandbox in genere serve una seconda vulnerabilità, e GPT-5.6-Cyber l'ha trovata. Nello stesso post: almeno 5 vulnerabilità in un mobile OS popolare, 3 critiche in un database, oltre 400 in un kernel. Tutto sotto la soglia Preparedness: il modello "raggiunge High ma non Critical".
Il rifiuto viveva dentro il modello e si vedeva nella risposta. Il cancello vive fuori: identità, chiave hardware, attestazione, tier. La domanda non è più "il modello me lo dirà?", ma "chi mi ha fatto entrare, e con quali permessi?".
Cosa cambia per chi fa security in produzione
Per chi lavora con questi modelli, la conseguenza è operativa e datata. Il 1 settembre 2026 è una scadenza: gli account individuali Daybreak senza hardware security key non entrano più. La scelta Blue contro Red, prima inesistente, è ora una decisione di rischio: Daybreak Blue è il default per la maggior parte dei workflow difensivi, Daybreak Red serve solo a chi fa ricerca di vulnerabilità autorizzata e validazione di exploit, ed espone a un modello che risponde al 95.0% delle richieste avanzate.
La verifica da fare, prima di affidare un workflow a un modello cyber, è quindi sulle misure che stanno fuori dal modello:
- Sandbox isolati, senza accesso ai sistemi di produzione o alla rete aperta
- Auto-review mode per le azioni fuori dalla sandbox, prima che vengano eseguite
- Profili di permesso con scope definito, per imporre i confini
Le pratiche che OpenAI elenca come "best practices" per gli utenti Daybreak coincidono con le uniche garanzie rimaste. Chi assume che un modello "sicuro" sia un modello che rifiuta, oggi non ha più un indicatore: ha solo un cancello da controllare, una scadenza da rispettare e una variabile di prodotto da non scambiare per una misura di capacità.
Further Reading
https://openai.com/index/expanding-daybreak-as-the-cyber-defense-window-narrows/
https://openai.com/index/daybreak-models-are-now-available-on-aws/
Raluca Ada Popa and Four Flynn
