Claude Code et sécurité : permissions, données et bonnes pratiques

Depuis la version 2.1.283, une session Claude Code ouverte dans un terminal ou dans VS Code démarre en mode auto. L'agent n'attend plus votre feu vert avant de lancer une commande : un second modèle relit chaque action et bloque celles qu'il juge dangereuses. C'est confortable, et cela déplace la question de la sécurité. Les règles de permission, les hooks et ce classifieur jugent tous le texte d'une commande. Ce que l'agent peut réellement lire, modifier et joindre sur le réseau se décide ailleurs, dans le bac à sable du système et dans ce que vous laissez à sa portée.

Chez Noxcod, nos agents tournent tous les jours sur un serveur Linux dédié plutôt que sur nos portables, avec un garde-fou branché en hook devant chaque commande shell. Nous l'avons rejoué le 22 octobre 2026 pour préparer cet article. Il refuse un rm -rf, un git reset --hard ou une suppression écrite en Python sur une ligne. Il laisse passer make clean et npm run reset-db, parce que l'effet de ces deux commandes vit dans un fichier qu'il ne lit pas. Cet article s'adresse au responsable technique qui outille ses développeurs : ce que chaque mode laisse faire, où partent vos données, et le réglage que nous imposerions dès le premier jour.

Ce que Claude Code fait sans vous demander, mode par mode

Sans réglage de votre part, Claude Code lance aujourd'hui presque tout sans vous demander, puisque le mode auto est devenu le mode de départ et qu'un classifieur y valide les actions à votre place. La documentation des modes de permission en compte six, du plus prudent au plus permissif. Le mode Manuel, nommé default dans les réglages, ne laisse passer que les lectures. Le mode acceptEdits ajoute les modifications de fichiers et quelques commandes comme mkdir, mv ou rm dans le dossier du projet. Le mode Plan explore sans rien modifier. Le mode dontAsk refuse tout ce qui demanderait une validation, ce qui en fait le bon choix pour l'intégration continue. Le mode bypassPermissions laisse tout passer, et Anthropic le réserve aux conteneurs et aux machines virtuelles isolés.

Le mode auto se place entre les deux extrêmes. Selon la liste publiée par Anthropic, son classifieur bloque par défaut le téléchargement suivi d'une exécution (curl | bash), l'envoi de données sensibles vers l'extérieur, les déploiements et migrations de production, le push --force, le git reset --hard et l'affichage d'un jeton valide dans la conversation. Après trois blocages consécutifs ou vingt au total, il se met en pause et les demandes de validation reviennent. La même page prévient que ce mode réduit les demandes sans garantir la sécurité.

Deux détails surprennent les équipes. Un ensemble fixe de commandes jugées en lecture seule, dont cat, grep, find et git status, s'exécute sans demande dans tous les modes, et cette liste n'est pas modifiable : pour l'encadrer, il faut une règle ask ou deny. Ensuite, depuis la version 2.1.302, un lancement non interactif en claude -p démarre en mode Manuel et refuse tout appel qui aurait demandé une validation, puisque personne n'est là pour répondre. Si vous découvrez l'outil, notre fiche sur Claude Code résume son périmètre avant d'entrer dans ces réglages.

Pourquoi une règle de permission ne protège pas une commande écrite autrement

Une règle de permission compare le texte de la commande écrite par Claude à un motif, donc elle arrête la forme habituelle d'une action et laisse passer la même action formulée autrement. La documentation des permissions en donne des exemples précis. Une règle qui refuse git push ne voit pas git -C . push origin main. Une règle qui refuse rm ne voit ni /bin/rm -rf build/ ni la même commande enveloppée dans bash -c. Anthropic écrit en toutes lettres qu'une telle règle couvre l'invocation que Claude produit d'habitude et ne constitue pas une frontière de sécurité autour du programme.

