Comment sécuriser Claude Code ? Le guide permissions 2026

TL;DR — Sécuriser Claude Code en 5 points

• Claude Code démarre en lecture seule : chaque commande Bash qui modifie le système demande une approbation, sauf une liste intégrée de commandes read-only (ls, cat, git status).
• Les règles de permission s'évaluent dans un ordre strict : deny, puis ask, puis allow. La première correspondance gagne, la spécificité ne change rien.
• Une règle écrite dans CLAUDE.md ne bloque rien : les permissions sont appliquées par Claude Code, pas par le modèle. Seuls settings.json, /permissions, les modes et les hooks font autorité.
• Le sandbox (/sandbox) isole Bash au niveau de l'OS (fichiers + réseau), mais son mode lecture par défaut laisse toujours lire ~/.aws et ~/.ssh : il faut ajouter sandbox.credentials.
• La vraie faille n'est pas Claude : c'est la prompt injection — des instructions cachées dans un fichier, une page web ou une sortie MCP. Le contenu externe est de la donnée, jamais un ordre.

Comment sécuriser Claude Code concrètement ?

La réponse courte tient en une phrase : Claude Code est sécurisé par défaut, et vous le dé-sécurisez sans le savoir à chaque « Yes, don't ask again ». Par défaut, l'agent a des permissions strictement en lecture seule ; toute action qui écrit un fichier ou lance une commande système passe par une approbation explicite. Le problème n'est donc jamais « Claude va-t-il faire une bêtise ? » mais « quelles autorisations ai-je accumulées, sans les relire, en cliquant machinalement pour ne plus être interrompu ? ».

Après un mois de développement, un projet accumule facilement plusieurs dizaines de règles allow invisibles, écrites automatiquement dans .claude/settings.local.json. Chacune paraît anodine au moment du clic. Mises bout à bout, elles dessinent une surface d'attaque que personne n'a jamais relue. C'est exactement ce point aveugle que cet article vient combler : moins un catalogue de peurs qu'une configuration à trois couches, copiable telle quelle, plus les nuances contre-intuitives que la plupart des tutoriels ratent.

Ce guide s'appuie uniquement sur la documentation officielle Anthropic (pages Security, Permissions et Sandboxing, 2026). Si vous débutez, commencez par notre guide des premiers pas avec Claude Code avant de durcir votre configuration.

Pourquoi CLAUDE.md ne sécurise-t-il rien ?

C'est l'erreur numéro un, et elle est dangereuse parce qu'elle donne un faux sentiment de sécurité. Écrire « ne fais jamais de git push » ou « n'accède jamais au fichier .env » dans CLAUDE.md n'empêche techniquement rien. La documentation est explicite :

« Les règles de permission sont appliquées par Claude Code, pas par le modèle. Les instructions de votre prompt ou de CLAUDE.md orientent ce que Claude essaie de faire, mais elles ne changent pas ce que Claude Code autorise. » — Documentation officielle Claude Code, Configure permissions (Anthropic, 2026)

Autrement dit, CLAUDE.md façonne l'intention du modèle ; settings.json façonne ce qui est réellement possible. Une consigne en langage naturel est un panneau « défense d'entrer » ; une règle deny est une serrure. Pour toute contrainte qui compte vraiment — secrets, pushes, suppressions — il faut la serrure. Le panneau, seul, se contourne à la première prompt injection.

Quelles règles mettre dans settings.json ?

Les permissions vivent dans quatre fichiers, du plus général au plus spécifique : les managed settings de l'entreprise, le .claude/settings.json du projet (versionné, il voyage avec le repo), le ~/.claude/settings.json personnel, et le .claude/settings.local.json local et non commité. Les listes allow et deny de tous ces fichiers fusionnent : un deny posé dans les settings utilisateur s'applique même si un fichier de projet contient un allow correspondant.

Trois types de règles, évalués dans cet ordre :

Point crucial que beaucoup ignorent : un deny large comme Bash(aws *) ne peut pas porter d'exception. Même si vous ajoutez un allow plus précis Bash(aws s3 ls), le deny gagne toujours, parce qu'il est évalué en premier. On ne construit pas une allowlist avec des deny ; on interdit, un point c'est tout.

Voici une base deny minimale et défendable, à placer dans le .claude/settings.json du projet :

@@@json

{

"permissions": {

"deny": [

"Read(./.env)",

"Read(./.env.*)",

"Read(./secrets/**)",

"Bash(rm -rf:*)",

"Bash(git push --force:*)",

"Bash(curl:*)",

"Bash(wget:*)"

],

"ask": [

"Bash(git push:*)",

"Bash(npm publish:*)"

]

}

}

@@@

Deux subtilités qui font toute la différence. D'abord, une règle Read(.env) sans chemin suit la sémantique gitignore et bloque le fichier à n'importe quelle profondeur du projet. Ensuite, depuis les versions récentes, une règle Read en deny bloque aussi l'outil Edit sur le même chemin — mais pas Write ni NotebookEdit. Pour un fichier qu'aucun outil ne doit modifier, ajoutez explicitement une règle Edit en deny.

