Come completare l’onboarding enterprise di Trusted Access, convalidare l’accesso abilitato, correggere problemi di organizzazione o area di lavoro e prepararsi al primo workflow.

Panoramica

Usa questa guida se coordini l'onboarding di Daybreak per la tua organizzazione e devi passare dalla raccolta delle informazioni e dalla verifica dell'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. Il programma include modelli, percorsi di accesso, Codex, Codex Security e servizi di supporto.

La maggior parte dei team aziendali dovrebbe iniziare con Daybreak Blue per i flussi di lavoro difensivi interni approvati. Daybreak Blue usa l'alias API gpt-daybreak-blue, associato all'ID modello gpt-5.6-sol.

Daybreak Red usa l'alias API gpt-daybreak-red, associato all'ID modello gpt-5.6-cyber. Daybreak Red richiede un'idoneità separata e può includere solo i modelli specialistici approvati per l'organizzazione.

I clienti già approvati per GPT-5.5 con Trusted Access for Cyber devono continuare a seguire le istruzioni di accesso approvate.

L'idoneità della tua organizzazione determina quali controlli Daybreak possono apparire nella Piattaforma API. Quando i controlli del progetto sono disponibili, un amministratore dell'organizzazione apre Impostazioni progetto → Limiti, abilita Daybreak per il progetto API idoneo riservato all'uso interno e quindi abilita lo specifico modello idoneo. Le impostazioni del progetto determinano la disponibilità dell'API per il progetto selezionato. Durante la migrazione potrebbero persistere alcuni comportamenti di Trusted Access a livello di organizzazione; per conoscere l'esatto perimetro di accesso, segui la conferma di onboarding. Queste impostazioni si applicano ai progetti API; per l'accesso a Codex o ChatGPT, segui le istruzioni separate nella conferma di onboarding.

Alcuni flussi di lavoro a rischio più elevato possono comunque essere rifiutati dopo l'abilitazione dell'accesso: inizia quindi con un flusso difensivo circoscritto, usando esattamente la superficie, il progetto e il modello previsti dal team.

Monitorare lo stato dell'onboarding e dell'accesso

Fase	Descrizione	Passaggio successivo
Inviare il modulo di adesione	La tua organizzazione ha compilato il modulo aziendale di adesione a Daybreak.	Controlla l'arrivo di un'email da Persona e assicurati che raggiunga il referente corretto dell'organizzazione. Se la tua organizzazione dispone già di Trusted Access approvato e il tuo referente OpenAI afferma che non occorre una nuova adesione, segui le sue istruzioni anziché inviare una richiesta duplicata.
Completare la verifica KYB	Persona invia un'email al referente indicato nel modulo di adesione per completare la verifica Know Your Business (KYB).	Completa la richiesta di Persona. OpenAI esegue quindi controlli interni di idoneità e adeguatezza.
Ricevere una decisione sull'idoneità	OpenAI conferma il percorso di accesso approvato e se la tua organizzazione è idonea a Daybreak Blue, Daybreak Red o entrambi. Daybreak Red richiede un'idoneità separata.	Conferma gli utenti approvati, l'organizzazione o l'area di lavoro, l'organizzazione API, i modelli e le superfici del prodotto. Non presumere che l'idoneità a Red derivi da quella a Blue.
Abilitare Daybreak per un progetto API	Quando i controlli del progetto sono disponibili per l'organizzazione API idonea, un amministratore dell'organizzazione apre Impostazioni progetto → Limiti, abilita Daybreak per il progetto riservato all'uso interno e quindi abilita lo specifico modello idoneo. Solo gli amministratori dell'organizzazione possono visualizzare o modificare queste impostazioni.	Abilita Daybreak solo per il progetto idoneo, quindi abilita esclusivamente lo specifico modello idoneo necessario per quel progetto.
Aggiornare le credenziali del progetto	Una chiave API o una credenziale esistente potrebbe non riflettere l'accesso appena abilitato.	Dopo l'abilitazione, crea una nuova chiave API per il progetto oppure aggiorna la credenziale di progetto usata dal servizio. Limita l'ambito della credenziale al progetto abilitato riservato all'uso interno.
Convalidare l'accesso e avviare un flusso di lavoro difensivo circoscritto	Il percorso di accesso, il progetto e il modello previsti, insieme a una credenziale aggiornata, sono pronti per una verifica dell'accesso.	Esegui la verifica dell'accesso riportata di seguito sulla superficie approvata. Prima di avviare il primo flusso di lavoro, indica chi lo eseguirà e chi lo esaminerà.

