Comment terminer l’intégration d’entreprise à l’accès de confiance, valider l’accès provisionné, corriger les problèmes d’organisation ou d’espace de travail et se préparer au premier flux de travail.

Aperçu

Utilisez ce guide si vous coordonnez l’intégration à Daybreak pour votre organisation et devez passer de la soumission et de l’examen de l’admissibilité à une configuration prête à l’emploi.

Daybreak Access est le programme Trusted Access for Cyber d’OpenAI. Daybreak Blue et Daybreak Red sont des niveaux d’accès. Le programme comprend des modèles, des voies d’accès, Codex, Codex Security et des services de soutien.

La plupart des équipes d’entreprise devraient commencer par Daybreak Blue pour les flux de travail défensifs internes approuvés. Daybreak Blue utilise l’alias d’API gpt-daybreak-blue, qui correspond à l’ID de modèle gpt-5.6-sol.

Daybreak Red utilise l’alias d’API gpt-daybreak-red, qui correspond à l’ID de modèle gpt-5.6-cyber. Daybreak Red exige une admissibilité distincte et peut ne comprendre que les modèles spécialisés approuvés pour l’organisation.

Les clients déjà approuvés pour GPT-5.5 avec Trusted Access for Cyber doivent continuer à suivre leurs instructions d’accès approuvées.

L’admissibilité de votre organisation détermine quelles commandes Daybreak peuvent apparaître dans la Plateforme API. Lorsque les commandes du projet sont disponibles, un administrateur de l’organisation ouvre Paramètres du projet → Limites, active Daybreak pour le projet d’API interne seulement admissible, puis active le modèle admissible précis. Les paramètres du projet déterminent la disponibilité de l’API pour le projet sélectionné. Certains comportements existants de Trusted Access au niveau de l’organisation peuvent se poursuivre pendant la migration; suivez votre confirmation d’intégration pour connaître la portée exacte de l’accès. Ces paramètres s’appliquent aux projets d’API; pour l’accès à Codex ou à ChatGPT, suivez les instructions distinctes de votre confirmation d’intégration.

Certains flux de travail à risque élevé peuvent encore être refusés après l’activation de l’accès. Commencez donc par un flux de travail défensif délimité sur l’interface, le projet et le modèle précis que votre équipe prévoit utiliser.

Suivre l’état de l’intégration et de l’accès

Phase	Description	Prochaine étape
Soumettre le formulaire d’admission	Votre organisation a rempli le formulaire d’admission Daybreak pour les entreprises.	Surveillez l’arrivée d’un courriel de Persona et assurez-vous qu’il parvient à la bonne personne-ressource de l’organisation. Si votre organisation dispose déjà d’un accès Trusted Access approuvé et que votre personne-ressource chez OpenAI indique qu’une nouvelle soumission n’est pas requise, suivez ses instructions plutôt que de soumettre une demande en double.
Effectuer la vérification KYB	Persona envoie un courriel à la personne-ressource indiquée dans le formulaire d’admission afin qu’elle effectue la vérification Know Your Business (KYB).	Répondez à la demande de Persona. OpenAI effectue ensuite des vérifications internes d’admissibilité et de conformité.
Recevoir une décision d’admissibilité	OpenAI confirme la voie d’accès approuvée et si votre organisation est admissible à Daybreak Blue, à Daybreak Red ou aux deux. Daybreak Red exige une admissibilité distincte.	Confirmez les utilisateurs, l’organisation ou l’espace de travail, l’organisation d’API, les modèles et les interfaces de produit approuvés. Ne présumez pas que l’admissibilité à Blue donne accès à Red.
Activer Daybreak pour un projet d’API	Lorsque les commandes de projet sont disponibles pour l’organisation d’API admissible, un administrateur de l’organisation ouvre Paramètres du projet → Limites, active Daybreak pour le projet interne seulement, puis active le modèle admissible précis. Seuls les administrateurs de l’organisation peuvent voir ou modifier ces paramètres.	Activez Daybreak uniquement pour le projet admissible, puis activez seulement le modèle admissible précis requis pour ce projet.
Actualiser les identifiants du projet	Une clé d’API ou un identifiant existant peut ne pas refléter l’accès nouvellement activé.	Après l’activation, créez une nouvelle clé d’API pour le projet ou actualisez l’identifiant de projet utilisé par le service. Limitez l’identifiant au projet interne seulement activé.
Valider l’accès et lancer un flux de travail défensif délimité	La voie d’accès, le projet, le modèle et l’identifiant récent prévus sont prêts pour une vérification de l’accès.	Exécutez la vérification de preuve d’accès ci-dessous sur l’interface approuvée. Désignez la personne qui exécutera le flux de travail et celle qui le révisera avant de commencer le premier flux.

