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 al provisioning, fino a una configurazione pronta all’uso.

Daybreak è il programma di OpenAI dedicato al lavoro di cybersecurity, inclusi modelli, percorsi di accesso, Codex, Codex Security e servizi di supporto.

La maggior parte dei team enterprise usa GPT-5.5 con Trusted Access for Cyber per workflow difensivi interni approvati. Per questo percorso di accesso, OpenAI effettua il provisioning dell’organizzazione o dell’area di lavoro individuata tramite il processo di raccolta delle informazioni dopo il completamento della verifica KYB di Persona e dei controlli interni di idoneità. L’accesso può riguardare un’organizzazione Codex o ChatGPT, un’organizzazione API o entrambe, a seconda della configurazione approvata.

Alcuni workflow a rischio più elevato possono comunque essere rifiutati dopo il provisioning: inizia quindi con un workflow difensivo circoscritto sull’esatta superficie che il tuo team prevede di usare.

Tieni traccia dello stato di onboarding e provisioning

Fase	Descrizione	Cosa fare dopo
Invia il modulo di raccolta informazioni	La tua organizzazione ha completato il modulo di raccolta informazioni enterprise per Trusted Access	Attendi l’email di Persona e completa la verifica KYB. Assicurati che l’email di Persona arrivi al contatto corretto dell’organizzazione.
Ricevi e completa l’email KYB di Persona	Dopo l’invio del modulo di raccolta informazioni, Persona invia un’email al contatto indicato nel modulo per completare la verifica Know Your Business (KYB).	Completa la richiesta KYB di Persona. Una volta completata la KYB, OpenAI esegue controlli interni di idoneità ed effettua il provisioning solo dopo il superamento di tali controlli.
Ricevi la notifica di avvenuto provisioning	OpenAI ha applicato l’accesso all’organizzazione o all’area di lavoro richiesta nel modulo di raccolta informazioni.	Verifica che l’accesso sia correttamente abilitato sulla superficie richiesta. Tieni presente che l’accesso al momento non è elencato in una dashboard dell’area di lavoro visibile al cliente.
Verifica di avere accesso e avvia un workflow difensivo circoscritto	L’organizzazione o l’area di lavoro con provisioning è confermata e il controllo di accesso previsto riesce	Scegli un primo workflow difensivo circoscritto, indica chi lo eseguirà e chi lo revisionerà, e usa il plugin Codex Security o un’organizzazione API Responses approvata.

Comprendi il percorso di accesso abilitato

La conferma di OpenAI dovrebbe indicare quale percorso di accesso è stato sottoposto a provisioning, chi può usarlo e quale organizzazione o area di lavoro usare per prima.

Per workflow pratici sui repository, inizia con Codex o con il plugin Codex Security. Usa Codex CLI o Codex GitHub Action per l’automazione approvata. Se l’accesso viene sottoposto a provisioning per un’organizzazione API, mantieni richieste e credenziali circoscritte a tale organizzazione.

Percorso di accesso abilitato	Chi può usarlo	Dove si applica l’accesso	Prima superficie per convalidare l’accesso
Accesso tramite Codex	Membri dell’organizzazione o area di lavoro interna Codex o ChatGPT indicata	L’organizzazione o l’area di lavoro con provisioning. Per questo percorso, l’accesso è esteso a tutta l’organizzazione	Per il lavoro di sicurezza sugli asset statici, inizia con il plugin Codex Security.
Accesso tramite organizzazione API	Utenti o servizi autenticati nell’organizzazione API interna indicata	L’organizzazione API con provisioning	L’API Responses o un altro workflow API Codex approvato.

Per GPT-5.5 con Trusted Access for Cyber, l’accesso all’area di lavoro viene sottoposto a provisioning per l’organizzazione Codex o ChatGPT indicata, mentre l’accesso API viene sottoposto a provisioning per l’organizzazione API indicata. Se la conferma indica un percorso diverso a livello utente o specifico per modello, segui quelle istruzioni esatte invece di presumere un accesso esteso a tutta l’organizzazione. Se il percorso di accesso sottoposto a provisioning non è chiaro, chiedi al tuo contatto OpenAI di confermarlo prima di eseguire i test.

Convalida l’accesso abilitato

Dopo che OpenAI conferma il provisioning, esegui questo prompt sull’esatta superficie confermata. Puoi farlo in Codex dopo aver effettuato l’accesso all’organizzazione o all’area di lavoro solo interna, oppure tramite l’API Responses usando le credenziali dell’organizzazione API confermata.

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 atteso, conferma prima l’identità con cui hai effettuato l’accesso e l’organizzazione o l’area di lavoro. Il risultato può indicare un provisioning incompleto, una mancata corrispondenza di routing o un limite di policy. Se il provisioning è completo e il problema persiste, segui Trusted Access for Cyber - Problemi comuni e risoluzione dei problemi per i passaggi diagnostici e i dettagli da includere quando contatti il supporto. Per aprire una richiesta di supporto, consulta: Come posso contattare il supporto? Un rifiuto può apparire 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.

