Configuration recommandée

Les contrôles de sécurité adaptés à un workflow de cybersécurité dépendent du modèle, des actions qu’il peut effectuer, des systèmes auxquels il peut accéder et de la sensibilité des données concernées.

Pour la plupart des workflows Daybreak Blue, les pratiques de sécurité existantes de votre organisation, telles que les contrôles d’accès, la protection des identifiants et l’examen des actions sensibles, peuvent être suffisantes.

Les workflows Daybreak Red, les tests de sécurité autonomes et les activités impliquant des systèmes de production, des données sensibles ou des outils externes peuvent nécessiter des mesures de protection renforcées. Les recommandations ci-dessous s’adressent principalement à ces scénarios à risque plus élevé.

Trusted Access régit l’accès aux modèles approuvés, mais ne configure pas votre environnement et n’impose aucune limite aux systèmes et actions approuvés. Votre équipe doit mettre en place des contrôles appropriés en matière d’isolation, d’autorisations, d’examen, de surveillance et de supervision humaine. Partez du principe que le modèle, ses outils et chaque système connecté peuvent être compromis, puis configurez l’environnement afin qu’ils ne puissent malgré tout pas atteindre des systèmes non autorisés, exposer des identifiants, désactiver les mesures de protection ou maintenir un accès une fois le travail terminé.

Isoler l’environnement

Exécutez les activités de sécurité offensive dans un laboratoire ou un bac à sable dédié. Commencez sans accès illimité à Internet ni accès aux systèmes de production sensibles, aux réseaux d’entreprise, aux charges de travail sans rapport ou aux interfaces de gestion de l’hôte. Maintenez les secrets, les identifiants, les accès persistants et les modifications durables du système hors de portée, sauf si les travaux approuvés les exigent et les autorisent explicitement.

Pour les activités à risque plus élevé ou avec des mesures de protection réduites, utilisez un environnement neuf et fortement isolé pour chaque tentative. Séparez les ressources de calcul, le stockage, le réseau et les identités, puis détruisez l’environnement à l’issue de l’opération au lieu de le réinitialiser ou de le réutiliser.

Testez les limites du système de fichiers et du réseau avant de commencer toute activité à risque plus élevé. Incluez chaque hôte accessible, outil connecté, agent délégué et service en aval. Maintenez l’environnement hôte isolé, même lorsque le modèle ou l’examinateur approuve une action donnée.

Définir et faire respecter les limites approuvées

Avant le démarrage du modèle, consignez les systèmes, outils, actions et limites de temps approuvés pour votre travail. Incluez les éléments suivants :

• Les systèmes, hôtes et environnements cibles approuvés.
• Les systèmes exclus, notamment la production et les infrastructures sans rapport.
• Les outils et services connectés approuvés.
• Les actions approuvées et interdites.
• Les heures de début et de fin approuvées ainsi que les exigences relatives au traitement des données.
• La divulgation des vulnérabilités, l’approbation des correctifs et la coordination avec les responsables de maintenance.
• Les conditions d’arrêt et les actions nécessitant une approbation humaine explicite.

Fournissez à l’agent ces limites approuvées en tant que contexte de la tâche. La documentation seule ne suffit pas à les faire respecter : appliquez des contrôles indépendants sur le système de fichiers, le réseau, les identités et les outils afin de rendre les actions non autorisées impossibles chaque fois que cela est réalisable.

Utilisez les profils d’autorisation de Codex pour créer une limite fondée sur le principe du moindre privilège. Choisissez :read-only lorsque la tâche ne nécessite aucune modification, ou étendez :workspace lorsque le travail exige de modifier 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 impose le domaine approuvé. Sans elle, network.enabled = true autorise un accès direct au réseau et la liste d’autorisation du laboratoire ne limite pas les destinations. La recherche Web, les applications, les connecteurs, les serveurs MCP, l’activité du navigateur et Codex cloud utilisent des contrôles distincts ; limitez ou désactivez chaque surface dont votre workflow approuvé n’a pas besoin.