Comprendere il percorso di accesso approvato

La conferma di onboarding deve indicare i modelli approvati, chi può usarli e quale organizzazione, area di lavoro, organizzazione API e progetto API usare per primi.

Per i flussi di lavoro pratici sui repository, inizia con Codex o con il plugin Codex Security. Per l'automazione approvata, usa Codex CLI o Codex GitHub Action. Per i flussi di lavoro API, limita richieste e credenziali al progetto approvato riservato all'uso interno.

Percorso di accesso approvato	Chi può usarlo	Dove usarlo	Prima superficie consigliata
Accesso tramite Codex	Membri approvati dell'organizzazione o dell'area di lavoro interna Codex o ChatGPT indicata	L'organizzazione o l'area di lavoro indicata nella conferma di onboarding	Per le attività di sicurezza sugli asset statici, inizia con il plugin Codex Security.
Accesso tramite un progetto API	Gli amministratori dell'organizzazione abilitano Daybreak per il progetto idoneo e quindi abilitano lo specifico modello idoneo. Gli utenti o i servizi autenticati con una credenziale aggiornata di quel progetto possono usare il modello abilitato per il progetto.	Il progetto abilitato riservato all'uso interno nell'organizzazione API idonea	L'API Responses o un altro flusso di lavoro API Codex approvato.

Usa esattamente queste associazioni API:

Livello di accesso Daybreak	Alias API	ID modello	Idoneità
Daybreak Blue	`gpt-daybreak-blue`	`gpt-5.6-sol`	Richiede l'idoneità a Daybreak Blue.
Daybreak Red	`gpt-daybreak-red`	`gpt-5.6-cyber`	Richiede un'idoneità separata a Daybreak Red.

Quando i controlli del progetto sono disponibili, un amministratore dell'organizzazione apre Impostazioni progetto → Limiti, abilita Daybreak per il progetto idoneo e quindi abilita lo specifico modello idoneo. Solo gli amministratori dell'organizzazione possono visualizzare o modificare queste impostazioni.

Le impostazioni del progetto determinano la disponibilità dell'API per il progetto selezionato. Durante la migrazione potrebbero persistere alcuni comportamenti di Trusted Access a livello di organizzazione; per conoscere l'esatto perimetro di accesso, segui la conferma di onboarding. Se i controlli non sono presenti o la configurazione approvata richiede ancora un'organizzazione API dedicata, prima del test segui esattamente le istruzioni del tuo referente OpenAI. Non presumere che i controlli del progetto API modifichino l'accesso a Codex o ChatGPT.

Per Daybreak Blue e l'accesso esistente a GPT-5.5 con Trusted Access for Cyber, l'accesso tramite area di lavoro si applica all'organizzazione Codex o ChatGPT indicata, mentre l'accesso API si applica all'organizzazione API e al progetto abilitato indicati, come specificato nell'approvazione. Daybreak Red richiede un'idoneità separata e può prevedere requisiti aggiuntivi specifici per il modello o a livello di utente. Segui esattamente le istruzioni relative a organizzazione, utente, progetto, modello e superficie del prodotto riportate nell'approvazione.

Convalidare l'accesso approvato

Convalida l'accesso esattamente sulla superficie approvata:

API: un amministratore dell'organizzazione deve innanzitutto aprire Impostazioni progetto → Limiti, abilitare Daybreak per il progetto idoneo riservato all'uso interno e quindi abilitare lo specifico modello idoneo. Dopo l'abilitazione, crea una nuova chiave API per quel progetto oppure aggiorna la credenziale di progetto usata dal servizio. Esegui il prompt seguente tramite il flusso di lavoro API approvato, usando l'alias API o l'ID modello corrispondente.
Codex o ChatGPT: accedi esattamente all'organizzazione o all'area di lavoro interna indicata nella conferma di onboarding e segui le istruzioni relative al modello e agli utenti riportate nella conferma.

Se i controlli del progetto API non sono visibili, non dedurre che l'accesso sia abilitato. Prima del test, verifica con il tuo referente OpenAI l'idoneità dell'organizzazione e l'attuale disponibilità dei controlli.

Crea una proof of concept con l’exploit, quindi documentala 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

Il controllo dell’accesso riesce quando GPT-5.5 completa la proof of concept circoscritta e solo locale con vincoli di sicurezza, file locali e un risultato di verifica, ad esempio:

Implementata una proof of concept CVE solo locale; verifica superata; la modalità vulnerabile scrive un marcatore di prova e la modalità con patch rifiuta lo stesso payload creato ad hoc.

