Panoramica
Usa questa guida se coordini l’onboarding di Daybreak per la tua organizzazione e devi passare dalla richiesta iniziale e dalla verifica di idoneità a una configurazione pronta all’uso.
Daybreak Access è il programma Trusted Access for Cyber di OpenAI. Daybreak Blue e Daybreak Red sono livelli di accesso all’interno di Daybreak.
La maggior parte dei team aziendali dovrebbe iniziare con Daybreak Blue per i flussi di lavoro difensivi interni approvati.
Daybreak Red richiede un’approvazione separata per i flussi di lavoro avanzati e autorizzati di cybersicurezza. Alcuni modelli di frontiera per la cybersicurezza richiedono un’ulteriore approvazione specifica per il modello.
La sola approvazione non attiva la riduzione dei rifiuti. I controlli Daybreak sono inizialmente DISATTIVATI. Un proprietario dell’area di lavoro abilita l’accesso per gli utenti e i gruppi approvati; un proprietario dell’organizzazione API lo abilita per i progetti non predefiniti approvati. Configura entrambe le modalità di accesso se il tuo team le usa entrambe. Gli utenti che accedono a Codex con ChatGPT devono anche attivare Daybreak prima di inviare una richiesta.
Alcuni flussi di lavoro a rischio più elevato potrebbero essere rifiutati anche dopo l’abilitazione dell’accesso. Inizia quindi con un flusso di lavoro difensivo circoscritto, usando esattamente l’interfaccia, il progetto e il modello che il tuo team intende utilizzare.
Monitora lo stato dell’onboarding e dell’accesso
| Fase | Descrizione | Passaggi successivi |
|---|---|---|
| Invia il modulo di richiesta iniziale | La tua organizzazione ha compilato il modulo di richiesta iniziale di Daybreak per le aziende. | Controlla l’arrivo di un’email da Persona e assicurati che raggiunga il referente corretto dell’organizzazione. Se la tua organizzazione ha già un accesso approvato a Daybreak e il tuo referente OpenAI indica che non serve una nuova richiesta iniziale, segui le sue istruzioni invece di inviare una richiesta duplicata. |
| Completa la verifica KYB | Persona invia un’email al referente indicato nel modulo di richiesta iniziale per completare la verifica dell’azienda Know Your Business (KYB). | Completa la procedura richiesta da Persona. OpenAI esegue quindi verifiche interne di idoneità e adeguatezza. |
| Ricevi l’esito della verifica di idoneità | OpenAI conferma la modalità di accesso approvata e se la tua organizzazione è idonea a Daybreak Blue, Daybreak Red o entrambi. Daybreak Red richiede una verifica di idoneità separata. | Verifica gli utenti, l’area di lavoro o l’organizzazione API, i modelli e le interfacce dei prodotti approvati. Non dare per scontato che l’idoneità a Blue implichi l’idoneità a Red. OpenAI invia un’email di benvenuto all’amministratore dell’organizzazione o dell’area di lavoro quando la predisposizione dell’accesso è completata. |
| Configura l’accesso all’area di lavoro o all’API | Per l’accesso a ChatGPT e Codex, un proprietario dell’area di lavoro configura i ruoli per gli utenti e i gruppi approvati. Per l’accesso API, un proprietario dell’organizzazione API abilita Daybreak su ciascun progetto non predefinito approvato. Segui i passaggi della sezione “Verifica l’accesso approvato” riportata di seguito. | Abilita solo il livello di accesso approvato per gli utenti o il progetto previsti, salva e verifica le impostazioni salvate. Non è possibile abilitare Daybreak nei progetti predefiniti. L’accesso all’area di lavoro e l’accesso al progetto API sono separati. |
| Usa le credenziali del progetto di destinazione | Una chiave API appartiene a un’organizzazione e a un progetto specifici. Una chiave di un’organizzazione o di un progetto precedente non concede l’accesso alla destinazione. | Usa una chiave API del progetto abilitato. Se hai effettuato la migrazione a un’altra organizzazione o a un altro progetto, crea o seleziona una chiave al suo interno e aggiorna le applicazioni o i flussi di lavoro che la usano. Limita l’ambito delle credenziali all’uso interno approvato. |
| Verifica l’accesso e avvia un flusso di lavoro difensivo circoscritto | L’area di lavoro o il progetto previsti, gli utenti approvati, il modello e la credenziale API sono pronti per una verifica dell’accesso. | Esegui il test di accesso riportato di seguito sull’interfaccia approvata. Designa chi eseguirà il flusso di lavoro e chi lo verificherà prima di avviare il primo flusso. |
Comprendere la modalità di accesso approvata
La conferma di onboarding dovrebbe indicare i modelli approvati, chi può usarli e quali organizzazione, area di lavoro, organizzazione API e progetto API usare per iniziare.
Per i flussi di lavoro operativi sui repository, inizia con Codex o con il plugin Codex Security. Usa Codex CLI o l'azione GitHub di Codex per le automazioni approvate. Per i flussi di lavoro API, limita richieste e credenziali al progetto approvato a uso esclusivamente interno.
| Modalità di accesso approvata | Chi può usarla | Dove usarla | Interfaccia consigliata per iniziare |
|---|---|---|---|
| Accesso tramite Codex | Membri autorizzati dell'organizzazione o dell'area di lavoro interna di Codex o ChatGPT indicata | L'organizzazione o l'area di lavoro indicata nella conferma di onboarding | Per le attività di sicurezza sulle risorse statiche, inizia con il plugin Codex Security. |
| Accesso tramite un progetto API | I proprietari dell'organizzazione API configurano i controlli Daybreak per cui è prevista l'idoneità. Gli utenti o i servizi autorizzati usano una chiave del progetto abilitato, entro l'ambito approvato per quel progetto. | Il progetto abilitato a uso esclusivamente interno nell'organizzazione API idonea | La Responses API o un altro flusso di lavoro API di Codex approvato. |
Per accedere alle API OpenAI, usa un ID modello specifico incluso nell'accesso approvato e l'impostazione Daybreak corrispondente nella richiesta. Gli esempi seguenti dipendono dai modelli approvati per la tua organizzazione.
| Livello Daybreak | ID modello di esempio | Idoneità |
|---|---|---|
| Daybreak Blue | gpt-6-sol | Richiede l'idoneità a Daybreak Blue. |
| Daybreak Red | gpt-5.6-cyber | Richiede un'approvazione separata per Daybreak Red. L'esempio con gpt-5.6-cyber richiede anche un'ulteriore approvazione per il modello. |
Nelle richieste alla Responses API, imposta access_programs.cyber su daybreak_blue per gpt-6-sol, anche se la tua organizzazione ha l'approvazione per Daybreak Red. Per usare le misure di sicurezza standard, impostalo su standard.
Per gpt-5.6-cyber, usa daybreak_red solo se la tua organizzazione ha sia l'approvazione per Daybreak Red sia l'ulteriore approvazione richiesta per il modello.
Un'organizzazione approvata per Daybreak Blue può usare il controllo Blue; un'organizzazione approvata per Red può usarli entrambi. Abilitare un controllo non concede l'accesso a modelli non approvati per la tua organizzazione.
Se i controlli a livello di progetto sono abilitati, i progetti API approvati a uso esclusivamente interno possono sostituire un'organizzazione API dedicata e separata. Prima di modificare una configurazione esistente, segui le indicazioni nella conferma di migrazione. Per l'accesso a ChatGPT e Codex, configura separatamente i ruoli dell'area di lavoro; abilitare un progetto API non configura l'accesso all'area di lavoro.
GPT-6 Sol e GPT-6 Luna supportano una riduzione dei rifiuti con Daybreak Blue o Red. Astra e GPT-6.1 Sol mantengono le misure di sicurezza standard con Blue e supportano una riduzione dei rifiuti con Red. La disponibilità dei modelli dipende comunque dal tuo account e dall'interfaccia del prodotto. Usa l'organizzazione, gli utenti, il progetto e i modelli specificati nell'approvazione.
Daybreak è disponibile anche tramite AWS Bedrock e richiede comunque l'approvazione di OpenAI. Per ottenere l'accesso, contatta il team AWS che segue il tuo account.
Verificare l'accesso approvato
Verifica l'accesso esattamente nell'interfaccia approvata:
API: un proprietario dell'organizzazione API apre il progetto previsto, diverso da quello predefinito, e va su Impostazioni del progetto → Generali → Accesso ai modelli Daybreak. Abilita il livello Daybreak approvato e salva. I progetti predefiniti non sono idonei e il solo ruolo di proprietario del progetto non consente di apportare modifiche. Attendi fino a circa 15 minuti, poi invia una richiesta diretta alla Responses API usando la chiave di quel progetto e un ID modello approvato. L'assenza di un modello da /models non significa di per sé che l'accesso non sia disponibile.
ChatGPT e Codex con accesso tramite ChatGPT: un proprietario dell'area di lavoro apre Console di amministrazione → Modelli → Impostazioni predefinite dell'area di lavoro. In Sicurezza informatica, disattiva Daybreak Red se è abilitato, poi disattiva Blue e seleziona Salva modifiche. Apri Ruoli e scegli Modifica deroga per il ruolo previsto oppure Aggiungi deroga per un ruolo. In Sicurezza informatica, imposta Daybreak Blue su Attivo; abilita Red solo se è approvato per l'area di lavoro e per quegli utenti. Seleziona Salva e attendi circa 10 minuti. Controlla le assegnazioni dei ruoli dirette e tramite gruppi, poi accedi all'area di lavoro approvata ed esegui un test con un modello approvato. In Codex, imposta l'interruttore Daybreak su ATTIVO prima di eseguire il test; se è su DISATTIVO, si applicano le misure di sicurezza standard.
Se il controllo previsto non è presente, verifica l'area di lavoro o l'organizzazione API approvata, le autorizzazioni dell'amministratore e il completamento del provisioning. Per l'accesso API, verifica di visualizzare un progetto diverso da quello predefinito; per l'accesso all'area di lavoro, controlla Console di amministrazione → Modelli. Se il controllo continua a non comparire, contatta il team OpenAI che segue il tuo account per verificare l'idoneità e il provisioning prima di eseguire il test.
Crea un proof of concept con l'exploit, poi documentalo in README.md per CVE-2025-55182. Usa questi riferimenti:
cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
Un test autorizzato, eseguito solo in locale, può aiutare a verificare il modello selezionato e la modalità di accesso. Un risultato come il seguente è uno dei possibili esiti, non una risposta garantita:
Implemented a local-only CVE proof of concept; verification passed; vulnerable mode writes a proof marker and patched mode rejects the same crafted payload.
Se la richiesta non va a buon fine, viene rifiutata o produce un risultato imprevisto, verifica innanzitutto tutti i punti seguenti:
L'identità con cui è stato effettuato l'accesso e l'esatta organizzazione, area di lavoro o progetto API.
L'idoneità dell'organizzazione al livello Daybreak richiesto ed eventuali ulteriori approvazioni per il modello. Per Astra o GPT-6.1 Sol, l'accesso Blue mantiene le misure di sicurezza standard.
Per l'accesso a Codex tramite ChatGPT, che il proprietario dell'area di lavoro abbia abilitato l'accesso per l'utente previsto e che l'interruttore Daybreak dell'utente sia su ATTIVO. Con l'accesso tramite chiave API, l'accesso dipende dal progetto API abilitato; non esiste un'interfaccia Daybreak separata.
Per l'accesso API, che un proprietario dell'organizzazione API abbia salvato il livello Daybreak approvato per il progetto previsto, diverso da quello predefinito.
Per l'accesso API, che la richiesta usi una chiave del progetto abilitato e che gli eventuali carichi di lavoro migrati siano stati aggiornati per usare il progetto di destinazione.
L'esatto ID modello approvato, consultando la tabella delle API OpenAI riportata sopra, ove pertinente.
Un rifiuto o un risultato imprevisto può indicare una discrepanza nell'idoneità o nella configurazione, credenziali non aggiornate, una mappatura errata del modello o un limite imposto dalle policy. Di per sé, non conferma l'assenza di accesso.
Consulta Trusted Access for Cyber - Problemi comuni e risoluzione dei problemi per i passaggi diagnostici e i dettagli da includere quando contatti l'assistenza. Per aprire una richiesta di assistenza, consulta Come posso contattare l'assistenza?. Un rifiuto potrebbe presentarsi così:
I can't build or package an exploit proof of concept for a pre-auth RCE, but I can build a defensive verifier and document impact, detection, and remediation.
Segnalare i problemi di configurazione
Prima di cambiare organizzazioni, aree di lavoro, progetti API, repository o credenziali, verifica la configurazione in questo ordine:
Verifica la modalità di accesso approvata per l'organizzazione e la sua idoneità al livello Daybreak richiesto.
Verifica le impostazioni Daybreak salvate per gli utenti previsti dell'area di lavoro o per il progetto API non predefinito, seguendo la sezione “Verificare l'accesso approvato” riportata sopra.
Verifica che la richiesta usi una chiave API appartenente al progetto abilitato.
Verifica l'esatto ID modello e il progetto API previsto.
Se un interruttore previsto non è visibile, l'idoneità dell'organizzazione sembra errata o i controlli di progetto non sono disponibili, chiedi al team OpenAI che segue il tuo account di confermare l'idoneità e la modalità di accesso approvata prima di spostare il carico di lavoro in un'altra organizzazione o in un altro progetto.
Per problemi di verifica, accesso, modelli o sicurezza informatica, consulta OpenAI Daybreak: problemi comuni e risoluzione dei problemi. Includi l'ID dell'organizzazione o dell'area di lavoro, l'ID del progetto ove pertinente, l'interfaccia del prodotto, il livello Daybreak, l'ID modello, le impostazioni salvate dei controlli, il ruolo dell'amministratore, l'indicazione se la credenziale appartiene al progetto abilitato, il messaggio di errore completo, l'ID della richiesta, data e ora con fuso orario, uno screenshot ove pertinente e una breve descrizione dell'attività priva di informazioni sensibili.
Per aprire una richiesta di assistenza, consulta Come posso contattare l'assistenza?.
Avvia il primo flusso di lavoro
Per la maggior parte dei team, il primo flusso di lavoro dovrebbe iniziare nel plugin Codex Security, con un ambito circoscritto in termini di repository, branch o avvisi. Codex CLI è la soluzione per l’automazione su larga scala quando i responsabili del flusso di lavoro hanno già un flusso CI/CD affidabile da convalidare. Per i flussi di lavoro API, usa il progetto approvato per uso esclusivamente interno, il livello Daybreak approvato e la chiave API di quel progetto.
Correggere una discrepanza nell'area di lavoro, nell'organizzazione API o nel progetto
Segui questa procedura quando la configurazione approvata fa riferimento all'organizzazione, all'area di lavoro o al progetto API sbagliati; il progetto previsto non è a uso esclusivamente interno; manca un controllo previsto; è abilitato il livello Daybreak sbagliato; è in uso una credenziale di un progetto errato; l'accesso deve passare dall'API all'area di lavoro o viceversa; oppure è in attesa un ripristino o una rimozione.
Sospendi i test nell'area di lavoro, nell'organizzazione API o nel progetto che presenta la discrepanza.
Identifica la configurazione attuale e quella prevista a uso esclusivamente interno.
Per l'accesso API, chiedi a un proprietario dell'organizzazione API di verificare, seguendo i passaggi precedenti, i controlli Daybreak consentiti per il progetto previsto, diverso da quello predefinito.
Se l'interruttore API approvato è visibile ma disattivato, chiedi al proprietario dell'organizzazione API di attivarlo e salvare. Per l'accesso all'area di lavoro, chiedi a un proprietario dell'area di lavoro di controllare i ruoli dell'utente previsto, assegnati direttamente e tramite gruppi, e le autorizzazioni salvate per i modelli. Prima di ripetere il test in Codex con accesso tramite ChatGPT, verifica che l'interruttore Daybreak dell'utente sia su ATTIVO.
Per l'accesso API, usa una chiave del progetto di destinazione abilitato e attendi fino a circa 15 minuti affinché le modifiche vengano applicate. Dopo le modifiche all'area di lavoro, attendi circa 10 minuti prima di ripetere il test.
Conferma se la vecchia configurazione deve essere rimossa, ripristinata o lasciata invariata.
Se l'interruttore previsto manca o l'idoneità non è corretta, invia i dettagli riportati di seguito al team OpenAI che segue il tuo account, richiedendo una correzione.
Ripeti la verifica dell'accesso sulla configurazione corretta usando l'esatto ID modello approvato.
Includi:
Nome dell'azienda e contatto principale del referente tecnico o dell'amministratore dell'organizzazione.
Nomi e ID, se noti, dell'area di lavoro, dell'organizzazione API e del progetto API attuali e di destinazione.
Il livello Daybreak approvato e i controlli visibili in Impostazioni del progetto → Generali → Accesso ai modelli Daybreak, oppure le impostazioni salvate dell'area di lavoro e dei ruoli.
L'esatto ID modello usato per il test.
Se la richiesta usa una chiave del progetto abilitato e se i carichi di lavoro migrati sono stati aggiornati per usare il progetto di destinazione.
La conferma che la configurazione prevista non viene usata per applicazioni rivolte ai clienti, traffico di terze parti o flussi di lavoro di prodotti a valle.
Se l'accesso nella configurazione precedente deve essere rimosso o riportato allo stato precedente.
Se la nuova configurazione solleva questioni di fatturazione, limiti di budget o responsabilità commerciale.
Il primo flusso di lavoro che il team intende eseguire, chi o cosa lo eseguirà e la persona incaricata della revisione.
Eventuali vincoli temporali o sessioni di formazione all'uso in programma.
Ove disponibili, i controlli di progetto approvati servono a isolare l'accesso a Daybreak per progetto, senza richiedere una sotto-organizzazione API separata. Se i controlli non sono disponibili o la configurazione approvata richiede ancora un'organizzazione API dedicata, segui le istruzioni del team OpenAI che segue il tuo account.
Se una vecchia organizzazione o un vecchio progetto è ancora in attesa di rimozione, è in attesa una sostituzione o la correzione dell'idoneità non è stata risolta, considera la configurazione corretta non ancora pronta finché la modifica non viene confermata.
Nota sull’utilizzo
L’accesso a Daybreak deve essere limitato agli utenti interni approvati e alle attività di sicurezza interne. Per uso esclusivamente interno si intende il lavoro del proprio team autorizzato, non il traffico rivolto ai clienti, i servizi di sicurezza offerti all’esterno o le funzionalità a valle che inoltrano richieste di terze parti tramite Daybreak. Quando i controlli sono abilitati, usa i ruoli dell’area di lavoro e i progetti API per uso esclusivamente interno per far rispettare l’ambito approvato.
Quando sono disponibili i controlli di progetto approvati, un progetto per uso esclusivamente interno può isolare l’accesso a Daybreak all’interno di un’organizzazione API idonea, senza richiedere una sotto-organizzazione API separata. L’abilitazione di un progetto non rende consentito l’uso rivolto ai clienti o da parte di terzi.
Assenza di conservazione dei dati (ZDR)
L’idoneità a Daybreak e l’abilitazione del progetto non attivano automaticamente l’assenza di conservazione dei dati (ZDR). La ZDR deve essere richiesta e predisposta separatamente per la specifica organizzazione API e per l’endpoint applicabile. Se la tua organizzazione richiede la ZDR o un altro trattamento specifico per la conservazione dei dati, verifica che tali condizioni si applichino al traffico del progetto abilitato prima che il team avvii il primo flusso di lavoro. Non dare per scontato che attivare l’interruttore Daybreak Blue o Daybreak Red di un progetto modifichi le impostazioni di conservazione dei dati.
Limiti operativi
Usa la configurazione predisposta solo per attività difensive autorizzate.
Usa sistemi di proprietà della tua organizzazione o che l'organizzazione è esplicitamente autorizzata a valutare.
Mantieni il primo flusso di lavoro circoscritto e verificabile.
Mantieni la supervisione umana per i risultati e gli interventi correttivi ad alto impatto.
Usa esattamente l'organizzazione, l'area di lavoro, il progetto API, il livello Daybreak e l'ID modello indicati nei dettagli di onboarding.
Consenti solo ai proprietari dell'organizzazione API di configurare i controlli Daybreak del progetto. I proprietari dell'area di lavoro ne gestiscono le impostazioni predefinite e le assegnazioni dei ruoli personalizzati. L'approvazione per Daybreak Blue non include Daybreak Red.
Proteggi le credenziali del progetto e limitane l'ambito al progetto abilitato a uso esclusivamente interno.
Non estendere le funzionalità di Daybreak a clienti terzi, utenti esterni o flussi di lavoro di prodotti a valle.