Comment confirmer l’accès approuvé, corriger les problèmes d’espace de travail ou d’organisation API et préparer le premier workflow.

Présentation

Utilisez ce guide si vous coordonnez l’onboarding Daybreak pour votre organisation et devez passer de l’approbation à une configuration prête à l’emploi.

Daybreak est le programme d’OpenAI axé sur le travail en cybersécurité, notamment les modèles, les parcours d’accès, Codex, Codex Security et les services associés.

La plupart des équipes d’entreprise utilisent GPT-5.5 avec Trusted Access for Cyber pour les workflows défensifs internes approuvés. Selon votre configuration, l’accès peut être provisionné pour un espace de travail, une organisation API, une identité Codex nommée ou plusieurs parcours. Les détails d’onboarding fournis par OpenAI doivent indiquer l’espace de travail exact, l’organisation API, l’identité Codex approuvée et l’accès au modèle à utiliser. Certains workflows à risque plus élevé peuvent toujours être refusés même après approbation ; commencez donc par un workflow défensif délimité sur la surface exacte que votre équipe prévoit d’utiliser.

1. Suivre l’état de l’onboarding

L’approbation est la première étape de l’onboarding. Considérez la configuration comme prête uniquement après le provisionnement du parcours d’accès approuvé sur le bon espace de travail interne ou la bonne organisation API, et après que votre équipe a prouvé que la surface prévue fonctionne.

État	Signification	Étape suivante
Soumis	Votre organisation a envoyé une demande, ou votre équipe de compte OpenAI l’a envoyée en votre nom.	Gardez prêts l’espace de travail ou l’organisation API proposés, le périmètre d’usage interne, l’administrateur technique et le premier workflow au cas où OpenAI aurait besoin de plus de détails.
Approuvé	OpenAI a confirmé que l’organisation est approuvée pour Trusted Access for Cyber.	Confirmez le parcours d’accès approuvé par OpenAI et l’espace de travail, l’organisation API, l’identité Codex approuvée ou la configuration de modèle couverts.
Provisionné	OpenAI a confirmé que l’accès a été appliqué à un espace de travail nommé, une organisation API, une identité Codex approuvée ou une configuration de modèle.	Prouvez que l’accès est actif sur cette surface exacte avant le premier workflow.
Prêt à exécuter	Le parcours d’accès est confirmé, les corrections de configuration sont terminées et votre équipe dispose de preuves observables dans l’interface utilisateur ou l’API.	Choisissez un premier workflow défensif délimité, nommez l’exécutant et le réviseur du workflow, puis utilisez le plugin Codex Security ou l’API Responses via un espace de travail approuvé pour un banc de test existant.

2. Comprendre le parcours d’accès approuvé

Les détails d’onboarding fournis par OpenAI doivent indiquer le parcours d’accès approuvé, qui peut l’utiliser et quelle surface de workflow utiliser en premier. Pour les workflows pratiques, le meilleur point de départ est Codex ou le plugin Codex Security. Utilisez Codex CLI, ou la Codex GitHub Action, pour l’automatisation à grande échelle. Si vos détails d’onboarding nomment une organisation API approuvée, considérez-la comme la configuration de ce parcours d’automatisation approuvé.

Parcours d’accès approuvé	Qui peut l’utiliser	Où s’applique l’accès	Première surface à inspecter
Accès à l’espace de travail pour Codex	Membres de l’espace de travail d’entreprise Codex ou ChatGPT interne nommé.	L’espace de travail provisionné. Un espace de travail ChatGPT peut être le contexte d’administration, d’adhésion ou de connexion pour Codex.	Pour le travail de sécurité sur les actifs statiques, commencez par le plugin Codex Security.
Accès à l’organisation API pour Codex CLI	Utilisateurs ou services utilisant des identifiants dans l’organisation API interne nommée.	L’organisation API ou le projet provisionné.	Codex CLI avec authentification par token.

La plupart des approbations d’entreprise utilisent l’accès à l’espace de travail, l’accès à l’organisation API, ou les deux. Certaines approbations sont plus étroites : une identité Codex nommée n’accorde pas le même accès à chaque personne de l’espace de travail, et l’accès API ne s’applique qu’à l’organisation API nommée. Si les détails d’onboarding n’identifient pas le parcours d’accès, demandez à votre contact OpenAI de le confirmer avant que votre équipe interne ne commence les tests.

3. Confirmer l’accès une fois approuvé

Il est préférable de valider la preuve d’accès sur la surface produit spécifique que votre équipe utilisera, plutôt que de se contenter d’une confirmation générale que votre organisation a été approuvée. Le moyen le plus rapide de valider l’accès consiste à installer et essayer le plugin Codex Security ; si vous prévoyez d’utiliser Codex CLI pour l’automatisation à grande échelle, validez cette configuration d’automatisation exacte et l’organisation API.

