Claude Code et la sécurité : permissions, sandbox et bonnes pratiques

Confier à un agent l’accès à votre code, à votre terminal et à votre réseau soulève forcément une question : que peut-il vraiment faire sans votre accord ? Claude Code répond par un modèle de permissions strict, un sandbox optionnel qui isole les commandes bash, et une série de garde-fous contre l’injection de prompt. Voici comment ces mécanismes fonctionnent concrètement, où se situent les vrais risques, et comment les configurer correctement en entreprise.

Le modèle de permissions par défaut

Par défaut, Claude Code applique un système à plusieurs niveaux. Les opérations en lecture seule (lire un fichier, faire un grep) ne demandent jamais d’autorisation. Les commandes bash qui modifient quelque chose déclenchent une invite, sauf un ensemble intégré de commandes reconnues comme sûres (ls, cat, git status, pwd, etc.). Les modifications de fichiers demandent également une validation, valable jusqu’à la fin de la session.

Ce mode par défaut s’appelle Manual dans l’interface (valeur default dans la configuration). Vous pouvez basculer vers d’autres modes avec Maj+Tab pendant une session :

• acceptEdits : accepte automatiquement les modifications de fichiers et les commandes filesystem courantes (mkdir, touch, mv, cp) dans le dossier de travail, mais continue de demander pour le reste.
• plan : Claude explore le code et propose un plan sans jamais éditer vos fichiers sources.
• auto : supprime la plupart des invites, mais chaque action passe par un classificateur de sécurité séparé qui vérifie qu’elle correspond bien à votre demande avant exécution. C’est l’option recommandée pour réduire la fatigue des validations tout en gardant une supervision.
• dontAsk : refuse automatiquement tout ce qui n’est pas explicitement pré-autorisé, utile en CI verrouillée.
• bypassPermissions : supprime toutes les invites, y compris les garde-fous habituels. C’est l’équivalent du flag --dangerously-skip-permissions.

Chaque mode peut aussi être choisi dès le lancement, sans passer par Maj+Tab, avec le flag --permission-mode. Par exemple, pour démarrer une session en exploration seule, sans risque d’édition accidentelle sur un dépôt inconnu :

claude --permission-mode plan

Vous affinez ce comportement avec des règles allow, ask et deny dans un fichier settings.json, consultables et modifiables via la commande /permissions. L’ordre d’évaluation est fixe : deny, puis ask, puis allow. Une règle deny large comme Bash(git push *) bloque donc l’action même si une règle allow plus précise la couvrirait aussi. Ces fichiers de configuration peuvent être commités dans le dépôt (.claude/settings.json) pour que toute l’équipe hérite des mêmes règles, ou définis au niveau utilisateur, voire imposés par une politique managée qu’aucun développeur ne peut assouplir.

Voici à quoi ressemblent des règles réelles, cohérentes avec la capture ci-dessus : les commandes de test sont autorisées, un push git force une confirmation, et les fichiers sensibles restent inaccessibles en lecture, quel que soit le mode actif :

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

La syntaxe Bash(npm test:*) est équivalente à Bash(npm test *) : le suffixe :* est une écriture raccourcie du joker final. Notez aussi l’ordre de priorité en action ici : même si une commande de test correspondait par erreur à une règle deny plus large ailleurs dans le fichier, cette règle deny l’emporterait toujours sur l’allow ci-dessus.

Le sandboxing : isoler les commandes bash

Le sandbox est un mécanisme distinct des modes de permission. Il s’active avec la commande /sandbox et applique une isolation au niveau du système d’exploitation (Seatbelt sur macOS, bubblewrap sur Linux et WSL2) à toutes les commandes bash et leurs processus enfants, quel que soit le mode de permission actif.

Concrètement, une commande sandboxée ne peut écrire que dans le dossier de travail courant et un répertoire temporaire dédié. Côté réseau, aucun domaine n’est autorisé par défaut : la première tentative de connexion à un nouveau domaine déclenche une demande de validation, puis ce domaine reste autorisé pour le reste de la session. Vous pouvez pré-autoriser des domaines via allowedDomains dans les paramètres du sandbox pour éviter ces interruptions. Cela s’écrit directement dans settings.json :

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["registry.npmjs.org", "api.github.com"]
    }
  }
}

En mode auto-allow, les commandes sandboxées s’exécutent sans invite puisque la frontière technique remplace la validation manuelle, ce qui réduit fortement le nombre de confirmations à traiter tout en maintenant une isolation réelle. C’est différent du mode auto vu plus haut : l’un s’appuie sur une barrière système, l’autre sur un classificateur qui juge l’intention de l’action.

