Sécurité de Codex en pratique : permissions, sandbox et protection contre les fuites de secrets

Votre racine de projet contient un fichier .env avec le mot de passe de base de données et des clés API tierces. Vous ouvrez Codex pour lui demander de refactorer les tests. Dans le menu, trois choix apparaissent : read-only, workspace-write, danger-full-access. Lequel choisir ?

Après avoir choisi workspace-write, Codex demande l’autorisation d’exécuter npm install. Vous validez. Avez-vous vérifié si le script postinstall oublié dans package.json peut, à ce moment-là, lire vos variables d’environnement ou envoyer une requête vers un service que vous ne connaissez pas ?

Vous mettez Codex dans GitHub Actions pour automatiser les PR reviews. Le workflow contient OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}. Vous pensez que les secrets sont sûrs. Mais avez-vous pensé que les scripts de test, les third-party actions et les hooks d’installation de dépendances du même job peuvent aussi lire cette clé ?

Trois limites répondent directement à ces questions : une instruction n’est pas une permission, une approbation n’est pas une isolation, une sandbox n’est pas un audit. Voici la checklist de permissions minimales pour les scénarios local, Cloud et CI.

Les permissions ne reposent pas sur des consignes verbales : comprendre les trois limites sandbox, approval et permission profile

Beaucoup de gens pensent qu’une ligne dans AGENTS.md disant « ne lis pas le fichier .env » suffit à empêcher Codex d’accéder aux informations sensibles. Ce n’est pas du contrôle de permissions, mais une règle de projet. La vraie limite de sécurité vient de trois couches : la sandbox limite le périmètre des spawned commands, l’approval policy décide quand Codex s’arrête pour demander confirmation, et le permission profile applique un contrôle d’accès forcé.

La sécurité de Codex ne tient pas avec une seule couche. La sandbox détermine ce que git, les gestionnaires de paquets et les test runners peuvent atteindre en tant que spawned commands. L’approval policy décide si Codex doit obtenir votre accord avant une opération critique. Le permission profile est la couche de configuration où l’on peut réellement écrire "**/*.env" = "deny". Les trois ensemble forment les permissions effectives.

Comparatif des modes sandbox : read-only, workspace-write, danger-full-access

La sandbox encadre les spawned commands, pas seulement les opérations fichier intégrées à Codex. git, les gestionnaires de paquets et les test runners héritent de la même frontière. Les prérequis de plateforme comptent aussi : Linux/WSL2 s’appuie sur bubblewrap ou user namespace, macOS sur la sandbox système, et Windows dépend des capacités de sandbox disponibles.

L’approval policy décide quand Codex doit s’arrêter pour demander :

Les combinaisons à faible risque sont read-only + never pour les contrôles CI en lecture seule et workspace-write + on-request pour le développement local. La combinaison à haut risque est danger-full-access + never, à réserver aux environnements contrôlés.

Configuration permission profile : filesystem deny, network rules

Le permission profile est un contrôle d’accès forcé, pas une consigne verbale. Les permissions filesystem supportent read/write/deny. Les règles plus spécifiques écrasent les règles plus larges, et deny a la priorité.

Exemple de deny glob pour .env :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

{
  "filesystem": {
    "rules": {
      "**/*.env": "deny",
      "**/.env.local": "deny",
      "**/secrets/**": "deny",
      "workspace/**": "write"
    }
  }
}

Cette configuration rend les fichiers .env illisibles même en workspace-write, même si le workspace est globalement inscriptible. deny est prioritaire, et les règles précises écrasent les règles larges.

Un network profile peut configurer enabled = true avec des domaines allow/deny, et deny reste prioritaire. Les réseaux local/private ont une protection par défaut ; autoriser localhost ou Docker socket est une exception explicite. Docker socket est un escape hatch local : il peut atteindre services locaux, conteneurs et réseaux. À ouvrir avec prudence.

Le network proxy limite l’accès réseau des commandes déjà lancées ; il ne donne pas le réseau à lui seul. Un allow global * équivaut à un accès réseau large et doit rester rare.