Parcours d’accès approuvé	Vérification	L’accès est actif lorsque	Preuves à capturer
Accès à l’espace de travail pour Codex	Installez le plugin Codex Security et suivez les prompts suggérés sur une instance Codex locale.	Le plugin Codex Security peut analyser, examiner et corriger les constats dans votre dépôt cible.	@codexsecurity dans le champ de saisie invoque des compétences spécifiques telles que threat-model.
Accès à l’organisation API pour l’utilisation de l’API Responses	Exécutez un workflow d’automatisation défensive interne délimité. Vous pouvez utiliser cet exemple de commande cURL pour valider l’accès via l’API Responses :`curl --fail-with-body -i -sS https://api.openai.com/v1/responses` `-H "Content-Type: application/json"` `-H "Authorization: Bearer $OPENAI_API_KEY"` `-H "OpenAI-Organization: $ORGANIZATION_ID"` `-H "OpenAI-Project: $PROJECT_ID"` `-d '{` `"model": "gpt-5.5",` `"input": "Hello, Cyber World."` `}'`	La requête s’authentifie dans l’organisation API attendue, utilise la configuration de modèle issue de l’onboarding et renvoie une sortie vérifiable plutôt qu’une erreur d’accès ou de routage.	Organisation ou projet API, propriétaire des identifiants API, nom de modèle envoyé, horodatage, ID de requête si disponible, et HTTP 200 ou sortie de réponse SDK réussie.

Prompt facultatif de validation d’accès

Une fois l’accès provisionné, vous pouvez le valider en essayant ce prompt dans l’espace de travail ou l’organisation API approuvé réservé à un usage interne :

Créez une preuve de concept avec l’exploit, puis documentez-la dans README.md pour cette CVE :

- cve.org/CVERecord?id=CVE-2025-55182
- react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

L’accès est probablement provisionné lorsque GPT-5.5 peut réaliser une preuve de concept locale uniquement avec des contraintes de sécurité, des fichiers locaux et un résultat de vérification tel que :

Mise en œuvre d’une preuve de concept CVE locale uniquement ; vérification réussie ; le mode vulnérable écrit un marqueur de preuve et le mode corrigé rejette la même charge utile conçue.

Si l’accès n’est pas provisionné, le modèle peut refuser la mise en œuvre d’un exploit et rediriger vers du contenu défensif, par exemple :

Je ne peux pas créer ni empaqueter une preuve de concept d’exploit pour une RCE pré-authentification, mais je peux créer un vérificateur défensif et documenter l’impact, la détection et la remédiation.

4. Faire remonter les problèmes de configuration

Si vous rencontrez des problèmes de configuration, partagez un dossier de support concis avec votre représentant OpenAI avant de changer d’espace de travail ou d’organisation API, de reconnecter des dépôts ou de reconfigurer l’accès. Incluez le type de problème, la surface utilisée, l’espace de travail ou l’organisation API, l’e-mail connecté ou le propriétaire des identifiants API, le nom du dépôt ou de l’artefact, l’ID d’analyse ou l’ID d’exécution du banc de test le cas échéant, le nom du modèle, l’horodatage, l’ID de requête si disponible, ainsi que l’erreur, le refus ou l’état d’interface utilisateur manquant exact.

Type de problème	Éléments à capturer	Où les obtenir
Accès à l’espace de travail	Nom ou ID de l’espace de travail, e-mails des membres d’équipe concernés, rôle attendu, et erreur d’accès ou état d’interface utilisateur manquant.	Sélecteur d’espace de travail, menu du compte, vue membre ou administrateur, et page ou fenêtre modale où l’erreur d’accès apparaît.
Incompatibilité entre espace de travail et organisation API	Configuration actuelle, configuration prévue réservée à un usage interne, activation attendue de Codex Security, de l’automatisation Codex CLI ou des deux, et nécessité éventuelle d’un retour arrière ou d’une suppression.	Détails d’onboarding, sélecteur d’espace de travail, paramètres d’organisation de la Platform, confirmation de l’équipe de compte et dossier de correction.
État de l’analyse initiale	Nom du dépôt, heure de début de l’analyse, état actuel de l’analyse, et indication si le dépôt est toujours en remplissage initial.	Page d’analyse Codex Security, liste des analyses, historique d’analyse du dépôt ou bannière d’état.
Accès API	Organisation API, projet le cas échéant, propriétaire des identifiants API, configuration attendue, accès au modèle attendu et erreur d’authentification ou de routage.	Journaux du banc de test, journaux de tâche CI, journaux du client API, exception SDK, réponse d’erreur API, métadonnées de réponse ou en-têtes de réponse.
Facturation ou limites	Organisation nouvelle ou existante, responsable commercial, responsable de la facturation, limites budgétaires et question restante sur la consolidation ou le contrôle des dépenses.	Confirmation de l’équipe de compte, page de facturation ou de limites de la Platform, documents d’approvisionnement ou du responsable commercial.
Incompatibilité d’accès au modèle	L’espace de travail ou l’organisation API utilisé, l’accès au modèle attendu d’après l’onboarding et ce que votre équipe interne voit réellement.	Modèle de session Codex ou libellé d’accès si visible, champ de modèle de la requête API, réponse d’erreur API, réponse de validation d’accès ou texte de refus, journaux du banc de test, ou capture d’écran de l’option manquante ou de l’erreur d’accès.

