Présentation

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

Daybreak Access est le programme d’accès de confiance pour la cybersécurité d’OpenAI. Daybreak Blue et Daybreak Red sont des niveaux d’accès au sein de Daybreak.

La plupart des équipes en entreprise devraient commencer par Daybreak Blue pour leurs workflows défensifs internes approuvés.

Daybreak Red nécessite une approbation distincte pour les workflows de cybersécurité avancés et autorisés. Certains modèles de cybersécurité de pointe nécessitent une approbation supplémentaire propre à chaque modèle.

L’approbation seule n’active pas la réduction des refus. Les paramètres Daybreak sont initialement DÉSACTIVÉS. Un propriétaire de l’espace de travail active l’accès pour les utilisateurs et groupes approuvés ; un propriétaire de l’organisation API l’active pour les projets approuvés autres que les projets par défaut. Configurez les deux si votre équipe utilise les deux modes d’accès. Les utilisateurs qui se connectent à Codex avec ChatGPT doivent aussi activer Daybreak avant d’envoyer une requête.

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

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

Comprendre le mode d’accès approuvé

Votre confirmation d’intégration doit préciser les modèles approuvés, les personnes autorisées à les utiliser, ainsi que l’organisation, l’espace de travail, l’organisation API et le projet API à utiliser en premier.

Pour les flux de travail pratiques sur un dépôt, commencez par Codex ou le plugin Codex Security. Utilisez Codex CLI ou l’action GitHub Codex pour les automatisations approuvées. Pour les flux de travail via l’API, limitez les requêtes et les identifiants au projet approuvé réservé à un usage interne.

Pour accéder à l’API OpenAI, utilisez un identifiant de modèle spécifique inclus dans votre accès approuvé et le paramètre de requête Daybreak correspondant. Les exemples ci-dessous dépendent des modèles approuvés pour votre organisation.

Dans les requêtes à l’API Responses, définissez access_programs.cyber sur daybreak_blue pour gpt-6-sol, même si votre organisation dispose d’une approbation Daybreak Red. Pour utiliser les garde-fous standard, définissez ce paramètre sur standard.

Pour gpt-5.6-cyber, utilisez daybreak_red uniquement si votre organisation dispose à la fois de l’approbation Daybreak Red et de l’approbation supplémentaire requise pour ce modèle.

Une organisation approuvée pour Daybreak Blue peut utiliser le paramètre Blue ; une organisation approuvée pour Red peut utiliser les deux. L’activation d’un paramètre ne donne pas accès à des modèles non approuvés pour votre organisation.

Lorsque les paramètres au niveau du projet sont activés, les projets API approuvés réservés à un usage interne peuvent remplacer une organisation API dédiée distincte. Suivez les instructions de votre confirmation de migration avant de modifier une configuration existante. Pour la connexion à ChatGPT et Codex, configurez séparément les rôles de l’espace de travail ; l’activation d’un projet API ne configure pas l’accès à l’espace de travail.

GPT-6 Sol et GPT-6 Luna permettent de réduire les refus avec Daybreak Blue ou Red. Astra et GPT-6.1 Sol conservent les garde-fous standard avec Blue et permettent de réduire les refus avec Red. La disponibilité des modèles dépend toujours de votre compte et de l’interface produit utilisée. Utilisez l’organisation, les utilisateurs, le projet et les modèles précisés dans votre approbation.

Daybreak est également disponible via AWS Bedrock et nécessite toujours l’approbation d’OpenAI. Contactez l’équipe AWS chargée de votre compte pour obtenir l’accès.

Valider l’accès approuvé

Validez l’accès sur l’interface exacte qui a été approuvée :

