Comment terminer l’intégration Trusted Access en entreprise, valider l’accès provisionné, corriger les problèmes d’organisation ou d’espace de travail et préparer le premier workflow.

Présentation

Utilisez ce guide si vous coordonnez l’intégration à Daybreak pour votre organisation et devez passer de la demande et de l’examen d’éligibilité à une configuration opérationnelle.

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 d’assistance.

La plupart des équipes d’entreprise doivent commencer par Daybreak Blue pour les workflows 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 éligibilité distincte et peut ne comprendre que les modèles spécialisés approuvés pour l’organisation.

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

L’éligibilité de votre organisation détermine quels contrôles Daybreak peuvent apparaître dans la Plateforme API. Lorsque les contrôles du projet sont disponibles, un administrateur de l’organisation ouvre Paramètres du projet → Limites, active Daybreak pour le projet d’API interne éligible, puis active le modèle éligible concerné. Les paramètres du projet déterminent la disponibilité de l’API pour le projet sélectionné. Certains comportements Trusted Access existants au niveau de l’organisation peuvent persister pendant la migration ; suivez votre confirmation d’intégration pour connaître le périmètre d’accès exact. 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 workflows à risque élevé peuvent encore être refusés après l’activation de l’accès. Commencez donc par un workflow défensif limité sur l’interface, le projet et le modèle exacts que votre équipe prévoit d’utiliser.

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

Phase	Description	Étape suivante
Envoyer le formulaire de demande	Votre organisation a rempli le formulaire de demande Daybreak pour les entreprises.	Surveillez l’arrivée d’un e-mail de Persona et vérifiez qu’il parvient au bon contact de l’organisation. Si votre organisation dispose déjà d’un accès Trusted Access approuvé et que votre contact OpenAI indique qu’une nouvelle demande n’est pas nécessaire, suivez ses instructions au lieu d’envoyer une demande en double.
Effectuer la vérification KYB	Persona envoie un e-mail au contact indiqué dans le formulaire afin d’effectuer la vérification Know Your Business (KYB).	Répondez à la demande de Persona. OpenAI effectue ensuite des contrôles internes d’éligibilité et d’adéquation.
Recevoir une décision d’éligibilité	OpenAI confirme la voie d’accès approuvée et indique si votre organisation est éligible à Daybreak Blue, à Daybreak Red ou aux deux. Daybreak Red exige une éligibilité distincte.	Confirmez les utilisateurs approuvés, l’organisation ou l’espace de travail, l’organisation d’API, les modèles et les interfaces des produits. Ne déduisez pas l’éligibilité à Red de celle à Blue.
Activer Daybreak pour un projet d’API	Lorsque les contrôles du projet sont disponibles pour l’organisation d’API éligible, un administrateur de l’organisation ouvre Paramètres du projet → Limites, active Daybreak pour le projet interne, puis active le modèle éligible concerné. Seuls les administrateurs de l’organisation peuvent afficher ou modifier ces paramètres.	Activez Daybreak uniquement pour le projet éligible, puis activez uniquement le modèle éligible 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 activé.
Valider l’accès et démarrer un workflow défensif limité	La voie d’accès, le projet et le modèle prévus, ainsi que l’identifiant récent, sont prêts pour une vérification d’accès.	Exécutez la vérification d’accès ci-dessous sur l’interface approuvée. Désignez la personne chargée d’exécuter le workflow et celle chargée de le vérifier avant de lancer le premier workflow.

Comprendre la voie d’accès approuvée

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

Pour les workflows pratiques sur les dépôts, commencez par Codex ou le plugin Codex Security. Utilisez Codex CLI ou l’action GitHub Codex pour l’automatisation approuvée. Pour les workflows d’API, limitez les requêtes et les identifiants au projet interne approuvé.