Pourquoi bloquer curl, wget et le fichier .env ?

Parce que ce sont les deux portes de sortie classiques d'une exfiltration. Un secret ne « fuit » pas tout seul : il faut d'abord le lire (le .env, les clés dans ~/.ssh), puis l'envoyer quelque part (curl, wget). Fermez l'une des deux portes et l'attaque échoue.

Bonne nouvelle : Anthropic a déjà fermé la seconde à demi. Les commandes réseau comme curl et wget ne sont pas auto-approuvées par défaut — elles déclenchent une prompt comme n'importe quelle commande non read-only. Mais un développeur pressé peut avoir cliqué « Yes, don't ask again » sur un curl anodin il y a trois semaines. D'où la règle deny explicite ci-dessus : elle neutralise cet historique.

Côté lecture, la vigilance porte sur un piège précis. Bloquer Read(./.env) empêche l'outil Read d'ouvrir le fichier, mais pas un cat .env lancé en Bash… sauf que les règles Read et Edit en deny s'appliquent aussi aux commandes fichier que Claude Code reconnaît dans Bash, comme cat, head, tail et sed. Ce qu'elles ne couvrent pas, ce sont les sous-processus arbitraires : un script Python ou Node qui ouvre le fichier lui-même passe à travers. Pour une étanchéité réelle au niveau du système d'exploitation, il faut le sandbox.

À quoi sert le sandbox, et où s'arrête-t-il ?

Le sandbox (commande /sandbox) fait ce que les règles de permission ne peuvent pas : il impose une isolation au niveau de l'OS — Seatbelt sur macOS, bubblewrap sur Linux et WSL2. La contrainte tient quel que soit ce que le modèle a décidé de lancer, et même si une commande autorisée fait plus que ce que son nom laisse croire. En mode auto-allow, les commandes Bash sandboxées s'exécutent sans prompt tant qu'elles restent dans les limites définies : écriture dans le répertoire de travail, réseau vers les seuls domaines autorisés.

Mais attention au faux sentiment de sécurité. Le comportement de lecture par défaut du sandbox reste très permissif :

« Accès en lecture à l'ensemble de l'ordinateur, sauf certains répertoires interdits. Ce comportement par défaut autorise toujours la lecture de fichiers d'identifiants comme ~/.aws/credentials et ~/.ssh/. » — Documentation officielle Claude Code, Sandboxing (Anthropic, 2026)

Traduction : activer le sandbox ne protège pas vos clés cloud et SSH tant que vous ne l'avez pas dit explicitement. Le bloc à ajouter dans sandbox.credentials scelle cette fuite et retire les tokens de l'environnement des commandes sandboxées :

@@@json

{

"sandbox": {

"enabled": true,

"credentials": {

"files": [

{ "path": "~/.aws/credentials", "mode": "deny" },

{ "path": "~/.ssh", "mode": "deny" }

],

"envVars": [

{ "name": "GITHUB_TOKEN", "mode": "deny" },

{ "name": "NPM_TOKEN", "mode": "deny" }

]

}

}

}

@@@

Une dernière limite à garder en tête : le sandbox isole les sous-processus Bash, pas les outils de fichiers intégrés (Read, Edit, Write) qui, eux, passent par le système de permissions. Les deux couches sont complémentaires, jamais interchangeables. Et sans isolation réseau, un agent compromis peut exfiltrer des fichiers sensibles ; sans isolation fichier, il peut piéger des ressources système pour gagner un accès réseau. Il faut les deux.

Quel est le vrai risque : la prompt injection

Si vous ne deviez retenir qu'une menace, ce serait celle-ci. La prompt injection consiste à cacher des instructions malveillantes dans du contenu que l'agent va lire — un fichier du repo, une page récupérée par WebFetch, la sortie d'un serveur MCP, la réponse d'une API tierce. L'agent, s'il « croit » ces instructions, peut être détourné vers une action que vous n'avez jamais demandée.