Checklist locale de permissions minimales : du review read-only au full access

En local, plus de droits ne veut pas dire moins de problèmes. L’approbation peut arrêter certaines opérations, mais l’isolation réelle vient de la sandbox et du permission profile. Commencez par les permissions les plus étroites, puis élargissez selon la tâche.

Tableau de décision : quand utiliser read-only, quand utiliser workspace-write

Étapes pour protéger .env et les fichiers de secrets :

1. Identifiez le chemin du fichier de configuration permission profile utilisé, selon la documentation Codex Permissions.
2. Ajoutez "**/*.env" = "deny" dans les permissions filesystem.
3. Vérifiez que les règles spécifiques écrasent les règles larges et que deny est prioritaire.
4. Testez : en mode workspace-write, une tentative de lecture de .env doit être refusée.
5. Étendez si besoin avec "**/.env.local" = "deny" et "**/secrets/**" = "deny".

Ne vous reposez pas sur les consignes verbales. AGENTS.md guide le comportement, mais n’applique pas de contrôle d’accès forcé. Codex peut suivre la consigne, ou lire pour une autre raison. Seul un deny dans le permission profile est contraignant.

Risques d’installation de dépendances : npm postinstall, pip hooks, Docker socket

Installer des dépendances ne se limite pas à télécharger des fichiers. Les scripts postinstall et prepare de npm/pnpm, ainsi que les hooks de pip install, s’exécutent automatiquement. Ils peuvent lire des variables d’environnement, envoyer des requêtes réseau ou modifier des fichiers système.

Checklist des risques :

• Un postinstall inconnu peut lire des variables d’environnement : même avec un deny .env, postinstall s’exécute dans l’environnement des spawned commands et peut voir les environment variables.
• Il peut envoyer des requêtes réseau : télécharger un binaire supplémentaire, envoyer de la télémétrie, joindre un dépôt privé.
• Il peut modifier des fichiers système : écrire une configuration globale, modifier PATH.

Recommandations d’audit :

1. Vérifiez d’abord les scripts et l’origine : champ scripts de package.json, setup.py des paquets pip.
2. Utilisez des sources fiables : verrouillez les versions et évitez les mises à niveau automatiques vers des versions inconnues.
3. Approuvez dans un environnement maîtrisé : en local, utilisez workspace-write + on-request et lisez ce que Codex veut installer avant de valider.

Docker socket est un escape hatch local. L’autoriser peut donner accès aux services locaux, aux conteneurs et au réseau. Ne le configurez que si le besoin est clair, jamais par défaut.

Frontières Cloud : setup vs agent phase, cycle de vie des secrets

Une Cloud task ne tourne pas en local, mais dans un conteneur isolé hébergé par OpenAI. La sandbox peut encadrer les spawned commands, mais la protection des secrets vient surtout du cycle de vie des Cloud secrets : disponibles pendant setup, supprimés avant l’agent phase. La sandbox n’est pas un audit ; la sécurité vient de la séparation des couches.

Cycle de vie du Cloud container :

1. Créer le container
2. checkout le repo
3. Exécuter le setup script
4. Appliquer les paramètres réseau
5. L’agent exécute sa boucle de commandes
6. Produire answer/diff

Frontière setup vs agent phase : les secrets seulement dans setup

Pendant setup, le réseau est disponible, les dépendances peuvent être installées et les secrets sont accessibles. Pendant l’agent phase, l’environnement est hors ligne par défaut, les secrets ont été supprimés, et seules les environment variables restent.

Les setup scripts tournent dans une session Bash séparée. Un export ne passe donc pas automatiquement dans l’agent phase. Si vous faites export MY_KEY=xxx dans setup, l’agent phase n’hérite pas de cette variable. Seuls Cloud secrets et environment variables traversent les phases selon leurs règles.

secrets vs environment variables : différence essentielle

Les secrets ne sont disponibles que dans les setup scripts. Ils conviennent à l’installation de dépendances et à l’accès aux dépôts privés. L’agent phase ne doit pas contenir de secrets de production. Les environment variables restent tout du long et conviennent aux paramètres non sensibles.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Frontières d’installation des dépendances :

