Guide pratique de la sécurité de Codex

Utilisez cette fiche si les employés doivent se connecter à Codex via l’espace de travail ChatGPT de l’entreprise et si les comptes ChatGPT personnels et l’authentification par clé API sont interdits sur les postes gérés.

Résultat visé

Sur les appareils gérés par l’entreprise, Codex accepte uniquement les connexions via ChatGPT à l’espace de travail ChatGPT de l’entreprise.

Prérequis

• L’UUID de l’espace de travail ChatGPT Enterprise approuvé.

• Un moyen de distribuer la configuration gérée de Codex aux postes concernés.

• La décision d’interdire l’authentification par clé API sur les postes gérés.

Configuration

1. Consignez l’UUID de l’espace de travail approuvé dans votre dépôt de configuration interne.

2. Ajoutez les exigences d’authentification obligatoires au fichier requirements.toml local :

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

   La première clé autorise uniquement l’authentification via ChatGPT. La seconde limite la connexion à l’espace de travail approuvé. Remplacez l’UUID de l’exemple par celui de votre espace de travail. Consultez la référence des exigences.

3. Déployez ces exigences via le fichier requirements.toml local ou via les exigences MDM pour macOS, en utilisant les chemins indiqués dans la section Où placer la configuration. Ces exigences s’appliquent avant le chargement des identifiants et la récupération de la politique cloud. Codex les ignore lorsqu’elles figurent dans les exigences gérées dans le cloud. Empêchez les utilisateurs de modifier le fichier et son répertoire parent. Les valeurs par défaut de l’ancien fichier managed_config.toml n’imposent pas cette restriction.

4. Pendant la phase pilote, déconnectez les utilisateurs ou supprimez les sessions Codex personnelles enregistrées précédemment. Ne supposez pas qu’une nouvelle politique invalide rétroactivement une session existante.

5. Associez la restriction de connexion aux rôles de l’espace de travail et aux droits d’accès des groupes. L’authentification détermine l’identité qui se connecte. Le contrôle d’accès basé sur les rôles (RBAC) détermine les fonctionnalités de Codex que cette identité peut utiliser. Consultez la page Authentification.

Vérification

• Déconnectez-vous de Codex.

• Essayez de vous connecter avec un compte ChatGPT personnel. Résultat attendu : la connexion à l’espace de travail personnel est refusée.

• Essayez de vous connecter à Codex avec une clé API. Résultat attendu : la connexion par clé API est refusée.

• Connectez-vous à l’espace de travail approuvé avec le compte professionnel. Résultat attendu : la connexion aboutit.

• Redémarrez l’application de bureau, la CLI et l’extension IDE, puis répétez les vérifications.

Retour arrière

Rétablissez les exigences d’authentification locales précédentes et redéployez les fichiers de configuration vérifiés.

Limites

Ce contrôle s’applique aux clients Codex gérés sur les postes gérés. Associez-le à des contrôles applicatifs sur les postes et à une politique réseau si l’exigence est « aucune utilisation personnelle de Codex depuis les équipements de l’entreprise ».

Utilisez cette fiche si les développeurs ont besoin d’un accès en lecture seule ou limité à l’espace de travail et que vous souhaitez les empêcher de sélectionner Accès complet ou de contourner les approbations et le bac à sable avec --yolo.

Résultat visé

Les utilisateurs peuvent sélectionner uniquement les profils approuvés qui donnent accès en lecture seule ou limitent l’accès à l’espace de travail. Ils ne peuvent sélectionner ni danger-full-access, ni approval_policy = "never", ni --yolo.

Configuration

1. Définissez un profil approuvé pour l’espace de travail :

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. Imposez les profils et les politiques d’approbation autorisés :

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"
   
   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

   La liste est exhaustive. Tout profil absent de la liste ou défini sur false est refusé, y compris les profils ajoutés dans les versions futures. Consultez la référence de configuration.

3. Pour les anciens clients qui utilisent encore sandbox_mode, utilisez les paramètres suivants :

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. Distribuez ces paramètres sous forme d’exigences imposées par l’administrateur. Un fichier de configuration modifiable par l’utilisateur ne les impose pas.

5. Si vous décidez ensuite d’autoriser la révision automatique, ajoutez-la explicitement après l’avoir testée. La révision automatique change qui examine les demandes de dépassement des limites. Elle ne rétablit pas une limite supprimée. Consultez la page Révision automatique.

Vérification

• Ouvrez le sélecteur d’autorisations. Résultat attendu : l’option Accès complet est indisponible ou sa sélection est refusée.

• Lancez Codex avec --dangerously-bypass-approvals-and-sandbox. Résultat attendu : Codex refuse de démarrer ou impose un profil compatible.

• Lancez Codex avec --sandbox danger-full-access --ask-for-approval never. Résultat attendu : le démarrage est refusé.

• Exécutez une tâche habituelle dans l’espace de travail. Résultat attendu : la tâche aboutit et tout dépassement des limites nécessite toujours une approbation.

Retour arrière

Rétablissez l’ensemble d’exigences précédent. Maintenez le blocage de l’accès sans restriction, sauf si une exception a été approuvée séparément.

Limites

Ce contrôle régit les autorisations de Codex à l’exécution. Il ne retire pas ses privilèges à un compte privilégié du système d’exploitation.

Utilisez cette fiche si votre organisation doit déterminer quels serveurs MCP Codex peut utiliser et imposer la liste des serveurs approuvés.

L’autorisation et la configuration d’un serveur sont deux étapes distinctes. Une entrée dans la liste autorise un serveur correspondant sans créer sa configuration. Configurez le serveur séparément avec le nom et l’identité correspondants, ainsi que le mécanisme d’authentification requis.

Résultat visé

Codex active uniquement les serveurs MCP dont le nom et l’identité configurés correspondent à la liste approuvée par l’entreprise.

Configuration

1. Recensez, pour chaque serveur approuvé, son responsable, sa fonction, son mode de transport, son exécutable ou son URL exacte, son mécanisme d’authentification, la classification de ses données et ses outils capables d’écrire des données.

2. Commencez par tout interdire. Une table gérée vide désactive tous les serveurs MCP :

   [mcp_servers]

