Sécurité d'OpenAI Codex : risques, contrôles et bonnes pratiques

Qu'est-ce qu'OpenAI Codex, et pourquoi change-t-il le modèle de sécurité ?

OpenAI Codex est l'outil de code agentique d'OpenAI. Il fonctionne partout où le développeur travaille déjà : un CLI Codex dans le terminal, une extension d'IDE, un mode cloud et multi-agent qui exécute des tâches de manière asynchrone, et un SDK pour brancher Codex sur votre propre automatisation. Il agit sur des instructions en langage naturel : analyser une base de code, générer une fonctionnalité, exécuter les tests, corriger les échecs, ouvrir une pull request. Il se connecte à GitHub, fonctionne aux côtés des systèmes de build, et peut être pointé vers un dépôt et laissé à l'oeuvre.

Une clarification de nommage d'abord, car elle déroute presque tout le monde qui cherche sur ce sujet. "Codex" dans cet article désigne l'agent de code (CLI, extension d'IDE, cloud et SDK). Séparément, OpenAI a livré une fonctionnalité littéralement appelée Codex Security : un agent qui se connecte à un dépôt, construit un modèle de menace spécifique à la base de code, analyse l'historique des commits, valide les vulnérabilités candidates dans un environnement isolé, et propose des correctifs pour relecture humaine. Les deux sont faciles à confondre. Ce guide porte sur la sécurisation de l'agent de code Codex. Codex Security, la capacité de détection de vulnérabilités d'OpenAI, est couverte brièvement ci-dessous comme un apport d'assistance, pas comme un programme de sécurité complet.

Cette propriété agentique est celle qui brise l'ancien modèle de sécurité. Un assistant d'IDE traditionnel suggère des complétions ; un humain accepte ou rejette chacune d'elles. Le rayon d'impact d'une mauvaise suggestion est un bloc de code qu'un développeur doit encore coller. Codex prend des actions à la place. Il lit des fichiers que vous n'avez pas nommés, exécute des commandes que vous n'avez pas tapées, modifie du code dans toute l'arborescence, et en mode cloud il peut tourner longtemps sans que personne ne regarde. La surface d'attaque n'est plus "quel code le modèle a-t-il suggéré". C'est "que peut faire cet agent avec l'accès qu'il a, et qui peut influencer ses instructions".

“

Une suggestion est un brouillon qu'un humain choisit d'accepter. Une action est une chose qui a déjà eu lieu. Le modèle de sécurité doit passer de la relecture des brouillons à la contrainte des actions.

Il y a un second changement qui compte encore davantage, et il concerne la vitesse. La pull request est devenue le foyer de la sécurité applicative parce qu'elle se situait à la cadence humaine : une personne ralentissait, lisait le diff, et ne fusionnait qu'ensuite. Codex, surtout en mode cloud et multi-agent, ne tourne pas à la cadence humaine. Une seule session peut livrer plus de code en un après-midi qu'un relecteur n'en lit en une semaine. Quand cela arrive, le diff cesse d'être un point de contrôle et devient un compte rendu de décisions déjà prises. Tout contrôle qui n'agit qu'au niveau de la pull request relit désormais l'histoire au lieu de la prévenir.

Pour la plupart des équipes, la question pratique n'est pas de savoir si Codex dispose de protections natives. C'est le cas, et elles sont sensément conçues. La question est de savoir si ces protections suffisent pour un usage quotidien. La réponse honnête est non. Le propre guide "Exécuter Codex en toute sécurité" d'OpenAI présente le bac à sable et les approbations comme une défense en profondeur, pas comme une frontière complète, et dès que vous passez en mode accès complet ou activez l'accès réseau dans le bac à sable, ces garde-fous tombent par conception. Une adoption sécurisée dépend toujours des permissions, de la discipline de bac à sable, de la supervision humaine et de la validation indépendante du code, des dépendances et des pipelines.

Comment fonctionne le modèle de sécurité de Codex

Le modèle de Codex est construit autour de trois idées : exécuter le travail dans un bac à sable, demander avant de faire quoi que ce soit qui s'en échappe, et garder le réseau fermé sauf si vous l'ouvrez. En pratique, cela se traduit par une poignée de contrôles.

C'est une base de référence véritablement réfléchie, et la majeure partie de cette liste n'existait pas dans les assistants d'IDE d'une génération précédente. Le piège est de la lire comme une frontière de sécurité achevée. OpenAI est explicite : le mode auto est un compromis plutôt qu'une garantie, le mode full-access et le flag --dangerously-bypass-approvals-and-sandbox suppriment le bac à sable à dessein, et activer l'accès réseau dans le bac à sable est un échange délibéré de sécurité contre capacité. Chaque contrôle de cette liste a un moyen documenté de le désactiver, et la section suivante porte sur ce qui se passe quand vous le faites, ou quand un attaquant le fait pour vous.

Les 6 principaux risques de sécurité d'OpenAI Codex

Les risques ci-dessous ne sont pas théoriques. Ils correspondent à des vulnérabilités documentées, à des recherches publiées et au Top 10 OWASP pour les applications LLM. Les chiffres qui les encadrent sont les mêmes que ceux que toute équipe AppSec cite désormais.

1. Injection de commande et exécution de code à distance

Codex écrit et exécute du code au niveau système, donc une faille dans la façon dont il gère ses propres entrées devient un chemin vers l'exécution de code. Ce n'est pas hypothétique. BeyondTrust Phantom Labs a divulgué une vulnérabilité critique d'injection de commande dans OpenAI Codex qui permettait le vol de jetons d'accès utilisateur GitHub, avec la charge utile dissimulée dans un nom de branche GitHub et masquée de l'interface à l'aide de caractères Unicode invisibles. Parce qu'elle vivait dans la requête de création de tâche, elle affectait d'un coup le site ChatGPT, le CLI Codex, le SDK Codex et l'extension d'IDE Codex.

OpenAI l'a corrigée (un correctif initial dans la semaine suivant le rapport de décembre 2025, des protections shell renforcées et une portée de jeton réduite début 2026, finalement classée Critique Priorité 1), donc ce bug spécifique est clos. Il reste l'illustration la plus claire de la surface : un agent qui exécute des commandes shell en votre nom transforme toute entrée non assainie qu'il lit, un nom de branche, un nom de fichier, une réponse d'outil, en un point d'injection potentiel. Le danger s'aggrave quand l'agent tourne avec un accès shell large et un mode permissif, car une chaîne de commandes individuellement inoffensives peut installer une dépendance, altérer une configuration de CI, ou ouvrir un mécanisme de persistance.

2. Chaîne d'approvisionnement (supply chain) et dépendances malveillantes

Codex installe des paquets, clone des dépôts et exécute des scripts de configuration dans le cadre d'un travail normal, et sa propre popularité en a fait une cible. TechRadar et d'autres médias ont rapporté un paquet npm, codexui-android, qui se faisait passer pour une interface distante de Codex, a attiré environ 29,000 téléchargements, et après une version initiale propre a poussé une mise à jour qui exfiltrait silencieusement le contenu du fichier d'identifiants Codex (~/.codex/auth.json), jetons d'accès, de rafraîchissement et d'identité, vers un serveur contrôlé par l'attaquant. Parce que le jeton de rafraîchissement (refresh token) n'expire pas, une seule installation compromise peut accorder un accès persistant et silencieux.

Cet incident s'inscrit dans un schéma plus large. Tout au long de 2025 et jusqu'en 2026, le typosquatting npm et les campagnes de paquets sosies ont de plus en plus ciblé les outils de code par IA et leurs écosystèmes. Le flux de développement lui-même devient le vecteur d'attaque : un package.json empoisonné, un hook post-installation malveillant, ou un assistant typosquatté peut transformer un prompt de routine "configure ce dépôt" en vol d'identifiants. L'hallucination de paquet l'aggrave : un agent qui invente avec assurance un nom de paquet plausible mais inexistant offre à un attaquant un créneau pour l'enregistrer et le militariser.

3. Injection de prompt et écriture d'exploit détournée

L'injection de prompt est le risque déterminant des outils de code agentiques, et c'est le risque LLM numéro un de l'OWASP pour la troisième année consécutive (LLM01). Un attaquant cache des instructions dans quelque chose que l'agent lit, un fichier, une page web, un ticket, le README d'une dépendance, la sortie d'un outil, et l'agent les suit, écrasant son comportement prévu.

Le cadre agentique aggrave les conséquences, car Codex ne fait pas que répondre ; il agit et il écrit du code au niveau système. Un agent détourné peut être poussé à écrire un exploit, à affaiblir un contrôle d'autorisation, à ajouter un chemin de désérialisation non sûr, ou à câbler une porte dérobée qui paraît correcte à un relecteur fatigué. La forme dangereuse est indirecte : vous n'avez pas à coller un prompt malveillant, vous avez seulement à pointer Codex vers un dépôt empoisonné ou à le laisser consommer une sortie d'outil hostile. Parce qu'un modèle de langage ne peut pas séparer de manière fiable une instruction de confiance d'une instruction malveillante intégrée dans des données, l'injection peut conduire à une exécution de commande, une exfiltration de données ou une manipulation de code silencieuse.

4. Bac à sable et modes d'approbation trop permissifs

La sécurité de Codex repose sur son bac à sable et ses invites d'approbation, et les deux peuvent être abaissés d'un seul flag. Choisir full-access (danger-full-access), ou activer l'accès réseau sortant à l'intérieur du bac à sable workspace-write, échange le garde-fou contre de la capacité, et OpenAI le dit clairement. Avec le bac à sable ouvert et le réseau accessible, le même agent qui était contenu il y a un instant peut désormais écrire en dehors de l'espace de travail et envoyer des données n'importe où.

Le mécanisme qui érode cela en pratique est la lassitude des approbations. Quand l'agent s'interrompt à répétition, les gens recourent à --ask-for-approval never, ou au préréglage full-auto, pour faire disparaître les invites. En une semaine, la valeur par défaut prudente est silencieusement devenue une autorisation globale, et personne n'a décidé qu'il en soit ainsi. La version au niveau de l'équipe est pire : un développeur tourne en read-only, un autre tourne en full-access parce que c'était plus rapide un vendredi, et au moment où ils partagent un dépôt ou un flux automatisé, la configuration la plus faible fixe la posture réelle de tout le monde.

5. Conservation des données et confidentialité

Codex est utile parce qu'il a du contexte, et ce contexte inclut couramment plus que le fichier devant vous : code source adjacent, configuration, variables d'environnement et parfois identifiants. Les agents génèrent et transmettent de grandes quantités de code privé en série, prompt après prompt, tâche après tâche. Pour les bases de code sensibles ou réglementées, la bonne question n'est pas seulement "la connexion est-elle chiffrée" mais "qu'est-ce qui est stocké, combien de temps, où, et qui peut y accéder".

L'exposition est souvent indirecte plutôt que spectaculaire. En résumant un dépôt ou en déboguant une erreur, l'agent peut faire remonter un jeton ou un point de terminaison interne dans une sortie qui atterrit ensuite dans une pull request, un ticket ou un chat, où il survit longtemps après la fin de la session. Les organisations adoptant Codex à grande échelle devraient examiner les conditions de traitement et de conservation des données d'OpenAI pour la surface qu'elles utilisent (l'API, les paliers business et entreprise diffèrent), tenir les secrets et les données réglementées hors de portée de l'agent, et traiter tout ce que l'agent émet comme potentiellement journalisé.

6. L'autonomie à grande échelle

La capacité qui rend Codex séduisant, lancer une tâche et revenir à une pull request finie, est aussi celle qui élargit l'écart de relecture. En mode cloud et multi-agent, Codex peut effectuer des changements importants et radicaux à travers de nombreux fichiers avec peu d'attention humaine entre-temps. Plus la tâche est autonome et de longue durée, plus le diff est grand, et plus la part qu'un humain lit réellement avant d'approuver est petite.

Cela compte pour la sécurité car la fenêtre permettant à un changement non sûr ou malveillant d'atterrir croît avec la taille du diff non lu. Une régression d'autorisation subtile, une dépendance injectée, ou une validation discrètement affaiblie est bien plus facile à manquer dans un changement autonome de 2,000 lignes que dans un changement de 20 lignes qu'un développeur a tapé délibérément. L'autonomie ne crée pas tant de nouvelles classes de vulnérabilités qu'elle ne supprime la friction naturelle qui les attrapait autrefois, ce qui est précisément pourquoi les contrôles ci-dessous s'appuient si fortement sur la relecture, le cadrage et la gouvernance au moment du prompt.

Ce que la sécurité native de Codex couvre, et ce qu'elle ne couvre pas

Les contrôles natifs sont réels, et il est utile d'être précis sur la ligne entre ce qu'ils gèrent et ce qu'ils vous laissent.

Lisez la colonne de droite comme le vrai travail. Les contrôles natifs sont le plancher : le bac à sable et la valeur réseau par défaut empêchent une erreur honnête, ou une seule commande détournée, de devenir un désastre à l'échelle de la machine. Ils n'ont pas été conçus pour arrêter un adversaire déterminé qui contrôle les entrées de l'agent, et OpenAI ne prétend pas qu'ils l'aient été. Tout ce qui transforme "Codex est installé" en "Codex est gouverné" vit dans les pratiques qui suivent.

Bonnes pratiques pour sécuriser OpenAI Codex

Ces neuf pratiques comblent l'écart entre la base de référence native et une vraie posture de sécurité. Aucune d'elles n'est exotique ; la discipline réside dans leur application cohérente à travers une équipe qui avance vite.

1. Gardez le bac à sable activé et full-access désactivé. Par défaut, utilisez read-only pour l'exploration et auto (workspace-write) pour le vrai travail, et traitez full-access (danger-full-access) et --dangerously-bypass-approvals-and-sandbox comme réservés aux conteneurs jetables. Confirmez que le bac à sable de l'OS est réellement engagé sur chaque plateforme où vous tournez, et ne le désactivez jamais sur une machine qui peut atteindre de vrais identifiants ou des hôtes de production.

2. Laissez le réseau fermé sauf si une tâche en a vraiment besoin. La valeur cloud par défaut d'aucun accès sortant est le garde-fou le plus précieux que Codex livre, car l'exfiltration a généralement besoin du réseau. N'activez l'accès réseau dans le bac à sable workspace-write que pour la tâche spécifique qui le requiert, restreignez-le à des destinations connues quand vous le pouvez, et désactivez-le ensuite plutôt que de le laisser ouvert par habitude.

3. Appliquez le moindre privilège aux dépôts et aux jetons. Donnez à Codex l'accès uniquement aux dépôts dont une tâche a besoin, préférez des jetons GitHub à courte durée de vie et à portée étroite plutôt que des jetons larges et persistants, et faites-les tourner selon un calendrier plutôt que d'attendre un incident. La divulgation de BeyondTrust rappelle qu'un seul jeton GitHub fuité peut atteindre tous les dépôts auxquels il a été accordé, donc la portée du jeton est la portée de la brèche.

4. Gouvernez les dépendances et les paquets. Restreignez les installations aux registres de confiance ou aux miroirs internes, exigez une approbation pour les nouveaux paquets, et analysez tout avec l'analyse de composition logicielle (SCA). Ne laissez pas l'agent installer automatiquement des paquets obscurs ou non vérifiés, aussi confiant soit-il dans ses suggestions, vérifiez qu'un paquet suggéré existe réellement avant de l'ajouter, et méfiez-vous particulièrement des outils d'assistance qui enveloppent Codex lui-même, c'est exactement là que vivait le voleur de jetons codexui-android.

5. Gardez un humain dans la boucle sur le code généré. Traitez la sortie de Codex comme un brouillon, pas comme une implémentation finale, et dimensionnez la relecture à la taille du changement. Acheminez le code généré et modifié à travers la relecture de pull request et les tests automatisés, avec une attention accrue sur l'authentification, la validation des entrées et les chemins privilégiés. L'objectif n'est pas la méfiance envers le modèle ; c'est qu'un agent produisant des milliers de lignes par jour, surtout en mode cloud, produira des failles subtiles plus vite qu'elles ne remontent d'elles-mêmes.

6. Exécutez le travail non fiable en isolation. Quand vous pointez Codex vers un dépôt inconnu, un ticket tiers, ou tout ce que vous n'avez pas rédigé, exécutez-le dans un conteneur ou une VM sans secrets hôtes montés et sans chemin vers la production. L'injection de prompt indirecte arrive exactement par ce genre de contenu, donc la défense la moins coûteuse est de s'assurer qu'un agent détourné n'ait rien de précieux à portée.

7. Gérez les secrets hors de portée. Gardez les secrets en clair entièrement hors du contexte de l'agent : utilisez un coffre-fort et injectez à l'exécution, expurgez les valeurs sensibles dans les journaux, et ne laissez pas l'agent lire des fichiers d'identifiants ou des contenus de .env dont il n'a pas besoin. Protégez le fichier d'identifiants Codex lui-même (~/.codex/auth.json) comme la cible de grande valeur qu'il est, et si un secret apparaît un jour dans un compte rendu ou une sortie, faites-le tourner immédiatement et enquêtez sur la façon dont il est arrivé là.

8. Contraignez l'autonomie en mode cloud et multi-agent. Cadrez étroitement les tâches de longue durée et asynchrones, préférez plusieurs changements relisables à un seul changement radical, et exigez une approbation humaine avant qu'une branche rédigée par Codex ne fusionne dans quoi que ce soit de protégé. Plus le diff autonome est grand, plus la relecture doit être délibérée, donc fixez des attentes (et des règles de protection de branche) qui correspondent au volume que Codex peut produire.

9. Définissez la politique par dépôt et par sensibilité d'environnement. Classez les dépôts (publics, internes, réglementés, production) et appliquez des contrôles plus stricts aux plus sensibles : modes read-only ou à portée étroite, réseau fermé, accès aux secrets refusé, relecture renforcée exigée. N'exécutez Codex contre des systèmes critiques que dans des environnements sans chemin direct vers les identifiants de production, et documentez la politique pour que les développeurs sachent où l'aide de l'IA est autorisée et sous quelles contraintes. Utilisez Codex Security et le SAST traditionnel comme apports d'assistance à cette relecture, pas comme un substitut à celle-ci.

Là où les contrôles natifs s'arrêtent : sécuriser l'agent au moment du prompt

Reparcourez les risques et un schéma émerge. Le bac à sable, les modes d'approbation et l'étape de relecture agissent tous sur ce que l'agent a déjà décidé de faire, ou sur du code qu'il a déjà écrit. Ils se regroupent autour de la pull request, car c'est là que l'AppSec a toujours vécu. Mais la PR n'a jamais été un point de contrôle que parce qu'un humain la lisait, et à la cadence de l'agent, surtout en mode cloud, plus personne ne la lit de bout en bout.

L'endroit où imposer une règle n'est plus le diff ; c'est le prompt, avant que la ligne non sûre ne soit écrite. Quelle que soit la règle que vous voulez que l'agent suive, elle doit être entre ses mains au moment où il écrit, pas en attente dans un scanner qui arrive une fois que le code est sur le disque et que l'agent est passé à la tâche suivante.

C'est la couche qu'ajoute VibeDefend. C'est un CLI npm gratuit qui s'installe en environ cinq secondes et branche OpenAI Codex (plus Claude Code, Cursor, Windsurf et VS Code Copilot) sur trois couches de gouvernance qui tournent à l'intérieur de la boucle de l'agent.

Règles métier Les conventions de votre dépôt qui n'ont jamais été écrites (utiliser Decimal128 pour l'argent, l'autorisation passe par requireOwner). VibeDefend les extrait de la façon dont votre équipe code déjà et les charge dans le contexte de l'agent avant chaque modification. Règles de sécurité OWASP Top 10, SOC 2, RGPD et ISO 27001, chargés le jour de l'installation. L'agent lit le rappel applicable avant d'écrire, de sorte que l'exigence du référentiel devient partie du code au lieu d'une case à cocher au moment de l'audit. Garde des actions Les appels destructeurs (un sudo rm -rf, une lecture brute d'une variable d'environnement en forme de secret, un psql ad hoc contre un hôte de production) sont interceptés avant de se déclencher. Avertissement ou blocage selon la règle, chaque interception consignée dans la piste d'audit.

Surtout, rien de votre code ne transite par le réseau. Les décisions se prennent localement à côté de l'agent ; seules des métadonnées de gouvernance structurées (la règle qui s'est déclenchée, le chemin du fichier, la sévérité, un horodatage) atteignent le backend. Les tenants UE et US sont physiquement séparés, et vous choisissez la région au moment de l'installation. Ce modèle de confidentialité est ce qui permet à un contrôle de se situer aussi près du code sans devenir lui-même un risque d'exfiltration de données, ce qui importe d'autant plus pour un agent dont le propre fichier d'identifiants a déjà été une cible de vol.

Ce n'est pas un remplacement des pratiques ci-dessus. C'est la couche manquante qu'elles supposent en place : celle qui met vos règles entre les mains de l'agent au moment du prompt, pour que la ligne non sûre soit réécrite avant même d'être suggérée, au lieu d'être attrapée trois étapes plus tard par un scanner lisant un diff que personne n'a eu le temps de lire. Le bac à sable empêche l'agent de faire ce qu'il ne doit pas faire ; VibeDefend façonne ce qu'il écrit en premier lieu.

Foire aux questions

OpenAI Codex est-il sûr ?

OpenAI Codex est sûr à utiliser lorsqu'il est mis en bac à sable et cadré, et risqué lorsqu'il ne l'est pas. Son bac à sable au niveau de l'OS, ses modes d'approbation hiérarchisés et son comportement réseau désactivé par défaut dans le cloud préviennent une large classe d'accidents et contiennent la plupart des commandes égarées. Le risque résiduel vient de la configuration (mode full-access, réseau activé, approbations désactivées), des entrées (injection de prompt, dépôts et paquets malveillants), et de l'autonomie à grande échelle (changements cloud massifs sous-relus). Traitez-le comme un agent puissant qui a besoin de moindre privilège, d'isolation et de relecture humaine, pas comme un outil sécurisé clé en main.

Quelle est la différence entre Codex et "Codex Security" ?

Ce sont deux choses différentes d'OpenAI qui partagent un nom. Codex est l'outil de code agentique : le CLI, l'extension d'IDE, le mode cloud et le SDK qui lisent votre dépôt, modifient des fichiers, exécutent des commandes et ouvrent des pull requests. Codex Security est un agent distinct de détection de vulnérabilités qui se connecte à un dépôt, construit un modèle de menace, analyse l'historique des commits, valide les problèmes candidats en isolation, et propose des correctifs pour relecture humaine. Ce guide porte sur la sécurisation de l'agent de code Codex. Codex Security est un apport d'assistance à la relecture de code, utile comme paire d'yeux supplémentaire, pas un programme de sécurité complet.

Codex exécute-t-il le code dans un bac à sable ?

Oui. Codex exécute les commandes dans un bac à sable au niveau du système d'exploitation : Seatbelt sur macOS, Landlock et seccomp sur Linux, et un bac à sable dédié sur Windows. Par défaut, les écritures sont limitées à l'espace de travail actif et, dans l'environnement cloud, l'accès réseau sortant est désactivé. Ces valeurs par défaut sont le coeur de son modèle de sécurité. Elles peuvent être abaissées délibérément avec full-access (danger-full-access) ou en activant l'accès réseau dans le bac à sable workspace-write, et OpenAI est explicite : le faire supprime la protection à dessein.

Codex peut-il fuiter mon jeton GitHub ou mes identifiants ?

Il le peut si vous n'êtes pas prudent, et il y a un précédent. BeyondTrust Phantom Labs a divulgué une vulnérabilité d'injection de commande qui permettait aux attaquants de voler des jetons d'accès utilisateur GitHub via un nom de branche forgé, à travers le site ChatGPT, le CLI Codex, le SDK et l'extension d'IDE ; OpenAI l'a depuis corrigée. Séparément, un paquet npm malveillant se faisant passer pour un assistant Codex a exfiltré le fichier d'identifiants Codex (~/.codex/auth.json) depuis environ 29,000 installations. Défendez le jeton en le cadrant étroitement, en le faisant tourner, en vérifiant tout outil d'assistance, et en protégeant le fichier d'identifiants comme un secret de grande valeur.

Codex envoie-t-il mon code à OpenAI ?

Codex envoie le contexte dont il a besoin aux modèles d'OpenAI pour générer des réponses, ce qui peut inclure du code, des contenus de fichiers et le contexte environnant de votre tâche. Ce qui est stocké et pour combien de temps dépend de la surface que vous utilisez et de votre palier (les conditions API, business et entreprise diffèrent sur la conservation et l'entraînement). Pour du code sensible, choisissez un palier et une configuration qui correspondent à vos exigences de traitement des données, tenez les secrets et les données réglementées hors de portée de l'agent, et examinez les politiques de conservation. Les métadonnées de gouvernance d'une couche ajoutée comme VibeDefend restent séparées et ne transmettent pas de code source.

