Comment terminer l’intégration Trusted Access en entreprise, valider l’accès provisionné, corriger les problèmes d’organisation ou d’espace de travail et préparer le premier workflow.

Présentation

Utilisez ce guide si vous coordonnez l’intégration Daybreak pour votre organisation et devez passer de la demande initiale au provisionnement, jusqu’à une configuration prête à l’emploi.

Daybreak est le programme d’OpenAI consacré aux travaux de cybersécurité, notamment les modèles, les voies d’accès, Codex, Codex Security et les services associés.

La plupart des équipes d’entreprise utilisent GPT-5.5 avec Trusted Access for Cyber pour les workflows défensifs internes approuvés. Pour cette voie d’accès, OpenAI provisionne l’organisation ou l’espace de travail identifié lors du processus de demande une fois la vérification KYB par Persona et les contrôles internes d’adéquation terminés. L’accès peut s’appliquer à une organisation Codex ou ChatGPT, à une organisation API, ou aux deux, selon la configuration approuvée.

Certains workflows à risque plus élevé peuvent encore être refusés après le provisionnement ; commencez donc par un workflow défensif circonscrit sur la surface exacte que votre équipe prévoit d’utiliser.

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

Phase	Description	Étape suivante
Envoyer le formulaire de demande	Votre organisation a rempli le formulaire de demande Trusted Access pour les entreprises	Surveillez l’arrivée d’un e-mail de Persona et effectuez la vérification KYB. Assurez-vous que l’e-mail de Persona parvient au bon contact dans l’organisation.
Recevoir et traiter l’e-mail KYB de Persona	Une fois le formulaire de demande envoyé, Persona envoie un e-mail au contact indiqué dans ce formulaire pour effectuer la vérification Know Your Business (KYB).	Traitez la demande KYB de Persona. Une fois le KYB terminé, OpenAI effectue des contrôles internes d’adéquation et ne provisionne l’accès qu’après leur validation.
Recevoir la notification indiquant que vous avez été provisionné	OpenAI a appliqué l’accès à l’organisation ou à l’espace de travail demandé dans le formulaire de demande.	Vérifiez que l’accès est correctement provisionné sur la surface demandée. Notez que l’accès n’est actuellement pas affiché dans un tableau de bord d’espace de travail visible par le client.
Vérifier que vous disposez de l’accès et lancer un workflow 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 workflow défensif circonscrit, nommez la personne qui l’exécutera et celle qui le relira, puis utilisez le plugin Codex Security ou une organisation approuvée pour l’API Responses.

Comprendre la voie d’accès provisionnée

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

Pour les workflows pratiques sur des dépôts, commencez avec Codex ou le plugin 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 requêtes et les identifiants au périmètre de cette organisation.

Voie d’accès provisionnée	Qui peut l’utiliser	Où l’accès s’applique	Première surface pour valider l’accès
Accès via Codex	Membres de l’organisation ou de l’espace de travail interne Codex ou ChatGPT nommé	L’organisation ou l’espace de travail provisionné. Pour cette voie, l’accès s’applique à toute l’organisation	Pour les travaux de sécurité sur des ressources statiques, commencez avec le plugin Codex Security.
Accès via une 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 workflow approuvé de l’API Codex.

Pour GPT-5.5 avec Trusted Access for Cyber, l’accès à l’espace de travail est provisionné pour l’organisation Codex ou ChatGPT nommée, et l’accès à l’API pour l’organisation API nommée. Si votre confirmation mentionne une autre voie au niveau utilisateur ou propre à un modèle, suivez ces instructions exactes au lieu de supposer que l’accès s’applique à toute l’organisation. Si la voie d’accès provisionnée n’est pas claire, demandez à votre contact OpenAI de la confirmer avant de tester.

Valider l’accès provisionné

Après confirmation du provisionnement par OpenAI, exécutez ce prompt sur la surface exacte confirmée. Cela peut se faire dans Codex en étant connecté à l’organisation ou à l’espace de travail réservé à un usage interne, ou via 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 mène à bien la preuve de concept circonscrite, strictement locale, avec des contraintes de sécurité, des fichiers locaux et un résultat de vérification tel que :