3. Ajoutez les serveurs HTTP approuvés en indiquant leur URL exacte :

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. Ajoutez les serveurs stdio approuvés en indiquant leur exécutable et leurs arguments positionnels :

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

   La règle de correspondance structurée vérifie l’exécutable, le nombre d’arguments et leur ordre. Elle n’impose aucune contrainte à cwd, env ou env_vars. Avant d’approuver un serveur stdio, assurez-vous de maîtriser l’ensemble de son contexte de lancement. Protégez son exécutable et ses dépendances et empêchez toute configuration utilisateur ou projet non fiable de fournir un répertoire de travail ou un environnement susceptible de modifier son comportement. Si vous ne pouvez pas imposer cette limite indépendamment, n’approuvez pas le serveur stdio et utilisez un serveur HTTP qui a fait l’objet d’un examen.

5. Ajoutez séparément les identités MCP fournies par des plugins sous plugins.<plugin>.mcp_servers.<server>.

6. Conservez la liste approuvée dans un dépôt de configuration dont les modifications sont examinées et déployez-la via les exigences imposées par l’administrateur.

Le client n’active un serveur que si son nom et son identité correspondent tous deux à une entrée approuvée. Consultez la configuration gérée.

Vérification

• Configurez le serveur approuvé en reprenant exactement les paramètres prévus. Résultat attendu : le serveur démarre.

• Modifiez un caractère de l’URL. Résultat attendu : le serveur est désactivé.

• Modifiez le nombre ou l’ordre des arguments stdio, ou fournissez un argument qui ne respecte pas les règles configurées. Résultat attendu : le serveur est désactivé. Les valeurs qui respectent toujours un préfixe autorisé restent permises.

• Dans un projet de test fiable que vous pourrez supprimer, essayez de remplacer cwd, env et env_vars par des valeurs inoffensives, sans modifier l’exécutable ni les arguments correspondants. La vérification de l’identité à elle seule ne rejette pas ces substitutions. Vérifiez que votre contrôle indépendant du contexte de lancement refuse les substitutions dangereuses ou que le serveur stdio reste exclu de la liste des serveurs approuvés. N’utilisez pas de véritable charge d’injection.

• Ajoutez un nom non approuvé. Résultat attendu : le serveur est désactivé.

• Testez un serveur fourni par un plugin. Résultat attendu : le serveur fonctionne uniquement avec l’identité approuvée.

Retour arrière

Supprimez l’entrée que vous venez d’ajouter. Pour interrompre immédiatement toute utilisation de MCP, déployez une table mcp_servers vide.

Limites

L’inscription d’une identité dans la liste des identités autorisées ne garantit pas que les outils, les données en amont, les identifiants ou l’environnement de lancement du serveur sont sûrs. Les processus MCP stdio locaux s’exécutent en dehors du bac à sable des commandes locales. Vérifier l’exécutable et ses arguments ne limite pas les accès du serveur et n’empêche pas le chargement de code via l’environnement. Examinez séparément l’ensemble du contexte de lancement et les autorisations du serveur. Consultez les exigences relatives aux identités MCP.

Utilisez cette fiche si votre équipe de sécurité doit comprendre ce que fait Codex sur les postes et sur le réseau. Elle permet de réunir les événements d’exécution et d’utilisation des outils, les décisions d’approbation, les enregistrements d’audit de l’espace de travail et les journaux réseau pour mener des investigations.

Résultat visé

Les équipes de sécurité peuvent mettre en relation les exécutions de Codex, les décisions concernant les outils, les approbations, les enregistrements d’audit de l’espace de travail et le trafic réseau sortant réellement observé, sans dépendre du récit qu’en fait le modèle.

Quatre sources à exploiter

1. OpenTelemetry dans Codex : événements liés aux exécutions, aux API, au modèle, au bac à sable, aux approbations et aux outils.

2. Hooks gérés du cycle de vie : enregistrements produits sur le poste lors de l’utilisation des outils et des demandes d’autorisation.

3. Journaux du proxy ou de la passerelle réseau : destinations DNS/HTTP visées et résultats des tentatives de connexion.

4. API de conformité : enregistrements d’audit et d’investigation à l’échelle de l’espace de travail.

Aucune de ces sources ne couvre à elle seule toute la surveillance réseau.

Configuration

1. Envoyez les journaux OpenTelemetry de Codex à votre collecteur en masquant le contenu brut des prompts :

   [otel]
   environment = "enterprise"
   log_user_prompt = false
   
   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

   Avant de démarrer le client, fournissez OTLP_TOKEN au processus Codex via votre gestionnaire de secrets approuvé ou via l’environnement du processus. N’incluez pas ce jeton dans les fichiers TOML déployés ni dans le dépôt de code.

   Codex peut émettre des événements de début de conversation, des requêtes API, des événements de streaming, des métadonnées de prompts, des décisions concernant les outils et des résultats d’outils. Consultez la configuration avancée.

2. Déployez OTel en dehors de la configuration locale des projets. Les fichiers .codex/config.toml des projets ne peuvent pas modifier le routage de la télémétrie.

3. Ajoutez des hooks gérés du cycle de vie pour SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop et SessionEnd.

4. Installez les scripts des hooks dans un répertoire géré par l’administrateur et définissez allow_managed_hooks_only = true si vous souhaitez ignorer les hooks des utilisateurs, des projets et des plugins.

5. Faites passer le trafic des commandes exécutées dans le bac à sable par un proxy disposant de ses propres journaux. OTel enregistre l’exécution de l’outil. Le proxy enregistre la destination à laquelle le sous-processus a tenté de se connecter.

6. Configurez séparément la télémétrie pour la recherche web, les applications, les connecteurs, les serveurs MCP, l’activité du navigateur et Codex Cloud. Les règles du proxy des commandes locales ne les couvrent pas automatiquement.

7. Transmettez en continu au SIEM les enregistrements pris en charge par l’API de conformité et appliquez vos propres règles de conservation, y compris en cas d’obligation de conservation à des fins juridiques. Consultez la page API de conformité et événements d’audit.

8. Mettez en relation le compte utilisateur ou de service, l’hôte ou le runner, l’ID de conversation, le modèle, la version du client, le profil d’autorisations, la décision d’approbation, la destination et le nom de l’outil.

