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 workflows pratiques sur des dépôts, commencez par Codex ou le plugin Codex Security. Utilisez Codex CLI ou l’action GitHub Codex pour les automatisations approuvées. Pour les workflows API, limitez les requêtes et les identifiants au projet approuvé réservé à un usage interne.

Pour accéder à l’API OpenAI, utilisez un alias Daybreak ou un identifiant de modèle approuvé. Les alias peuvent pointer vers des modèles éligibles plus récents au fil du temps ; les exemples ci-dessous ne sont pas des cibles fixes pour ces alias. Ces alias de l’API OpenAI ne sont pas disponibles sur Amazon Bedrock.

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 aux modèles non couverts par l’approbation de votre organisation.

Lorsque les paramètres au niveau du projet sont activés, des 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 protections 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 du produit. Utilisez l’organisation, les utilisateurs, le projet et les modèles indiqués dans votre approbation.

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

Valider l’accès approuvé

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

• API : un propriétaire de l’organisation API ouvre le projet visé, autre qu’un projet 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 statut de propriétaire de projet ne permet pas d’apporter des modifications. Patientez jusqu’à environ 15 minutes, puis envoyez une requête directe à l’API Responses avec la clé de ce projet et un alias ou 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 visé 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 ces utilisateurs. Sélectionnez Enregistrer et patientez environ 10 minutes. Vérifiez les rôles attribués directement et via des groupes, puis connectez-vous à l’espace de travail approuvé et effectuez un test avec un modèle approuvé. Dans Codex, ACTIVEZ le bouton Daybreak avant le test ; lorsqu’il est DÉSACTIVÉ, les protections 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 en place est terminée. Pour l’accès à l’API, vérifiez que vous consultez un projet autre qu’un projet 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 chargée de votre compte OpenAI pour confirmer l’éligibilité et la mise en place avant de procéder aux tests.

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é, exclusivement local, peut aider à vérifier le modèle et le mode d’accès sélectionnés. Le résultat suivant est un exemple possible, et non une réponse garantie :

Preuve de concept de la CVE implémentée en local uniquement ; 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 protections standard.

• Pour la connexion à Codex via ChatGPT, que le propriétaire de l’espace de travail a activé l’accès pour l’utilisateur visé et que le bouton 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 visé, autre qu’un projet 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’alias API ou l’identifiant de modèle approuvé exact, 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 incohérence d’éligibilité ou de configuration, des identifiants obsolètes, une correspondance de modèle incorrecte ou une limite imposée par les règles d’utilisation. 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 se présenter ainsi :

Je ne peux pas créer ni empaqueter une 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 la correction.

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 visés de l’espace de travail ou le projet API autre qu’un projet 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’alias ou l’identifiant de modèle exact et le projet API visé.

Si un bouton 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 chargée de votre compte OpenAI 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 du produit, le niveau Daybreak, l’alias API ou l’identifiant de modèle, les paramètres enregistrés, le rôle de l’administrateur, l’appartenance ou non de l’identifiant au projet activé, le message d’erreur complet, l’identifiant de requête, l’horodatage et le fuseau horaire, une capture d’écran le cas échéant, ainsi qu’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 incohérence 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 visé 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 être transféré entre les modes API et 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 présentant l’incohérence.

• Identifiez la configuration actuelle et la configuration visée 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 éligibles pour le projet visé, autre qu’un projet par défaut, en suivant les étapes ci-dessus.

• Si le bouton 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 directs et de groupe de l’utilisateur visé, ainsi que ses autorisations de modèles enregistrées. Avant de refaire un test dans Codex avec la connexion via ChatGPT, vérifiez que le bouton 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. Prévoyez environ 10 minutes pour l’application des modifications de l’espace de travail avant de refaire un test.

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

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

• Relancez le test de validation de l’accès sur la configuration corrigée avec l’alias ou l’identifiant de modèle approuvé exact.

Incluez les éléments suivants :

• Le nom de l’entreprise et le contact technique principal ou l’administrateur de l’organisation.

• Les noms et identifiants des espaces de travail, organisations API et projets API actuels et visés, 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’alias API ou l’identifiant de modèle exact utilisé pour le test.

• Indiquez 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 visée n’est pas utilisée pour des applications destinées aux clients, du trafic tiers ou des workflows de produits en aval.

• Indiquez si l’accès de la configuration précédente doit être supprimé ou rétabli à un état antérieur.

• Indiquez si la nouvelle configuration soulève une question de facturation, de plafond budgétaire ou de responsabilité commerciale.

• Le premier workflow que l’équipe prévoit d’exécuter, les responsables prévus pour son exécution et la personne chargée de sa révision.

• Les contraintes de calendrier ou toute session de prise en main à venir, le cas échéant.

Lorsque des paramètres de projet approuvés sont disponibles, ils servent à isoler l’accès à Daybreak par projet plutôt qu’à nécessiter une sous-organisation API distincte. Si ces 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 chargée de votre compte OpenAI.

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

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 en place uniquement pour des travaux défensifs autorisés.

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

• Limitez le périmètre du premier workflow et veillez à ce qu’il puisse être examiné.

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

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

• Autorisez uniquement les propriétaires de l’organisation API à configurer les paramètres Daybreak des projets. 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 pour Daybreak Blue n’inclut pas Daybreak Red.

• Sécurisez 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 à des clients tiers, à des utilisateurs externes ou à des workflows de produits en aval.