Permissions et sécurité

Claude Code intègre un système de permissions multicouche qui contrôle chaque action de l'agent sur votre machine. Maîtriser la configuration des modes de permission, des règles allow/deny et du sandboxing vous protège contre les exécutions non autorisées et les injections de prompt. Ce guide détaille comment sécuriser votre environnement Claude Code étape par étape.

Claude Code permissions et sécurité désigne l'ensemble des mécanismes qui régulent les actions qu'un agent IA peut exécuter sur votre poste de travail. Claude Code propose several permission mechanisms, un système de règles granulaires dans settings.json et un sandboxing natif via Seatbelt (macOS) et bubblewrap (Linux). misconfigured permissions are a frequent source of security incidents with AI agents.

Comment fonctionnent les modes de permission de Claude Code ?

Claude Code propose 6 modes de permission via le flag --permission-mode qui déterminent le niveau d'autonomie accordé à l'agent. Chaque mode correspond à un cas d'usage précis, du plus restrictif au plus permissif.

Le mode default est le mode par défaut. L'agent vous demande confirmation avant chaque opération sensible : écriture de fichier, exécution de commande shell, appel réseau. Ce mode convient aux premières sessions et à la découverte de l'outil.

Le mode acceptEdits approuve automatiquement les éditions de fichiers. Les commandes shell et autres outils nécessitent toujours votre validation. Ce mode accélère le travail courant sur le code.

Le mode plan est un mode analyse uniquement : Claude Code affiche un plan d'action et vous demande confirmation avant toute exécution. Ce mode convient à la revue de code et aux décisions d'architecture.

Le mode auto utilise un classifieur en arrière-plan pour approuver automatiquement les actions sûres (research preview). Il nécessite Claude Code v2.1.83+ et le modèle Opus 4.6+ ou Sonnet 4.6. Il est activé par défaut sur l'API Anthropic. Sur Amazon Bedrock, Google Vertex AI et Microsoft Foundry, il est désactivé par défaut et doit être activé avec la variable CLAUDE_CODE_ENABLE_AUTO_MODE=1 ; sur ces fournisseurs, seuls Opus 4.7 et Opus 4.8 sont pris en charge.

Le mode dontAsk auto-refuse tout appel d'outil qui demanderait normalement confirmation. Seules les actions correspondant à vos règles allow et les commandes Bash en lecture seule s'exécutent. Les règles ask sont refusées au lieu de déclencher une demande.

Le mode bypassPermissions (--dangerously-skip-permissions) supprime toutes les confirmations. Chaque action s'exécute immédiatement. Réservez ce mode aux environnements isolés (conteneurs Docker, CI/CD) où aucune donnée sensible n'est exposée.

En session, Shift+Tab ou Alt+M permet de cycler entre les modes de permission disponibles, sans redémarrer Claude Code.

Pour passer d'un mode à l'autre, utilisez le flag --permission-mode au lancement ou Shift+Tab / Alt+M en session :

# Mode default (défaut)
claude

# Mode acceptEdits
claude --permission-mode acceptEdits

# Mode plan (analyse avant action)
claude --permission-mode plan

# Mode auto (classifieur en arrière-plan, research preview, API Anthropic)
claude --permission-mode auto

# Mode bypass (CI/CD uniquement)
claude --dangerously-skip-permissions

Vous pouvez aussi définir le mode par défaut dans settings.json avec "defaultMode": "plan".

Pour approfondir chaque mode avec des exercices pratiques, consultez le tutoriel permissions et sécurité qui vous guide étape par étape. Si vous débutez, le démarrage rapide vous permet de configurer vos permissions en moins de 5 minutes.

À retenir : le mode default convient à la grande majorité des usages quotidiens ; ne passez en bypassPermissions que dans un environnement jetable. Utilisez Shift+Tab ou Alt+M pour cycler entre les modes en session.

Comment configurer les règles allow/deny dans settings.json ?

Le fichier settings.json est le cœur de la configuration de sécurité de Claude Code. Il contient des règles granulaires qui autorisent ou bloquent des outils spécifiques, avec ou sans restriction de pattern.

Ouvrez votre fichier de configuration avec cette commande :

cat ~/.claude/settings.json

La structure de base contient trois clés principales : allow, deny et ask. Chaque règle cible un outil précis et peut inclure un pattern pour filtrer les arguments.

{
 "permissions": {
 "allow": [
 "Read",
 "Write",
 "Bash(git *)",
 "Bash(npm test *)",
 "Bash(npm run *)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(curl *)",
 "Bash(wget *)"
 ],
 "ask": [
 "Bash(git push *)"
 ]
 }
}