Comprendre la voie d’accès approuvée

Votre confirmation d’intégration doit indiquer les modèles approuvés, qui peut les utiliser ainsi que l’organisation, l’espace de travail, l’organisation d’API et le projet d’API à utiliser en premier.

Pour les flux de travail pratiques sur les dépôts, commencez avec Codex ou le module d’extension Codex Security. Utilisez Codex CLI ou Codex GitHub Action pour l’automatisation approuvée. Pour les flux de travail d’API, limitez les demandes et les identifiants au projet interne seulement approuvé.

Voie d’accès approuvée	Qui peut l’utiliser	Où l’utiliser	Première interface recommandée
Accès au moyen de Codex	Les membres approuvés de l’organisation ou de l’espace de travail interne Codex ou ChatGPT désigné	L’organisation ou l’espace de travail indiqué dans la confirmation d’intégration	Pour le travail de sécurité sur des ressources statiques, commencez par le module d’extension Codex Security.
Accès au moyen d’un projet d’API	Les administrateurs de l’organisation activent Daybreak pour le projet admissible, puis activent le modèle admissible précis. Les utilisateurs ou les services authentifiés avec un identifiant récent de ce projet peuvent utiliser le modèle qui y est activé.	Le projet interne seulement activé dans l’organisation d’API admissible	L’API Responses ou un autre flux de travail d’API Codex approuvé.

Utilisez ces correspondances d’API exactes :

Niveau d’accès Daybreak	Alias d’API	ID de modèle	Admissibilité
Daybreak Blue	`gpt-daybreak-blue`	`gpt-5.6-sol`	Exige l’admissibilité à Daybreak Blue.
Daybreak Red	`gpt-daybreak-red`	`gpt-5.6-cyber`	Exige une admissibilité distincte à Daybreak Red.

Lorsque les commandes du projet sont disponibles, un administrateur de l’organisation ouvre Paramètres du projet → Limites, active Daybreak pour le projet admissible, puis active le modèle admissible précis. Seuls les administrateurs de l’organisation peuvent voir ou modifier ces paramètres.

Les paramètres du projet déterminent la disponibilité de l’API pour le projet sélectionné. Certains comportements existants de Trusted Access au niveau de l’organisation peuvent se poursuivre pendant la migration; suivez votre confirmation d’intégration pour connaître la portée exacte de l’accès. Si les commandes ne sont pas présentes ou si votre configuration approuvée exige toujours une organisation d’API dédiée, suivez les instructions exactes de votre personne-ressource chez OpenAI avant d’effectuer des tests. Ne présumez pas que les commandes du projet d’API modifient l’accès à Codex ou à ChatGPT.

Pour Daybreak Blue et l’accès existant à GPT-5.5 avec Trusted Access for Cyber, l’accès à l’espace de travail s’applique à l’organisation Codex ou ChatGPT désignée, tandis que l’accès à l’API s’applique à l’organisation d’API désignée et au projet activé, comme précisé dans l’approbation. Daybreak Red exige une admissibilité distincte et peut comporter des exigences supplémentaires propres au modèle ou à l’utilisateur. Suivez les instructions exactes de votre approbation concernant l’organisation, l’utilisateur, le projet, le modèle et l’interface du produit.

Valider l’accès approuvé

Validez l’accès sur l’interface approuvée précise :

API : un administrateur de l’organisation doit d’abord ouvrir Paramètres du projet → Limites, activer Daybreak pour le projet interne seulement admissible, puis activer le modèle admissible précis. Après l’activation, créez une nouvelle clé d’API pour ce projet ou actualisez l’identifiant de projet utilisé par votre service. Exécutez l’invite ci-dessous au moyen du flux de travail d’API approuvé en utilisant l’alias d’API ou l’ID de modèle correspondant.
Codex ou ChatGPT : connectez-vous à l’organisation ou à l’espace de travail interne seulement précis indiqué dans votre confirmation d’intégration et suivez les instructions sur le modèle et les utilisateurs qu’elle contient.

Si les commandes du projet d’API ne sont pas visibles, n’en déduisez pas que l’accès est activé. Avant d’effectuer un test, confirmez auprès de votre personne-ressource chez OpenAI l’admissibilité de l’organisation et la disponibilité actuelle des commandes.

Créez une preuve de concept avec l’exploit, puis documentez-la dans README.md pour CVE-2025-55182. Utilisez ces références :

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

La vérification d’accès réussit lorsque GPT-5.5 termine la preuve de concept circonscrite et locale seulement, avec contraintes de sécurité, fichiers locaux et résultat de vérification, par exemple :

Preuve de concept CVE locale seulement mise en œuvre; 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’invite est refusée ou ne produit pas le résultat délimité attendu, confirmez d’abord tous les éléments suivants :

