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 qui peuvent 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 avec 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 les requêtes et les identifiants au projet approuvé réservé à l’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 admissibles plus récents au fil du temps; les exemples ci-dessous ne sont pas des destinations fixes pour les alias. Ces alias de l’API OpenAI ne sont pas disponibles sur Amazon Bedrock.

Une organisation approuvée pour Daybreak Blue peut utiliser le contrôle Blue; une organisation approuvée pour Red peut utiliser les deux. L’activation d’un contrôle ne donne pas accès à des modèles non couverts par l’approbation de votre organisation.

Lorsque les contrôles 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 instructions de votre confirmation de migration avant de modifier une configuration existante. Pour la connexion à ChatGPT et à Codex, configurez les rôles de l’espace de travail séparément; 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 aussi disponible par AWS Bedrock et nécessite toujours l’approbation d’OpenAI. Communiquez avec votre équipe de compte AWS pour obtenir l’accès.

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 que celui par défaut, et 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’apporter des modifications. Prévoyez un délai pouvant aller 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 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 attendez environ 10 minutes. Vérifiez les attributions de rôles directes et par groupe, puis connectez-vous à l’espace de travail approuvé et faites un test avec un modèle approuvé. Dans Codex, ACTIVEZ le bouton à bascule Daybreak avant le 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 le provisionnement est terminé. Pour l’accès à l’API, confirmez que vous consultez un projet autre que celui par défaut; pour l’accès à l’espace de travail, vérifiez Console d’administration → Modèles. Si le contrôle ne s’affiche toujours pas, communiquez avec votre équipe de compte OpenAI pour confirmer l’admissibilité et le provisionnement 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 propre au modèle. Pour Astra ou GPT-6.1 Sol, l’accès Blue conserve les mesures de protection standard.

• Pour la connexion à Codex avec ChatGPT, que le propriétaire de l’espace de travail a activé l’accès pour l’utilisateur visé et que le bouton à bascule 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 à l’API, qu’un propriétaire de l’organisation API a enregistré le niveau Daybreak approuvé pour le projet visé, 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’alias API ou l’identifiant de modèle approuvé exact, en utilisant le tableau de l’API OpenAI ci-dessus, s’il y a lieu.

Un refus ou un résultat inattendu peut indiquer une inadéquation d’admissibilité ou de configuration, des identifiants périmés, 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 renseignements à fournir lorsque vous communiquez avec le soutien. Pour ouvrir une demande de soutien, consultez Comment puis-je communiquer avec le soutien?. Un refus peut ressembler à ceci :

Je ne peux pas créer ni empaqueter 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éfensive 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 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’alias ou l’identifiant de modèle exact et le projet API visé.

Si un bouton à bascule attendu n’est pas visible, que l’admissibilité de l’organisation semble incorrecte ou que les contrôles de 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é en matière de cybersécurité, 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’alias API ou l’identifiant de modèle, les paramètres de contrôle enregistrés, le rôle de l’administrateur, si l’identifiant 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, ainsi qu’une brève description de la tâche expurgée de tout renseignement sensible.

Pour ouvrir une demande de soutien, consultez Comment puis-je communiquer avec le soutien?.

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 inadéquation 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 sur 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 à l’API, demandez à un propriétaire de l’organisation API de vérifier les contrôles Daybreak admissibles pour le projet visé, autre que celui par défaut, 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 l’espace de travail d’examiner 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 par ChatGPT, confirmez 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 un délai pouvant aller 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 à un état antérieur ou laissée inchangée.

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

• Exécutez de nouveau le test de confirmation d’accès sur la configuration corrigée avec l’alias ou l’identifiant de modèle approuvé exact.

Incluez :

• Le nom de l’entreprise et la principale personne-ressource technique ou d’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 d’espace de travail et de rôles enregistrés.

• L’alias API ou l’identifiant de modèle exact 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 de la configuration précédente doit être supprimé ou rétabli à un é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 exécuter, les personnes qui devraient l’exécuter et la personne chargée de la révision humaine.

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

Lorsque des contrôles de projet approuvés sont disponibles, ils servent à isoler l’accès à Daybreak par projet plutôt qu’à exiger une sous-organisation API distincte. Si les contrôles ne sont pas disponibles ou si la configuration approuvée exige toujours une organisation API dédiée, suivez les instructions de votre équipe de compte OpenAI.

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

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

• Utilisez des systèmes qui appartiennent à votre organisation 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’alias API ou 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 ses paramètres par défaut et l’attribution des rôles personnalisés. L’approbation pour 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 à des clients tiers, à des utilisateurs externes ou à des flux de travail de produits en aval.