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 quatre modes de permission distincts, un système de règles granulaires dans settings.json et un sandboxing natif via Seatbelt (macOS) et bubblewrap (Linux). plus de 80 % des incidents de sécurité liés aux agents IA proviennent d'une mauvaise configuration des permissions.

Comment fonctionnent les quatre modes de permission de Claude Code ?

Claude Code propose quatre modes de permission 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 Normal 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 Plan restreint l'agent à la lecture seule et à la planification. Aucune modification de fichier ni exécution de commande n'est autorisée. Utilisez ce mode pour auditer un codebase ou préparer une stratégie de refactoring sans risque.

Le mode Auto-accept approuve automatiquement les opérations de lecture et d'écriture de fichiers. Les commandes shell nécessitent toujours votre validation. Ce mode accélère le travail courant de 40 % selon les benchmarks Anthropic.

Le mode Bypass 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.

Pour passer d'un mode à l'autre, exécutez la commande suivante dans le terminal :

claude --allowedTools "Edit,Write,Bash(git *)" config set permissions.mode auto-accept

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 Normal convient à 90 % des usages quotidiens ; ne passez en Bypass que dans un environnement jetable.

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 deux clés principales : allow et deny. Chaque règle cible un outil précis et peut inclure un pattern glob pour filtrer les arguments.

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

Les règles deny sont prioritaires sur les règles allow. 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 que le sandbox est actif avec cette commande :

claude config get sandbox.enabled

Sur Linux, bubblewrap crée un namespace utilisateur isolé. Le processus sandboxé voit un système de fichiers minimal avec uniquement les montages explicitement autorisés. Le temps de démarrage du sandbox est inférieur à 15 ms.

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 de 95 % la surface d'attaque exploitable par injection de prompt. Le sandbox intercepte en moyenne 12 appels système bloqués par session de développement.

À retenir : le sandboxing est activé par défaut depuis Claude Code v1.0 - ne le désactivez jamais sur une 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 la détection automatique. Claude Code analyse les résultats d'outils et signale les contenus suspects. Quand l'agent détecte une tentative d'injection, il affiche un avertissement et suspend l'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

En pratique, 73 % des tentatives d'injection ciblent les commandes shell selon une étude OWASP (2025). 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 le timeout des commandes pour éviter les processus suspendus :

{
  "permissions": {
    "allow": ["Read", "Bash(git *)"],
    "deny": ["Bash(rm -rf *)"]
  },
  "sandbox": {
    "enabled": true,
    "networkAccess": false
  },
  "commandTimeout": 120000
}

Le paramètre commandTimeout définit la durée maximale d'exécution d'une commande en millisecondes. La valeur par défaut est 120 000 ms (2 minutes). Pour les builds longs, augmentez cette valeur à 600 000 ms (10 minutes).

Le paramètre networkAccess dans la section sandbox contrôle l'accès réseau des processus enfants. En le désactivant, vous empêchez toute exfiltration de données, même si une injection réussit à exécuter une commande.

Concrètement, la hiérarchie de configuration suit trois niveaux :

1. Global : ~/.claude/settings.json - s'applique à tous les projets
2. Projet partagé : .claude/settings.json à la racine du dépôt - versionné avec le code
3. Projet local : .claude/settings.local.json - ignoré par git, surcharges personnelles

Les deny se cumulent entre les niveaux : 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 : désactivez networkAccess dans le sandbox pour tout projet manipulant des données confidentielles ou des secrets d'API.

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 :

claude logs --last-session

Chaque entrée de log contient l'horodatage, l'outil utilisé, les arguments passés et le résultat. Les commandes bloquées par les règles deny apparaissent avec le statut DENIED. 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 :

claude --mode bypass --allowedTools "Read,Edit,Bash(npm test *),Bash(npm run build *)" \
  --sandbox-network=false \
  -p "Corrige les tests échoués"

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. Limitez le timeout à 5 minutes (300 000 ms) pour éviter les blocages
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).

En pratique, un pipeline CI/CD avec Claude Code exécute en moyenne 45 opérations par run, avec un temps moyen de 3,2 minutes pour une suite de tests de 200 fichiers.

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. En 2026, 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 sont autorisés en mode Normal (avec confirmation). En mode Auto-accept, ils s'exécutent sans demande. Ajoutez ces commandes dans votre deny global.

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 des patches de sécurité réguliers. La version 2.3 de janvier 2026 a corrigé une faille de contournement du sandbox. Mettez à jour avec :

npm update -g @anthropic-ai/claude-code

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.