Permissions des agents de code IA et mode YOLO : une configuration plus sûre

Les modes de permission dans trois outils

Tout agent de code IA arbitre entre deux choses : la fréquence à laquelle il vous interrompt, et ce qu’il peut faire sans demander. Les réglages portent un nom différent dans chaque outil, mais la logique est la même : un mode qui demande, un mode qui laisse un relecteur automatique décider, et un mode qui ignore tout, surnommé mode YOLO.

Ce que les modes « tout ignorer » contournent vraiment

Ces modes suppriment bien plus que les demandes de confirmation. Dans Codex, le flag supprime à la fois les approbations et le sandbox. Cursor décrit Run Everything comme l’exécution automatique de chaque appel d’outil, sans sandbox ni relecteur. Le mode bypass de Claude Code saute aussi les demandes pour les écritures dans son propre répertoire .claude et dans .git.

Les éditeurs sont cohérents sur la place de ces modes : Claude Code recommande de n’utiliser le mode bypass que dans des environnements isolés comme des conteneurs ou des VM, et Codex signale son flag comme présentant un risque élevé et déconseillé. Même dans un conteneur, tout ce qui y est monté, comme un identifiant cloud ou un agent SSH, reste exposé. Le guide sur ce à quoi les agents ont accès liste ce que cela inclut généralement.

Ce qu’un dépôt peut modifier

La configuration des agents vit de plus en plus dans le dépôt, à côté du code : réglages .claude/, .codex/config.toml, .cursor/mcp.json, définitions de hooks et fichiers d’instructions comme AGENTS.md et CLAUDE.md. C’est pratique pour les équipes, et cela signifie qu’un git clone peut changer le comportement d’un agent.

• Les validations de confiance aident. Codex ne charge la couche .codex/ d’un projet qu’après que vous avez fait confiance au projet. Claude Code n’applique les règles allow d’un dépôt qu’une fois que chaque membre de l’équipe a accordé sa confiance au dossier, et ignore bypassPermissions comme mode par défaut dans les réglages de projet.
• Tout n’est pas verrouillé de la même façon. Les hooks, les définitions de serveurs MCP et les fichiers d’instructions arrivent toujours avec le dépôt ; les serveurs MCP ont leur propre demande d’approbation, et la confiance d’espace de travail de Cursor est désactivée tant que vous ne l’activez pas.
• Les anciennes versions se comportent différemment. Un réglage que les versions actuelles ignorent peut encore être respecté par un ancien client sur la machine de quelqu’un, et sa présence indique que le projet s’attend à ce que des agents tournent sans surveillance.

Les réglages d’agent à ne pas commiter

Voici les schémas à repérer en revue avant qu’ils n’atteignent la branche principale :

• Approbations désactivées : bypassPermissions comme mode par défaut, un sous-agent avec permissionMode: bypassPermissions, ou un script de package qui lance un agent avec --dangerously-skip-permissions ou --dangerously-bypass-approvals-and-sandbox.
• Règles allow qui pré-approuvent n’importe quoi : Bash(*), ou des jokers sur des shells, des interpréteurs, des lanceurs de paquets et des outils réseau, comme Bash(curl:*) ou Bash(npx:*).
• Hooks qui téléchargent et exécutent un script, par exemple en redirigeant curl vers un shell.
• Serveurs MCP non épinglés, lancés depuis un script distant, joints en HTTP simple ou configurés avec un identifiant codé en dur.
• Texte caché dans les fichiers d’instructions : commentaires HTML ou Unicode invisible dans AGENTS.md ou CLAUDE.md, qu’un relecteur ne voit pas mais que l’agent lit.

{  "permissions": {    "defaultMode": "bypassPermissions",    "allow": ["Bash(*)", "Bash(curl:*)", "Bash(npx:*)"]  }}

Une base plus sûre

1. Gardez le mode par défaut ou le mode auto sur les portables ; réservez les modes « tout ignorer » aux environnements jetables.
2. Commitez des règles allow étroites pour les commandes exactes que votre projet exécute, et interdisez la lecture des secrets.
3. Épinglez les versions des serveurs MCP et gardez leurs identifiants dans des variables d’environnement, pas dans le fichier.
4. Activez le sandbox là où il est facultatif, et limitez l’accès réseau à une liste d’autorisation.
5. En revue, traitez les modifications de la configuration des agents et des fichiers d’instructions comme des changements sensibles pour la sécurité.

{  "permissions": {    "allow": ["Bash(npm run test:*)", "Bash(npm run lint)"],    "deny": ["Read(./.env)", "Read(./secrets/**)"]  }}

Une règle allow qui se termine par un joker n’est sûre que si la commande qui la précède l’est : une règle pour npm run test est étroite, une règle pour node ou curl ne l’est pas.

La place de vetkit

L’audit de dépôt de vetkit vérifie la configuration d’agent commitée dans le cadre de sa suite « risques du code IA » : réglages et flags de contournement des approbations, règles allow qui pré-approuvent des commandes shell ou réseau arbitraires, hooks qui exécutent des scripts distants, serveurs MCP non épinglés ou lancés à distance, serveurs MCP en HTTP simple ou avec des identifiants codés en dur, et commentaires cachés ou Unicode invisible dans les fichiers d’instructions des agents. Les mêmes règles sont partagées avec le serveur @vetkit/mcp et avec Agent Watch, qui signale ce que les agents font réellement sur les machines de l’équipe ; le guide de supervision couvre cet aspect.

Sources

Nous avons relevé les informations sur chaque outil dans sa propre documentation le 10 novembre 2026 :

• Claude Code : permissions, réglages et sécurité
• OpenAI Codex : approbations et sécurité des agents et bases de la configuration
• Cursor : modes d’exécution et sécurité des agents

Les noms de produits sont des marques de leurs propriétaires respectifs. vetkit n’est ni affilié à ceux-ci, ni approuvé ou sponsorisé par eux. Vous avez repéré une information obsolète ? Écrivez à contact@vetkit.dev et nous la corrigerons.