Vue d’ensemble

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 les workflows défensifs internes autorisés.

Daybreak Red nécessite une autorisation distincte pour les workflows de cybersécurité avancés et autorisés. Toutes les organisations Daybreak Red sont éligibles à GPT-5.6 Cyber. GPT-6 Cyber nécessite une autorisation distincte pour ce modèle. Activez et imposez l’authentification unique (SSO) dans chaque organisation ou espace de travail où vous utilisez Daybreak Red. Par défaut, l’accès à GPT-6 Cyber via l’API nécessite une liste d’adresses IP autorisées. Les projets API qui utilisent la politique de non-conservation des données nécessitent généralement aussi le traitement privé de sécurité.

L’autorisation 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 autorisés ; un propriétaire de l’organisation API l’active pour les projets autorisé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 également 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 exacts 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 autorisé

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

Pour les workflows directement dans les dépôts, commencez par Codex ou le plugin Codex Security. Utilisez Codex CLI ou l’action GitHub Codex pour les automatisations autorisées. Pour les workflows API, limitez les requêtes et les identifiants au projet autorisé réservé à un usage interne.

Pour accéder à l’API OpenAI, utilisez un identifiant de modèle spécifique inclus dans votre autorisation d’accès et le paramètre de requête Daybreak correspondant. Les exemples ci-dessous dépendent des modèles autorisé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 autorisation Daybreak Red. Pour utiliser les protections standard, définissez ce paramètre sur standard.

Pour les deux modèles Cyber, utilisez daybreak_red dans l’API Responses.

Une organisation autorisée à utiliser Daybreak Blue peut utiliser le paramètre Blue ; une organisation autorisée à utiliser Red peut utiliser les deux. L’activation d’un paramètre ne donne pas accès aux modèles non couverts par l’autorisation de votre organisation.

Lorsque les paramètres au niveau du projet sont activés, les projets API autorisé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 prennent en charge la réduction des refus avec Daybreak Blue ou Red. Astra et GPT-6.1 Sol conservent les protections 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 indiqués dans votre autorisation.

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

Valider GPT-6.1 Terra avec Daybreak

Pour GPT-6.1 Terra, vérifiez l’autorisation Daybreak Red et activez explicitement Daybreak pour la requête. Daybreak Blue seul n’active pas la réduction des refus en cybersécurité sur Terra. Dans l’API Responses, utilisez la clé du projet activé autre que celui par défaut et définissez explicitement access_programs.cyber ; si ce paramètre est omis, les protections standard s’appliquent. Chat Completions ne prend pas en charge ce mode de réduction des refus.

Pour Codex et ChatGPT Work, vérifiez l’espace de travail autorisé et l’accès Daybreak de l’utilisateur, utilisez un client pris en charge et activez le paramètre Daybreak. Validez séparément l’accès à l’API et à l’espace de travail. Si une requête autorisée échoue toujours, relevez 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 requête, l’horodatage et l’erreur expurgée des données sensibles.

Valider l’accès autorisé

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

• API : un propriétaire de l’organisation API ouvre le projet prévu, 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 autorisé et enregistrez. Les projets par défaut ne sont pas éligibles, et le seul rôle de propriétaire de 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 autorisé. 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 concerné ou Ajouter une dérogation de rôle. Sous Cybersécurité, définissez Daybreak Blue sur Activé ; n’activez Red que s’il est autorisé pour l’espace de travail et les utilisateurs concernés. Sélectionnez Enregistrer et patientez environ 10 minutes. Vérifiez les attributions de rôles directes et par groupe, puis connectez-vous à l’espace de travail autorisé et testez avec un modèle autorisé. Dans Codex, placez le bouton Daybreak sur ACTIVÉ avant de tester ; 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 autorisé, les permissions de l’administrateur et si le provisionnement est terminé. Pour l’accès 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 le provisionnement 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 comme celui qui suit est une issue possible, et non une réponse garantie :

Preuve de concept CVE strictement locale implémentée ; 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 votre organisation au niveau Daybreak demandé et, pour GPT-6 Cyber, l’autorisation pour ce modèle. Pour Astra ou GPT-6.1 Sol, l’accès Blue conserve les protections standard.

• Pour la connexion à Codex avec ChatGPT, que le propriétaire de l’espace de travail a activé l’accès pour l’utilisateur concerné et que le bouton Daybreak de cet utilisateur est sur ACTIVÉ. Avec la 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 API, qu’un propriétaire de l’organisation API a enregistré le niveau Daybreak autorisé pour le projet prévu, autre que celui 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 autorisé, 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 règles. 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 ressembler à ceci :

Je ne peux pas créer ni mettre en paquet 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 :

• Vérifiez que votre organisation est autorisée à utiliser le mode d’accès et le niveau Daybreak que vous utilisez. Pour GPT-6 Cyber, vérifiez que l’autorisation inclut ce modèle.

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

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

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

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 OpenAI chargée de votre compte de confirmer l’éligibilité et le mode d’accès autorisé 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 cybersécurité, suivez les instructions de l’article 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’identifiant du modèle, les paramètres enregistrés, le rôle de l’administrateur, l’appartenance ou non de l’identifiant d’authentification 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 données 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.