Les secrets de la cage dorée : comment OpenAI verrouille Codex

CONFIGURATIONS DE SÉCURITÉ : UN APERÇU

1# config.toml23# Turn on autoreview4approvalsreviewer = "autoreview" 5# Add known development directories to the sandbox automatically6sandboxworkspacewrite.writableroots = ["~/development"] 78# requirements.toml910# Require Codex to operate inside the sandbox11allowedsandboxmodes = ["read-only", "workspace-write"]

1# requirements.toml23# Ensure web fetch only comes from OpenAI's cache4allowedwebsearchmodes = ["cached"] 56[experimentalnetwork]7# Turn on Network Proxy8enabled = true9# Allow Codex to interact with localhost10allowlocalbinding = true 11# Block all requests to this domain12denieddomains = ["pastebin.com"] 13# Auto-allow requests to these domains14alloweddomains = ["login.microsoftonline.com", "*.openai.com"]

1# config.toml23# Store CLI Auth Creds in OS Keychain4cliauthcredentialsstore = "keyring"           5# Store MCP Creds in OS Keychain6mcpoauthcredentialsstore = "keyring"          7# Require Auth via ChatGPT8forcedloginmethod = "chatgpt"                  9# Require Auth to Specific ChatGPT Workspace10forcedchatgptworkspace_id = "<workspace-uuid>"

1# default.rules23prefixrule(4    pattern = ["gh", "pr", ["view", "list"]],5    decision = "allow",6    justification = "Allows read-only GitHub PR inspection via gh CLI.",7)8prefixrule(9    pattern = ["kubectl", ["get", "describe", "logs"]],10    decision = "allow",11    justification = "Allows Kubernetes resource inspection for debugging.",12)

1# config.toml23[otel]4loguserprompt = true5environment = "prod"67[otel.exporter.otlp-http]8endpoint = "http://localhost:14318/v1/logs"9protocol = "binary"

UN APERÇU DES CONTRÔLES ET DE LA TÉLÉMÉTRIE

À mesure que les systèmes d’IA gagnent en capacités, ils agissent de plus en plus au nom des utilisateurs. Les agents de codage peuvent examiner des dépôts de manière autonome, exécuter des commandes et interagir avec des outils de Développement, des tâches qui nécessitaient auparavant une exécution humaine directe. Avec Codex, OpenAI a conçu ces capacités en même temps que les contrôles dont les organisations ont besoin pour un déploiement sûr. Les équipes de sécurité doivent pouvoir gouverner ce que les agents peuvent accéder, quand une approbation humaine est nécessaire, avec quels systèmes ils peuvent interagir et quelle télémétrie existe pour expliquer leur comportement.

OpenAI déploie Codex avec des objectifs clairs : garder l’agent dans des limites techniques strictes, permettre aux développeurs d’agir rapidement sur les actions à faible risque et rendre explicites les actions à plus haut risque. Une télémétrie native des agents est également préservée pour comprendre ce que l’agent a fait. En pratique, cela se traduit par une configuration gérée, une exécution contrainte, des politiques réseau et des journaux natifs.

BAC À SABLE ET APPROBATIONS : LE DUO GAGNANT

Le bac à sable (sandbox) définit la limite technique d’exécution : là où Codex peut écrire, s’il peut atteindre le réseau et quels chemins restent protégés. La politique d’approbation détermine quand Codex doit demander la permission, par exemple pour sortir du bac à sable. L’utilisateur peut approuver une action ponctuelle ou un type d’action pour toute la session.

Pour les demandes de routine, le mode examen automatique (auto-review) réduit les interruptions : une fois activé, il auto-approuve certaines requêtes. Codex envoie l’action prévue et le contexte récent à un sous-agent d’approbation, qui valide automatiquement les actions à faible risque. Résultat : Codex avance sur le travail courant sans harceler l’utilisateur, mais s’arrête toujours sur les actions à risque élevé ou aux conséquences imprévues.

1# config.toml23# Turn on autoreview4approvalsreviewer = "autoreview" 5# Add known development directories to the sandbox automatically6sandboxworkspacewrite.writableroots = ["~/development"] 78# requirements.toml910# Require Codex to operate inside the sandbox11allowedsandboxmodes = ["read-only", "workspace-write"]

