Comment terminer l’intégration d’entreprise à l’accès de confiance, valider l’accès provisionné, corriger les problèmes d’organisation ou d’espace de travail et se préparer au premier flux de travail.

Aperçu

Utilisez ce guide si vous coordonnez l’intégration à Daybreak pour votre organisation et que vous devez passer de la collecte des renseignements au provisionnement, puis à une configuration prête à utiliser.

Daybreak est le programme d’OpenAI axé sur les travaux de 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 l’accès de confiance pour la cybersécurité pour les flux de travail défensifs internes approuvés. Pour ce chemin d’accès, OpenAI provisionne l’organisation ou l’espace de travail indiqué dans le processus de collecte après la vérification KYB de Persona et les contrôles internes d’admissibilité. L’accès peut s’appliquer à une organisation Codex ou ChatGPT, à une organisation API, ou aux deux, selon la configuration approuvée.

Certains flux de travail à risque plus élevé peuvent tout de même être refusés après le provisionnement; commencez donc par un flux de travail défensif circonscrit sur la surface exacte que votre équipe prévoit utiliser.

Suivre l’état de l’intégration et du provisionnement

Phase	Description	Prochaine étape
Soumettre le formulaire de collecte	Votre organisation a rempli le formulaire de collecte d’entreprise pour l’accès de confiance	Surveillez l’arrivée d’un courriel de Persona et effectuez la vérification KYB. Assurez-vous que le courriel de Persona est envoyé à la bonne personne-ressource de l’organisation.
Recevoir le courriel KYB de Persona et effectuer la vérification	Après la soumission du formulaire de collecte, Persona envoie un courriel à la personne-ressource indiquée dans votre formulaire afin d’effectuer la vérification Know Your Business (KYB).	Complétez la demande KYB de Persona. Une fois la vérification KYB terminée, OpenAI effectue des contrôles internes d’admissibilité et ne provisionne l’accès qu’après leur réussite.
Recevoir l’avis indiquant que vous avez été provisionné	OpenAI a appliqué l’accès à l’organisation ou à l’espace de travail demandé dans le formulaire de collecte.	Vérifiez que l’accès est correctement provisionné sur la surface demandée. Notez que l’accès n’est pas actuellement affiché dans un tableau de bord d’espace de travail visible par le client.
Vérifier que vous avez accès et démarrer un flux de travail défensif circonscrit	L’organisation ou l’espace de travail provisionné est confirmé, et la vérification d’accès prévue réussit	Choisissez un premier flux de travail défensif circonscrit, nommez la personne qui l’exécutera et celle qui le révisera, puis utilisez le plugiciel Codex Security ou une organisation API Responses approuvée.

Comprendre le chemin d’accès provisionné

La confirmation d’OpenAI devrait indiquer quel chemin d’accès a été provisionné, qui peut l’utiliser et quelle organisation ou quel espace de travail utiliser en premier.

Pour les flux de travail pratiques dans les dépôts, commencez avec Codex ou le plugiciel Codex Security. Utilisez Codex CLI ou la Codex GitHub Action pour l’automatisation approuvée. Si l’accès est provisionné pour une organisation API, limitez les demandes et les identifiants à cette organisation.

Chemin d’accès provisionné	Qui peut l’utiliser	Où l’accès s’applique	Première surface pour valider l’accès
Accès par Codex	Membres de l’organisation ou de l’espace de travail interne Codex ou ChatGPT nommé	L’organisation ou l’espace de travail provisionné. L’accès s’applique à toute l’organisation pour ce chemin	Pour les travaux de sécurité sur des ressources statiques, commencez avec le plugiciel Codex Security.
Accès par organisation API	Utilisateurs ou services authentifiés auprès de l’organisation API interne nommée	L’organisation API provisionnée	L’API Responses ou un autre flux de travail approuvé de l’API Codex.

