Aperçu

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’admissibilité à une configuration prête à l’emploi.

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 avec Daybreak Blue pour leurs flux de travail défensifs internes approuvés.

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

L’approbation seule n’active pas la réduction des refus. Les contrôles 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 ceux 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 flux de travail à risque plus élevé peuvent encore être refusés après l’activation de l’accès. Commencez donc par un flux de travail défensif à portée limitée 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

Comprendre le mode d’accès approuvé

Votre confirmation d’intégration devrait 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 dans un dépôt, commencez par Codex ou le plugiciel Codex Security. Utilisez Codex CLI ou l’action GitHub de Codex pour les automatisations approuvées. Pour les flux de travail API, limitez la portée des requêtes et des identifiants au projet approuvé réservé à l’usage interne.

Pour accéder à l’API OpenAI, utilisez un identifiant de modèle précis 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 de l’approbation pour Daybreak Red. Pour utiliser les mesures de protection 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 pour Daybreak Red et de l’approbation supplémentaire requise pour le 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 à l’usage interne peuvent remplacer une organisation API dédiée distincte. Suivez les indications 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 prennent en charge la réduction des refus avec Daybreak Blue ou Red. Astra et GPT-6.1 Sol conservent les mesures de protection standard avec Blue et prennent en charge la réduction des 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 précisés dans votre approbation.

Daybreak est également offert par l’entremise d’AWS Bedrock et nécessite toujours l’approbation d’OpenAI. Communiquez avec l’équipe responsable de votre compte AWS pour obtenir l’accès.

Valider GPT-6.1 Terra avec Daybreak

Pour GPT-6.1 Terra, confirmez l’approbation pour Daybreak Red et activez explicitement Daybreak pour la requête. Daybreak Blue seul ne permet pas de réduire les refus liés à la cybersécurité sur Terra. Dans l’API Responses, utilisez la clé du projet activé autre que le projet par défaut et définissez explicitement access_programs.cyber; si vous omettez ce paramètre, les mesures de protection standard s’appliquent. Chat Completions ne prend pas en charge ce mode d’accès avec réduction des refus.

Pour Codex et ChatGPT Work, validez l’accès à Daybreak de l’espace de travail et de l’utilisateur approuvés, utilisez un client pris en charge et activez le paramètre Daybreak. Validez séparément l’accès à l’API et l’accès à l’espace de travail. Si une requête approuvée échoue toujours, consignez le modèle exact, le point de terminaison ou l’interface du produit, l’organisation, le projet ou l’espace de travail, les paramètres activés, l’identifiant de la requête, l’horodatage et le message d’erreur expurgé.

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 visé, autre que le 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 admissibles, et le seul rôle de propriétaire de projet ne permet pas d’effectuer des modifications. Prévoyez un délai pouvant aller jusqu’à environ 15 minutes, puis envoyez une requête directe à l’API Responses à l’aide de la clé de ce projet et d’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 par 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é; activez Red uniquement s’il est approuvé pour l’espace de travail et ces utilisateurs. Sélectionnez Enregistrer et prévoyez environ 10 minutes. Examinez les attributions de rôles directes et par groupe, puis connectez-vous à l’espace de travail approuvé et effectuez un test avec un modèle approuvé. Dans Codex, activez le commutateur Daybreak avant de faire un test; lorsqu’il est désactivé, les mesures de protection standard s’appliquent.

Si le contrôle 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 API, confirmez que vous consultez un projet autre que le projet par défaut; pour l’accès à l’espace de travail, vérifiez Console d’administration → Modèles. Si le contrôle n’apparaît toujours pas, communiquez avec votre équipe de compte OpenAI pour confirmer l’admissibilité et la mise à disposition avant de faire un test.

Créez une preuve de concept avec le code d’exploitation, 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. Un résultat comme le suivant est une issue possible, et non une réponse garantie :

Preuve de concept CVE exclusivement locale 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 spécialement conçue.

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

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

• L’admissibilité 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 mesures de protection standard.

• Pour la connexion à Codex par ChatGPT, que le propriétaire de l’espace de travail a activé l’accès pour l’utilisateur visé et que le commutateur Daybreak de l’utilisateur est activé. Avec la connexion par clé API, l’accès dépend du projet API activé; il n’y a pas d’interface Daybreak distincte.

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

• Pour l’accès 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, s’il y a lieu.

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 imposée par une politique. Cela ne confirme pas à lui seul l’absence d’accès.

