OpenAI détaille la sécurisation de Codex : bacs à sable, validations et audit des actions de l'agent

Le 8 mai 2026, OpenAI a expliqué comment elle encadre Codex dans ses propres processus de travail. Le principe est simple : un agent de code doit accélérer le développement, sans obtenir d'accès incontrôlé aux fichiers, au réseau ou à l'infrastructure.

Un périmètre pour Codex

La première couche de protection est le bac à sable. Il fixe le cadre technique : où Codex peut écrire, quels répertoires sont accessibles en écriture, si l'accès au réseau est autorisé et quels chemins restent protégés.

Une politique de validation s'y superpose. Si l'agent doit agir hors de l'environnement autorisé, il est tenu de demander une confirmation. L'utilisateur peut approuver une action précise ou autoriser ce type d'action jusqu'à la fin de la session. Le risque d'opérations accidentelles ou opaques s'en trouve réduit.

OpenAI utilise en outre un mode Auto-review. Lorsque Codex s'apprête à franchir la limite du bac à sable, il transmet son plan d'action et le contexte récent à un sous-agent de validation automatique. Celui-ci peut laisser passer automatiquement les requêtes à faible risque, et dans certains cas des requêtes plus sensibles, si l'utilisateur dispose déjà d'un niveau d'autorisation suffisant. Résultat : les tâches routinières ne freinent pas le travail, tandis que les actions potentiellement dangereuses restent bloquées pour vérification.

«

Maintenir l'agent dans des limites techniques claires, accélérer les actions à faible risque et signaler explicitement celles qui sont risquées » : c'est ainsi qu'OpenAI décrit l'objectif de ce dispositif.

Réseau, accès, règles

La deuxième couche concerne la gestion des accès. OpenAI n'accorde pas à Codex un accès sortant libre à Internet : la politique réseau autorise les destinations attendues, bloque celles qui sont indésirables et exige une validation pour les domaines inconnus. Même la recherche et le web fetch peuvent être limités à des réponses en cache.

Les identifiants du CLI et de MCP OAuth sont stockés dans le keyring du système, la connexion passe obligatoirement par ChatGPT et l'accès est rattaché à un enterprise-workspace précis. Objectif : maintenir l'activité de l'agent à l'intérieur des périmètres de contrôle de l'entreprise.

• Modes de bac à sable autorisés : read-only et workspace-write uniquement
• Seuls les répertoires de travail connus à l'avance sont ouverts automatiquement en écriture
• Côté réseau, il est possible d'activer un proxy, d'autoriser localhost et de bloquer certains domaines
• Des adresses connues comme *.openai.com peuvent passer sans validation manuelle
• Les exigences administratives ne peuvent pas être désactivées côté utilisateur

Des règles spécifiques s'appliquent aussi aux commandes shell. Codex ne considère pas toutes les commandes comme également sûres : les opérations read-only courantes peuvent passer sans confirmation, même hors du bac à sable, tandis que les motifs dangereux peuvent être bloqués ou envoyés en revue. Dans l'exemple d'OpenAI, la lecture de pull requests via gh pr view et list, ainsi que le diagnostic Kubernetes via kubectl get, describe et logs, sont autorisés sans question superflue.

L'entreprise déploie sa politique de base via des managed configs et des requirements : le même périmètre s'applique donc dans l'application desktop, le CLI et l'extension IDE.

Des logs qui expliquent

OpenAI souligne que les restrictions seules ne suffisent pas. Les logs de sécurité classiques montrent bien ce qui s'est passé : un processus lancé, un fichier modifié, une tentative de connexion réseau. Mais ils permettent difficilement de reconstituer l'intention de l'agent et de l'utilisateur.

Codex peut donc exporter des logs OpenTelemetry enrichis d'un contexte propre à l'agent : requêtes initiales de l'utilisateur, décisions de validation (approvals), résultats des appels d'outils, utilisation des serveurs MCP et événements du proxy réseau, avec ce qui a été autorisé et ce qui a été bloqué. Pour les clients Enterprise et Edu, cette activité est également accessible via la Compliance Logs Platform, et les journaux peuvent être centralisés dans des systèmes SIEM et de conformité.

En interne, OpenAI confie ces données à un agent IA de security triage. Lorsque la protection endpoint signale une action étrange de Codex, l'équipe sécurité ne se contente pas de l'alerte : elle examine les journaux associés. Quelle était la requête initiale, quels outils ont été lancés, ce que l'agent a tenté de faire, quelles décisions le réseau a prises et où une validation était requise. Il devient ainsi plus rapide de distinguer un comportement attendu d'une erreur bénigne ou d'un cas qui exige réellement une escalade.

Ces mêmes logs servent aussi sur le plan opérationnel : comprendre comment progresse l'usage interne de Codex, quels outils sont sollicités et où la politique doit encore être ajustée.

Ce que cela signifie

OpenAI présente de fait un modèle d'entreprise pour les agents de code : non pas un modèle intelligent à la place du contrôle, mais un modèle placé dans un environnement strictement configuré, avec audit et règles. Pour les entreprises qui veulent déployer ce type d'assistant, le message est clair : la question produit centrale ne porte plus seulement sur la qualité du modèle, mais aussi sur sa capacité à s'intégrer à la sécurité, à la conformité et aux processus internes.