Les hooks partagent cette limite, et notre propre mesure du 22 octobre l'illustre. Notre garde-fou lit chaque commande avant qu'elle parte et reconnaît bien les suppressions déguisées en une ligne de Python ou de Node. Il ne peut rien dire d'un make clean, parce que ce que fait cette cible est écrit dans un Makefile qu'il n'ouvre pas. Il reste utile contre les maladresses de l'agent, comme les autres pièces de notre méthode avec hooks, skills et MCP, sans jamais faire office de barrière.

Les règles de lecture ont la même frontière. D'après la référence des réglages, une règle Read(./.env) s'applique aux outils de fichiers intégrés, aux commandes shell que Claude Code reconnaît (cat, head, tail, sed, tee) et aux redirections. Elle ne s'applique pas à un grep -r sur tout le dossier, ni à un sous-processus quelconque. Un script de test qui charge le fichier .env, ou une ligne de Python qui l'ouvre, le lira sans que la règle intervienne.

Le classifieur du mode auto voit plus large qu'un motif, puisqu'il vérifie que l'action correspond à votre demande. À notre sens, il reste un modèle qui lit du texte, donc un modèle qu'un texte peut orienter. Un fichier piégé, une page web ou un ticket rédigé par un attaquant entre dans la conversation au même titre que vos consignes : c'est tout le principe de la prompt injection. Face à une erreur de l'agent, ces trois couches suffisent souvent. Face à quelqu'un qui pilote l'agent à votre place, il faut une limite que le texte ne peut pas négocier.

Le bac à sable, la seule barrière que le système d'exploitation fait respecter

Le bac à sable de Claude Code enferme chaque commande shell dans une limite appliquée par le système d'exploitation, quelle que soit la façon dont la commande est écrite, mais il est désactivé par défaut. On l'active avec la commande /sandbox ou par la clé sandbox.enabled dans les réglages. Il s'appuie sur Seatbelt sous macOS, sur bubblewrap et socat sous Linux et WSL2.

Ses réglages par défaut méritent d'être lus de près. Les écritures sont limitées au dossier du projet et à un dossier temporaire. Le réseau ne sort que par un proxy local qui vérifie chaque domaine contre une liste, vide au départ. Les lectures, elles, couvrent la plus grande partie de la machine, y compris ~/.ssh et ~/.aws/credentials, et les variables d'environnement sont héritées avec les secrets qu'elles contiennent. Activer le bac à sable ferme donc d'abord la porte de sortie. Pour fermer celle des fichiers, il faut ajouter des entrées denyRead ou un bloc credentials qui interdit ou masque les clés.

Le bac à sable a un avantage que les équipes sous-estiment. Les règles Read en refus y sont fusionnées dans la liste des chemins interdits, ce qui rend votre Read(./.env) opposable à n'importe quel sous-processus lancé dans le bac à sable. Il fait aussi gagner du temps : Anthropic indique que, dans son usage interne, il a réduit les demandes de permission de 84 %, puisque les commandes contenues dans la limite n'ont plus besoin d'être validées une à une.

Ses limites sont documentées, et trois d'entre elles changent la configuration. Quand une commande échoue dans le bac à sable, Claude peut demander à la relancer en dehors : le réglage allowUnsandboxedCommands: false supprime cette échappatoire. Les hooks, les serveurs MCP locaux et la ligne d'état tournent hors du bac à sable avec tous vos droits. Enfin, autoriser un domaine large comme github.com ouvre une voie d'exfiltration, car le proxy décide sur le nom d'hôte sans inspecter le trafic chiffré.

Ce que l'agent lit part chez le fournisseur et reste en clair sur votre disque

Tout ce que Claude Code lit ou affiche entre dans la conversation : ce contenu part chez le fournisseur du modèle avec chaque requête, et il reste stocké en clair sur votre machine pendant 30 jours. La page sur l'usage des données précise que les invites et les réponses du modèle transitent chiffrées en TLS 1.2 ou plus, et que les transcriptions locales sont conservées en texte brut sous ~/.claude/projects/, une durée réglable par cleanupPeriodDays. Un secret lu une seule fois par l'agent se retrouve donc dans deux endroits que vous ne surveillez pas.