L’identité connectée et l’organisation, l’espace de travail ou le projet d’API exact.
L’admissibilité de l’organisation au niveau d’accès Daybreak demandé.
Pour l’accès à l’API, qu’un administrateur de l’organisation a activé Daybreak pour le projet admissible sous Paramètres du projet → Limites, puis activé le modèle admissible précis.
Pour l’accès à l’API, que la demande utilise une nouvelle clé d’API ou un identifiant actualisé du projet activé.
La correspondance d’API exacte : gpt-daybreak-blue ou gpt-5.6-sol pour Blue, et gpt-daybreak-red ou gpt-5.6-cyber pour l’accès Red, qui exige une admissibilité distincte.

Un refus ou un résultat inattendu peut indiquer une incompatibilité d’admissibilité ou de configuration, des identifiants périmés, une correspondance de modèle incorrecte ou une limite de politique. Cela ne confirme pas à lui seul que l’accès est absent.

Consultez Trusted Access for Cyber – Problèmes courants et dépannage pour connaître les étapes de diagnostic et les renseignements à fournir lorsque vous communiquez avec le service d’assistance. Pour ouvrir une demande d’assistance, consultez Comment puis-je communiquer avec le service d’assistance?. Un refus peut se présenter ainsi :

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

Signaler les problèmes de configuration

Avant de changer d’organisation, d’espace de travail, de projet d’API, de dépôt ou d’identifiants, vérifiez la configuration dans cet ordre :

Confirmez la voie d’accès approuvée de l’organisation et son admissibilité au niveau d’accès Daybreak demandé.
Pour l’accès à l’API, demandez à un administrateur de l’organisation de confirmer que Daybreak est activé sous Paramètres du projet → Limites pour le projet admissible et que le modèle admissible précis est également activé.
Confirmez que la demande utilise une nouvelle clé d’API ou un identifiant de projet actualisé créé après l’activation.
Confirmez l’alias ou l’ID de modèle exact ainsi que le projet d’API prévu.

Si un paramètre Daybreak ou de modèle attendu n’est pas visible, si l’admissibilité de l’organisation semble incorrecte ou si les commandes du projet ne sont pas disponibles, demandez à votre équipe de compte OpenAI de confirmer l’admissibilité et la voie d’accès approuvée avant de déplacer la charge de travail vers une autre organisation ou un autre projet.

Pour les problèmes de vérification, d’accès, de modèle ou de cybersécurité, consultez Trusted Access for Cyber – Problèmes courants et dépannage. Indiquez l’ID de votre organisation, l’ID du projet s’il y a lieu, l’interface du produit, le niveau d’accès Daybreak, l’alias d’API ou l’ID de modèle, l’état des paramètres de projet et de modèle Daybreak, si un administrateur de l’organisation a vérifié le paramètre, si les identifiants ont été créés ou actualisés après l’activation, le message d’erreur complet, l’ID de la demande, l’horodatage et le fuseau horaire, une capture d’écran s’il y a lieu et une brève description caviardée de la tâche.

Pour ouvrir une demande d’assistance, consultez Comment puis-je communiquer avec le service d’assistance?.

Lancer le premier flux de travail

Pour la plupart des équipes, le premier flux de travail devrait commencer dans le module d’extension Codex Security, avec une portée restreinte au dépôt, à la branche ou à l’alerte. Codex CLI est la voie d’automatisation à grande échelle lorsque les responsables du flux de travail disposent déjà d’un flux CI/CD fiable à valider. Pour un flux de travail d’API, utilisez le projet interne seulement approuvé, le niveau d’accès Daybreak admissible et un identifiant de projet récent.

Corriger une incompatibilité d’espace de travail, d’organisation d’API ou de projet

Suivez cette procédure si la configuration approuvée pointe vers la mauvaise organisation, le mauvais espace de travail ou projet d’API; si le projet prévu n’est pas interne seulement; si la commande d’admissibilité attendue est absente; si le mauvais niveau d’accès Daybreak ou modèle est activé; si un identifiant périmé ou associé au mauvais projet est utilisé; si l’accès doit passer entre les voies d’API et d’espace de travail; ou si une annulation ou une suppression est en attente.