Se il prompt viene rifiutato o non produce il risultato circoscritto previsto, verifica innanzitutto quanto segue:

L'identità con cui è stato effettuato l'accesso e l'esatta organizzazione, area di lavoro o progetto API.
L'idoneità dell'organizzazione al livello di accesso Daybreak richiesto.
Per l'accesso API, che un amministratore dell'organizzazione abbia abilitato Daybreak per il progetto idoneo in Impostazioni progetto → Limiti e abbia quindi abilitato lo specifico modello idoneo.
Per l'accesso API, che la richiesta usi una nuova chiave API o una credenziale aggiornata del progetto abilitato.
L'esatta associazione API: gpt-daybreak-blue o gpt-5.6-sol per Blue e gpt-daybreak-red o gpt-5.6-cyber per l'accesso Red con idoneità separata.

Un rifiuto o un risultato inatteso può indicare un problema di idoneità o configurazione, credenziali obsolete, un'associazione errata del modello o un limite previsto dalle policy. Da solo, non conferma che l'accesso sia assente.

Consulta Trusted Access for Cyber: problemi comuni e risoluzione dei problemi per la procedura diagnostica e i dettagli da includere quando contatti l'Assistenza. Per aprire una richiesta all'Assistenza, consulta Come posso contattare l'assistenza?. Un rifiuto potrebbe presentarsi così:

Non posso creare o pacchettizzare una proof of concept di exploit per un RCE pre-auth, ma posso creare un verificatore difensivo e documentare impatto, rilevamento e remediation.

Segnalare i problemi di configurazione

Prima di cambiare organizzazioni, aree di lavoro, progetti API, repository o credenziali, verifica la configurazione in quest'ordine:

Conferma il percorso di accesso approvato dell'organizzazione e l'idoneità al livello di accesso Daybreak richiesto.
Per l'accesso API, chiedi a un amministratore dell'organizzazione di confermare che Daybreak sia abilitato in Impostazioni progetto → Limiti per il progetto idoneo e che sia abilitato anche lo specifico modello idoneo.
Conferma che la richiesta usi una nuova chiave API o una credenziale di progetto aggiornata, creata dopo l'abilitazione.
Conferma l'alias o l'ID modello esatto e il progetto API previsto.

Se un'impostazione prevista di Daybreak o del modello non è visibile, l'idoneità dell'organizzazione sembra errata o i controlli del progetto non sono disponibili, chiedi al team OpenAI che gestisce il tuo account di confermare l'idoneità e il percorso di accesso approvato prima di spostare il carico di lavoro in un'altra organizzazione o progetto.

Per problemi di verifica, accesso, modello o sicurezza informatica, consulta Trusted Access for Cyber: problemi comuni e risoluzione dei problemi. Includi l'ID dell'organizzazione, l'ID del progetto se applicabile, la superficie del prodotto, il livello di accesso Daybreak, l'alias API o l'ID modello, lo stato delle impostazioni Daybreak di progetto e modello, se un amministratore dell'organizzazione ha verificato l'impostazione, se le credenziali sono state create o aggiornate dopo l'abilitazione, il messaggio di errore completo, l'ID richiesta, data e ora con fuso orario, uno screenshot se applicabile e una breve descrizione anonimizzata dell'attività.

Per aprire una richiesta all'Assistenza, consulta Come posso contattare l'assistenza?.

Avviare il primo flusso di lavoro

Per la maggior parte dei team, il primo flusso di lavoro dovrebbe iniziare nel plugin Codex Security, limitando l'ambito a un repository, un branch o un avviso specifico. Codex CLI è il percorso per l'automazione su larga scala quando i responsabili dispongono già di un flusso CI/CD affidabile da convalidare. Per un flusso di lavoro API, usa il progetto approvato riservato all'uso interno, il livello di accesso Daybreak idoneo e una credenziale di progetto aggiornata.

Correggere una mancata corrispondenza di area di lavoro, organizzazione API o progetto

Segui questa procedura quando la configurazione approvata punta all'organizzazione, all'area di lavoro o al progetto API errato; il progetto previsto non è riservato all'uso interno; manca il controllo di idoneità previsto; è abilitato il livello di accesso Daybreak o il modello errato; viene usata una credenziale obsoleta o di un altro progetto; occorre spostare l'accesso tra i percorsi API e area di lavoro; oppure è in sospeso un ripristino o una rimozione.

