Guide

À quoi les agents de code IA ont-ils accès sur votre machine ?

Claude Code, Codex et Cursor tournent sous votre compte. Ce qu’ils peuvent atteindre sur un poste de développeur, leurs limites par défaut et les failles qui restent.

10 novembre 2026 · 8 min de lecture · Par l’équipe vetkit

La réponse courte

Un agent de code IA comme Claude Code, OpenAI Codex ou Cursor s’exécute sur votre machine sous votre compte utilisateur. Tout ce que ce compte peut lire, exécuter ou joindre sur le réseau est, en principe, à la portée de l’agent. Ce qui l’arrête réellement, c’est une combinaison de demandes d’approbation, d’un sandbox facultatif ou activé par défaut, et des réglages choisis par vous ou par votre dépôt.

Ces garde-fous sont réels et progressent vite, mais ils diffèrent d’un outil à l’autre, plusieurs sont désactivés ou assouplis par défaut, et chaque éditeur les présente comme des garde-fous plutôt que comme une frontière étanche. Mieux vaut savoir ce qui se trouve de l’autre côté.

Ce qui est à portée

Sur un portable de développeur classique, un processus lancé sous votre compte peut généralement atteindre :

Les identifiants stockés sur disque. Les clés SSH dans ~/.ssh, les identifiants cloud comme ~/.aws/credentials, les jetons de registre dans ~/.npmrc, les sessions CLI ouvertes pour GitHub, les fournisseurs cloud et les bases de données, ainsi que les fichiers .env de chaque projet que vous avez cloné.
Les autres projets. Code source, notes et configuration en dehors du dépôt dans lequel l’agent a été lancé.
Le réseau. N’importe quel domaine joignable depuis votre machine, y compris les sites de type pastebin, les services de partage de fichiers et des webhooks arbitraires.
Les outils à effets de bord. git push, les gestionnaires de paquets, les CLI cloud, les clients de base de données et kubectl, souvent déjà authentifiés.
Les emplacements persistants. Profils de shell, éléments d’ouverture de session, hooks git, ainsi que les fichiers de configuration et d’instructions de l’agent lui-même, qui déterminent ce que la session suivante aura le droit de faire.

Rien de tout cela ne suppose un agent malveillant. Les scénarios habituels sont banals : une commande qui en fait plus que prévu, une installation de dépendance qui exécute un script, ou des instructions cachées dans une page web, une issue ou un README que l’agent lit et suit (injection de prompt). Les trois éditeurs mettent en garde contre l’injection de prompt dans leur propre documentation de sécurité.

Comment Claude Code, Codex et Cursor le limitent

Ce tableau résume ce qu’indiquait la documentation de chaque outil le 10 novembre 2026. Les valeurs par défaut changent d’une version à l’autre : vérifiez votre propre version et vos réglages.

Limites par défaut de trois agents de code IA
Outil	Approbations par défaut	Sandbox des commandes	Option « tout ignorer »
Claude Code	Les sessions interactives démarrent en mode auto, où un classifieur examine les actions au lieu de vous solliciter à chaque fois ; un mode manuel demande avant les modifications et les commandes	Désactivé par défaut. Une fois activé (Seatbelt sous macOS, bubblewrap sous Linux), les écritures sont limitées au projet et le réseau passe par une liste d’autorisation, mais les lectures couvrent toujours la majeure partie de la machine, sauf si vous les interdisez	Mode `bypassPermissions` ; la documentation recommande de ne l’utiliser que dans des conteneurs ou des VM
OpenAI Codex	Dans les dossiers sous contrôle de version, écriture dans l’espace de travail avec approbation à la demande ; lecture seule ailleurs	Activé par défaut (Seatbelt sous macOS, bubblewrap et seccomp sous Linux) ; réseau coupé par défaut	`--dangerously-bypass-approvals-and-sandbox` (alias `--yolo`), signalé comme déconseillé
Cursor	Les actions sensibles demandent une approbation ; le mode d’exécution recommandé s’appuie sur un relecteur automatique, et les modifications de fichiers de l’espace de travail, hors fichiers de configuration, ne déclenchent pas de demande	Utilisé quand c’est possible dans le mode par défaut (Seatbelt sous macOS, Landlock sous Linux) ; les lectures hors de l’espace de travail sont autorisées avec le réglage d’accès en lecture par défaut	Mode « Run Everything », sans sandbox ni relecteur