Le piège qui nous a fait écrire une règle ne venait pas d'une lecture volontaire. Charger un fichier de secrets avec source .env paraît anodin. Il suffit qu'une valeur contienne une barre verticale, ce qui arrive avec certains formats de jetons, pour que le shell coupe la ligne en deux et exécute la seconde moitié comme une commande. Nous l'avons reproduit avec un faux jeton 12|fauxSecretPourDemo. La variable reste vide, et le shell affiche « fauxSecretPourDemo: command not found ». Le message d'erreur contient la partie secrète, il remonte à l'agent, puis à la transcription.

Notre règle depuis est simple à appliquer. Aucun fichier de secrets n'est chargé par source : la valeur est lue par un vrai analyseur, Python ou jq, puis passée directement dans l'en-tête de la requête qui en a besoin. Côté Claude Code, trois réglages complètent ce geste. Les règles Read en refus couvrent .env et vos dossiers de secrets. Le bloc credentials du bac à sable peut masquer une clé : la commande ne voit qu'un substitut, que le proxy remplace par la vraie valeur sur les seuls domaines autorisés. La variable CLAUDE_CODE_SUBPROCESS_ENV_SCRUB retire les identifiants de l'environnement de tous les sous-processus.

La télémétrie inquiète souvent à tort. D'après la section consacrée à la télémétrie, les métriques d'usage n'incluent jamais votre code, vos invites ni vos chemins de fichiers, et les rapports d'erreur sont expurgés des motifs de secrets connus avant de partir. Le vrai point d'attention est ailleurs. La commande /feedback envoie une copie de la conversation, code compris, et ces rapports sont conservés cinq ans. Répondre « Oui » au questionnaire qui suit une évaluation de session envoie aussi la transcription, gardée jusqu'à six mois. Sur un dépôt client, nous recommandons de couper ces deux canaux.

Entraînement et rétention : tout dépend du contrat sous lequel tourne Claude Code

Anthropic n'entraîne pas ses modèles sur le code envoyé sous conditions commerciales, alors qu'un compte personnel Free, Pro ou Max alimente l'entraînement si son réglage de confidentialité l'autorise. Les conditions commerciales couvrent les offres Team et Enterprise, l'API et les plateformes tierces comme Amazon Bedrock. La seule exception côté entreprise est volontaire : une organisation peut s'inscrire au programme de partenariat développeur et fournir ses données pour l'entraînement.

La durée de conservation suit la même ligne de partage. Un compte personnel qui autorise l'usage de ses données pour l'amélioration des modèles voit sa conservation portée à cinq ans, contre 30 jours s'il refuse. Un compte commercial reste à 30 jours en standard. La conservation zéro, sans persistance côté serveur, existe pour Claude for Enterprise, mais elle ne fait pas partie de l'offre de base : l'équipe commerciale d'Anthropic l'active organisation par organisation, après vérification d'éligibilité. Pour les certifications, la page sécurité de Claude Code renvoie au Trust Center d'Anthropic, qui met à disposition le rapport SOC 2 Type 2 et le certificat ISO 27001.

Notre position est tranchée : le code d'un client ne devrait jamais passer par l'abonnement personnel d'un développeur, même réglé pour refuser l'entraînement. Anthropic précise que ce réglage se modifie à tout moment, et l'entreprise n'a aucun moyen de le vérifier. Un compte Team, Enterprise ou API fixe la règle dans les conditions commerciales. Si votre client exige que les données restent dans une région précise, passer par un fournisseur cloud comme Bedrock ou Microsoft Foundry change aussi le chiffrement au repos et, selon l'option d'hébergement, l'endroit où les requêtes sont traitées.