• API : un propriétaire de l’organisation API ouvre le projet prévu, autre que celui par défaut, puis accède à Paramètres du projet → Général → Accès aux modèles Daybreak. Activez le niveau Daybreak approuvé et enregistrez. Les projets par défaut ne sont pas éligibles, et le seul rôle de propriétaire du projet ne permet pas d’effectuer des modifications. Prévoyez jusqu’à environ 15 minutes, puis envoyez une requête directe à l’API Responses avec la clé de ce projet et un identifiant de modèle approuvé. L’absence d’un modèle dans /models ne signifie pas à elle seule que l’accès est indisponible.

• ChatGPT et Codex avec connexion via ChatGPT : un propriétaire de l’espace de travail ouvre Console d’administration → Modèles → Paramètres par défaut de l’espace de travail. Sous Cybersécurité, désactivez Daybreak Red s’il est activé, puis désactivez Blue et sélectionnez Enregistrer les modifications. Ouvrez Rôles et choisissez Modifier la dérogation pour le rôle prévu ou Ajouter une dérogation de rôle. Sous Cybersécurité, réglez Daybreak Blue sur Activé ; n’activez Red que s’il est approuvé pour l’espace de travail et les utilisateurs concernés. Sélectionnez Enregistrer et patientez environ 10 minutes. Vérifiez les rôles attribués directement et par groupe, puis connectez-vous à l’espace de travail approuvé et effectuez un test avec un modèle approuvé. Dans Codex, activez le bouton bascule Daybreak avant le test ; lorsqu’il est désactivé, les garde-fous standard s’appliquent.

Si le paramètre attendu est absent, vérifiez l’espace de travail ou l’organisation API approuvé, les autorisations de l’administrateur et si la mise à disposition est terminée. Pour l’accès à l’API, vérifiez que vous consultez un projet autre que celui par défaut ; pour l’accès à l’espace de travail, consultez Console d’administration → Modèles. Si le paramètre n’apparaît toujours pas, contactez l’équipe OpenAI chargée de votre compte pour confirmer l’éligibilité et la mise à disposition avant de tester.

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

Un test autorisé, strictement local, peut aider à vérifier le modèle et le mode d’accès sélectionnés. Un résultat tel que le suivant est possible, mais ne constitue pas une réponse garantie :

Preuve de concept de la CVE implémentée pour un usage strictement local ; vérification réussie ; le mode vulnérable écrit un marqueur de preuve et le mode corrigé rejette la même charge utile spécialement conçue.

Si la requête échoue, est refusée ou produit un résultat inattendu, vérifiez d’abord tous les points suivants :

• L’identité connectée et l’organisation, l’espace de travail ou le projet API exact.

• L’éligibilité de l’organisation au niveau Daybreak demandé et toute approbation supplémentaire pour le modèle. Pour Astra ou GPT-6.1 Sol, l’accès Blue conserve les garde-fous standard.

• Pour la connexion à Codex via ChatGPT, que le propriétaire de l’espace de travail a activé l’accès pour l’utilisateur prévu et que le bouton bascule Daybreak de cet utilisateur est activé. Avec une connexion par clé API, l’accès dépend du projet API activé ; il n’existe pas d’interface Daybreak distincte.

• Pour l’accès à l’API, qu’un propriétaire de l’organisation API a enregistré le niveau Daybreak approuvé pour le projet prévu, autre que celui par défaut.

• Pour l’accès à l’API, que la requête utilise une clé du projet activé et que toute charge de travail migrée a été mise à jour pour utiliser le projet de destination.

• L’identifiant exact du modèle approuvé, en vous référant au tableau de l’API OpenAI ci-dessus, le cas échéant.

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 les politiques. Cela ne confirme pas à lui seul l’absence d’accès.

Consultez Accès de confiance pour la cybersécurité : 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 prendre la forme suivante :

Je ne peux pas créer ni préparer un package de preuve de concept d’exploit pour une exécution de code à distance avant authentification, mais je peux créer un outil de vérification défensif et documenter l’impact, la détection et les mesures correctives.

Faire remonter les problèmes de configuration

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

• Confirmez le mode d’accès approuvé de l’organisation et son éligibilité au niveau Daybreak demandé.