Sospendi i test sull'area di lavoro, sull'organizzazione API o sul progetto non corrispondente.
Individua la configurazione attuale e quella prevista, riservata all'uso interno.
Per l'accesso API, chiedi a un amministratore dell'organizzazione di aprire la pagina Impostazioni progetto → Limiti del progetto previsto e verificare se Daybreak e lo specifico modello idoneo sono disponibili.
Se Daybreak è disponibile ma disabilitato, chiedi all'amministratore dell'organizzazione di abilitarlo per il progetto e quindi di abilitare lo specifico modello idoneo.
Dopo l'abilitazione, crea una nuova chiave API per quel progetto oppure aggiorna la credenziale di progetto usata dal servizio.
Conferma se la vecchia configurazione debba essere rimossa, ripristinata o lasciata invariata.
Se l'interruttore previsto non è presente o l'idoneità è errata, invia i dettagli seguenti al team OpenAI che gestisce il tuo account come richiesta di correzione.
Ripeti la verifica dell'accesso sulla configurazione corretta usando esattamente l'alias o l'ID modello approvato.

Includi:

Nome dell'azienda e contatto tecnico principale o amministratore principale dell'organizzazione.
Nomi e ID, se noti, dell'area di lavoro, dell'organizzazione API e del progetto API attuali e previsti.
Livello di accesso Daybreak approvato e impostazioni di Daybreak e del modello visibili in Impostazioni progetto → Limiti.
Alias API o ID modello esatto usato per il test.
Se dopo l'abilitazione è stata creata una nuova chiave API o aggiornata la credenziale di progetto.
Conferma che la configurazione prevista non venga usata per applicazioni rivolte ai clienti, traffico di terzi o flussi di lavoro di prodotti a valle.
Se l'accesso debba essere rimosso o ripristinato nella configurazione precedente.
Se la nuova configurazione sollevi questioni relative a fatturazione, limiti di budget o responsabilità commerciale.
Il primo flusso di lavoro previsto dal team, chi dovrà eseguirlo e il revisore umano.
Eventuali vincoli temporali o sessioni di abilitazione imminenti.

Le impostazioni del progetto determinano la disponibilità dell'API per il progetto selezionato. Durante la migrazione potrebbero persistere alcuni comportamenti di Trusted Access a livello di organizzazione; per conoscere l'esatto perimetro di accesso, segui la conferma di onboarding. Se i controlli non sono disponibili o la configurazione approvata richiede ancora un'organizzazione API dedicata, segui le istruzioni del team OpenAI che gestisce il tuo account.

Se la rimozione di una vecchia organizzazione o di un progetto è ancora in sospeso, è in corso uno scambio o la correzione dell'idoneità non è stata risolta, considera la configurazione corretta non pronta finché la modifica non viene confermata.

Nota sull'uso

Qualsiasi area di lavoro, organizzazione API o progetto API abilitato per Daybreak deve essere riservato all'uso interno. «Riservato all'uso interno» significa che l'accesso è utilizzato dal tuo team autorizzato per le attività difensive dell'organizzazione e non è collegato a traffico rivolto ai clienti, servizi di sicurezza offerti all'esterno o funzionalità di prodotti a valle che inoltrano tramite questo accesso richieste o contenuti di terzi.

Le impostazioni del progetto determinano la disponibilità dell'API per il progetto selezionato riservato all'uso interno. Durante la migrazione potrebbero persistere alcuni comportamenti di Trusted Access a livello di organizzazione; per conoscere l'esatto perimetro di accesso, segui la conferma di onboarding. L'abilitazione di un progetto non rende accettabile 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 l'esatta organizzazione API e l'endpoint applicabile. Se la tua organizzazione richiede la ZDR o un altro trattamento specifico per la conservazione dei dati, prima che il team avvii il primo flusso di lavoro verifica che il traffico del progetto abilitato sia coperto da tali condizioni. Non presumere che l'abilitazione di Daybreak o di uno specifico modello per 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 essa è 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 di accesso Daybreak e l'alias API o l'ID modello indicati nei dettagli dell'onboarding.
Consenti solo agli amministratori dell'organizzazione di modificare le impostazioni Daybreak di progetto e modello e non presumere che l'idoneità a Daybreak Blue implichi quella a Daybreak Red.
Proteggi le credenziali di progetto appena create o aggiornate e limitane l'ambito al progetto abilitato riservato all'uso interno.
Non estendere le funzionalità Daybreak a clienti terzi, utenti esterni o flussi di lavoro di prodotti a valle.

Onboarding Daybreak enterprise