Vérification

Dans une session de test contrôlée, effectuez les opérations suivantes :

• Lisez un fichier autorisé.

• Essayez de lire un fichier dont la lecture est bloquée.

• Exécutez une commande autorisée.

• Tentez d’envoyer une requête sortante qui doit être bloquée.

• Demandez une approbation et faites-la refuser.

• Terminez la session.

Résultats attendus pour chaque source :

• OTel affiche les événements d’exécution et d’utilisation des outils.

• Les hooks retracent le cycle de vie de la session.

• Les journaux du proxy indiquent les destinations autorisées et bloquées.

• Le système de collecte reçoit les enregistrements de conformité pris en charge.

• Le SIEM associe ces enregistrements à l’utilisateur ou à la charge de travail.

Retour arrière

Désactivez l’exportateur et les hooks en rétablissant la configuration précédente. Conservez la journalisation indépendante du proxy lors du retour arrière de la télémétrie.

Limites

Ne garantissez pas que la télémétrie de Codex capture chaque argument de commande, chaque octet de sortie ou chaque paquet réseau. Documentez ce que couvre chaque couche.

Utilisez cette fiche si Codex ne doit pas accéder à Internet ou doit uniquement joindre des destinations approuvées. Choisissez la procédure locale ou cloud qui correspond à votre environnement. Leurs politiques ont des périmètres distincts.

Résultat visé

Selon la configuration choisie, Codex ne peut pas accéder à Internet ou peut uniquement joindre les domaines approuvés. Les environnements Codex Cloud (ancienne version) peuvent également restreindre les méthodes HTTP.

Configuration de la version actuelle de Codex Cloud

1. Créez des environnements distincts selon le niveau de confiance, par exemple no-internet-review, approved-dependencies-build et cyber-lab.

2. Dans la configuration de l’environnement, désactivez Autoriser tout accès à Internet public et Autoriser les domaines des gestionnaires de paquets.

3. Si un accès à Internet public est nécessaire, ajoutez les noms d’hôtes exacts approuvés sous Domaines autorisés supplémentaires. Supprimez les secrets HTTP qui autorisent des destinations publiques non approuvées. Pour bloquer l’accès à Internet public en dehors du VPN, laissez cette liste vide et supprimez les secrets HTTP qui autorisent des destinations publiques.

4. Enregistrez la configuration et testez les services pendant la phase de préparation. Publiez ou republiez l’environnement, puis testez l’accès aux destinations approuvées et non approuvées dans une nouvelle tâche. Examinez les scripts de préparation séparément. Fixez les versions des dépendances, privilégiez les miroirs approuvés et évitez de télécharger des exécutables qui n’ont pas été examinés.

Consultez la section Se connecter aux services. Les paramètres actuels de Codex Cloud ne proposent pas le sélecteur de méthodes HTTP de l’ancienne version.

Configuration de Codex Cloud (ancienne version)

1. Laissez l’accès de l’agent à Internet désactivé s’il est inutile. Par défaut, l’ancienne version de Codex Cloud bloque Internet pendant la phase d’exécution de l’agent. Les scripts de préparation disposent toujours d’un accès à Internet pour installer les dépendances.

2. Si l’agent a besoin d’un accès, activez-le avec une liste restreinte de domaines autorisés. Commencez par Aucun, puis ajoutez les domaines exacts.

3. Pour les workflows limités au téléchargement, autorisez uniquement GET, HEAD et OPTIONS. Cela bloque POST, PUT, PATCH, DELETE et les autres méthodes. Examinez séparément les scripts de préparation, car la restriction appliquée pendant l’exécution de l’agent ne régit pas leur accès à Internet.

Consultez la page Accès de l’agent à Internet dans l’ancienne version. Ces préréglages et contrôles des méthodes HTTP s’appliquent uniquement à l’ancienne version de Codex Cloud.

Configuration de Codex en local

1. Dans le fichier requirements.toml géré par l’administrateur, définissez et sélectionnez le profil réseau approuvé, puis limitez les utilisateurs à ce profil :

   default_permissions = "corp-build"
   
   [allowed_permission_profiles]
   "corp-build" = true
   
   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"
   
   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false
   
   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. Déployez l’ensemble d’exigences vérifié en suivant les instructions de configuration gérée. Définir un profil nommé ne suffit pas à l’activer. Le paramètre default_permissions le sélectionne et la liste des profils autorisés empêche d’en choisir un autre.

3. Activez le proxy géré par l’administrateur dans le même ensemble d’exigences pour imposer les restrictions de domaines et empêcher les utilisateurs d’élargir la liste. Déployez ensemble le proxy et le profil qui autorise le réseau. Sans proxy actif, ce profil accorde un accès direct au réseau sans appliquer ses règles de domaines :

   Attention : [experimental_network] est expérimental et peut évoluer. Avant de généraliser le déploiement, validez son fonctionnement sur chaque version du client local et chaque système d’exploitation pris en charge. La prise en charge sur Windows est limitée. N’appliquez cette politique aux utilisateurs de Windows qu’après avoir vérifié que les restrictions sont effectives dans votre environnement.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true
   
   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. Laissez la mise en écoute sur des ports locaux désactivée, sauf si le workflow en a besoin. Configurez séparément l’accès aux cibles du réseau privé. Autoriser un domaine n’autorise pas à lui seul ses adresses privées. Consultez les exigences d’accès au réseau.

5. Configurez séparément la recherche web, les applications, les serveurs MCP, l’activité du navigateur et Codex Cloud. Les règles du bac à sable local ne les contrôlent pas.

Vérification

• Envoyez une requête à un domaine approuvé et vérifiez qu’elle aboutit.

• Envoyez une requête à un domaine non approuvé et vérifiez qu’elle est bloquée.

• Envoyez des requêtes à localhost, à une adresse IP privée et à un point de terminaison de métadonnées cloud. Vérifiez que chaque requête est bloquée, sauf autorisation explicite.

• Dans Codex Cloud (ancienne version), tentez d’envoyer une requête POST à un domaine autorisé. Vérifiez qu’elle est bloquée lorsque seuls GET, HEAD et OPTIONS sont autorisés.