Quel mode de bac à sable / d'approbation Codex devrais-je utiliser ?

Pour la plupart du travail, read-only pour explorer et auto (le bac à sable workspace-write avec approbation à la demande) pour effectuer des changements, avec le réseau laissé fermé. Réservez full-access (danger-full-access) et --dangerously-bypass-approvals-and-sandbox aux conteneurs jetables sans vrais identifiants, et évitez --ask-for-approval never sur toute machine qui peut atteindre la production ou les secrets. Adaptez le mode à la sensibilité du dépôt : plus le système est critique, plus le bac à sable doit être serré, plus l'approbation doit être fréquente, et moins l'agent doit avoir de réseau.

En quoi la sécurité de Codex diffère-t-elle de Claude Code, Cursor ou GitHub Copilot ?

Les fondamentaux sont partagés (moindre privilège, gestion des secrets, relecture humaine, analyse des dépendances), mais les surfaces diffèrent. Les surfaces distinctives de Codex sont son bac à sable au niveau de l'OS plus l'échappatoire full-access, ses incidents d'injection de commande et de chaîne d'approvisionnement (supply chain) npm, et l'écart de relecture du mode cloud autonome. Claude Code s'appuie sur une intégration MCP et shell profonde ; Cursor a eu Workspace Trust désactivé par défaut ; GitHub Copilot a lutté contre les suggestions non sûres et la fuite de secrets à grande échelle. Nous couvrons chaque agent dans son propre guide.