Ce choix de contrat se tranche avec la personne qui suit le RGPD dans l'entreprise, comme pour tout service qui envoie du code et des données de travail à un tiers. Notre article sur la gouvernance de l'IA, le RGPD et l'AI Act détaille la démarche, du registre des traitements à l'analyse d'impact.

Un dépôt cloné peut faire exécuter du code avant votre premier message

Les hooks déclarés dans les réglages d'un dépôt s'exécutent dès que Claude Code les charge, et un lancement en claude -p ne montre jamais la fenêtre de confiance qui vous aurait prévenu. En session interactive, Claude Code demande si vous faites confiance au dossier et liste ce qu'il s'apprête à autoriser. En mode non interactif, la documentation indique que les hooks du projet, son bloc de variables d'environnement et ses commandes d'aide sont utilisés, et que les serveurs déclarés dans .mcp.json sont connectés sans rien demander.

C'est le scénario typique d'un audit de code ou d'une reprise de projet. La même page propose trois parades, à combiner. L'option --setting-sources user ignore les réglages du projet et son .mcp.json. L'option --bare ne charge ni hooks, ni skills, ni serveurs MCP du dépôt. Enfin --settings '{"disableAllHooks": true}' coupe les hooks pour ce lancement, ce qu'un réglage dans vos préférences personnelles ne garantit pas, parce que les réglages du projet passent devant.

La chaîne d'approvisionnement ajoute un risque plus sournois. Le 26 août 2025, des versions piégées du paquet npm nx ont été publiées avec un script postinstall qui parcourait le disque, collectait des identifiants et les publiait dans un dépôt GitHub au nom de la victime. L'avis de sécurité de Nx cite les agents d'IA parmi les façons moins évidentes d'installer un paquet sans y penser. L'analyse de Wiz Research ajoute qu'environ 50 % des victimes avaient au moins un assistant de code en ligne de commande, Claude en tête, et que le programme malveillant le lançait avec l'option qui saute toutes les validations. L'exfiltration par l'IA n'a réussi que dans moins d'un quart des cas, avec moins de 100 secrets valides retrouvés sur 20 000 fichiers.

Notre règle sur les projets JavaScript ferme cette porte en deux réglages. npm n'exécute aucun script d'installation (ignore-scripts=true), et nous réglons le minimumReleaseAge de pnpm à 72 heures, quand sa valeur par défaut est de 1 440 minutes, soit 24 heures. Les versions piégées de Nx sont restées en ligne environ quatre heures, de 18 h 32 à 22 h 44, heure de New York : avec un délai d'une journée, une installation qui accepte une plage de versions ne les aurait jamais retenues. Côté outil, le dépôt GitHub de Claude Code comptait 35 avis de sécurité publiés au 22 octobre 2026, dont 28 de gravité élevée. La mise à jour automatique installe les correctifs, mais une session déjà ouverte garde son ancienne version : ce matin-là, deux de nos sessions tournaient encore en 2.1.302 alors que la 2.1.306 était installée.

Le réglage que nous imposerions à une équipe dès le premier jour

Pour une équipe, la sécurité de Claude Code tient dans un fichier de réglages gérés que les développeurs ne peuvent pas écraser depuis leur poste. Les réglages gérés passent avant tous les autres, y compris les options de ligne de commande, et un refus posé à n'importe quel niveau ne peut être levé par aucun autre. Une consigne écrite dans un fichier de mémoire, elle, reste du contexte que le modèle peut ignorer.

La base que nous recommandons tient en cinq réglages, dans cet ordre :

1. Le bac à sable obligatoire, en mode strict (allowUnsandboxedCommands: false et failIfUnavailable), avec une liste de domaines courte et sans domaine large.
2. Les secrets hors de portée : refus en lecture sur .env et les dossiers de secrets, blocage de ~/.ssh et ~/.aws dans le bloc credentials, nettoyage de l'environnement des sous-processus.
3. Le mode bypass interdit par disableBypassPermissionsMode, et des règles ask sur git push et les commandes de déploiement, qui forcent une validation même en mode auto.
4. Les dépendances installées sans script et avec un délai de quarantaine, sur chaque poste et dans la CI.
5. Le suivi de l'usage par les métriques OpenTelemetry, et un hook ConfigChange qui trace toute modification des réglages pendant une session.