Les règles deny sont prioritaires sur les règles allow. La liste ask force une confirmation même si l'outil serait normalement auto-approuvé. Si une commande correspond à la fois à une règle allow et deny, elle sera bloquée. En pratique, cette hiérarchie vous permet de créer des politiques de type "tout autoriser sauf".

Concrètement, vous pouvez définir des règles par projet en plaçant un fichier .claude/settings.json à la racine du dépôt. Les règles projet fusionnent avec les règles globales, et les deny projet s'ajoutent aux deny globaux.

{
 "permissions": {
 "allow": [
 "Bash(docker compose *)",
 "Bash(make *)"
 ],
 "deny": [
 "Bash(docker push *)"
 ]
 }
}

Pour vérifier votre configuration actuelle, consultez l'aide-mémoire des permissions qui récapitule toutes les syntaxes de règles. La FAQ permissions et sécurité répond aux questions courantes sur les conflits de règles.

À retenir : placez toujours les commandes destructrices (rm, drop, push --force) dans la liste deny, même si vous travaillez en mode Normal.

Pourquoi le sandboxing est-il indispensable pour Claude Code ?

Le sandboxing isole les processus lancés par Claude Code du reste de votre système. Sans sandbox, une commande malveillante injectée via un prompt pourrait accéder à vos fichiers personnels, vos clés SSH ou vos tokens d'API.

Claude Code utilise Seatbelt sur macOS et bubblewrap sur Linux. Ces technologies limitent les appels système disponibles pour les processus enfants. En pratique, le sandbox bloque l'accès aux répertoires hors du projet, aux sockets réseau non autorisés et aux périphériques système.

Sur macOS, Seatbelt applique un profil de sandbox qui restreint l'accès au système de fichiers. Seuls les répertoires du projet et les dépendances nécessaires sont accessibles. Vérifiez l'état du sandbox avec la commande /sandbox.

Sur Linux et WSL2, bubblewrap crée un namespace utilisateur isolé. Le processus sandboxé voit un système de fichiers minimal avec uniquement les montages explicitement autorisés. Sur ces plateformes, installez au préalable les paquets bubblewrap et socat. Le filtre seccomp est optionnel : il ajoute le blocage des sockets de domaine Unix et s'installe via npm install -g @anthropic-ai/sandbox-runtime.

Pour diagnostiquer un problème de sandbox, le guide de dépannage vous aide à identifier les erreurs courantes. Vous pouvez aussi consulter le guide complet de Claude Code pour comprendre l'architecture globale de sécurité.

le sandboxing réduit significativement la surface d'attaque exploitable par injection de prompt.

À retenir : le sandboxing n'est pas activé par défaut. Activez-le via la commande /sandbox ou en définissant "sandbox": { "enabled": true } dans votre settings.json. Activez-le sur toute machine de développement contenant des données sensibles.

Comment se protéger contre les prompt injections dans Claude Code ?

Une prompt injection se produit lorsqu'un contenu malveillant dans un fichier ou une réponse API manipule le comportement de l'agent. Claude Code intègre plusieurs couches de défense contre ce vecteur d'attaque.

La première défense est le système de permissions lui-même. Même si un prompt injecté demande à l'agent d'exécuter rm -rf /, le mode Normal exigera votre confirmation. Configurez des règles deny explicites pour les commandes destructrices.

La deuxième couche est le sandbox au niveau de l'OS (Seatbelt sur macOS, bubblewrap sur Linux), qui restreint les fichiers et les domaines réseau accessibles. Les hooks PreToolUse complètent cette défense : ils peuvent inspecter puis bloquer un appel d'outil avant son exécution.

Voici comment renforcer votre protection en pratique :

1. Activez le mode Normal pour toute session impliquant des fichiers non vérifiés
2. Ajoutez des règles deny pour les commandes réseau (curl, wget, nc)
3. Limitez les répertoires accessibles via le sandbox
4. Vérifiez les fichiers .claude/settings.json des dépôts clonés avant de les utiliser
5. Inspectez le contenu du fichier CLAUDE.md de chaque projet

# Vérifier le CLAUDE.md d'un projet cloné avant de lancer Claude Code
cat CLAUDE.md
# Vérifier les settings du projet
cat .claude/settings.json

Les tentatives d'injection ciblent fréquemment les commandes shell. Bloquez systématiquement les commandes réseau sortantes dans vos règles deny pour réduire ce risque.

Le fichier CLAUDE.md peut lui aussi être un vecteur d'injection. Avant de travailler sur un dépôt externe, lisez son contenu et vérifiez qu'il ne contient pas d'instructions masquées. Pour comprendre le fonctionnement du système de mémoire, consultez le guide CLAUDE.md.