ACCÈS RÉSEAU : UN PROXY BIEN GARDÉ

Pas d’accès sortant illimité pour Codex. La politique réseau gérée autorise les destinations attendues, bloque les domaines interdits et exige une approbation pour les destinations inconnues. Ainsi, Codex peut exécuter des flux de travail courants sans bénéficier d’un large accès au réseau. La configuration s’appuie sur un proxy réseau expérimental qui filtre chaque requête.

1# requirements.toml23# Ensure web fetch only comes from OpenAI's cache4allowedwebsearchmodes = ["cached"] 56[experimentalnetwork]7# Turn on Network Proxy8enabled = true9# Allow Codex to interact with localhost10allowlocalbinding = true 11# Block all requests to this domain12denieddomains = ["pastebin.com"] 13# Auto-allow requests to these domains14alloweddomains = ["login.microsoftonline.com", "*.openai.com"]

IDENTITÉ ET AUTHENTIFICATION : VERROUILLAGE TOTAL

La gestion des identifiants est tout aussi stricte. Les secrets CLI et MCP OAuth sont stockés dans le trousseau sécurisé du système d’exploitation. La connexion est forcée via ChatGPT et l’accès est verrouillé sur l’espace de travail d’entreprise. Ainsi, toute activité Codex reste liée aux contrôles de l’espace de travail et apparaît dans la plateforme de journaux de conformité ChatGPT.

1# config.toml23# Store CLI Auth Creds in OS Keychain4cliauthcredentialsstore = "keyring"           5# Store MCP Creds in OS Keychain6mcpoauthcredentialsstore = "keyring"          7# Require Auth via ChatGPT8forcedloginmethod = "chatgpt"                  9# Require Auth to Specific ChatGPT Workspace10forcedchatgptworkspace_id = "<workspace-uuid>"

TÉLÉMÉTRIE AVANCÉE : COMPRENDRE LE « POURQUOI »

Le contrôle n’est que la moitié du chemin. Une fois les agents déployés, les équipes de sécurité ont besoin de visibilité sur ce qu’ils font et pourquoi. Les journaux de sécurité classiques disent ce qui s’est passé (un processus a démarré, un fichier modifié), mais pas l’intention. Codex offre une vue plus consciente de l’agent grâce à l’export de journaux OpenTelemetry. Sont tracés les prompts utilisateur, les décisions d’approbation, les résultats d’exécution, l’utilisation des serveurs MCP et les décisions du proxy réseau. Ces journaux sont également disponibles via la plateforme de conformité OpenAI pour les clients Enterprise et Edu.

1# config.toml23[otel]4loguserprompt = true5environment = "prod"67[otel.exporter.otlp-http]8endpoint = "http://localhost:14318/v1/logs"9protocol = "binary"

Chez OpenAI, ces journaux sont utilisés avec un agent de triage de sécurité alimenté par l’IA. Quand une alerte signale un comportement inhabituel, l’outil de sécurité de point de terminaison remonte l’événement suspect. Les journaux Codex aident alors à expliquer l’intention de l’utilisateur et celle de l’agent. L’agent de triage IA inspecte la demande d’origine, l’activité outillée, les approbations, les résultats et les décisions réseau pour distinguer un comportement normal d’une erreur bénigne ou d’une véritable escalade. L’analyse est présentée à l’équipe de sécurité pour examen.

La même télémétrie sert au pilotage opérationnel : comprendre l’adoption interne, suivre l’usage des outils et des serveurs MCP, mesurer la fréquence des blocages réseau et ajuster le déploiement. Ces journaux peuvent être centralisés dans des systèmes SIEM et de conformité.

CONCLUSION : UNE ADOPTION EN TOUTE CONFIANCE

À mesure que les agents de codage s’intègrent aux flux de développement, les équipes de sécurité ont besoin d’outils conçus pour ce changement. Codex fournit les surfaces de contrôle, la gestion de configuration, le bac à sable et la télémétrie détaillée nécessaires à une adoption sécurisée. Avec ces garde-fous, les équipes peuvent activer Codex en confiance, en équilibrant productivité des développeurs et exigences de sécurité. Plus d’informations sur la configuration de Codex et l’API de conformité sont disponibles dans la documentation d’OpenAI.