Voie d’accès approuvée	Qui peut l’utiliser	Où l’utiliser	Première interface recommandée
Accès via Codex	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 les travaux de sécurité sur des ressources statiques, commencez par le plugin Codex Security.
Accès via un projet d’API	Les administrateurs de l’organisation activent Daybreak pour le projet éligible, puis le modèle éligible concerné. Les utilisateurs ou services authentifiés avec un identifiant récent de ce projet peuvent utiliser le modèle qui y est activé.	Le projet interne activé dans l’organisation d’API éligible	L’API Responses ou un autre workflow d’API Codex approuvé.

Utilisez ces correspondances d’API exactes :

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

Lorsque les contrôles du projet sont disponibles, un administrateur de l’organisation ouvre Paramètres du projet → Limites, active Daybreak pour le projet éligible, puis active le modèle éligible concerné. Seuls les administrateurs de l’organisation peuvent afficher ou modifier ces paramètres.

Les paramètres du projet déterminent la disponibilité de l’API pour le projet sélectionné. Certains comportements Trusted Access existants au niveau de l’organisation peuvent persister pendant la migration ; suivez votre confirmation d’intégration pour connaître le périmètre d’accès exact. Si les contrôles ne sont pas présents ou si votre configuration approuvée exige encore une organisation d’API dédiée, suivez les instructions exactes de votre contact OpenAI avant tout test. Ne supposez pas que les contrôles 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 par 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 et au projet activé désignés, conformément à l’approbation. Daybreak Red exige une éligibilité distincte et peut imposer 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 exacte approuvée :

API : un administrateur de l’organisation doit d’abord ouvrir Paramètres du projet → Limites, activer Daybreak pour le projet interne éligible, puis activer le modèle éligible concerné. 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 le prompt ci-dessous via le workflow 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 strictement interne indiqué dans votre confirmation d’intégration, puis suivez les instructions relatives au modèle et aux utilisateurs qui y figurent.

Si les contrôles du projet d’API ne sont pas visibles, n’en déduisez pas que l’accès est activé. Avant tout test, confirmez auprès de votre contact OpenAI l’éligibilité de l’organisation et la disponibilité actuelle des contrôles.

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 mène à bien la preuve de concept circonscrite, strictement locale, 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 le prompt est refusé ou ne produit pas le résultat limité attendu, commencez par confirmer tous les points suivants :

L’identité connectée et l’organisation, l’espace de travail ou le projet d’API exact.
L’éligibilité 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 éligible sous Paramètres du projet → Limites, puis activé le modèle éligible concerné.
Pour l’accès à l’API, que la requête 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 soumis à une éligibilité distincte.

Un refus ou un résultat inattendu peut indiquer une incompatibilité d’éligibilité ou de configuration, des identifiants obsolètes, une correspondance de modèle incorrecte ou une limite imposée par la 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 informations à fournir lorsque vous contactez l’assistance. Pour ouvrir une demande d’assistance, consultez Comment contacter l’assistance ?. Un refus peut se présenter ainsi :

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.

Faire remonter les problèmes de configuration

Avant de modifier des organisations, espaces de travail, projets d’API, dépôts ou identifiants, vérifiez la configuration dans cet ordre :

Confirmez la voie d’accès approuvée de l’organisation et son éligibilité 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 éligible et que le modèle éligible concerné est également activé.
Confirmez que la requête 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 et le projet d’API prévu.

Si un paramètre Daybreak ou de modèle attendu n’est pas visible, si l’éligibilité de l’organisation semble incorrecte ou si les contrôles du projet ne sont pas disponibles, demandez à votre équipe de compte OpenAI de confirmer l’éligibilité 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 le cas échéant, 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 requête, l’horodatage et le fuseau horaire, une capture d’écran le cas échéant, ainsi qu’une brève description expurgée de la tâche.

Pour ouvrir une demande d’assistance, consultez Comment contacter l’assistance ?.

Démarrer le premier workflow