Deux détails surprennent. D’abord, les sandbox restreignent surtout les écritures et le réseau, pas les lectures : dans le sandbox de Claude Code comme avec le réglage par défaut de Cursor, une commande peut encore lire des fichiers comme ~/.ssh tant que vous ne l’interdisez pas explicitement. Ensuite, le réglage par défaut qui paraît le plus sûr n’est pas forcément celui que vous utilisez, car un collègue, un alias shell ou un script de CI peut lancer l’agent avec les approbations désactivées.

Là où les limites s’arrêtent

Les commandes approuvées s’exécutent avec tous vos droits. La page sécurité de Claude Code précise qu’une commande Bash que vous approuvez peut toujours écrire partout où votre compte utilisateur le peut. Approuver npm install, c’est approuver chaque script d’installation qu’il récupère.
Les relecteurs automatiques sont eux aussi des modèles. Les modes auto réduisent la lassitude face aux demandes, mais un classifieur peut se tromper, et les éditeurs qualifient ces modes de « best effort ».
Les hooks ne sont pas une frontière de sécurité. Claude Code et Cursor indiquent que les hooks laissent passer par défaut en cas de timeout ou d’erreur (fail open), et Claude Code recommande le système de permissions, et non les hooks, pour les règles strictes d’autorisation ou d’interdiction.
Les dépôts embarquent de la configuration. Réglages de projet, définitions de serveurs MCP, hooks et fichiers d’instructions arrivent avec un git clone. Les outils attendent de plus en plus que vous ayez accordé votre confiance à un dossier avant de les appliquer, mais tous les réglages ne sont pas verrouillés de la même façon. Le guide des permissions passe en revue ce qu’un dépôt peut modifier.
Personne ne regarde après coup. Les demandes d’approbation protègent le moment où vous approuvez. Sans trace de ce que la session a réellement fait, la lecture d’un identifiant suivie d’un envoi ressemble à n’importe quel après-midi chargé.

Réduire ce qu’un agent peut atteindre

Activez le sandbox là où il est facultatif, et interdisez la lecture des chemins contenant des identifiants (Claude Code prend en charge filesystem.denyRead et le blocage des lectures hors du répertoire de travail ; Cursor propose un réglage de lecture limité à l’espace de travail).
Gardez l’accès réseau fermé par défaut et n’autorisez que les domaines dont une tâche a besoin.
N’utilisez les modes « tout ignorer » que dans un conteneur ou une VM jetable, sans aucun identifiant personnel monté, comme le recommandent les éditeurs eux-mêmes.
Utilisez des identifiants à courte durée de vie et au périmètre restreint sur les postes de développement, pour qu’un jeton divulgué vaille moins.
Relisez la configuration des agents comme du code. Fichiers de réglages, serveurs MCP et fichiers d’instructions dans une pull request méritent la même attention qu’une nouvelle dépendance.
Gardez une trace des sessions, pour pouvoir répondre après coup à la question « à quoi l’agent a-t-il touché ? ». Le guide de supervision compare les options.

La place de vetkit

vetkit aborde le sujet sous deux angles. Les contrôles « risques du code IA » de l’audit de dépôt signalent la configuration d’agent commitée qui élargit les accès : approbations désactivées, réglages qui pré-approuvent des commandes shell ou réseau arbitraires, hooks qui téléchargent et exécutent des scripts, serveurs MCP non épinglés ou récupérés à distance, identifiants dans la configuration MCP et texte caché dans les fichiers d’instructions des agents.

Agent Watch, une application de bureau pour les machines d’équipe, enregistre ce que les agents de code IA font réellement pendant une session : lectures d’identifiants, nouvelles destinations réseau, commandes destructrices, écritures hors du projet et modifications de leurs propres réglages. Il observe et signale ; il ne bloque aucune action, et il envoie des alertes et des résumés de session plutôt que le contenu des fichiers ou les prompts. Consultez la documentation d’Agent Watch pour la disponibilité et le modèle de confidentialité.

Sources

Nous avons relevé les informations sur chaque outil dans sa propre documentation le 10 novembre 2026. Les pages de chaque éditeur font foi :

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.