Un point à connaître avant de faire confiance au sandbox : par défaut, le proxy réseau intégré n’inspecte pas le contenu du trafic HTTPS, il se contente d’autoriser ou bloquer selon le nom d’hôte demandé. Autoriser un domaine large comme github.com peut donc, en théorie, laisser passer une exfiltration de données via des techniques de contournement de ce type de filtrage. Pour un modèle de menace plus strict, la documentation recommande un proxy personnalisé qui termine le TLS et inspecte réellement le trafic.

Les risques réels

Le risque le plus documenté n’est pas un bug de Claude Code lui-même, mais l’injection de prompt : un contenu malveillant caché dans un fichier, une page web récupérée, ou un commentaire de dépôt peut tenter de détourner les instructions de l’agent. Chaque fichier lu, chaque réponse d’outil traitée, chaque commentaire ingéré est une surface d’attaque potentielle. Claude Code atténue ce risque par une analyse contextuelle des demandes, une fenêtre de contexte séparée pour WebFetch, et surtout par le système de permissions lui-même : une action sensible reste soumise à validation même si l’instruction provient d’un contenu externe compromis.

C’est précisément pourquoi le flag --dangerously-skip-permissions (mode bypassPermissions) mérite son nom. Sans invite de validation, il n’y a plus de point de contrôle humain pour intercepter une instruction injectée avant qu’elle s’exécute. Ce mode ne doit être utilisé que dans un environnement isolé, comme un conteneur ou une VM sans accès à des ressources sensibles, jamais sur une machine hôte avec vos identifiants réels. D’ailleurs Claude Code refuse de démarrer dans ce mode en tant que root ou via sudo sur Linux et macOS, précisément pour limiter les dégâts d’une erreur du modèle.

Le mode auto a été conçu comme alternative plus sûre à ce flag : il élimine les invites répétitives tout en conservant un classificateur qui bloque par défaut les actions à haut risque (exécuter du code téléchargé, pousser en force, détruire de l’infrastructure, envoyer des données sensibles vers l’extérieur). Si vous cherchez à réduire la fatigue des permissions sans désactiver toute supervision, c’est l’option à privilégier plutôt que le bypass complet.

Bonnes pratiques en entreprise

Pour une équipe ou une organisation, la bonne approche consiste à définir une politique centralisée plutôt que de compter sur la discipline individuelle. Les paramètres managés, déployés via MDM ou une politique gérée depuis la console d’administration, priment sur tous les autres niveaux de configuration et ne peuvent pas être assouplis par un projet ou un utilisateur. Cela permet notamment d’imposer permissions.disableBypassPermissionsMode pour interdire le mode bypass à tous les développeurs, ou de forcer le sandbox pour chaque session via sandbox.enabled combiné à failIfUnavailable.

Un fichier settings.json partagé au niveau du projet, commité dans le dépôt, garantit que toute l’équipe travaille avec les mêmes règles allow/deny sans avoir à les reconfigurer individuellement. Un exemple minimal versionnable, combinant règles de permissions et sandbox obligatoire, ressemble à ceci :

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "deny": ["Bash(git push *)"]
  },
  "sandbox": {
    "enabled": true
  }
}

Pensez aussi à protéger explicitement les identifiants sensibles (clés AWS, dossier .ssh) avec les règles sandbox.credentials, car la lecture de ces fichiers reste autorisée par défaut même sandbox activé.

Ce qui part vers Anthropic

Pour utiliser le modèle, Claude Code envoie vos prompts et le contenu de code pertinent vers l’API Anthropic, chiffré en transit via TLS. Pour les comptes commerciaux (Team, Enterprise, API), Anthropic n’entraîne pas ses modèles sur ce contenu sauf opt-in explicite, avec une rétention standard de 30 jours. Les comptes grand public (Free, Pro, Max) peuvent choisir d’autoriser l’usage de leurs données pour l’amélioration des modèles, ce qui porte la rétention à 5 ans ; sans ce choix, elle reste à 30 jours. Les organisations qualifiées peuvent activer la rétention zéro (zero data retention) pour Claude Code, sans persistance côté serveur.

Deux commandes méritent une attention particulière : /feedback envoie une copie de l’historique de conversation, y compris le code, vers Anthropic, avec une rétention de 5 ans indépendamment de vos préférences d’entraînement. Le suivi de session (transcript-share) est distinct et toujours soumis à votre accord explicite avant tout envoi.

Pour aller plus loin sur la prise en main de l’outil, voir comment utiliser Claude Code et comment le personnaliser avec des skills et des plugins. Si vous rencontrez des blocages liés aux permissions ou au sandbox, notre guide sur les erreurs courantes couvre les cas les plus fréquents.