La checklist de sécurité vous donne une liste complète de vérifications à effectuer avant chaque session sur un dépôt inconnu.

À retenir : les permissions + le sandbox + votre vigilance sur les fichiers non vérifiés forment un triangle de défense efficace contre les injections.

Quels réglages essentiels configurer dans settings.json pour la sécurité ?

Le fichier settings.json accepte plusieurs paramètres de sécurité au-delà des simples règles allow/deny. Voici les réglages que chaque développeur devrait connaître.

Configurez les règles allow/deny pour contrôler précisément les outils autorisés :

{
 "permissions": {
 "allow": ["Read", "Bash(git *)"],
 "deny": ["Bash(rm -rf *)"]
 }
}

Le sandboxing est configurable dans settings.json via la clé sandbox :

{
 "permissions": {
 "allow": ["Read", "Bash(git *)"],
 "deny": ["Bash(rm -rf *)"]
 },
 "sandbox": {
 "enabled": true,
 "filesystem": {
  "allowWrite": ["/var/myapp", "/tmp/builds"]
 }
 }
}

La clé sandbox.enabled active ou désactive le sandboxing (Seatbelt sur macOS, bubblewrap sur Linux). sandbox.filesystem.allowWrite définit les répertoires supplémentaires en écriture accessibles au sandbox au-delà du répertoire de travail.

Le fichier settings.json supporte aussi les hooks qui interceptent les événements de l'agent :

{
 "hooks": {
 "PreToolUse": [
 {
  "matcher": "Bash",
  "hooks": [
  {"type": "command", "command": "echo 'Bash called'", "timeout": 5}
  ]
 }
 ],
 "PostToolUse": [],
 "UserPromptSubmit": [],
 "SessionStart": [],
 "Stop": [],
 "Notification": []
 }
}

Parmi les événements supportés figurent PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop et Notification ; cette liste n'est pas exhaustive, d'autres événements du cycle de vie existent. Chaque hook peut utiliser un matcher (regex) et un champ if pour un filtrage fin. Les types de hooks sont : command, http, mcp_tool, prompt et agent. Le champ timeout d'un hook de type command s'exprime en secondes (valeur par défaut : 600 secondes). Codes de sortie : 0 = succès, l'action suit le flux de permissions normal ; 2 = erreur bloquante (bloque l'appel d'outil pour les événements PreToolUse) ; tout autre code non nul = erreur non bloquante, l'action se poursuit et une erreur de hook est affichée dans le transcript.

La hiérarchie de configuration suit plusieurs niveaux (du plus prioritaire au moins prioritaire) :

1. Managed/Policy : politique d'organisation définie par l'administrateur, priorité la plus haute, ne peut jamais être annulée par un autre niveau
2. Arguments en ligne de commande : les flags passés au lancement (--permission-mode, --allowedTools, etc.)
3. Projet local : .claude/settings.local.json, ignoré par git, propre à votre poste
4. Projet partagé : .claude/settings.json à la racine du dépôt, versionné avec le code
5. Global/Utilisateur : ~/.claude/settings.json, s'applique à tous les projets, priorité la plus basse

Attention : les règles deny ne suivent pas cette logique d'écrasement. Elles fusionnent entre les niveaux et s'additionnent : une règle deny globale ne peut jamais être annulée par une règle allow projet. Ce comportement garantit que vos garde-fous personnels restent actifs quel que soit le projet.

Pour découvrir des astuces avancées de configuration, consultez la page astuces permissions et sécurité. Si vous travaillez en équipe, la gestion du contexte vous explique comment partager une configuration cohérente.

À retenir : combinez des règles deny strictes avec le sandboxing automatique pour une sécurité maximale sur les projets sensibles.

Comment auditer et surveiller les actions de Claude Code ?

Surveiller les actions de l'agent est aussi essentiel que configurer les permissions. Claude Code génère des logs détaillés de chaque opération exécutée, vous permettant de retracer toute activité suspecte.

Consultez les logs de la dernière session avec cette commande :

# Consultez les logs dans ~/.claude/projects/

Le répertoire ~/.claude/projects/ contient les transcripts de session, qui retracent les outils utilisés, les arguments passés et les résultats. Les actions refusées par les règles deny y sont visibles dans le transcript. En pratique, un audit hebdomadaire de 10 minutes suffit pour détecter les anomalies.

Le coding agentique introduit des risques spécifiques car l'agent prend des décisions autonomes. Examinez régulièrement les patterns de commandes pour vérifier que l'agent n'a pas développé des comportements inattendus.

Pour une première prise en main de l'outil, le guide d'installation et premier lancement couvre la mise en place complète. Vous pouvez ensuite suivre le guide vos premières conversations pour apprendre à interagir avec l'agent en toute sécurité.

