Les mesures de sécurité à mettre en place pour un workflow de cybersécurité dépendent du modèle, des actions qu’il peut exécuter, des systèmes auxquels il a accès et de la sensibilité des données concernées.
Pour la plupart des workflows Daybreak Blue, les pratiques de sécurité déjà en place dans votre organisation peuvent suffire, notamment le contrôle des accès, la protection des identifiants et l’examen des actions sensibles.
Les workflows Daybreak Red, les tests de sécurité autonomes et les activités qui font intervenir des systèmes de production, des données sensibles ou des outils externes peuvent nécessiter des protections renforcées. Les recommandations ci-dessous s’adressent principalement à ces situations à risque accru.
Il vous incombe d’évaluer les risques propres à votre workflow et de mettre en place les mesures de sécurité appropriées. Les protections du modèle et Trusted Access ne remplacent pas les pratiques de sécurité, de surveillance et de supervision de votre organisation.
Trusted Access régit les accès autorisés aux modèles. Il ne configure pas votre environnement et ne fait pas respecter les limites fixées pour les systèmes et les actions autorisés. Votre équipe doit mettre en place les mesures appropriées en matière d’isolation, de permissions, d’examen des actions, de surveillance et de supervision humaine. Partez du principe que le modèle, ses outils et chacun des systèmes connectés peuvent être compromis. Configurez l’environnement pour que, même dans ce cas, aucun d’eux ne puisse atteindre des systèmes non autorisés, exposer des identifiants, désactiver les protections ou conserver un accès après la fin des travaux.
Isolez l’environnement
Menez vos activités de sécurité offensive dans un laboratoire dédié ou un bac à sable. Au départ, interdisez l’accès sans restriction à Internet ainsi que l’accès aux systèmes de production sensibles, aux réseaux de l’entreprise, aux charges de travail sans rapport avec la tâche et aux interfaces d’administration des hôtes. Gardez les secrets et les identifiants hors de portée et empêchez tout accès persistant ou toute modification durable des systèmes, sauf si les travaux approuvés les exigent et les autorisent expressément.
Pour les travaux à risque accru ou menés avec des protections réduites, utilisez à chaque tentative un nouvel environnement doté d’une isolation renforcée. Isolez les ressources de calcul, le stockage, le réseau et les identités. À l’issue de la tentative, détruisez l’environnement au lieu de le réinitialiser ou de le réutiliser.
Avant de commencer des travaux à risque accru, testez les limites d’accès au système de fichiers et au réseau. Incluez chaque hôte accessible, outil connecté, agent auquel une tâche est déléguée et service en aval. Maintenez l’isolation de l’environnement hôte même si le modèle ou le système de révision approuve une action particulière.
Définissez et faites respecter le périmètre autorisé
Avant de lancer le modèle, consignez les systèmes, les outils et les actions autorisés, ainsi que les limites de temps fixées pour vos travaux. Précisez les éléments suivants :
- Les systèmes cibles, les hôtes et les environnements autorisés.
- Les systèmes exclus, notamment l’infrastructure de production et celle qui est sans rapport avec les travaux.
- Les outils et les services connectés autorisés.
- Les actions autorisées et interdites.
- Les heures de début et de fin autorisées et les exigences relatives au traitement des données.
- Les modalités de divulgation des vulnérabilités, d’approbation des correctifs et de coordination avec les responsables de la maintenance.
- Les conditions d’arrêt et les actions qui nécessitent une approbation humaine explicite.
Communiquez ce périmètre à l’agent dans le contexte de la tâche. Le consigner ne suffit pas à le faire respecter. Appliquez des contrôles indépendants au système de fichiers, au réseau, aux identités et aux outils pour rendre les actions non autorisées impossibles chaque fois que c’est réalisable.
Utilisez les profils de permissions de Codex pour limiter les accès selon le principe du moindre privilège. Choisissez :read-only si la tâche ne nécessite aucune modification, ou étendez :workspace si les travaux nécessitent de modifier des fichiers dans l’espace de travail. Par exemple :
approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "cyber-lab"
[features]
network_proxy = true
[permissions.cyber-lab]
description = "Limit security testing to the approved lab and workspace."
extends = ":workspace"
[permissions.cyber-lab.filesystem]
glob_scan_max_depth = 3
[permissions.cyber-lab.filesystem.":workspace_roots"]
"**/.env*" = "deny"
"**/*.pem" = "deny"
[permissions.cyber-lab.network]
enabled = true
# Uncomment only for an approved host that resolves to a private address.
# allow_local_binding = true
[permissions.cyber-lab.network.domains]
"lab.example.com" = "allow"La fonctionnalité network_proxy limite les connexions au domaine autorisé. Sans elle, network.enabled = true autorise un accès direct au réseau et la liste d’autorisation du laboratoire ne restreint pas les destinations. La recherche web, les applications, les connecteurs, les serveurs MCP, l’activité du navigateur et Codex Cloud disposent de contrôles distincts. Restreignez ou désactivez chacun de ces moyens d’accès si le workflow autorisé n’en a pas besoin.
Remplacez lab.example.com par une cible autorisée. La limite de profondeur évite de parcourir tout l’espace de travail sur Linux, WSL et Windows. Si des fichiers sensibles se trouvent plus bas dans l’arborescence, augmentez la profondeur ou interdisez l’accès à leurs chemins exacts. Ne combinez pas les profils de permissions avec les anciens paramètres sandbox_mode. Suivez les instructions de configuration des profils de permissions.
Si le nom de l’hôte autorisé du laboratoire se résout en une adresse privée, Codex bloque cet hôte par défaut, même s’il figure dans la liste d’autorisation. Définissez allow_local_binding = true uniquement pour des travaux expressément autorisés sur un réseau privé. Limitez la liste aux destinations strictement nécessaires et consultez les recommandations relatives aux réseaux locaux et privés. Vous pouvez également ajouter l’adresse IP privée exacte à la liste d’autorisation si cette adresse est approuvée.
Bloquez par défaut l’accès à l’Internet public et aux réseaux de production. Si un accès externe est nécessaire, faites-le passer par une passerelle ou un proxy qui applique les restrictions indépendamment de l’agent, limite les destinations à une liste restreinte, inspecte les requêtes et les journalise. Appliquez les mêmes restrictions aux connexions indirectes via les gestionnaires de paquets, les webhooks, les services de récupération de contenu par URL, les redirections, les API cloud et les outils connectés. Chargez les dépendances avant l’exécution ou utilisez des dépendances approuvées par un administrateur.
Protégez les identifiants et les données sensibles
Gardez les clés API réutilisables, les identifiants cloud, les mots de passe et les jetons de comptes de service hors des prompts, des dépôts, des variables d’environnement, des systèmes de fichiers partagés et des journaux accessibles au modèle. Lorsqu’une authentification est nécessaire, utilisez un service intermédiaire ou une passerelle distincte pour fournir des identifiants de courte durée, limités à la cible précise et à l’action autorisée, sans les exposer au modèle.
Fournissez uniquement les données nécessaires à la tâche autorisée. Supprimez les informations sensibles superflues, bloquez l’accès aux points de terminaison qui fournissent des métadonnées cloud ou des identifiants et traitez les fichiers générés par le modèle comme non fiables.
Évitez :danger-full-access et --yolo dans les workflows de cybersécurité. Le mode Accès complet supprime les restrictions du bac à sable dont dépend la Révision automatique. Les organisations qui gèrent la configuration de manière centralisée peuvent exclure :danger-full-access et --yolo, limiter les politiques d’approbation autorisées et imposer la Révision automatique au moyen de la configuration gérée par l’entreprise.
Avant d’activer le mode Accès complet pour un modèle de sécurité approuvé, l’application de bureau ChatGPT affiche un avertissement propre à ce modèle concernant les actions dangereuses. Cet avertissement recommande de choisir Approuver pour moi et renvoie aux instructions de configuration de la politique de révision. L’avertissement ne rétablit pas les restrictions du bac à sable et ne prévaut pas sur la politique de l’organisation.
Utilisez la Révision automatique en complément de l’isolation de l’environnement, des permissions fondées sur le moindre privilège, de la documentation du périmètre de l’intervention, de la surveillance et de la supervision humaine.
Examinez les actions sensibles de Codex
La Révision automatique transmet les demandes d’approbation admissibles à un système de révision distinct avant l’exécution de l’action proposée. Ce système examine l’action, le contexte de la tâche et la politique applicable. Les organisations peuvent remplacer la politique de révision par une politique qui précise les cibles autorisées, les actions interdites et les approbations humaines requises.
Exigez une approbation humaine explicite pour les actions qui touchent à la production, aux systèmes externes ou aux données sensibles, ainsi que pour celles qui impliquent une élévation de privilèges, un accès persistant ou des modifications irréversibles. Traitez comme non fiables les instructions intégrées aux sites web, aux dépôts, aux documents et aux sorties des outils. Elles ne peuvent ni élargir le périmètre autorisé ni prévaloir sur les contrôles d’accès.
Dans l’application de bureau ChatGPT, lorsque vous sélectionnez un modèle Daybreak approuvé, le réglage des permissions passe automatiquement à Approuver pour moi si ce mode est disponible pour votre compte et autorisé par la politique de votre organisation. Cela s’applique également lorsque vous utilisez la commande /model de l’application de bureau. Si ce mode n’est pas disponible, le mode de permissions actuel reste en vigueur. La sélection d’un modèle ne prévaut jamais sur les exigences imposées par l’organisation.
Pour que la Révision automatique fonctionne, maintenez les trois contrôles suivants :
- Utilisez une politique d’approbation interactive telle que
approval_policy = "on-request". - Définissez
approvals_reviewer = "auto_review". - Maintenez des restrictions effectives au moyen d’un bac à sable ou d’un profil de permissions.
Les requêtes vers une cible figurant dans la liste d’autorisation du réseau restent dans le périmètre réseau et ne déclenchent pas à elles seules la Révision automatique. Pour soumettre une commande sensible à un examen même si sa destination figure dans cette liste, créez une règle de commande explicite dans ~/.codex/rules/ :
prefix_rule(
pattern = ["curl"],
decision = "prompt",
justification = "Review requests to the approved cybersecurity target.",
)Redémarrez Codex après avoir ajouté la règle. Avec approvals_reviewer = "auto_review", le système de révision examine les commandes qui correspondent à la règle avant leur exécution. Ajoutez une règle de demande d’approbation pour chaque commande sensible, ou utilisez approval_mode = "prompt" pour certains outils MCP. Les actions qui nécessitent une décision humaine doivent toujours faire l’objet d’une approbation humaine explicite.
La Révision automatique évalue les actions qui nécessitent une approbation. Avec approval_policy = "never" ou le mode Accès complet, une action sensible peut s’exécuter sans demande d’approbation. Maintenez des contrôles d’accès et une surveillance indépendants de l’agent pendant toute l’intervention.
Pour définir une politique adaptée au périmètre des travaux et la faire appliquer dans toute l’organisation, consultez la section Configurez un workflow de cybersécurité autorisé.
Assurez une surveillance indépendante et bloquez l’exécution en cas de défaillance
Journalisez les requêtes du modèle, les appels d’outils, l’activité réseau, l’utilisation des identifiants et les modifications qui touchent à la sécurité. Conservez les journaux et les systèmes de surveillance en dehors de l’environnement contrôlé par le modèle. Déclenchez des alertes en cas de cible non autorisée, de requête réseau inattendue, d’exposition d’identifiants, de modification de la politique, de journaux manquants ou de tentative de contournement des protections.
Veillez à ce que l’application des politiques, les services intermédiaires qui fournissent les identifiants, les systèmes de révision et les dispositifs d’arrêt d’urgence restent indépendants de l’agent. Arrêtez le workflow en cas de défaillance d’un contrôle essentiel ou d’un système de surveillance.
Ajoutez des garde-fous aux workflows d’agents personnalisés
Si vous développez avec l’API Responses, le SDK Agents ou un autre harnais d’exécution, prévoyez un examen juste avant que les outils exécutent une action. Pour chaque action sensible proposée, vérifiez avant l’exécution que le système visé, l’action et l’horaire respectent le périmètre autorisé. Soumettez les actions ambiguës ou à haut risque à une personne, appliquez des restrictions indépendantes au système de fichiers et au réseau, conservez des journaux d’audit et bloquez l’exécution si le système de révision ou la politique est indisponible.
La Révision automatique de Codex ne protège pas automatiquement les outils personnalisés ni les harnais d’exécution externes. Consultez le guide Garde-fous et examen humain pour mettre en œuvre cette approche avec le SDK Agents et utilisez la politique de révision open source comme référence.
Le bac à sable et la révision intégrés à Codex sont distincts des contrôles de cybersécurité de l’API. Les protections de l’API peuvent renvoyer des erreurs cyber_policy. L’attribution d’une valeur safety_identifier à chaque utilisateur peut aider à limiter les répercussions d’une mesure de protection.
Nettoyez l’environnement et validez les résultats
Une fois les travaux terminés, révoquez les identifiants temporaires, arrêtez les processus en arrière-plan, supprimez les accès persistants et détruisez les environnements à risque accru. Vérifiez qu’il ne subsiste aucun rappel, aucun artefact exposé, aucun état partagé ni aucun accès d’une exécution à l’autre. Maintenez l’isolation entre les utilisateurs, entre les sessions et entre les évaluations.
Validez les constats avant d’agir, suivez les pratiques de divulgation coordonnée et veillez à ce que des personnes restent responsables des mesures correctives et des modifications.
Avant de commencer
Vérifiez le périmètre des systèmes et des actions autorisés, le choix du modèle, l’isolation de l’environnement, l’application du principe du moindre privilège, les restrictions d’accès au réseau et la protection des identifiants. Vérifiez également que l’examen des actions, la surveillance indépendante, l’arrêt d’urgence et le plan de nettoyage sont en place. Les protections du modèle, l’isolation, les permissions limitées au périmètre autorisé, l’examen des actions, la surveillance et la supervision humaine se complètent. Aucun de ces contrôles ne doit être utilisé seul.