• Vérifiez que les journaux du proxy ou de la passerelle contiennent des entrées pour les requêtes autorisées comme pour les requêtes refusées.

Retour arrière

Désactivez à nouveau l’accès à Internet dans l’environnement ou rétablissez la politique de domaines précédente. Évitez de revenir à un accès Internet sans restriction.

Limites

Une autorisation de sortir entièrement du bac à sable peut permettre de contourner le proxy des commandes locales. Avant de vous fier à la restriction, testez séparément les commandes ordinaires exécutées dans le bac à sable et celles dont l’exécution hors du bac à sable a été approuvée.

Un domaine autorisé peut néanmoins héberger du contenu servant à une attaque par injection de prompt, des paquets compromis ou une documentation dangereuse.

Utilisez cette fiche si Codex doit accéder aux répertoires de code source approuvés, mais que les secrets, les fichiers .env, les clés SSH et les dépôts sans rapport avec la tâche doivent rester hors de portée. Elle explique comment restreindre l’accès aux fichiers et limiter les variables d’environnement contenant des identifiants que reçoivent les commandes lancées.

Résultat visé

Codex peut travailler dans les répertoires de code source approuvés sans pouvoir lire les fichiers qui contiennent habituellement des secrets ni hériter d’un vaste ensemble de variables d’environnement contenant des identifiants.

Configuration

1. Définissez dans un profil d’espace de travail les motifs de chemins dont la lecture est interdite :

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"
   
   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6
   
   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. Interdisez également les chemins exacts des répertoires d’identifiants connus, des clés de signature, de la configuration de production et des dépôts voisins.

3. Dans le fichier système /etc/codex/config.toml ou le fichier utilisateur ~/.codex/config.toml, limitez les variables d’environnement transmises aux commandes lancées :

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false
   
   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

   Il s’agit d’un paramètre par défaut modifiable par l’utilisateur. Il limite les variables héritées sans imposer d’exigence ni empêcher l’accès aux fichiers d’identifiants, aux gestionnaires d’identifiants, au contenu chargé au démarrage du shell ou à d’autres identités. Consultez la configuration avancée.

4. Dans le fichier requirements.toml géré par l’administrateur, sélectionnez le profil restreint et autorisez uniquement ce profil. Les profils intégrés n’héritent pas de ses interdictions de lecture des fichiers secrets :

   default_permissions = "corp-workspace"
   
   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Choisissez le mode de transmission des identifiants pour votre environnement cloud :

   • Dans la version actuelle de Codex Cloud, utilisez les secrets HTTP pour les identifiants envoyés à un service HTTPS autorisé. Les programmes reçoivent une valeur de substitution. Pendant la préparation et les tâches, le proxy la remplace par la valeur réelle pour les destinations approuvées sur le port 443. L’identifiant brut n’est placé dans aucun processus ni fichier local. Les programmes ont accès aux variables d’environnement qui leur sont fournies directement. Consultez la section Variables d’environnement et secrets réseau.
   • Dans Codex Cloud (ancienne version), les secrets permettent l’authentification pendant la préparation, puis sont supprimés avant l’exécution de l’agent. Les variables d’environnement restent disponibles pendant toute la discussion. Consultez la page Environnements cloud de l’ancienne version.

6. Si l’agent doit s’authentifier, utilisez un service indépendant qui lui délivre des identifiants de courte durée valables uniquement pour la cible et l’action précises. Consultez la configuration recommandée.

Vérification

Créez des fichiers témoins inoffensifs :

.env.test
test-key.pem
.aws/credentials
.kube/config

Demandez ensuite à Codex d’effectuer les opérations suivantes :

• Lire un fichier ordinaire.

• Lire chaque fichier témoin.

• Rechercher des secrets de manière récursive.

• Afficher l’environnement de ses commandes.

• Lire un dépôt voisin.

Résultat attendu : la lecture du fichier ordinaire aboutit. Les fichiers interdits et les dépôts voisins restent inaccessibles et les variables exclues sont absentes de l’environnement des commandes.

Retour arrière

Rétablissez le profil précédent. Pendant que vous recherchez la cause des échecs de workflows, conservez les interdictions de lecture des fichiers dont vous savez qu’ils contiennent des secrets.

Limites

Les interdictions d’accès au système de fichiers ne suppriment pas les secrets déjà collés dans des prompts, enregistrés dans du code source lisible, renvoyés par des connecteurs ou écrits dans des journaux accessibles au modèle.

Utilisez cette fiche lorsque des actions telles que git push, les déploiements, les migrations de bases de données et les commandes de CLI cloud nécessitent une approbation préalable. Déterminez quelles commandes doivent faire l’objet d’une demande d’approbation et lesquelles doivent être interdites, puis configurez les règles correspondantes.

Résultat visé

Les commandes sensibles attendent systématiquement une approbation ou sont interdites, même si le modèle les juge appropriées.

Configuration

1. Déterminez quelles commandes nécessitent une demande d’approbation et lesquelles sont interdites.

2. Ajoutez des règles de commande imposées par l’administrateur :

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

   Les règles définies dans les exigences peuvent imposer une demande d’approbation ou interdire une commande. Elles ne peuvent pas l’autoriser. Consultez la configuration gérée.

3. Pour les profils à haut risque, ajoutez au même tableau prefix_rules une entrée pour les commandes qui passent par un shell, si celui-ci risque de masquer une commande sensible :

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

   Cette entrée génère de nombreuses demandes d’approbation. Réservez-la aux cas où elle est nécessaire.

4. Si une personne doit approuver les commandes, imposez les paramètres suivants :

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

   La révision automatique change qui examine la demande. Elle n’offre pas de garantie de sécurité déterministe. Consultez la page Révision automatique.

5. Transmettez à votre chaîne de traitement des événements de sécurité les événements PermissionRequest, les décisions concernant les outils et les résultats des outils.

Vérification

• Exécutez git status. Résultat attendu : aucune demande d’approbation ne s’affiche.

• Exécutez git push. Résultat attendu : une demande d’approbation s’affiche.

• Exécutez terraform apply. Résultat attendu : une demande d’approbation s’affiche.

• Exécutez kubectl delete pod test. Résultat attendu : une demande d’approbation s’affiche.