Pour la plupart des équipes, le premier workflow doit démarrer dans le plugin Codex Security avec un périmètre limité à un dépôt, une branche ou une alerte. Codex CLI est la voie d’automatisation à grande échelle lorsque les responsables du workflow disposent déjà d’un workflow CI/CD fiable à valider. Pour un workflow d’API, utilisez le projet interne approuvé, le niveau d’accès Daybreak éligible 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 lorsque la configuration approuvée désigne la mauvaise organisation, le mauvais espace de travail ou projet d’API ; que le projet prévu n’est pas strictement interne ; que le contrôle d’éligibilité attendu est absent ; que le mauvais niveau d’accès Daybreak ou modèle est activé ; qu’un identifiant obsolète ou associé au mauvais projet est utilisé ; que l’accès doit passer de la voie d’API à celle de l’espace de travail, ou inversement ; ou qu’une restauration ou une suppression est en attente.

Suspendez les tests sur l’espace de travail, l’organisation d’API ou le projet non conforme.
Identifiez la configuration actuelle et la configuration interne 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 éligible concerné 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 éligible concerné.
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, restaurée ou laissée inchangée.
Si le bouton attendu est absent ou si l’éligibilité est incorrecte, envoyez les informations ci-dessous à votre équipe de compte OpenAI dans une demande de correction.
Relancez la vérification d’accès sur la configuration corrigée avec l’alias ou l’ID de modèle exact approuvé.

Indiquez :

Le nom de l’entreprise et les coordonnées du principal contact technique ou administrateur de l’organisation.
Les noms et ID actuels et prévus de l’espace de travail, de l’organisation d’API et du projet d’API, s’ils sont connus.
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 tiers ou des workflows de produits en aval.
Si l’accès doit être supprimé ou restauré dans 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, les personnes chargées de son exécution et le vérificateur humain prévu.
Les contraintes de calendrier ou une prochaine session d’activation, le cas échéant.

Les paramètres du projet déterminent la disponibilité de l’API pour le projet sélectionné. Certains comportements Trusted Access existants au niveau de l’organisation peuvent persister pendant la migration ; suivez votre confirmation d’intégration pour connaître le périmètre d’accès exact. Si les contrôles ne sont pas disponibles ou si la configuration approuvée exige encore 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 une permutation est en attente ou si la correction d’éligibilité n’est pas résolue, considérez que la configuration corrigée n’est pas prête tant que la modification n’est pas confirmée.

Remarque sur l’utilisation

Tout espace de travail, toute organisation d’API ou tout projet d’API activé pour Daybreak doit être strictement interne. « Strictement interne » signifie que l’accès est utilisé par votre propre équipe autorisée pour les travaux défensifs de votre organisation et qu’il n’est lié ni au trafic destiné aux clients, ni à des services de sécurité proposés à l’extérieur, ni à une fonctionnalité de produit en aval qui transmet par cet accès les requêtes ou le contenu de tiers.

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

Politique de non-conservation des données (ZDR)

L’éligibilité à Daybreak et l’activation du projet n’activent pas automatiquement la politique de non-conservation des données (ZDR). La ZDR doit faire l’objet d’une demande et d’une mise en service distinctes pour l’organisation d’API exacte et le point de terminaison concerné. Si votre organisation exige la ZDR ou un autre traitement spécifique de conservation des données, confirmez que le trafic du projet activé est couvert par ces conditions avant que votre équipe ne démarre le premier workflow. Ne supposez pas que l’activation de Daybreak ou d’un modèle particulier pour un projet modifie les paramètres de conservation des données.

Limites opérationnelles

Utilisez la configuration fournie uniquement pour des travaux défensifs autorisés.
Utilisez des systèmes appartenant à votre organisation ou que celle-ci est explicitement autorisée à évaluer.
Veillez à ce que le premier workflow soit limité et vérifiable.
Maintenez une intervention humaine pour les constats et 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 exacts indiqués dans vos informations d’intégration.
Autorisez uniquement les administrateurs de l’organisation à modifier les paramètres de projet et de modèle Daybreak, et ne déduisez pas l’éligibilité à Daybreak Red de celle à Daybreak Blue.
Sécurisez les identifiants de projet nouvellement créés ou actualisés et limitez-les au projet interne activé.
N’étendez pas les fonctionnalités Daybreak aux clients tiers, aux utilisateurs externes ni aux workflows de produits en aval.

Onboarding Daybreak pour entreprises