Nous ajoutons deux habitudes que ces réglages ne couvrent pas. Chaque commit passe par une relecture automatique avant d'exister, ce qui rattrape une partie de ce que l'agent écrit de travers. Et les tâches qui peuvent boucler, comme une campagne de tests, tournent sous un plafond de mémoire depuis qu'un processus de test est monté à 21 Go et a fait tomber toutes les sessions de la machine. La disponibilité fait partie de la sécurité, et un agent qui sature un serveur partagé coûte autant qu'un agent qui efface un dossier.

Si vous ne deviez changer qu'une chose cette semaine, activez le bac à sable en mode strict avec une liste de domaines vide, puis ouvrez les domaines un par un quand une commande légitime échoue. Le reste se règle mieux avec une équipe qui sait pourquoi chaque réglage existe, ce que nous abordons dans notre article pour former une équipe à Claude Code. Si vous préférez que nous regardions votre configuration actuelle, vous pouvez contacter Noxcod : nous partons de vos réglages réels et de vos dépôts.

Questions fréquentes sur la sécurité de Claude Code

Claude Code envoie-t-il tout mon code à Anthropic ?

Il envoie ce qui entre dans la conversation : vos demandes, les fichiers que l'agent lit et les sorties des commandes qu'il lance. Il n'aspire pas le dépôt entier d'un coup, mais un agent qui explore un projet en lit vite une bonne partie. Sous conditions commerciales, ces données ne servent pas à l'entraînement et sont conservées 30 jours en standard. Les transcriptions restent aussi en clair sur votre disque pendant 30 jours.

Le mode auto suffit-il pour travailler sur le dépôt d'un client ?

Il suffit pour éviter la plupart des erreurs de l'agent, comme un push --force ou un déploiement non demandé, que son classifieur bloque par défaut. Il ne suffit pas face à un contenu piégé qui chercherait à orienter le classifieur, puisque celui-ci juge du texte. Sur un dépôt client, nous recommandons de l'associer au bac à sable en mode strict et à des règles ask sur les commandes qui sortent du poste, comme git push ou un déploiement.

Comment empêcher Claude Code de lire le fichier .env ?

Ajoutez une règle de refus Read(./.env) dans vos réglages, de préférence dans les réglages gérés pour qu'elle s'impose à toute l'équipe. Elle couvre les outils de lecture et des commandes comme cat ou head, mais pas un script qui ouvre le fichier lui-même. Pour que l'interdiction vaille pour tous les processus, activez le bac à sable, qui reprend cette règle au niveau du système.

Faut-il désactiver la télémétrie de Claude Code ?

Ce n'est pas la priorité, car les métriques n'incluent ni code, ni invites, ni chemins de fichiers. Si votre politique l'exige, DISABLE_TELEMETRY=1 coupe les métriques et CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC coupe tout le trafic non indispensable d'un coup. Pensez surtout à DISABLE_FEEDBACK_COMMAND=1 sur les postes qui touchent du code client, puisque /feedback envoie la conversation complète et la garde cinq ans.

Que faire quand un avis de sécurité concerne Claude Code ?

Vérifiez la version corrigée indiquée dans l'avis, puis redémarrez les sessions ouvertes. Nous l'avons constaté sur nos propres sessions : la mise à jour automatique remplace le programme installé, mais une session lancée avant continue d'utiliser l'ancienne version, et claude --version ne donne que la version installée. Sur une équipe, le réglage géré requiredMinimumVersion empêche une version trop ancienne de démarrer, mais il ne vérifie qu'au lancement.