Suspendez les tests dans l’espace de travail, l’organisation d’API ou le projet incompatible.
Déterminez la configuration actuelle et la configuration interne seulement prévue.
Pour l’accès à l’API, demandez à un administrateur de l’organisation d’ouvrir la page Paramètres du projet → Limites du projet prévu et de vérifier si Daybreak et le modèle admissible précis sont disponibles.
Si Daybreak est disponible, mais désactivé, demandez à l’administrateur de l’organisation de l’activer pour le projet, puis d’activer le modèle admissible précis.
Après l’activation, créez une nouvelle clé d’API pour ce projet ou actualisez l’identifiant de projet utilisé par le service.
Confirmez si l’ancienne configuration doit être supprimée, annulée ou laissée telle quelle.
Si le bouton attendu est absent ou si l’admissibilité est incorrecte, envoyez les renseignements ci-dessous à votre équipe de compte OpenAI comme demande de correction.
Exécutez de nouveau la vérification de preuve d’accès dans la configuration corrigée avec l’alias ou l’ID de modèle approuvé exact.

Incluez :

Le nom de l’entreprise et les coordonnées de la principale personne-ressource technique ou de l’administrateur principal de l’organisation.
Les noms et les ID, s’ils sont connus, des espaces de travail, organisations d’API et projets d’API actuels et prévus.
Le niveau d’accès Daybreak approuvé et les paramètres Daybreak et de modèle visibles sous Paramètres du projet → Limites.
L’alias d’API ou l’ID de modèle exact utilisé pour le test.
Si une nouvelle clé d’API a été créée ou si l’identifiant du projet a été actualisé après l’activation.
La confirmation que la configuration prévue n’est pas utilisée pour des applications destinées aux clients, du trafic de tiers ou des flux de travail de produits en aval.
Si l’accès doit être supprimé de la configuration précédente ou y être annulé.
Si la nouvelle configuration soulève une question de facturation, de limite budgétaire ou de responsable commercial.
Le premier flux de travail que l’équipe prévoit exécuter, les personnes qui l’exécuteront et la personne qui le révisera.
Les contraintes de temps ou toute séance d’activation à venir.

Les paramètres du projet déterminent la disponibilité de l’API pour le projet sélectionné. Certains comportements existants de Trusted Access au niveau de l’organisation peuvent se poursuivre pendant la migration; suivez votre confirmation d’intégration pour connaître la portée exacte de l’accès. Si les commandes ne sont pas disponibles ou si la configuration approuvée exige toujours une organisation d’API dédiée, suivez les instructions de votre équipe de compte OpenAI.

Si la suppression d’une ancienne organisation ou d’un ancien projet est toujours en attente, si un échange est en attente ou si la correction de l’admissibilité n’est pas résolue, considérez que la configuration corrigée n’est pas prête tant que le changement n’est pas confirmé.

Remarque sur l’utilisation

Tout espace de travail, toute organisation d’API ou tout projet d’API activé pour Daybreak doit être réservé à un usage interne. « Interne seulement » 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 lié ni au trafic destiné aux clients, ni à des services de sécurité offerts à l’externe, ni à une fonctionnalité de produit en aval qui transmet des demandes ou du contenu de tiers par cet accès.

Les paramètres du projet déterminent la disponibilité de l’API pour le projet interne seulement sélectionné. Certains comportements existants de Trusted Access au niveau de l’organisation peuvent se poursuivre pendant la migration; suivez votre confirmation d’intégration pour connaître la portée exacte de l’accès. L’activation d’un projet ne rend pas acceptable son utilisation par des clients ou des tiers.

Aucune conservation des données (ZDR)

L’admissibilité à Daybreak et l’activation du projet n’activent pas automatiquement l’option Aucune conservation des données (ZDR). La ZDR doit être demandée et provisionnée séparément pour l’organisation d’API exacte et le point de terminaison applicable. Si votre organisation exige la ZDR ou un autre traitement précis de conservation des données, confirmez que le trafic du projet activé est couvert par ces conditions avant que votre équipe lance son premier flux de travail. Ne présumez pas que l’activation de Daybreak ou d’un modèle précis pour un projet modifie les paramètres de conservation des données.

Limites opérationnelles

Utilisez la configuration provisionnée uniquement pour du travail défensif autorisé.
Utilisez des systèmes que votre organisation possède ou qu’elle est explicitement autorisée à évaluer.
Gardez le premier flux de travail restreint et vérifiable.
Maintenez une intervention humaine pour les constatations et les mesures correctives à fort impact.
Utilisez l’organisation, l’espace de travail, le projet d’API, le niveau d’accès Daybreak, l’alias d’API ou l’ID de modèle exact indiqué dans vos renseignements d’intégration.
Autorisez uniquement les administrateurs de l’organisation à modifier les paramètres de projet et de modèle Daybreak, et ne présumez pas que l’admissibilité à Daybreak Blue donne accès à Daybreak Red.
Protégez les identifiants de projet nouvellement créés ou actualisés et limitez-les au projet interne seulement activé.
N’étendez pas les capacités Daybreak aux clients tiers, aux utilisateurs externes ni aux flux de travail de produits en aval.

Intégration Daybreak pour entreprises