• La phase setup peut installer des dépendances avec réseau.
• L’agent phase est hors ligne par défaut.
• Les setup scripts peuvent accéder aux secrets ; un script inconnu peut les faire fuiter.
• Recommandation : relire les scripts et l’origine, utiliser des sources fiables et éviter d’exécuter des scripts inconnus dans setup.

Le container cache dure au maximum 12 heures. Les changements de setup, maintenance, env ou secrets déclenchent une cache invalidation.

CI et GitHub Action : codex exec, interdits autour des API keys, stratégie de sécurité de l’official Action

codex exec utilise par défaut une sandbox read-only, mais beaucoup de workflows placent OPENAI_API_KEY comme job-level environment variable. Dans le même job, les scripts de test, third-party actions et lifecycle scripts de dépendances peuvent lire cette clé. La sandbox n’est pas un audit ; la sécurité vient des permissions minimales et de la protection de la clé.

Interdit API key : ne pas la mettre en job-level env

Ne définissez pas OPENAI_API_KEY ou CODEX_API_KEY comme job-level environment variable dans un workflow qui checkout ou exécute le code du dépôt. Le code du dépôt, les tests, les lifecycle scripts et les third-party actions peuvent toujours accéder aux variables d’environnement dans le même job.

Checklist des interdits :

• Ne pas mettre OPENAI_API_KEY en job-level env.
• Ne pas définir de job-level key dans un workflow qui checkout ou exécute le code du dépôt.
• auth.json / ChatGPT-managed auth ne convient pas aux workflows de dépôts public/open-source.
• Ne pas exécuter du code non fiable dans le même process environment que la clé.

Bonnes pratiques :

1. Invocation inline unique : définir CODEX_API_KEY seulement pour une invocation codex exec.

- name: Run Codex
  run: CODEX_API_KEY=${{ secrets.CODEX_API_KEY }} codex exec "review PR #${{ github.event.number }}"

2. Proxy de l’official Action : utiliser le proxy de openai/codex-action@v1.

- uses: openai/codex-action@v1
  with:
    prompt: "review PR #${{ github.event.number }}"
    sandbox: read-only
    safety-strategy: drop-sudo

En CI, danger-full-access ne convient qu’à un isolated CI runner/container. Ce ne doit pas être l’option par défaut. Toutes les ressources du runner peuvent devenir accessibles.

Checklist de sécurité GitHub Action : limiter les déclencheurs, protéger la clé, faire tourner la clé

Paramètres de l’official Action :

read-only ne signifie pas que tous les secrets du runner sont protégés. L’Action tourne toujours sur le runner ; elle limite surtout le filesystem en lecture. drop-sudo retire sudo. sandbox doit être le mode le plus étroit qui permet de finir la tâche.

Checklist de sécurité GitHub Action :

• Limiter les déclencheurs : allow-users pour des utilisateurs précis, allow-bots avec prudence.
• Nettoyer les entrées PR/issue/prompt : éviter prompt injection et ne pas donner directement une entrée non fiable à Codex.
• Protéger l’API key : pas de job-level env, utiliser une invocation inline unique ou le proxy.
• Exécuter Codex en dernière étape : réduire la durée d’exposition de la clé.
• Faire tourner la clé en cas de suspicion de fuite : ne pas enquêter d’abord, limiter d’abord les dégâts.

Les entrées PR/issue/prompt doivent être traitées comme non fiables. Ne donnez pas directement un PR comment ou un issue body au prompt Codex.

Réaction à une fuite de secret : le premier geste après une suspicion

En cas de suspicion de fuite, le premier geste n’est pas l’enquête, mais la rotation de la clé. Limitez d’abord les dégâts, auditez ensuite. La sandbox peut limiter les spawned commands, mais elle ne peut pas empêcher Codex d’écrire une clé dans les logs, un PR comment ou une answer.

Étapes de réaction : rotation de clé, audit, révocation