Mise en œuvre d’une preuve de concept CVE locale uniquement ; 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 le prompt est refusé 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 erreur de routage ou une limite liée à la politique. Si le provisionnement est terminé et que le problème persiste, suivez Trusted Access for Cyber - Problèmes courants et dépannage pour connaître les étapes de diagnostic et les informations à inclure lorsque vous contactez le support. Pour ouvrir une demande auprès du support, consultez : Comment contacter le support ? Un refus peut se présenter ainsi :

Je ne peux pas créer ni empaqueter une preuve de concept d’exploit pour une RCE pré-authentification, mais je peux créer un vérificateur défensif et documenter l’impact, la détection et la remédiation.

Faire remonter les problèmes de configuration

Avant de changer d’espaces de travail, d’organisations API, de dépôts ou d’identifiants, demandez à votre équipe de compte OpenAI de confirmer que le provisionnement est terminé et que l’organisation, l’espace de travail et la voie 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, suivez Trusted Access for Cyber - Problèmes courants et dépannage. L’article inclut les étapes de diagnostic et les informations à fournir lorsque vous contactez le support, comme l’ID de votre organisation, la surface produit, le modèle, le message d’erreur complet, l’ID de requête, l’horodatage et le fuseau horaire, une capture d’écran le cas échéant, ainsi qu’une brève description expurgée de la tâche.

Pour ouvrir une demande auprès du support, consultez : Comment contacter le support ?

Lancer le premier workflow

Pour la plupart des équipes, le premier workflow doit commencer dans le plugin Codex Security, avec un périmètre restreint à un dépôt, une branche ou une alerte. Codex CLI est la voie d’automatisation à grande échelle lorsque les responsables du workflow disposent déjà d’un workflow CI/CD fiable à valider.

Corriger une incohérence d’espace de travail ou d’organisation API

Utilisez cette procédure lorsque la configuration approuvée pointe vers la mauvaise organisation, que l’organisation soumise n’est pas réservée à un usage interne, que l’accès doit être déplacé entre les voies API et espace de travail, ou qu’un retour en arrière ou une suppression est en attente.

Suspendez les tests sur l’espace de travail ou l’organisation API présentant l’incohérence.
Identifiez la configuration actuelle qui a été soumise ou provisionnée.
Identifiez l’espace de travail réservé à un usage interne, l’organisation API prévue, ou les deux.
Confirmez si l’ancienne configuration doit être supprimée, annulée ou laissée inchangée.
Envoyez les informations ci-dessous à votre équipe de compte OpenAI sous forme de demande de correction.
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.

Incluez :

nom de l’entreprise et contact principal de l’administrateur 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 réservé à un usage interne ou de l’organisation API prévue, 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 workflows produit en aval
indiquer si l’accès doit être supprimé de la configuration précédente ou y faire l’objet d’un retour en arrière
indiquer si la nouvelle configuration soulève une question de facturation, de limite budgétaire ou de responsable commercial
premier workflow que l’équipe prévoit d’exécuter et personnes qui devraient l’exécuter
contraintes de calendrier ou session d’activation à venir, le cas échéant

Si la suppression d’une ancienne organisation ou un échange est encore en attente, considérez que la configuration corrigée n’est pas prête tant qu’OpenAI n’a pas confirmé que la modification est terminée.

Note sur l’utilisation

Tout espace de travail ou toute organisation API activé pour Trusted Access doit être réservé à un usage interne. Réservé à un usage 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é à du trafic destiné aux clients, à des services de sécurité proposés en externe ni à une fonctionnalité de produit en aval qui fait passer des requêtes ou du contenu tiers par cet accès.

Politique de non-conservation des données (ZDR)

Le provisionnement Trusted Access n’active pas automatiquement la politique de non-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 particulier de conservation des données, confirmez que l’organisation que vous prévoyez d’utiliser est couverte par ces conditions avant que votre équipe ne lance le premier workflow.

Limites opérationnelles

Utilisez la configuration provisionnée uniquement pour des travaux défensifs autorisés.
Utilisez des systèmes que votre organisation possède ou qu’elle est explicitement autorisée à évaluer.
Gardez le premier workflow étroit et vérifiable.
Gardez des humains dans la boucle pour les constats à fort impact et la remédiation.
Utilisez l’espace de travail, la configuration API et l’accès au modèle indiqués dans vos détails d’onboarding.
N’étendez pas les capacités de Trusted Access à des clients tiers, des utilisateurs externes ou des workflows de produits en aval.

Onboarding Daybreak pour entreprises