OpenAI détaille les protections de Codex : sandboxes, approbations et audit des actions de l’agent

Le 8 mai 2026, OpenAI a expliqué comment elle restreint Codex dans ses flux de travail. L'idée est simple : un agent de code doit accélérer le développement, mais ne pas obtenir d'accès incontrôlé aux fichiers, réseaux et infrastructures.

Limites pour Codex

La première couche de protection est le bac à sable (sandbox). Elle établit des limites techniques : où Codex peut écrire, quels répertoires sont ouverts à l'écriture, si l'accès réseau est autorisé et quels chemins restent protégés. Au-dessus de cela, une politique d'approbation fonctionne. Si un agent doit faire quelque chose en dehors de l'environnement autorisé, il doit demander une confirmation. Un utilisateur peut approuver une seule action spécifique ou accorder une permission pour ce type d'action pour le reste de la session. Cela réduit le risque d'opérations accidentelles et opaques.

Séparément, OpenAI utilise un mode Auto-review. Quand Codex est sur le point de franchir une limite de bac à sable, il transmet le plan d'action et le contexte récent à un sous-agent d'auto-approbation séparé. Cet agent peut automatiquement autoriser les demandes à faible risque et, dans certains cas, même les plus sensibles, si l'utilisateur a déjà un niveau d'autorisation suffisant. En conséquence, les tâches routinières ne ralentissent pas le travail, tandis que les actions potentiellement dangereuses sont toujours arrêtées à l'étape de révision.

«

Garder un agent dans des limites techniques claires, accélérer les actions à faible risque et mettre explicitement en évidence celles à risque » — c'est ainsi qu'OpenAI décrit l'objectif de ce schéma.

Réseau, Accès et Règles

La deuxième couche est la gestion des accès. OpenAI ne donne pas à Codex un accès Internet sortant libre : la politique réseau autorise les destinations attendues, bloque les indésirables et exige une approbation pour les domaines inconnus. Même la recherche et la récupération web peuvent être limitées aux réponses en cache. Les identifiants CLI et MCP OAuth sont stockés dans le porte-clés du système, la connexion est obligatoire via ChatGPT, et l'accès est lié à un espace de travail d'entreprise spécifique. Cela garantit que l'activité de l'agent reste dans les limites de contrôle d'entreprise.

• Les modes de bac à sable autorisés — lecture seule et écriture d'espace de travail uniquement
• L'écriture est automatiquement activée uniquement dans les répertoires de travail pré-connus
• Pour le réseau, vous pouvez activer un proxy, autoriser localhost et bloquer des domaines spécifiques
• Les adresses connues comme *.openai.com peuvent passer sans approbation manuelle
• Les exigences administratives ne peuvent pas être désactivées du côté de l'utilisateur

Il y a aussi des règles séparées pour les commandes shell. Codex ne considère pas toutes les commandes comme également sûres : les opérations standard de lecture seule peuvent être ignorées sans confirmation même en dehors du bac à sable, tandis que les modèles dangereux sont bloqués ou envoyés pour révision. Dans l'exemple d'OpenAI, ils autorisent sans questions supplémentaires la lecture des demandes de tirage via gh pr view et list, ainsi que les diagnostics de Kubernetes via kubectl get, describe et logs. L'entreprise déploie la politique de base via des configurations gérées et des exigences, donc le même cadre de contrôle fonctionne dans l'application de bureau, CLI et l'extension IDE.

Logs avec Explication

OpenAI souligne séparément que les restrictions seules sont insuffisantes. Les logs de sécurité standard montrent bien ce qui s'est passé : un processus a démarré, un fichier a changé, il y a eu une tentative de connexion réseau. Mais il est difficile d'en déduire l'intention de l'agent et de l'utilisateur.

Par conséquent, Codex peut exporter des logs OpenTelemetry avec un contexte d'agent plus riche : les demandes utilisateur d'origine, les décisions d'approbation, les résultats des appels d'outils, l'utilisation des serveurs MCP et les événements de proxy réseau — ce qui a été autorisé et ce qui a été bloqué. Pour les clients Enterprise et Edu, cette activité est également disponible via la Plateforme de Logs de Conformité, et les logs peuvent être centralisés dans les systèmes SIEM et de conformité.

Au sein d'OpenAI, ces données sont utilisées par un agent IA pour le tri de sécurité. Quand la protection des points de terminaison signale un comportement étrange de Codex, l'équipe de sécurité ne regarde pas seulement l'alerte elle-même, mais aussi les logs d'accompagnement : quelle était la demande d'origine, quels outils ont été lancés, ce que l'agent a essayé de faire, quelles décisions le réseau a prises et où une approbation était requise. Cela aide à distinguer plus rapidement le comportement attendu d'une erreur inoffensive et d'un cas qui nécessite vraiment une escalade.

Les mêmes logs sont également utilisés opérationnellement — pour comprendre comment l'utilisation interne de Codex augmente, quels outils sont demandés et où la politique doit encore être ajustée.

Ce Que Cela Signifie

OpenAI démontre essentiellement un modèle d'entreprise pour les agents de code : pas un modèle intelligent à la place des contrôles, mais un modèle au sein d'un environnement strictement configuré avec audit et règles. Pour les entreprises qui cherchent à déployer de tels assistants, c'est un signal que la principale question de produit n'est maintenant pas seulement la qualité du modèle, mais aussi la façon dont il s'adapte à la sécurité, la conformité et les processus internes.