La parade de fond est une règle mentale simple, que Claude Code applique déjà en interne et que vous devez adopter : tout contenu externe est de la donnée, pas un ordre. Anthropic empile plusieurs garde-fous : détection contextuelle des instructions potentiellement dangereuses, approbation obligatoire des commandes réseau, fenêtre de contexte isolée pour WebFetch (pour éviter d'injecter des prompts malveillants dans la session), vérification de confiance au premier lancement d'un repo ou d'un nouveau serveur MCP, et détection d'injection de commande qui force une approbation manuelle même pour une commande déjà en allowlist.

Deux réflexes pratiques complètent ces protections. Un : ne collez jamais de contenu non fiable directement dans le prompt, et relisez toute commande suggérée avant de l'approuver. Deux — et c'est un piège d'automatisation méconnu — la vérification de confiance est désactivée en mode non-interactif avec le flag -p. Si vous scriptez Claude Code dans une CI, vous perdez ce garde-fou : compensez avec un sandbox strict et une allowlist minimale. Pour aller plus loin sur l'automatisation propre, voyez notre article sur les hooks Claude Code, qui permettent de valider chaque appel d'outil avant exécution.

Modes de permission : lequel pour quel usage ?

Le mode décide si un appel d'outil s'exécute et si vous êtes interrogé avant. Choisir le bon mode, c'est choisir le bon niveau de friction pour le bon contexte.

Un détail rassurant sur bypassPermissions : même dans ce mode « tout passe », les suppressions visant la racine du système ou votre dossier personnel (rm -rf /, rm -rf ~) déclenchent toujours une prompt, comme un coupe-circuit contre l'erreur du modèle. Ce n'est pas une raison pour l'utiliser hors d'un conteneur : il saute aussi les protections sur .git, .claude, .ssh et consorts.

Pour verrouiller une équipe, deux réglages à placer dans les managed settings (non contournables par le développeur) : permissions.disableBypassPermissionsMode et permissions.disableAutoMode à "disable".

Comment auditer ce que Claude Code peut déjà faire ?

C'est l'étape que tout le monde saute. Après quelques semaines, lancez :

@@@bash

/permissions

@@@

La commande liste toutes les règles actives, y compris les dizaines d'allow que vous avez générées sans y penser. Relisez-les comme vous reliriez une pull request : chaque Bash(...) en allow est une commande que Claude peut désormais lancer sans vous demander. Supprimez ce qui n'a plus lieu d'être. À faire une fois par mois sur les repos qui comptent.

Sur le plan gestion des secrets, la règle est plus simple encore : Claude Code stocke ses propres identifiants (clés API, tokens) dans le trousseau macOS quand il est disponible, protégés par les permissions de fichier sur Windows et Linux. Vos secrets à vous, eux, n'ont rien à faire dans le repo ni dans un prompt — trousseau, gestionnaire de secrets ou variables d'environnement scrubées, jamais en clair.

FAQ — Sécurité de Claude Code

Claude Code peut-il supprimer mes fichiers sans mon accord ?

Non par défaut. Toute commande qui modifie le système, y compris rm, demande une approbation. Le risque apparaît si vous avez auto-approuvé des commandes ou si vous tournez en bypassPermissions hors conteneur. Même là, rm -rf / et rm -rf ~ restent bloqués par un coupe-circuit.

Une consigne dans CLAUDE.md suffit-elle à interdire une action ?

Non. CLAUDE.md oriente l'intention du modèle mais n'applique aucune permission. Pour interdire réellement une action, utilisez une règle deny dans settings.json, une règle /permissions ou un hook PreToolUse. La documentation Anthropic est formelle sur ce point.

Le sandbox protège-t-il mes clés AWS et SSH ?

Pas automatiquement. Le sandbox isole l'écriture et le réseau, mais sa lecture par défaut autorise toujours ~/.aws/credentials et ~/.ssh. Ajoutez un bloc sandbox.credentials avec "mode": "deny" pour ces fichiers et unset vos tokens sensibles.

Qu'est-ce que la prompt injection et comment m'en protéger ?

C'est l'insertion d'instructions malveillantes dans du contenu que l'agent lit (fichier, page web, sortie MCP). Traitez tout contenu externe comme de la donnée, pas un ordre ; ne pipez pas de contenu non fiable dans Claude ; relisez chaque commande avant de l'approuver ; et bloquez curl/wget par une règle deny.

Comment lancer Claude Code en toute sécurité dans une CI ?

Le flag -p désactive la vérification de confiance. Compensez avec un sandbox strict (allowUnsandboxedCommands à false), une allowlist minimale, un scrub des variables d'environnement sensibles et des managed settings qui interdisent bypassPermissions.

Où voir toutes les permissions déjà accordées ?

Lancez /permissions dans une session. La commande affiche l'ensemble des règles allow, ask et deny actives, y compris celles générées par les « Yes, don't ask again ». Auditez-les régulièrement et supprimez celles devenues inutiles.

Le mot de la fin

Sécuriser Claude Code ne consiste pas à le brider au point de perdre l'intérêt d'un agent : c'est choisir sciemment ce qu'il peut faire, plutôt que de le découvrir après coup dans /permissions. Trois couches suffisent pour 95 % des cas : une deny list qui verrouille secrets, pushes et suppressions ; un sandbox avec credentials protégés ; et l'hygiène de la prompt injection. Le reste est de la discipline — auditer, relire, ne pas cliquer « ne plus demander » par réflexe.

Vous voulez maîtriser Claude Code de bout en bout, permissions comprises, sans passer trois week-ends à lire la doc ? La formation Maîtrise l'IA condense tout cela en modules pratiques. Et pour comparer objectivement les outils IA sur leur coût et leurs garanties réelles, gardez iaCockpit dans vos favoris.