Escalation dei problemi di configurazione

Prima di modificare aree di lavoro, organizzazioni API, repository o credenziali, chiedi al tuo team account OpenAI di confermare che il provisioning sia completo e che l’organizzazione, l’area di lavoro e il percorso di accesso previsti siano corretti.

Per problemi di verifica, accesso, modello o sicurezza cyber, segui Trusted Access for Cyber - Problemi comuni e risoluzione dei problemi. Include i passaggi diagnostici e le informazioni da fornire quando contatti il supporto, come ID dell’organizzazione, superficie di prodotto, modello, messaggio di errore completo, ID richiesta, timestamp e fuso orario, screenshot se applicabile e una breve descrizione redatta dell’attività.

Per aprire una richiesta di supporto, consulta: Come posso contattare il supporto?

Avvia il primo workflow

Per la maggior parte dei team, il primo workflow dovrebbe iniziare nel plugin Codex Security con un ambito ristretto a repository, branch o alert. Codex CLI è il percorso per l’automazione su scala quando i responsabili del workflow hanno già un workflow CI/CD affidabile da convalidare.

Correggi una mancata corrispondenza tra area di lavoro o organizzazione API

Usa questo percorso quando la configurazione approvata punta all’organizzazione sbagliata, l’organizzazione inviata non è solo interna, l’accesso deve essere spostato tra percorsi API e area di lavoro, oppure è in sospeso un rollback o una rimozione.

Metti in pausa i test sull’area di lavoro o sull’organizzazione API non corrispondente.
Identifica la configurazione attuale che è stata inviata o sottoposta a provisioning.
Identifica l’area di lavoro solo interna prevista, l’organizzazione API prevista o entrambe.
Conferma se la vecchia configurazione deve essere rimossa, ripristinata con rollback o lasciata invariata.
Invia i dettagli riportati di seguito al tuo team account OpenAI come richiesta di correzione.
Attendi che OpenAI confermi il completamento della correzione.
Esegui di nuovo il controllo di prova dell’accesso sulla configurazione corretta.

Includi:

nome dell’azienda e contatto principale dell’amministratore tecnico o dell’area di lavoro
nome e ID dell’area di lavoro o dell’organizzazione API attuale, se noti
nome e ID dell’area di lavoro o dell’organizzazione API solo interna prevista, se noti
conferma che la configurazione prevista non viene usata per applicazioni rivolte ai clienti, traffico di terze parti o workflow di prodotto a valle
se l’accesso deve essere rimosso o ripristinato con rollback dalla configurazione precedente
se la nuova configurazione crea una questione di fatturazione, limite di budget o titolare commerciale
il primo workflow che il team prevede di eseguire e gli esecutori del workflow previsti
eventuali vincoli temporali o sessioni di abilitazione imminenti

Se una vecchia organizzazione è ancora in attesa di rimozione o è in sospeso uno scambio, considera la configurazione corretta non pronta finché OpenAI non conferma che la modifica è completa.

Nota sull'utilizzo

Qualsiasi area di lavoro o organizzazione API abilitata per Trusted Access dovrebbe essere solo interna. Solo interna significa che l'accesso è usato dal tuo team autorizzato per il lavoro difensivo della tua organizzazione e non è collegato a traffico rivolto ai clienti, servizi di sicurezza offerti esternamente o qualsiasi funzionalità di prodotto a valle che inoltri richieste o contenuti di terze parti tramite questo accesso.

Assenza di conservazione dei dati (ZDR)

Il provisioning di Trusted Access non abilita automaticamente l’Assenza di conservazione dei dati (ZDR). La ZDR deve essere richiesta ed effettuata separatamente per l’organizzazione esatta. Se la tua organizzazione richiede la ZDR o un altro trattamento specifico per la conservazione dei dati, conferma che l’organizzazione che intendi usare sia coperta da tali termini prima che il team avvii il primo workflow.

Limiti operativi

Usa la configurazione assegnata solo per attività difensive autorizzate.
Usa sistemi di proprietà della tua organizzazione o per cui è esplicitamente autorizzata a effettuare valutazioni.
Mantieni il primo flusso di lavoro ristretto e verificabile.
Mantieni persone nel ciclo per risultati e remediation ad alto impatto.
Usa l'area di lavoro, la configurazione API e l'accesso al modello indicati nei dettagli di onboarding.
Non estendere le funzionalità di Trusted Access a clienti di terze parti, utenti esterni o flussi di lavoro di prodotti a valle.

Onboarding Daybreak enterprise