SFEIR Institute propose la formation Claude Code d'une journée qui inclut des labs pratiques sur la configuration des permissions et le sandboxing. Pour aller plus loin, la formation Développeur Augmenté par l'IA de 2 jours couvre l'intégration sécurisée des agents IA dans vos workflows de développement, avec des exercices sur les règles allow/deny et la détection d'injections.

À retenir : auditez vos logs au moins une fois par semaine et bloquez immédiatement tout pattern de commande non reconnu.

Peut-on utiliser Claude Code en toute sécurité dans un pipeline CI/CD ?

L'intégration de Claude Code dans un pipeline CI/CD nécessite une configuration de sécurité renforcée. L'agent s'exécute sans supervision humaine, ce qui rend les règles deny et le sandboxing critiques.

Lancez Claude Code en mode headless avec des permissions restreintes. Pour réellement limiter les outils, utilisez le mode dontAsk avec une allowlist : seuls les outils pré-approuvés s'exécutent, tout le reste est refusé.

claude --permission-mode dontAsk \
 --allowedTools "Read,Edit,Bash(npm test *),Bash(npm run build *)" \
 -p "Corrige les tests échoués"

Attention : ne combinez pas --dangerously-skip-permissions (mode bypassPermissions) avec --allowedTools. Le mode bypassPermissions court-circuite entièrement la couche de permissions, donc --allowedTools n'a aucun effet : aucune restriction d'outils ne s'applique. Réservez --dangerously-skip-permissions aux conteneurs jetables où aucune restriction d'outils n'est attendue.

En mode CI/CD, voici les pratiques recommandées par SFEIR Institute :

1. Activez le mode bypass uniquement dans un conteneur éphémère
2. Restreignez les outils autorisés au strict minimum via --allowedTools
3. Désactivez l'accès réseau dans le sandbox
4. Bornez la durée d'exécution pour éviter les blocages : limitez le timeout du job CI, et côté Claude Code utilisez --max-turns (nombre de tours agentiques en mode -p) ou --max-budget-usd (budget API maximal en mode -p)
5. Archivez les logs de chaque exécution pour audit

Le conteneur doit être détruit après chaque exécution. Aucun secret ne doit être monté en clair : utilisez des variables d'environnement injectées par votre gestionnaire de secrets (Vault, AWS Secrets Manager).

La formation Développeur Augmenté par l'IA – Avancé d'une journée couvre spécifiquement l'intégration CI/CD des agents IA, avec des labs sur la sécurisation des pipelines automatisés et la gestion des secrets.

À retenir : en CI/CD, traitez Claude Code comme n'importe quel processus non fiable : conteneur éphémère, permissions minimales, logs archivés.

Quels sont les pièges de sécurité les plus fréquents à éviter ?

Certaines erreurs reviennent régulièrement chez les développeurs qui configurent Claude Code pour la première fois. Voici les 5 pièges les plus courants et comment les éviter.

Piège 1 : laisser le mode Bypass activé en local. Ce mode désactive toutes les protections. Des dépôts publics contiennent des fichiers CLAUDE.md malveillants qui exploitent ce mode. Revenez systématiquement en mode Normal après vos sessions CI/CD.

Piège 2 : oublier de deny les commandes réseau. Par défaut, curl, wget et nc demandent confirmation en mode default. Même en mode acceptEdits, ils continuent de demander confirmation : ce mode n'auto-approuve que les éditions de fichiers et un jeu restreint de commandes filesystem (mkdir, touch, rm, rmdir, mv, cp, sed), pas les commandes réseau. Ajoutez néanmoins ces commandes dans votre deny global pour les bloquer dans tous les modes.

Piège 3 : partager un settings.json avec des allow trop permissifs. Un Bash() dans les allow projet autorise toutes les commandes shell. Préférez des patterns spécifiques comme Bash(npm ) ou Bash(git *).

Piège 4 : ignorer les mises à jour de sécurité. Claude Code reçoit régulièrement des correctifs de sécurité. Mettez à jour dès qu'une nouvelle version est disponible. Mettez à jour avec :

claude update
# ou : npm install -g @anthropic-ai/claude-code@latest

Piège 5 : ne pas vérifier les CLAUDE.md des sous-modules. Les sous-modules git peuvent contenir leurs propres fichiers de configuration. Inspectez chaque sous-module avant de lancer une session.

Pour une liste exhaustive de vérifications, la checklist de sécurité couvre tous les points critiques. Vous trouverez aussi des solutions aux problèmes courants dans le guide de dépannage.

À retenir : la majorité des incidents de sécurité proviennent de configurations trop permissives laissées en place par habitude : auditez vos settings chaque mois.