• Exécutez rm -rf test-directory. Résultat attendu : la commande est interdite.

• Refusez une demande d’approbation. Résultat attendu : la commande ne s’exécute pas et le refus est consigné.

• Redémarrez le client et répétez les vérifications. Résultat attendu : la règle reste en vigueur.

Retour arrière

Rétablissez l’ensemble d’exigences précédent. Si un motif correspond à trop de commandes, affinez les éléments qu’il recherche au lieu de supprimer la règle pour toute une catégorie de commandes sensibles.

Limites

Les règles de préfixe ne constituent pas un moteur complet d’application des politiques du système d’exploitation. Associez-les au bac à sable, à des comptes système dotés des privilèges minimaux, à des restrictions réseau, à la gestion des identités et des accès (IAM) dans le cloud, à la protection des branches, aux approbations de déploiement et aux autorisations des bases de données.

Fiches de configuration utilisées : Restreindre les profils d’autorisations et l’Accès complet ; Protéger les secrets et les dépôts sans rapport avec la tâche ; Exiger une approbation pour les commandes sensibles.

Les développeurs disposent d’un accès légitime à la production. Vous souhaitez qu’ils puissent utiliser Codex pour le développement sans que Codex apporte à la production des modifications qui n’ont pas été examinées.

• Définissez un profil approuvé pour l’espace de travail et imposez les profils et les politiques d’approbation autorisés. Distribuez ces paramètres sous forme d’exigences imposées par l’administrateur pour empêcher les utilisateurs de les remplacer.

• Exécutez Codex sous une identité distincte dotée de privilèges réduits ou dans un environnement qui ne peut ni accéder à des identifiants permettant l’écriture en production ni en obtenir. Les développeurs peuvent conserver leur accès à la production via un workflow autorisé distinct.

• Limitez les variables d’environnement transmises aux commandes lancées. Si l’agent doit s’authentifier, utilisez un service indépendant qui lui délivre des identifiants de courte durée valables uniquement pour la cible et l’action précises.

• Déterminez quelles commandes nécessitent une demande d’approbation et lesquelles sont interdites. Exigez une approbation humaine pour certaines commandes à fort impact, comme git push, terraform apply, les modifications de Kubernetes et les migrations de bases de données. Interdisez les commandes qui ne doivent jamais être exécutées.

• Maintenez les contrôles IAM de production, la protection des branches et les approbations de déploiement indépendamment de Codex.

Restriction des profils d’autorisations et approbation humaine obligatoire

Dans le fichier requirements.toml géré par l’administrateur, autorisez les profils intégrés d’espace de travail et de lecture seule et exigez que l’utilisateur examine les actions soumises à approbation :

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Le profil d’espace de travail permet de travailler dans cet espace, à l’intérieur de son bac à sable. Le profil en lecture seule convient aux tâches qui nécessitent moins de droits. Les profils d’accès complet ne figurent pas dans la liste des profils autorisés.

Définissez approval_policy = "on-request" dans la configuration du client si celui-ci nécessite un choix compatible explicite. Le paramètre on-request permet d’afficher une demande d’approbation lorsqu’elle est nécessaire, sans en demander une pour chaque commande. Ajoutez des règles explicites pour les actions à examiner et conservez un mécanisme indépendant d’autorisation pour la production.

Les listes gérées de profils autorisés nécessitent Codex 0.138.0 ou une version ultérieure. Pour les clients plus anciens, utilisez et testez les exigences documentées pour les anciens modes du bac à sable.

Redémarrez chaque client pilote, vérifiez que le profil approuvé fonctionne et qu’un profil d’accès complet non autorisé est refusé.

Séparation de l’identité de Codex et des identifiants de production

Dans votre système de gestion des appareils ou de provisionnement des environnements de développement, créez un utilisateur, un conteneur ou un hôte de développement dédié à Codex. Accordez-lui uniquement l’accès au code source et aux services de développement nécessaires. Ne montez pas les fichiers d’identifiants de production du développeur, ses gestionnaires de jetons ou ses trousseaux de clés dans cet environnement. Empêchez cette identité d’obtenir des rôles autorisant l’écriture en production.

Si l’agent a besoin d’accéder à un service, configurez le service de délivrance d’identifiants de votre organisation pour qu’il fournisse des identifiants de courte durée limités à la ressource de développement et à l’action concernées. Le développeur peut utiliser son identité habituelle via un workflow de production autorisé distinct.

Par exemple, dans AWS IAM, ouvrez Rôles, sélectionnez le rôle de développement de Codex et, sous Autorisations, ajoutez une politique intégrée vérifiée comme celle ci-dessous. Remplacez le compte et le rôle par les vôtres :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

Cet exemple empêche d’endosser le rôle indiqué, mais n’interdit pas d’endosser d’autres rôles. Supprimez également les autorisations directes sur la production, restreignez les autres rôles de production et sources d’identifiants et examinez les politiques de confiance ainsi que les contrôles appliqués à l’échelle de l’organisation.

Testez le rôle de développement avec un échantillon représentatif d’autorisations de développement et de production, sans modifier la production. Consultez les exemples de politiques de rôle AWS IAM.

Réduction de l’environnement du shell

Dans /etc/codex/config.toml pour une configuration de départ à l’échelle du système, ou dans ~/.codex/config.toml pour un seul utilisateur, configurez les variables d’environnement dont héritent les commandes lancées :

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Ce paramètre par défaut est modifiable et n’impose aucune restriction d’accès aux identifiants. Les paramètres utilisateur, le démarrage ou les instantanés du shell, les gestionnaires d’identifiants et d’autres sources peuvent toujours exposer des identifiants.

Dans requirements.toml, utilisez les restrictions facultatives suivantes pour désactiver les shells de connexion et les instantanés du shell si votre workflow le permet :

allow_login_shell = false

[features]
shell_snapshot = false

Testez ces paramètres sur un groupe pilote, car certains workflows dépendent de l’initialisation du shell de connexion.

Démarrez Codex avec des variables de test inoffensives correspondant aux filtres et inspectez l’environnement d’une commande lancée. Si les shells de connexion sont désactivés, vérifiez aussi qu’une demande d’ouverture d’un tel shell est refusée. Vérifiez séparément que l’identité d’exécution ne peut pas accéder à de véritables identifiants de production. Consultez la politique d’environnement du shell.