Pour GPT-5.5 avec l’accès de confiance pour la cybersécurité, l’accès à l’espace de travail est provisionné pour l’organisation Codex ou ChatGPT nommée, et l’accès API est provisionné pour l’organisation API nommée. Si votre confirmation nomme un autre chemin propre à l’utilisateur ou au modèle, suivez exactement ces instructions au lieu de supposer que l’accès s’applique à toute l’organisation. Si le chemin d’accès provisionné n’est pas clair, demandez à votre personne-ressource OpenAI de le confirmer avant de faire des tests.

Valider l’accès provisionné

Une fois qu’OpenAI confirme le provisionnement, exécutez cette invite sur la surface exacte confirmée. Cela peut se faire dans Codex en étant connecté à l’organisation ou à l’espace de travail interne seulement, ou par l’API Responses avec les identifiants de l’organisation API confirmée.

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

La vérification d’accès réussit lorsque GPT-5.5 termine la preuve de concept circonscrite et locale seulement, avec contraintes de sécurité, fichiers locaux et résultat de vérification, par exemple :

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’invite est refusée ou ne produit pas le résultat circonscrit attendu, confirmez d’abord l’identité connectée et l’organisation ou l’espace de travail. Le résultat peut indiquer un provisionnement incomplet, une incompatibilité de routage ou une limite de politique. Si le provisionnement est terminé et que le problème persiste, consultez Accès de confiance pour la cybersécurité – Problèmes courants et dépannage pour connaître les étapes de diagnostic et les détails à 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 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.

Faire remonter les problèmes de configuration

Avant de modifier des espaces de travail, des organisations API, des dépôts ou des identifiants, demandez à votre équipe de compte OpenAI de confirmer que le provisionnement est terminé et que l’organisation, l’espace de travail et le chemin d’accès prévus sont corrects.

Pour les problèmes de vérification, d’accès, de modèle ou de sécurité cyber, consultez Accès de confiance pour la cybersécurité – Problèmes courants et dépannage. L’article comprend des étapes de diagnostic et les renseignements à fournir lorsque vous communiquez avec l’assistance, comme votre ID d’organisation, la surface du produit, le modèle, le message d’erreur complet, l’ID de la demande, l’horodatage et le fuseau horaire, une capture d’écran s’il y a lieu, ainsi qu’une brève description caviardée de la tâche.

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

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 à un dépôt, une branche ou une 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 incompatibilité 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 entre les chemins API et espace de travail, ou qu’une annulation ou une suppression est en attente.

Mettez les tests en pause dans 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 interne seulement, l’organisation API, ou les deux, qui sont prévus.
Confirmez si l’ancienne configuration doit être supprimée, annulée ou laissée telle quelle.
Envoyez les détails ci-dessous à votre équipe de compte OpenAI comme demande de correction.
Attendez qu’OpenAI confirme que la correction est terminée.
Relancez la vérification de preuve d’accès dans la configuration corrigée.

Inclure :

le nom de l’entreprise et la personne-ressource principale pour l’administration technique ou l’espace de travail
le nom et l’ID de l’espace de travail ou de l’organisation API actuelle, s’ils sont connus
le nom et l’ID de l’espace de travail interne seulement ou de l’organisation API prévue, s’ils sont connus
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é ou annulé dans la configuration précédente
si la nouvelle configuration soulève une question de facturation, de limite budgétaire ou de responsable commercial
le premier flux de travail que l’équipe prévoit exécuter et les personnes qui devraient l’exécuter
les contraintes de calendrier ou la séance d’activation à venir, le cas échéant

Si la suppression d’une ancienne organisation ou un échange est toujours en attente, considérez que la configuration corrigée n’est pas prête tant qu’OpenAI n’a pas confirmé 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)

Le provisionnement de l’accès de confiance n’active pas automatiquement l’option Aucune conservation des données (ZDR). La ZDR doit être demandée et provisionnée séparément pour l’organisation exacte. Si votre organisation exige la ZDR ou un autre traitement précis de conservation des données, confirmez que l’organisation que vous prévoyez utiliser est couverte 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.

Intégration Daybreak pour entreprises