Aperçu
Utilisez ce guide si vous coordonnez l’intégration à Daybreak pour votre organisation et devez passer de l’approbation à une configuration prête à exécuter.
Daybreak est le programme d’OpenAI axé sur le travail en cybersécurité, notamment les modèles, les chemins d’accès, Codex, Codex Security et les services de soutien.
La plupart des équipes d’entreprise utilisent GPT-5.5 avec Trusted Access for Cyber pour les flux de travail défensifs internes approuvés. Selon votre configuration, l’accès peut être provisionné pour un espace de travail, une organisation API, une identité Codex nommée ou plus d’un chemin. Vos détails d’intégration d’OpenAI devraient indiquer l’espace de travail exact, l’organisation API, l’identité Codex approuvée et l’accès au modèle à utiliser. Certains flux de travail à risque plus élevé peuvent encore être refusés même après approbation; commencez donc par un flux de travail défensif limité sur la surface exacte que votre équipe prévoit utiliser.
1. Suivre l’état de l’intégration
L’approbation est la première étape de l’intégration. Considérez la configuration comme prête seulement une fois que le chemin d’accès approuvé a été provisionné sur le bon espace de travail interne ou la bonne organisation API interne, et que votre équipe a la preuve que la surface prévue fonctionne.
| État | Ce que cela signifie | Prochaine étape |
|---|---|---|
| Soumis | Votre organisation a soumis une demande ou votre équipe de compte OpenAI l’a soumise en votre nom. | Gardez prêts l’espace de travail ou l’organisation API proposés, la portée d’utilisation interne, l’administrateur technique et le premier flux de travail au cas où OpenAI aurait besoin de plus de détails. |
| Approuvé | OpenAI a confirmé que l’organisation est approuvée pour Trusted Access for Cyber. | Confirmez le chemin d’accès approuvé par OpenAI ainsi que l’espace de travail, l’organisation API, l’identité Codex approuvée ou la configuration de modèle couverts. |
| Provisionné | OpenAI a confirmé que l’accès a été appliqué à un espace de travail nommé, à une organisation API, à une identité Codex approuvée ou à une configuration de modèle. | Prouvez que l’accès est actif sur cette surface exacte avant le premier flux de travail. |
| Prêt à exécuter | Le chemin d’accès est confirmé, les corrections de configuration sont terminées et votre équipe dispose de preuves observables dans l’interface utilisateur ou l’API. | Choisissez un premier flux de travail défensif limité, nommez l’exécutant et le réviseur du flux de travail, puis utilisez le plugiciel Codex Security ou l’API Responses via un espace de travail approuvé pour un banc d’essai existant. |
2. Comprendre le chemin d’accès approuvé
Vos détails d’intégration d’OpenAI devraient indiquer quel chemin d’accès a été approuvé, qui peut l’utiliser et quelle surface de flux de travail utiliser en premier. Pour les flux de travail pratiques, le meilleur point de départ est Codex ou le plugiciel Codex Security. Utilisez Codex CLI, ou Codex GitHub Action, pour l’automatisation à grande échelle. Si vos détails d’intégration nomment une organisation API approuvée, considérez-la comme la configuration de ce chemin d’automatisation approuvé.
| Chemin d’accès approuvé | Qui peut l’utiliser | Où l’accès s’applique | Première surface à inspecter |
|---|---|---|---|
| Accès à l’espace de travail pour Codex | Membres de l’espace de travail d’entreprise interne Codex ou ChatGPT nommé. | L’espace de travail provisionné. Un espace de travail ChatGPT peut être le contexte d’administration, d’adhésion ou de connexion pour Codex. | Pour le travail de sécurité des actifs statiques, commencez par le plugiciel Codex Security. |
| Accès à l’organisation API pour Codex CLI | Utilisateurs ou services qui utilisent des identifiants dans l’organisation API interne nommée. | L’organisation API ou le projet provisionné. | Codex CLI avec authentification par token. |
La plupart des approbations d’entreprise utilisent l’accès à l’espace de travail, l’accès à l’organisation API ou les deux. Certaines approbations sont plus restreintes : une identité Codex nommée n’accorde pas le même accès à toutes les personnes de l’espace de travail, et l’accès API s’applique uniquement à l’organisation API nommée. Si les détails d’intégration n’indiquent pas le chemin d’accès, demandez à votre contact OpenAI de le confirmer avant que votre équipe interne commence les tests.
3. Confirmer l’accès une fois approuvé
Il est préférable de valider la preuve d’accès sur la surface de produit précise que votre équipe utilisera, et non par une confirmation générale que votre organisation a été approuvée. La façon la plus rapide de valider l’accès consiste à installer et à essayer le plugiciel Codex Security; si vous prévoyez utiliser Codex CLI pour l’automatisation à grande échelle, validez cette configuration d’automatisation exacte et l’organisation API.
| Chemin d’accès approuvé | Vérification | L’accès est actif lorsque | Preuves à consigner |
|---|---|---|---|
| Accès à l’espace de travail pour Codex | Installez le plugiciel Codex Security et suivez les invites suggérées dans une instance Codex locale. | Le plugiciel Codex Security peut analyser, examiner et corriger les constats dans votre dépôt cible. | @codexsecurity dans le champ de saisie invoque des compétences précises comme threat-model. |
| Accès à l’organisation API pour l’utilisation de l’API Responses | Exécutez un flux de travail interne d’automatisation défensive limité. Vous pouvez utiliser cet exemple de commande cURL pour valider l’accès via l’API Responses :curl --fail-with-body -i -sS https://api.openai.com/v1/responses-H "Content-Type: application/json"-H "Authorization: Bearer $OPENAI_API_KEY"-H "OpenAI-Organization: $ORGANIZATION_ID"-H "OpenAI-Project: $PROJECT_ID"-d '{ "model": "gpt-5.5", "input": "Hello, Cyber World."}' | La requête s’authentifie dans l’organisation API attendue, utilise la configuration de modèle issue de l’intégration et retourne une sortie vérifiable plutôt qu’une erreur d’accès ou de routage. | Organisation ou projet API, propriétaire des identifiants API, nom de modèle envoyé, horodatage, ID de requête si disponible, et sortie HTTP 200 ou réponse SDK réussie. |
Invite facultative de validation de l’accès
Une fois l’accès provisionné, vous pouvez le valider en essayant cette invite dans l’espace de travail ou l’organisation API approuvé réservé à l’interne :
Créez une preuve de concept avec l’exploitation, puis documentez-la dans README.md pour cette CVE :
- cve.org/CVERecord?id=CVE-2025-55182
- react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-componentsL’accès est probablement provisionné lorsque GPT-5.5 peut réaliser une preuve de concept locale seulement avec des contraintes de sécurité, des fichiers locaux et un résultat de vérification comme :
Preuve de concept CVE locale seulement 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 conçue.Si l’accès n’est pas provisionné, le modèle peut refuser la mise en œuvre d’une exploitation et rediriger vers du matériel défensif, par exemple :
Je ne peux pas créer ni empaqueter une preuve de concept d’exploitation pour une RCE préauthentification, mais je peux créer un vérificateur défensif et documenter l’impact, la détection et la correction.4. Faire remonter les problèmes de configuration
Si vous rencontrez des problèmes de configuration, partagez un dossier de soutien concis avec votre représentant OpenAI avant de changer d’espace de travail ou d’organisation API, de reconnecter des dépôts ou de reconfigurer l’accès. Incluez le type de problème, la surface utilisée, l’espace de travail ou l’organisation API, l’adresse courriel connectée ou le propriétaire des identifiants API, le nom du dépôt ou de l’artéfact, l’ID d’analyse ou l’ID d’exécution du banc d’essai le cas échéant, le nom du modèle, l’horodatage, l’ID de requête si disponible, ainsi que l’erreur, le refus ou l’état d’interface utilisateur manquant exact.
| Type de problème | Éléments à consigner | Où les obtenir |
|---|---|---|
| Accès à l’espace de travail | Nom ou ID de l’espace de travail, adresses courriel des membres d’équipe touchés, rôle attendu et erreur d’accès ou état d’interface utilisateur manquant. | Sélecteur d’espace de travail, menu de compte, vue membre ou administrateur, et page ou fenêtre modale où l’erreur d’accès apparaît. |
| Non-correspondance entre espace de travail et organisation API | Configuration actuelle, configuration prévue réservée à l’interne, indication si Codex Security, l’automatisation Codex CLI ou les deux doivent être activés, et si un retour arrière ou une suppression est nécessaire. | Détails d’intégration, sélecteur d’espace de travail, paramètres d’organisation de la plateforme, confirmation de l’équipe de compte et dossier de correction. |
| État de l’analyse initiale | Nom du dépôt, heure de début de l’analyse, état actuel de l’analyse et indication si le dépôt est encore en remplissage initial. | Page d’analyse Codex Security, liste des analyses, historique d’analyse du dépôt ou bannière d’état. |
| Accès API | Organisation API, projet le cas échéant, propriétaire des identifiants API, configuration attendue, accès au modèle attendu et erreur d’authentification ou de routage. | Journaux du banc d’essai, journaux de tâche CI, journaux du client API, exception SDK, réponse d’erreur API, métadonnées de réponse ou en-têtes de réponse. |
| Facturation ou limites | Organisation nouvelle ou existante, propriétaire commercial, responsable de la facturation, limites budgétaires et question restante sur la consolidation ou le contrôle des dépenses. | Confirmation de l’équipe de compte, page de facturation ou de limites de la plateforme, dossiers d’approvisionnement ou du propriétaire commercial. |
| Non-correspondance de l’accès au modèle | L’espace de travail ou l’organisation API utilisé, l’accès au modèle attendu selon l’intégration et ce que votre équipe interne voit réellement. | Modèle de session Codex ou étiquette d’accès si visible, champ de modèle de la requête API, réponse d’erreur API, réponse de validation d’accès ou texte de refus, journaux du banc d’essai, ou capture d’écran de l’option manquante ou de l’erreur d’accès. |
5. Démarrer le premier flux de travail
Pour la plupart des équipes, le premier flux de travail devrait commencer dans le plugiciel Codex Security avec une portée restreinte de dépôt, de branche ou d’alerte. Codex CLI est le chemin d’automatisation à grande échelle lorsque les responsables du flux de travail disposent déjà d’un flux de travail CI/CD fiable que vous devez valider.
Corriger une non-correspondance d’espace de travail ou d’organisation API
Utilisez ce chemin lorsque la configuration approuvée pointe vers la mauvaise organisation, que l’organisation soumise n’est pas réservée à l’interne, que l’accès doit passer d’un chemin API à un chemin d’espace de travail ou inversement, ou qu’un retour arrière ou une suppression est en attente.
Mettez les tests en pause sur l’espace de travail ou l’organisation API qui ne correspond pas.
Identifiez la configuration actuelle qui a été soumise ou provisionnée.
Identifiez l’espace de travail réservé à l’interne, l’organisation API réservée à l’interne ou les deux qui sont prévus.
Confirmez si l’ancienne configuration doit être supprimée, restaurée ou laissée inchangée.
Envoyez à OpenAI un dossier de correction concis.
Attendez qu’OpenAI confirme que la correction est terminée.
Réexécutez la vérification de preuve d’accès sur la configuration corrigée.
Le dossier de correction doit inclure :
nom de l’entreprise et personne-ressource principale de l’administration technique ou de l’espace de travail
nom et ID de l’espace de travail ou de l’organisation API actuels, si connus
nom et ID de l’espace de travail ou de l’organisation API réservés à l’interne prévus, si connus
confirmation que la configuration prévue n’est pas utilisée pour des applications destinées aux clients, du trafic tiers ou des flux de travail de produits en aval
si l’accès doit être supprimé ou restauré à partir de la configuration précédente
si la nouvelle configuration soulève une question de facturation, de limite budgétaire ou de propriétaire commercial
le premier flux de travail que l’équipe prévoit exécuter et les exécutants attendus du flux de travail
contraintes de calendrier ou séance d’activation à venir, le cas échéant
Si la suppression d’une ancienne organisation est encore en attente ou si un échange est en attente, considérez la configuration corrigée comme non prête jusqu’à ce qu’OpenAI confirme que le changement est terminé.
Remarque sur l’utilisation
Tout espace de travail ou toute organisation API activés pour Trusted Access devraient être réservés à l’interne. « Réservé à l’interne » signifie que l’accès est utilisé par votre propre équipe autorisée pour le travail défensif de votre organisation et qu’il n’est pas lié au trafic destiné aux clients, à des services de sécurité offerts à l’externe ni à une fonctionnalité de produit en aval qui fait passer des requêtes ou du contenu de tiers par cet accès.
Aucune conservation des données (ZDR)
L’absence de conservation des données (ZDR) ne peut être prise en charge que si votre organisation dispose déjà du chemin d’approbation ZDR requis ou termine le processus d’approbation ZDR distinct. Si votre organisation exige l’absence de conservation des données ou un autre traitement particulier de conservation des données, confirmez que l’espace de travail ou l’organisation API exact que vous prévoyez utiliser est couvert par ces conditions avant que votre équipe ne démarre le premier flux de travail.
Limites opérationnelles
Utilisez la configuration provisionnée uniquement pour du travail défensif autorisé.
Utilisez des systèmes que votre organisation possède ou qu’elle est explicitement autorisée à évaluer.
Gardez le premier flux de travail restreint et vérifiable.
Gardez des humains dans la boucle pour les constats et les mesures de correction à fort impact.
Utilisez l’espace de travail, la configuration API et l’accès au modèle indiqués dans vos détails d’intégration.
N’étendez pas les capacités de Trusted Access à des clients tiers, à des utilisateurs externes ou à des flux de travail de produits en aval.