Demandes d’approbation pour certaines commandes à fort impact

Ajoutez aux exigences des règles pour les commandes utilisées dans votre organisation. Par exemple :

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

Utilisez forbidden pour une commande qui ne doit jamais être exécutée. Remplacez ou complétez les motifs pour couvrir vos outils de déploiement et de migration.

Ces règles reconnaissent des préfixes de commandes et ne couvrent pas toutes les actions équivalentes. Testez séparément les chemins absolus, les wrappers, les autres ordres possibles des arguments, les autres clients et les autres outils.

Sur une cible de test que vous pourrez supprimer, exécutez une commande ordinaire, demandez l’exécution d’une action de la liste, refusez la demande d’approbation et vérifiez que l’action n’a pas été exécutée. Consultez la section Application des règles de commande.

Approbations des modifications de dépôts et des déploiements en dehors de Codex

Sur votre plateforme de gestion de versions, protégez les branches de production telles que main. Exigez un examen des modifications, les approbations nécessaires et les vérifications de statut requises. Vérifiez quels rôles peuvent contourner ces exigences. Configurez l’approbation des déploiements dans le système de déploiement concerné et les privilèges de la base de données dans la base elle-même.

Utilisez un dépôt de test que vous pourrez supprimer pour vérifier qu’une modification examinée est acceptée et qu’un push direct non autorisé est refusé. Ces contrôles s’appliquent que l’action ait été demandée via Codex ou non.

Vérification

Sur une cible de test que vous pourrez supprimer :

• Exécutez une tâche habituelle dans l’espace de travail. Résultat attendu : la tâche aboutit.

• Tentez d’exécuter une commande sensible représentative et refusez la demande d’approbation. Résultat attendu : la commande refusée ne s’exécute pas.

• Vérifiez que l’identité de Codex ne peut pas obtenir d’accès en écriture à la production.

• Redémarrez le client et répétez les vérifications.

Limites

Les règles de préfixe ne constituent pas un moteur complet d’application des politiques du système d’exploitation. Associez-les au bac à sable, à des comptes système dotés des privilèges minimaux, à des restrictions réseau, à la gestion des identités et des accès (IAM) dans le cloud, à la protection des branches, aux approbations de déploiement et aux autorisations des bases de données.

Fiches de configuration utilisées : Protéger les secrets et les dépôts sans rapport avec la tâche ; Restreindre les destinations réseau ; Autoriser uniquement les serveurs MCP approuvés ; Exiger une approbation pour les commandes sensibles.

Les développeurs utilisent Codex avec des dépôts internes. Vous souhaitez réduire le risque que du code soit envoyé vers un dépôt public, publié sous forme d’extrait de code public ou transmis à une autre destination non approuvée.

• Interdisez les chemins exacts des répertoires d’identifiants connus et des dépôts sans rapport avec la tâche. Limitez les variables d’environnement transmises aux commandes lancées.

• Si l’agent a besoin d’accéder à Internet, limitez son accès à une liste restreinte de domaines approuvés. Autorisez uniquement les noms et les identités de serveurs MCP approuvés. Soumettez certaines commandes de publication, comme git push, à un examen préalable ou interdisez-les.

• Utilisez les hooks et les autorisations du système de gestion de versions, des politiques pour les dépôts et les extraits de code publics, ainsi que des contrôles de prévention des fuites de données adaptés à votre organisation.

Interdiction d’accès aux dépôts sans rapport avec la tâche et aux fichiers d’identifiants

Dans le fichier requirements.toml géré par l’administrateur, ajoutez les chemins exacts que l’agent local ne doit pas pouvoir lire :

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

Remplacez les exemples par les chemins présents sur vos appareils gérés. Cette interdiction gérée s’applique à tous les profils d’autorisations autorisés. Une interdiction définie uniquement dans un profil personnalisé ne protège pas les utilisateurs qui en sélectionnent un autre. Privilégiez les chemins exacts connus et testez les motifs glob aux profondeurs de répertoire nécessaires.

Sur Windows en mode natif, la règle gérée deny_read couvre les outils qui accèdent directement aux fichiers, mais ne suffit pas à empêcher leur lecture par les sous-processus du shell. Utilisez également les identités du système d’exploitation et les listes de contrôle d’accès aux fichiers.

Créez des fichiers témoins inoffensifs aux emplacements interdits. Pour chaque profil autorisé, vérifiez que la lecture de ces fichiers est refusée aussi bien en accès direct que via le shell et qu’un fichier de code source approuvé reste lisible. Consultez les exigences gérées d’interdiction de lecture.

Réduction des variables du shell contenant des identifiants

Dans /etc/codex/config.toml ou ~/.codex/config.toml, limitez les variables d’environnement héritées :

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Ce paramètre limite les variables héritées, mais l’utilisateur peut le modifier. Il n’empêche pas l’accès aux fichiers d’identifiants, aux gestionnaires d’identifiants, au contenu chargé au démarrage du shell ou à d’autres identités.

Si cela convient à votre environnement, un administrateur peut également ajouter les restrictions suivantes à requirements.toml et les tester sur un groupe pilote pour évaluer leur effet sur les workflows des développeurs :

allow_login_shell = false

[features]
shell_snapshot = false

Testez avec des variables témoins fictives et une identité d’exécution distincte dotée des privilèges minimaux. N’utilisez pas de véritables identifiants. Consultez la politique d’environnement du shell.

Limitation des commandes locales aux destinations réseau approuvées

Si les commandes locales exécutées dans le bac à sable ont besoin du réseau, intégrez à requirements.toml les paramètres du profil et du proxy géré ci-dessous. Remplacez les domaines par ceux de vos points de terminaison approuvés :

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

Le profil donne aux commandes du bac à sable un accès au réseau, tandis que le proxy géré limite leurs destinations. Déployez-les ensemble. Sans le proxy géré prévu, le profil réseau n’applique pas les mêmes restrictions de destination. Si l’accès à Internet est inutile, laissez l’accès réseau désactivé.

Ne combinez pas la table de référence domains avec les anciens paramètres allowed_domains ou denied_domains. Migrez la politique existante et testez-la.

