À 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 façon autonome, exécuter des commandes et interagir avec des outils de développement. Il s’agit de tâches qui nécessitaient auparavant une exécution humaine directe.
Avec Codex, nous avons conçu ces capacités en parallèle des contrôles dont les organisations ont besoin pour un déploiement sûr. Les équipes de sécurité ont besoin de moyens pour encadrer le fonctionnement des agents : ce à quoi ils peuvent accéder, quand une approbation humaine est requise, avec quels systèmes ils peuvent interagir et quelles données de télémétrie existent pour expliquer leur comportement.
Chez OpenAI, nous déployons Codex avec quelques objectifs clairs : maintenir l’agent dans des limites techniques explicites, permettre aux développeurs d’avancer vite sur les actions à faible risque et rendre explicites les actions à risque plus élevé. Nous conservons aussi une télémétrie native à l’agent afin de pouvoir comprendre et auditer ce qu’il a fait. En pratique, cela signifie une configuration gérée, une exécution contrainte, des politiques réseau et des journaux natifs à l’agent.
Nous déployons Codex selon un principe simple : il doit être productif dans un environnement délimité, les actions quotidiennes à faible risque doivent être fluides, et les actions à risque plus élevé doivent s’arrêter pour examen.
Les approbations et le sandboxing fonctionnent ensemble. Le sandbox définit la limite technique d’exécution, notamment les emplacements où Codex peut écrire, s’il peut accéder au réseau et quels chemins restent protégés. La politique d’approbation détermine quand Codex doit demander l’autorisation d’effectuer une action, par exemple lorsqu’il doit faire quelque chose en dehors du sandbox. Les utilisateurs peuvent approuver l’action une seule fois, ou approuver ce type d’action pour la session.
Pour les demandes qui sortent du sandbox, nous utilisons le mode Approbation automatique(ouverture dans une nouvelle fenêtre), une fonctionnalité qui, lorsqu’elle est activée, approuve automatiquement certains types de demandes afin de réduire le nombre d’interruptions nécessaires pour approuver des actions de Codex. Codex envoie l’action prévue et le contexte récent au sous-agent d’approbation automatique, qui peut approuver automatiquement les actions à faible risque (ou les actions à haut risque si l’utilisateur dispose des autorisations nécessaires) sans interrompre l’utilisateur. Cela permet à Codex de poursuivre les tâches de routine tout en s’arrêtant sur les actions présentant un risque plus élevé ou susceptibles d’avoir des conséquences imprévues.
Nous n’exécutons pas Codex avec un accès sortant illimité. Notre politique réseau gérée autorise les destinations attendues, bloque les destinations que nous ne voulons pas que Codex atteigne et exige une approbation pour les domaines inconnus. Cela permet à Codex d’exécuter des workflows courants et fiables sans lui donner un accès réseau étendu.
Nous gérons également la manière dont Codex s’authentifie. Les identifiants OAuth CLI et MCP sont stockés dans le trousseau sécurisé du système d’exploitation, la connexion passe obligatoirement par ChatGPT, et l’accès est rattaché à notre espace de travail ChatGPT Enterprise. Cela permet de lier l’utilisation de Codex à nos contrôles au niveau de l’espace de travail et de rendre l’activité de Codex consultable dans les journaux de conformité ChatGPT de notre espace de travail Enterprise.
Nous utilisons des règles pour que Codex ne traite pas chaque commande shell comme étant également sûre. Les commandes courantes et sans risque que les ingénieurs utilisent au quotidien dans le développement sont autorisées sans approbation en dehors du sandbox, tandis que certaines commandes dangereuses peuvent être bloquées ou nécessiter une approbation. Cela permet à Codex d’avancer rapidement dans les tâches d’ingénierie ordinaires tout en imposant une revue ou en bloquant les schémas que nous ne voulons pas exécuter en dehors du sandbox.
Nous appliquons cette posture au moyen d’une combinaison d’exigences gérées dans le cloud, de préférences gérées macOS et de fichiers d’exigences locaux. Les exigences sont des contrôles imposés par les administrateurs que les utilisateurs ne peuvent pas contourner. Les préférences gérées macOS et les fichiers d’exigences locaux nous permettent de maintenir une base cohérente tout en testant différentes configurations selon l’équipe, le groupe d’utilisateurs ou l’environnement. Ces configurations s’appliquent à toutes les interfaces locales de Codex, y compris l’application de bureau, le CLI et l’extension IDE.
Le contrôle ne représente que la moitié du travail. Une fois les agents déployés, les équipes de sécurité ont besoin de visibilité sur ce que font ces agents et pourquoi. Les journaux de sécurité traditionnels restent utiles pour examiner les actions effectuées par Codex, mais ils répondent surtout à la question de savoir ce qui s’est passé : un processus a démarré, un fichier a changé, une connexion réseau a été tentée. Les équipes de sécurité doivent encore déterminer pourquoi Codex a effectué certaines actions, ou quelle était l’intention de l’utilisateur.
Codex peut offrir aux équipes de sécurité une vue mieux adaptée aux agents. Codex prend en charge l’exportation des journaux OpenTelemetry pour divers événements Codex tels que les prompts des utilisateurs, les décisions d’approbation des outils, les résultats d’exécution des outils, l’utilisation du serveur MCP, ainsi que les événements d’autorisation ou de refus du proxy réseau. Les journaux d’activité Codex sont aussi disponibles via la plateforme OpenAI de conformité pour les clients Enterprise et Edu.
Chez OpenAI, nous utilisons les journaux Codex aux côtés de notre agent de triage de sécurité alimenté par l’IA. Lorsqu’une alerte de sécurité endpoint indique que Codex a fait quelque chose d’inhabituel, l’outil de sécurité endpoint nous signale qu’un événement suspect s’est produit. Les journaux Codex aident ensuite à expliquer le contexte de l’intention de l’utilisateur et de l’agent. Notre agent de triage de sécurité par IA utilise les journaux Codex pour examiner la demande d’origine, l’activité des outils, les décisions d’approbation, les résultats des outils et toute décision ou tout blocage pertinent lié à la politique réseau. L’agent de triage de sécurité par IA présente son analyse à notre équipe de sécurité pour examen afin de distinguer le comportement attendu de l’agent, les erreurs sans gravité et l’activité qui justifie réellement une remontée.
Nous utilisons également cette même télémétrie sur le plan opérationnel. Nous nous servons de ces journaux pour comprendre comment l’adoption interne évolue, quels outils et serveurs MCP sont utilisés, à quelle fréquence le sandbox réseau bloque ou demande une approbation, et où des ajustements restent nécessaires. Ces journaux OpenTelemetry peuvent être centralisés dans des systèmes SIEM et de journalisation de conformité.
À mesure que des agents de codage comme Codex s’intègrent aux processus de développement, les équipes de sécurité ont besoin d’outils spécifiquement conçus pour gérer cette évolution. Codex fournit les interfaces de contrôle, la gestion de configuration, le sandboxing et la télémétrie détaillée adaptée aux agents nécessaires pour garantir une adoption sûre. Avec ces capacités en place, les équipes de sécurité peuvent déployer Codex avec plus de confiance, en conciliant la productivité des développeurs avec la visibilité et le contrôle requis pour la sécurité d’entreprise. Pour en savoir plus, consultez la documentation sur la configuration de Codex ici(ouverture dans une nouvelle fenêtre) et l’article d’aide sur l’API de conformité ici(ouverture dans une nouvelle fenêtre).