5. Démarrer le premier workflow

Pour la plupart des équipes, le premier workflow doit commencer dans le plugin Codex Security avec un périmètre étroit de dépôt, de branche ou d’alerte. Codex CLI est le parcours d’automatisation à grande échelle lorsque les responsables du workflow disposent déjà d’un workflow CI/CD de confiance à valider.

Corriger une incompatibilité entre espace de travail et organisation API

Utilisez ce parcours lorsque la configuration approuvée pointe vers la mauvaise organisation, que l’organisation soumise n’est pas réservée à un usage interne, que l’accès doit passer entre les parcours API et espace de travail, ou qu’un retour arrière ou une suppression est en attente.

Suspendez les tests sur l’espace de travail ou l’organisation API incompatibles.
Identifiez la configuration actuelle qui a été soumise ou provisionnée.
Identifiez l’espace de travail, l’organisation API, ou les deux, prévus pour un usage interne uniquement.
Confirmez si l’ancienne configuration doit être supprimée, annulée ou laissée inchangée.
Envoyez à OpenAI un dossier de correction concis.
Attendez qu’OpenAI confirme que la correction est terminée.
Relancez la vérification de preuve d’accès sur la configuration corrigée.

Le dossier de correction doit inclure :

le nom de l’entreprise et le contact principal de l’administrateur technique ou de l’espace de travail
le nom et l’ID de l’espace de travail ou de l’organisation API actuels, s’ils sont connus
le nom et l’ID de l’espace de travail ou de l’organisation API prévus pour un usage interne uniquement, s’ils sont connus
la confirmation que la configuration prévue n’est pas utilisée pour des applications destinées aux clients, du trafic tiers ou des workflows de produits en aval
si l’accès doit être supprimé ou annulé depuis la configuration précédente
si la nouvelle configuration soulève une question de facturation, de limite budgétaire ou de responsable commercial
le premier workflow que l’équipe prévoit d’exécuter et les exécutants attendus du workflow
les contraintes de calendrier ou toute session d’activation à venir, le cas échéant

Si la suppression d’une ancienne organisation ou un échange est encore en attente, considérez la configuration corrigée comme non prête tant qu’OpenAI n’a pas confirmé que le changement est terminé.

Note sur l’utilisation

Tout espace de travail ou toute organisation API activé pour Trusted Access doit être réservé à un usage interne. Réservé à un usage interne signifie que l’accès est utilisé par votre propre équipe autorisée pour le travail défensif de votre organisation, et qu’il n’est pas lié à du trafic destiné aux clients, à des services de sécurité proposés en externe ni à une fonctionnalité de produit en aval qui fait passer des requêtes ou du contenu tiers par cet accès.

Non-conservation des données (ZDR)

La non-conservation des données (ZDR) ne peut être prise en charge que si votre organisation dispose déjà du parcours d’approbation ZDR requis ou mène à bien le processus d’approbation ZDR distinct. Si votre organisation exige la ZDR ou un autre traitement spécifique de conservation des données, confirmez que l’espace de travail ou l’organisation API exact que vous prévoyez d’utiliser est couvert par ces conditions avant que votre équipe ne lance le premier workflow.

Limites opérationnelles

Utilisez la configuration provisionnée uniquement pour des travaux défensifs autorisés.
Utilisez des systèmes que votre organisation possède ou qu’elle est explicitement autorisée à évaluer.
Gardez le premier workflow étroit et vérifiable.
Gardez des humains dans la boucle pour les constats à fort impact et la remédiation.
Utilisez l’espace de travail, la configuration API et l’accès au modèle indiqués dans vos détails d’onboarding.
N’étendez pas les capacités de Trusted Access à des clients tiers, des utilisateurs externes ou des workflows de produits en aval.

Onboarding Daybreak pour entreprises