Redémarrez le client et vérifiez qu’un point de terminaison approuvé est accessible et qu’un point de terminaison non approuvé est bloqué.

Ces paramètres sont expérimentaux. Vérifiez leur prise en charge par le système d’exploitation et le client. Si un hôte approuvé se résout en une adresse privée, configurez séparément l’accès au réseau privé. Une autorisation de sortir entièrement du bac à sable peut permettre de contourner le proxy des commandes.

Ce contrôle réseau des commandes locales ne couvre pas à lui seul la recherche web, les applications, les serveurs MCP, l’activité du navigateur ou les environnements cloud. Ceux-ci nécessitent des politiques distinctes. Un domaine d’hébergement approuvé peut aussi contenir des dépôts publics ou des extraits de code publics. Une liste de destinations autorisées ne suffit donc pas à protéger le contenu. Consultez les exigences d’accès au réseau.

Configuration distincte du réseau des environnements cloud

Dans l’interface actuelle de Codex Cloud, ouvrez la configuration de l’environnement. Désactivez Autoriser tout accès à Internet public et Autoriser les domaines des gestionnaires de paquets. Si un accès à Internet public est nécessaire, ajoutez les noms d’hôtes exacts approuvés sous Domaines autorisés supplémentaires. Supprimez les secrets HTTP qui autorisent des destinations publiques non approuvées. Pour bloquer l’accès à Internet public en dehors du VPN, laissez cette liste vide et supprimez les secrets HTTP qui autorisent des destinations publiques. Enregistrez la configuration, publiez ou republiez l’environnement, puis testez une nouvelle tâche.

Examinez séparément l’authentification des services et les actions qu’ils permettent.

L’ancienne version de Codex Cloud dispose d’un paramètre distinct pour l’accès de l’agent à Internet dans chaque environnement. Il permet de contrôler les domaines autorisés et les méthodes HTTP. Les scripts de préparation suivent leurs propres règles d’accès.

Testez la version de l’environnement que vous utilisez réellement. Consultez la section Se connecter aux services et les paramètres Internet de l’ancienne version.

Restriction des serveurs MCP et approbation préalable des push Git

Dans requirements.toml, autorisez uniquement les identités approuvées des serveurs MCP locaux. Par exemple :

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

Configurez le serveur lui-même séparément dans le fichier config.toml de l’utilisateur ou des paramètres par défaut gérés. Utilisez le nom et l’URL correspondants ainsi que le mécanisme d’authentification requis par votre serveur :

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

L’exigence autorise uniquement un serveur correspondant, sans le créer. Examinez les accès et les outils propres à ce serveur.

Vérifiez que le serveur approuvé peut se connecter et qu’un serveur portant un autre nom ou utilisant une autre URL n’est pas autorisé.

Ajoutez une règle de commande gérée qui impose un examen avant l’exécution d’une commande de publication représentative :

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

Si une personne doit examiner la demande, associez cette règle à allowed_approval_policies = ["on-request"] et à allowed_approvals_reviewers = ["user"] au premier niveau des exigences.

Refusez un push de test et vérifiez qu’il ne s’exécute pas.

La correspondance par préfixe ne couvre pas tous les wrappers, clients API, applications ou autres moyens de publier du code.

Restriction des publications publiques via la gestion de versions et la prévention des fuites de données

Sur votre plateforme de gestion de versions, restreignez la création de dépôts publics et, si la plateforme le permet, limitez les personnes autorisées à modifier la visibilité d’un dépôt. Vérifiez quels utilisateurs privilégiés peuvent contourner ces restrictions. Examinez séparément les comptes personnels, les extraits de code, les organisations externes et les accès par jeton : les paramètres de l’organisation ne régissent pas toutes les destinations.

Dans le dépôt concerné, exigez un examen des modifications et vérifiez la protection des branches ainsi que les autorisations de contournement.

Dans la console de prévention des fuites de données (DLP) de votre organisation, configurez une politique pilote pour le code source sensible et les canaux de téléversement ou de dépôt effectivement couverts par votre solution DLP. Choisissez le blocage comme action et testez la politique avec un marqueur fictif inerte.

Si la plateforme de gestion de versions prend en charge des contrôles côté serveur, configurez des hooks vérifiés et imposez leur exécution dans les dépôts qui reçoivent des push.

Utilisez des destinations de test autorisées et vérifiez que le blocage intervient avant toute publication.

Vérification

• Créez des fichiers témoins inoffensifs et vérifiez que les tentatives de lecture des fichiers interdits échouent.

• Si l’accès réseau est activé, vérifiez qu’une requête vers une destination approuvée aboutit et qu’une requête vers une destination non approuvée est bloquée. Sinon, vérifiez que les requêtes réseau sont bloquées.

• À l’aide d’un marqueur inoffensif et de comptes ou de destinations de test que vous pourrez supprimer, vérifiez que des tentatives représentatives de publication publique sont bloquées avant la publication.

Limites

Un domaine autorisé peut héberger du contenu public. Configurez séparément la recherche web, les applications, les serveurs MCP, l’activité du navigateur et Codex Cloud. Les règles du bac à sable local ne les contrôlent pas.

Fiches de configuration utilisées : Restreindre les profils d’autorisations et l’Accès complet ; Autoriser uniquement les serveurs MCP approuvés ; Restreindre les destinations réseau ; Protéger les secrets et les dépôts sans rapport avec la tâche ; Exiger une approbation pour les commandes sensibles.

Vous souhaitez que les restrictions imposées à Codex restent en vigueur lorsqu’il travaille dans un dépôt ou qu’un utilisateur modifie la configuration locale.

• Distribuez les restrictions prises en charge concernant les autorisations, les approbations, MCP, le réseau et les commandes sous forme d’exigences imposées par l’administrateur.

• Installez les scripts des hooks dans un répertoire géré par l’administrateur et autorisez uniquement les hooks gérés si vous souhaitez ignorer ceux des utilisateurs, des projets et des plugins.

• Protégez les fichiers de politique et le circuit de distribution de la configuration à l’aide des contrôles du système d’exploitation et de gestion des appareils. Exécutez Codex sans les privilèges nécessaires pour modifier ces protections.