Première étape : faire tourner la clé. Ne cherchez pas d’abord l’origine ; rendez l’ancienne clé invalide.

Étapes suivantes :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

1. Auditer les logs : vérifier l’historique d’utilisation de la clé et repérer les appels anormaux.
2. Révoquer le token : s’assurer que l’ancienne clé est complètement invalide et qu’aucune session active ne reste.
3. Identifier la source : inspecter Codex log, sorties GitHub Action, scripts d’installation de dépendances et third-party actions.

Mesures de prévention :

• Ne pas mettre de clé API dans le code frontend ou le dépôt.
• Ne pas mettre de clé API en job-level env (CI).
• Utiliser permission profile deny pour .env.
• Faire tourner régulièrement les clés, comme le recommande l’OWASP Secrets Management Cheat Sheet.

Limites de Codex Security : ne remplace pas SAST et n’applique pas les patchs automatiquement

Codex Security est un LLM-driven security analysis toolkit qui tourne dans un ephemeral isolated container et produit des findings structurés ainsi que des suggestions de patch. Il peut aider à découvrir et valider des vulnérabilités, mais ne remplace pas SAST ni la revue de sécurité humaine.

Checklist des limites :

• Ne remplace pas SAST.
• Ne remplace pas manual security review.
• Un proposed patch doit être reviewed par l’utilisateur ; il n’est pas appliqué automatiquement.
• Son rôle : aider à trouver, vérifier et suggérer, pas réparer automatiquement.

Ne traitez pas Codex Security comme un scanner de sécurité universel. L’AI-driven analysis peut trouver certains problèmes, mais la vraie sécurité vient des couches : périmètre lisible, périmètre inscriptible, réseau, secrets, approval, review et révocation.

Conclusion

La limite de sécurité de Codex vient de trois couches : sandbox limite les spawned commands, approval policy décide quand s’arrêter et demander, permission profile applique le contrôle d’accès. Les trois ensemble forment les permissions réelles.

Trois limites à retenir :

• Une instruction n’est pas une permission : AGENTS.md est un guide, pas un contrôle d’accès forcé. Ne protégez pas .env et les API keys par une simple consigne.
• Une approbation n’est pas une isolation : approval policy peut arrêter certaines actions, mais l’isolation réelle vient de sandbox et permission profile.
• Une sandbox n’est pas un audit : sandbox peut limiter les spawned commands, mais ne peut pas empêcher Codex d’écrire une clé dans les logs, un PR comment ou une answer. La sécurité vient de couches.

Checklist rapide :

• Avez-vous configuré un deny glob pour .env ?
• Évitez-vous les API keys en job-level env dans CI ?
• Limitez-vous les déclencheurs de GitHub Action ?
• Avez-vous audité les scripts d’installation de dépendances ?
• Avez-vous un plan de rotation des clés ?

Les limites de sécurité ne bloquent pas les bugs logiques. Codex peut respecter toutes les règles de permission et générer tout de même un code avec bug, des tests peuvent échouer, un rollback peut rester nécessaire. Valider le diff, lancer les tests et préparer un plan de rollback : c’est la deuxième ligne de défense, en dehors de la frontière de sécurité.

Prochaines étapes :

• Rétrospective d’échec et processus de validation : comprendre comment traiter une erreur Codex, valider un diff et préparer un rollback.
• Automatisation codex exec et CI : approfondir le mode non interactif, la conception de workflows et la gestion des erreurs en CI.
• Règles de projet AGENTS.md : apprendre à écrire des règles de projet, tout en gardant en tête qu’il s’agit d’un guide, pas d’un système de permissions.

Lectures complémentaires :

• Panorama des outils AI coding 2026 : comprendre l’écosystème global des outils de code IA.
• Bases de GitHub Actions CI : revoir les concepts de base des workflows CI.
• Stratégie de déploiement GitHub Actions : comprendre les limites d’utilisation des secrets en déploiement.
• Risque de fuite de clé API frontend : comprendre pourquoi les clés ne doivent pas entrer dans le frontend ou le dépôt.