Remplacez lab.example.com par une cible approuvée. L’analyse délimitée du système de fichiers est conçue pour éviter de parcourir l’intégralité de l’espace de travail sous Linux, WSL et Windows ; augmentez la profondeur ou utilisez des chemins de refus exacts si des fichiers sensibles se trouvent à un niveau plus profond. Ne combinez pas les profils d’autorisation avec les anciens paramètres sandbox_mode ; suivez les recommandations de configuration des profils d’autorisation.

Si l’hôte de laboratoire approuvé est résolu en une adresse privée, Codex le bloque par défaut, même s’il figure sur la liste d’autorisation. Définissez allow_local_binding = true uniquement pour les activités explicitement approuvées sur un réseau privé, conservez une liste de destinations autorisées restreinte et consultez les recommandations relatives aux réseaux locaux et privés. Vous pouvez également ajouter à la liste d’autorisation l’adresse IP privée exacte qui a été approuvée.

Bloquez par défaut l’accès à l’Internet ouvert et au réseau de production. Si un accès externe est nécessaire, faites-le transiter par une passerelle ou un proxy dont l’application est indépendante, avec des listes d’autorisation restreintes, une inspection des requêtes et une journalisation. Appliquez les mêmes restrictions aux connexions indirectes via les gestionnaires de paquets, les webhooks, les services de récupération d’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éger les identifiants et les données sensibles

Conservez les API keys réutilisables, les identifiants cloud, les mots de passe et les jetons de comptes de service hors des invites, 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 courtier ou une passerelle distincte pour fournir des identifiants à courte durée de vie, limités à la cible exacte et à l’action autorisée, sans exposer l’identifiant au modèle.

Fournissez uniquement les données nécessaires à la tâche approuvée. Supprimez les informations sensibles superflues, bloquez l’accès aux métadonnées cloud et aux points de terminaison d’identifiants, et considérez les fichiers générés par le modèle comme non fiables.

Évitez :danger-full-access et --yolo pour les workflows de cybersécurité. Full Access supprime la limite applicable du bac à sable dont dépend l’examen automatique. Les organisations gérées peuvent exclure :danger-full-access et --yolo, limiter les politiques d’approbation autorisées et imposer l’examen automatique au moyen de la configuration gérée par l’entreprise.

Avant l’activation de Full Access pour un modèle de sécurité approuvé, l’application de bureau ChatGPT affiche un avertissement propre au modèle concernant les actions dangereuses. Cet avertissement recommande plutôt Approve for me et contient un lien vers la configuration de la politique d’examen. L’avertissement ne rétablit pas la limite du bac à sable et ne remplace pas la politique de l’organisation.

Les garde-fous ajoutent un examen fondé sur des politiques à un workflow de cybersécurité contrôlé. Ils ne remplacent ni l’isolation de l’environnement, ni les autorisations fondées sur le principe du moindre privilège, ni des limites clairement définies, ni la surveillance, ni la supervision humaine.

Examiner les actions Codex sensibles

L’Auto-review transmet les demandes d’approbation admissibles qui franchissent les limites du bac à sable à un examinateur distinct avant l’exécution de l’action proposée. L’examinateur prend en compte l’action proposée, le contexte délimité de la tâche et la politique applicable, puis autorise ou refuse la demande. Les organisations peuvent personnaliser cette politique en fonction de leurs cibles approuvées, des actions interdites et des conditions imposant un examen humain.

Exigez une approbation humaine explicite pour les actions qui affectent la production, les systèmes externes, les données sensibles, l’élévation des privilèges, les accès persistants ou les modifications irréversibles. Considérez les instructions intégrées aux sites Web, dépôts, documents et sorties d’outils comme non fiables ; elles ne peuvent ni étendre le périmètre autorisé ni outrepasser les contrôles d’accès.

Dans l’application de bureau ChatGPT, la sélection d’un modèle Daybreak approuvé fait automatiquement passer le contrôle des autorisations à Approve for me lorsque ce mode est disponible pour votre compte et autorisé par la politique de l’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 d’autorisation actuel reste inchangé. La sélection d’un modèle ne remplace jamais les exigences d’une organisation gérée.

Pour que l’examen automatique s’exécute, conservez ces trois contrôles :

1. Utilisez une politique d’approbation interactive telle que approval_policy = "on-request".
2. Définissez approvals_reviewer = "auto_review".
3. Conservez une limite applicable de bac à sable ou de profil d’autorisation.