• Examinez la configuration effective de chaque client et de chaque environnement concerné.

Application des restrictions sur les profils, les approbations, les identités de serveurs et les commandes

Intégrez les paramètres vérifiés au fichier requirements.toml géré par l’administrateur. Évitez de vous appuyer sur les paramètres modifiables de l’utilisateur ou du dépôt. Par exemple :

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

Cet exemple autorise deux profils, impose un examen humain lorsqu’une approbation est nécessaire, autorise une identité MCP correspondante et demande une approbation pour un préfixe de commande précis.

Configurez le serveur MCP lui-même séparément et ajoutez les motifs correspondant aux autres commandes sensibles de votre organisation. Ajoutez des restrictions globales sur les fichiers et des restrictions réseau si nécessaire. Les exigences encadrent les paramètres pris en charge, mais ne remplacent pas les contrôles des identités, des services et des destinations mis en œuvre en dehors de Codex.

Les listes gérées de profils autorisés nécessitent Codex 0.138.0 ou une version ultérieure.

Sur un client pilote, essayez de sélectionner un profil non autorisé, de modifier un paramètre utilisateur ou projet soumis à restriction et d’utiliser une identité MCP absente de la liste. Vérifiez que chaque tentative est refusée ou que la restriction reste en vigueur après le redémarrage. Refusez la demande d’approbation d’une commande de test et vérifiez qu’elle ne s’exécute pas.

Ajout de restrictions gérées sur le système de fichiers et le réseau

Pour interdire la lecture de fichiers locaux sensibles dans tous les profils autorisés, ajoutez la table suivante à requirements.toml et remplacez les exemples par les chemins de votre organisation :

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

Si des commandes locales exécutées dans le bac à sable ont besoin du réseau, définissez ensemble un profil autorisé donnant accès au réseau et les destinations gérées :

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

Utilisez cette politique de profil à la place du profil par défaut :workspace précédent, ou intégrez explicitement les deux noms de profil. Ne collez pas de clés ou de tables en double. Si les commandes n’ont pas besoin du réseau, laissez l’accès réseau désactivé.

Testez les chemins exacts interdits avec des fichiers inoffensifs, puis vérifiez l’accès aux destinations approuvées et le blocage des destinations non approuvées.

Sur Windows en mode natif, utilisez également des listes de contrôle d’accès aux fichiers, car la règle gérée deny_read ne couvre pas à elle seule les lectures par les sous-processus du shell.

Les paramètres réseau des commandes locales ne régissent pas les autres clients, les applications, les connecteurs ni les exécutions dans le cloud.

Installation et application des hooks gérés par l’administrateur

Demandez à un administrateur d’installer un programme de hook vérifié dans un répertoire géré par root, par exemple à l’emplacement /etc/codex/hooks/pre_tool_use_policy.py. Empêchez l’utilisateur qui exécute Codex de modifier le fichier ou son répertoire. Dans requirements.toml, activez les hooks et ignorez ceux des utilisateurs, des projets, des sessions et des plugins :

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

L’exigence enregistre le hook sans l’installer. Pour un test d’intégration local sur macOS, enregistrez le programme suivant sous le nom pre_tool_use_policy.py et demandez à un administrateur de l’installer avec les commandes ci-dessous.

Le programme bloque uniquement le marqueur de test. Avant de vous y fier, remplacez-le par une politique propre à votre organisation qui a fait l’objet d’un examen. Vérifiez que /usr/bin/python3 existe sur la cible et adaptez le chemin de l’interpréteur si nécessaire :

1
2
3
4
5
6
7
8import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

Redémarrez le client local, puis effectuez les vérifications suivantes :

• Vérifiez qu’une commande Bash inoffensive s’exécute.

• Vérifiez qu’une commande contenant CODEX_HOOK_TEST_DENY est bloquée.

• Vérifiez que l’utilisateur qui exécute Codex ne peut modifier ni la politique ni ses dépendances.

allow_managed_hooks_only ignore tous les hooks non gérés des utilisateurs, des projets, des sessions et des plugins, ce qui peut affecter d’autres workflows.

La règle de correspondance pour Bash ne couvre pas tous les outils ni toutes les entrées fournies ultérieurement à un processus déjà lancé. En cas d’erreur, de dépassement du délai ou de réponse mal formée du hook, l’appel d’outil peut se poursuivre.

Lorsque le mode Work est orchestré dans le cloud, les gestionnaires de hooks pris en charge sont différents. Conservez des protections indépendantes au niveau du système d’exploitation et des services. Consultez les sections sur les hooks gérés et le comportement des hooks.

Protection de la politique et de sa distribution

Sur macOS, un administrateur peut déployer un fichier d’exigences consolidé et vérifié dans un répertoire parent appartenant à root et empêcher l’utilisateur qui exécute Codex d’écrire dans ce fichier :

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

Sur Linux, utilisez le groupe d’administration approprié. Sur Windows, protégez le répertoire ProgramData et le fichier à l’aide de listes de contrôle d’accès gérées par l’administrateur. Limitez les personnes autorisées à modifier la politique MDM ou cloud, examinez les modifications et conservez une copie permettant un retour arrière.

Avec un compte pilote sans droits d’administration, vérifiez que ce compte ne peut modifier ni la politique, ni le répertoire parent, ni le programme du hook géré. Essayez un paramètre utilisateur ou projet moins restrictif, redémarrez Codex et vérifiez que la restriction imposée reste en vigueur.

Testez chaque client et chaque environnement concerné, sans supposer que tous les clients chargent la même politique.

Vérification

Avec une identité de test sans droits d’administration :

• Essayez de modifier la politique gérée. Résultat attendu : le fichier géré ne peut pas être modifié.

• Essayez d’assouplir une restriction via la configuration utilisateur ou projet. Résultat attendu : les paramètres moins restrictifs sont refusés ou restent soumis à la restriction imposée.

• Redémarrez le client et vérifiez que les restrictions s’appliquent toujours.

Limites

Un utilisateur ou un agent disposant de privilèges d’administration suffisants sur l’hôte peut être en mesure de modifier les protections qui entourent Codex. Les paramètres modifiables par l’utilisateur ne remplacent pas à eux seuls les exigences gérées par l’administrateur.