• Confirmez les paramètres Daybreak enregistrés pour les utilisateurs prévus de l’espace de travail ou le projet API autre que celui par défaut, en suivant la section « Valider l’accès approuvé » ci-dessus.

• Confirmez que la requête utilise une clé API appartenant au projet activé.

• Confirmez l’identifiant exact du modèle et le projet API prévu.

Si un bouton bascule attendu n’est pas visible, si l’éligibilité de l’organisation semble incorrecte ou si les paramètres du projet sont indisponibles, demandez à l’équipe OpenAI chargée de votre compte de confirmer l’éligibilité et le mode d’accès approuvé 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 sécurité en matière de cybersécurité, consultez OpenAI Daybreak : problèmes courants et dépannage. Incluez l’identifiant de votre organisation ou espace de travail, l’identifiant du projet le cas échéant, l’interface produit, le niveau Daybreak, l’identifiant du modèle, les paramètres enregistrés, le rôle de l’administrateur, si l’identifiant d’accès appartient au projet activé, le message d’erreur complet, l’identifiant de la requête, l’horodatage et le fuseau horaire, une capture d’écran le cas échéant et une brève description de la tâche expurgée des informations sensibles.

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

Lancer le premier workflow

Pour la plupart des équipes, le premier workflow devrait commencer dans le plugin Codex Security, avec un périmètre limité de dépôts, de branches ou d’alertes. Codex CLI est la solution d’automatisation à grande échelle lorsque les responsables disposent déjà d’un workflow CI/CD fiable à valider. Pour les workflows API, utilisez le projet approuvé réservé à un usage interne, le niveau Daybreak approuvé et la clé API de ce projet.

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

Suivez cette procédure si la configuration approuvée pointe vers la mauvaise organisation, le mauvais espace de travail ou le mauvais projet API ; si le projet prévu n’est pas réservé à un usage interne ; si un paramètre attendu est absent ; si le mauvais niveau Daybreak est activé ; si un identifiant d’un autre projet est utilisé ; si l’accès doit basculer entre l’API et l’espace de travail ; ou si un retour en arrière ou une suppression est en attente.

• Suspendez les tests sur l’espace de travail, l’organisation API ou le projet qui ne correspond pas à la configuration approuvée.

• Identifiez la configuration actuelle et la configuration prévue réservée à un usage interne.

• Pour l’accès à l’API, demandez à un propriétaire de l’organisation API de vérifier les paramètres Daybreak auxquels le projet prévu, autre que celui par défaut, est éligible, en suivant les étapes ci-dessus.

• Si le bouton bascule API approuvé est visible mais désactivé, demandez au propriétaire de l’organisation API de l’activer et d’enregistrer. Pour l’accès à l’espace de travail, demandez à un propriétaire de vérifier les rôles attribués directement et par groupe à l’utilisateur prévu, ainsi que ses autorisations de modèles enregistrées. Avant de refaire un test dans Codex avec une connexion via ChatGPT, vérifiez que le bouton bascule Daybreak de l’utilisateur est activé.

• Pour l’accès à l’API, utilisez une clé du projet de destination activé et prévoyez jusqu’à environ 15 minutes pour l’application des modifications. Attendez environ 10 minutes après les modifications de l’espace de travail avant de refaire un test.

• Confirmez si l’ancienne configuration doit être supprimée, rétablie dans un état antérieur ou laissée inchangée.

• Si le bouton bascule attendu est absent ou si l’éligibilité est incorrecte, envoyez les informations ci-dessous à l’équipe OpenAI chargée de votre compte pour demander une correction.

• Relancez la vérification de l’accès sur la configuration corrigée avec l’identifiant exact du modèle approuvé.

Incluez :

• Le nom de l’entreprise et le contact principal pour les questions techniques ou l’administration de l’organisation.

• Les noms et identifiants de l’espace de travail, de l’organisation API et du projet API actuels et prévus, s’ils sont connus.