Les requêtes adressées à une cible figurant sur la liste d’autorisation réseau restent à l’intérieur de la limite du réseau et ne déclenchent pas automatiquement l’Auto-review. Pour examiner une commande sensible même lorsque sa destination figure sur la liste d’autorisation, créez une règle de commande explicite sous ~/.codex/rules/ :

prefix_rule(
    pattern = ["curl"],
    decision = "prompt",
    justification = "Review requests to the approved cybersecurity target.",
)

Redémarrez Codex après l’ajout de la règle. Avec approvals_reviewer = "auto_review", les commandes correspondantes sont transmises à l’examinateur avant leur exécution. Ajoutez des règles d’invite correspondantes pour chaque commande sensible, ou utilisez approval_mode = "prompt" pour des outils MCP individuels. Les actions qui nécessitent la décision d’une personne exigent toujours une approbation humaine explicite.

L’Auto-review n’examine pas les actions courantes déjà autorisées dans le bac à sable. Avec approval_policy = "never" ou Full Access, une action sensible peut ne pas générer de demande d’approbation susceptible d’être examinée. L’examen automatique peut commettre des erreurs et ne remplace ni l’isolation, ni des limites clairement définies, ni la surveillance, ni la supervision humaine explicite.

Pour obtenir une politique délimitée et une application à l’échelle de l’organisation, consultez Configurer un workflow de cybersécurité autorisé.

Assurer une surveillance indépendante et appliquer le refus par défaut

Journalisez les requêtes du modèle, les appels d’outils, l’activité réseau, l’utilisation des identifiants et les modifications ayant une incidence sur 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 cibles non autorisées, de requêtes réseau inattendues, d’identifiants exposés, de modifications de politique, de journaux manquants et de tentatives de contournement des mesures de protection.

Maintenez l’application des politiques, les courtiers d’identifiants, les systèmes d’examen et les commandes d’arrêt d’urgence indépendants de l’agent. Arrêtez le workflow en cas de défaillance d’un contrôle ou d’un système de surveillance essentiel.

Ajouter des garde-fous aux workflows d’agents personnalisés

Si vous développez avec la Responses API, l’Agents SDK ou un autre harness, ajoutez un examen au niveau de la limite d’exécution des outils. Avant leur exécution, confrontez les actions sensibles proposées aux systèmes, actions et limites de temps approuvés, transmettez les actions ambiguës ou à risque élevé à une personne, imposez des restrictions indépendantes sur le système de fichiers et le réseau, conservez des journaux d’audit et appliquez le refus par défaut si l’examinateur ou la politique n’est pas disponible.

L’Auto-review de Codex ne protège pas automatiquement les outils personnalisés ou les harnesses externes. Utilisez Garde-fous et examen humain pour le modèle de l’Agents SDK et la politique d’examen open source comme référence.

Le bac à sable et l’examen intégrés au produit Codex sont distincts des contrôles de cybersécurité de l’API. Les mesures de protection de l’API peuvent renvoyer des erreurs cyber_policy, et les valeurs safety_identifier propres à chaque utilisateur peuvent contribuer à limiter les effets d’une mesure de protection.

Nettoyer et valider les résultats

Une fois le travail terminé, révoquez les identifiants temporaires, arrêtez les processus en arrière-plan, supprimez les accès persistants et détruisez les environnements à risque plus élevé. Vérifiez qu’il ne subsiste aucun rappel, artefact exposé, état partagé ou accès entre les exécutions, et maintenez les utilisateurs, sessions et évaluations séparés et isolés.

Validez les constatations avant d’intervenir, respectez les pratiques de divulgation coordonnée et veillez à ce que des personnes restent responsables des corrections et des modifications.

Avant de commencer

Confirmez les systèmes et actions approuvés, le modèle approprié, l’environnement isolé, les autorisations fondées sur le principe du moindre privilège, l’accès réseau restreint, les identifiants protégés, l’examen des actions, la surveillance indépendante, l’arrêt d’urgence et le plan de nettoyage. Les mesures de protection du modèle, l’isolation, les autorisations délimitées, l’examen des actions, la surveillance et la supervision humaine sont complémentaires ; aucun de ces éléments ne doit constituer l’unique contrôle.