Suivez Accès de confiance pour la cybersécurité — Problèmes courants et dépannage pour connaître les étapes de diagnostic et les renseignements à inclure lorsque vous communiquez avec l’assistance. Pour ouvrir une demande d’assistance, consultez Comment puis-je communiquer avec l’assistance?. Un refus peut ressembler à ceci :

Je ne peux pas créer ni préparer une preuve de concept d’exploitation 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 admissibilité 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 que le 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’identifiant exact du modèle et le projet API visé.

Si un commutateur attendu n’est pas visible, que l’admissibilité de l’organisation semble incorrecte ou que les contrôles du projet ne sont pas disponibles, demandez à votre équipe de compte OpenAI de confirmer l’admissibilité 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é informatique, suivez OpenAI Daybreak : Problèmes courants et dépannage. Incluez l’identifiant de votre organisation ou espace de travail, l’identifiant du projet s’il y a lieu, l’interface du produit, le niveau Daybreak, l’identifiant du modèle, les paramètres de contrôle 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 s’il y a lieu et une brève description de la tâche dont les renseignements sensibles ont été caviardés.

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

Lancer le premier flux de travail

Pour la plupart des équipes, le premier flux de travail devrait commencer dans le plugiciel Codex Security, avec un périmètre limité à un dépôt, une branche ou un ensemble d’alertes. Codex CLI est la voie à suivre pour l’automatisation à grande échelle lorsque les responsables disposent déjà d’un flux de travail CI/CD de confiance à valider. Pour les flux de travail API, utilisez le projet approuvé réservé à l’usage interne, le niveau Daybreak approuvé et la clé API de ce projet.

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

Suivez cette procédure lorsque la configuration approuvée pointe vers la mauvaise organisation, le mauvais espace de travail ou le mauvais projet API; que le projet visé n’est pas réservé à l’usage interne; qu’un contrôle attendu est absent; que le mauvais niveau Daybreak est activé; qu’un identifiant du mauvais projet est utilisé; que l’accès doit passer du mode API au mode espace de travail ou inversement; ou qu’un retour en arrière ou une suppression est en attente.

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

• Déterminez la configuration actuelle et la configuration visée réservée à l’usage interne.

• Pour l’accès API, demandez à un propriétaire de l’organisation API de vérifier les contrôles Daybreak admissibles pour le projet visé, autre que le projet par défaut, en suivant les étapes ci-dessus.

• Si le commutateur 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 l’espace de travail d’examiner les rôles directs et par groupe de l’utilisateur visé ainsi que ses autorisations de modèles enregistrées. Avant de refaire un test dans Codex avec une connexion par ChatGPT, confirmez que le commutateur Daybreak de l’utilisateur est activé.

• Pour l’accès 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 commutateur attendu est absent ou si l’admissibilité est incorrecte, envoyez les renseignements ci-dessous à votre équipe de compte OpenAI dans une demande de correction.

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

Incluez :

• Le nom de l’entreprise et les coordonnées de la principale personne-ressource technique ou responsable de l’administration 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 contrôles 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 visée 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 l’examen.

• Les contraintes de temps ou une prochaine séance d’accompagnement, s’il y a lieu.

Lorsque les contrôles de projet approuvés sont disponibles, ils visent à isoler l’accès Daybreak par projet plutôt qu’à exiger une sous-organisation API distincte. Si les contrôles sont indisponibles ou si la configuration approuvée nécessite toujours une organisation 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, qu’un remplacement est en attente ou que la correction d’admissibilité 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.

Note sur l’utilisation

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

Lorsque des contrôles de projet approuvés sont disponibles, un projet réservé à l’usage interne peut isoler l’accès à Daybreak au sein d’une organisation API admissible, 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.

Aucune conservation des données (ZDR)

L’admissibilité à Daybreak et l’activation du projet n’activent pas automatiquement le mode Aucune conservation des données (ZDR). Le mode ZDR doit être demandé et provisionné séparément pour l’organisation API précise et le point de terminaison applicable. Si votre organisation exige le mode ZDR ou un autre traitement particulier de conservation des données, confirmez que le trafic du projet activé est couvert par ces conditions avant que votre équipe lance le premier flux de travail. Ne supposez pas que l’activation du bouton à bascule 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 de défense autorisés.

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

• Gardez le premier flux de travail limité et facile à examiner.

• 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 renseignements d’intégration.

• Autorisez uniquement les propriétaires de l’organisation API à configurer les contrôles Daybreak du projet. Les propriétaires de l’espace de travail gèrent les paramètres par défaut de l’espace de travail et les attributions de 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é à l’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.