• Le niveau Daybreak approuvé et les paramètres visibles sous Paramètres du projet → Général → Accès aux modèles Daybreak, ou les paramètres enregistrés de l’espace de travail et des rôles.

• L’identifiant exact du modèle utilisé pour le test.

• Si la requête utilise une clé du projet activé et si les charges de travail migrées ont été mises à jour pour utiliser le projet de destination.

• 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 rétabli à son état antérieur.

• Si la nouvelle configuration soulève une question de facturation, de limite budgétaire ou de responsabilité commerciale.

• Le premier flux de travail que l’équipe prévoit d’exécuter, les personnes ou services qui l’exécuteront et la personne chargée de sa vérification.

• Les contraintes de calendrier ou une prochaine session de prise en main, le cas échéant.

Lorsque les paramètres de projet approuvés sont disponibles, ils permettent d’isoler l’accès à Daybreak par projet sans nécessiter une sous-organisation API distincte. Si les paramètres sont indisponibles ou si la configuration approuvée nécessite toujours une organisation API dédiée, suivez les instructions de l’équipe OpenAI chargée de votre compte.

Si une ancienne organisation ou un ancien projet est encore en attente de suppression, si un remplacement est en attente ou si la correction d’éligibilité n’est pas résolue, considérez la configuration corrigée comme non opérationnelle jusqu’à confirmation du changement.

Remarque sur l’utilisation

L’accès à Daybreak doit être limité aux utilisateurs internes approuvés et aux travaux de sécurité internes. Un usage exclusivement interne désigne le travail de votre propre équipe autorisée, et non le trafic destiné aux clients, les services de sécurité proposés à l’extérieur ou les fonctionnalités en aval qui font transiter des requêtes tierces par Daybreak. Lorsque les paramètres sont activés, utilisez les rôles de l’espace de travail et les projets API réservés à un usage interne pour faire respecter le périmètre approuvé.

Lorsque des paramètres de projet approuvés sont disponibles, un projet réservé à un usage interne peut isoler l’accès à Daybreak au sein d’une organisation API éligible, sans nécessiter de sous-organisation API distincte. L’activation d’un projet ne rend pas acceptable une utilisation destinée aux clients ou à des tiers.

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

L’éligibilité à Daybreak et l’activation d’un projet n’activent pas automatiquement la politique de non-conservation des données (ZDR). La ZDR doit être demandée et mise en place séparément pour l’organisation API précise et le point de terminaison concerné. Si votre organisation exige la ZDR ou un autre traitement spécifique de conservation des données, vérifiez que le trafic du projet activé est couvert par ces conditions avant que votre équipe ne lance le premier workflow. Ne supposez pas que l’activation du bouton Daybreak Blue ou Daybreak Red d’un projet modifie les paramètres de conservation des données.

Limites d’utilisation

• Utilisez la configuration mise à disposition uniquement pour des travaux défensifs autorisés.

• Utilisez des systèmes appartenant à votre organisation ou qu’elle est explicitement autorisée à évaluer.

• Limitez la portée du premier flux de travail et veillez à ce qu’il puisse être examiné.

• Maintenez une supervision humaine pour les constats et les mesures correctives à fort impact.

• Utilisez exactement l’organisation, l’espace de travail, le projet API, le niveau Daybreak et l’identifiant de modèle indiqués dans vos informations d’intégration.

• Autorisez uniquement les propriétaires de l’organisation API à configurer les paramètres Daybreak du projet. Les propriétaires de l’espace de travail gèrent ses paramètres par défaut et l’attribution des rôles personnalisés. L’approbation Daybreak Blue n’inclut pas Daybreak Red.

• Protégez les identifiants du projet et limitez leur portée au projet activé réservé à un usage interne.

• N’étendez pas les capacités de Daybreak aux clients tiers, aux utilisateurs externes ou aux flux de travail de produits en aval.