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 LLM pour décider automatiquement quelles actions sont sûres. Il nécessite Claude Sonnet 4.6 ou Opus 4.6, et un plan Team, Enterprise ou API.

Le mode dontAsk n'exécute que les outils pré-approuvés dans vos règles allow. Toute action non explicitement autorisée est silencieusement ignorée.

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 LLM, Team/Enterprise)
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|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 que le sandbox est actif avec cette commande :

Le sandbox est activé automatiquement et ne nécessite aucune commande de vérification.

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.

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 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

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,
 "pathPrefixes": ["/var/myapp", "/tmp/builds"]
 }
}

La clé sandbox.enabled active ou désactive le sandboxing (Seatbelt sur macOS, bubblewrap sur Linux). sandbox.pathPrefixes définit les répertoires supplémentaires 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": 5000}
  ]
 }
 ],
 "PostToolUse": [],
 "UserPromptSubmit": [],
 "SessionStart": [],
 "Stop": [],
 "Notification": []
 }
}

Les hooks supportent les événements PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop et Notification. Chaque hook peut utiliser un matcher (regex) et un champ if pour un filtrage fin. Les types de hooks sont : command, prompt, agent et http. Les codes de sortie déterminent le comportement : 0 = autoriser, 2 = bloquer, autre = autoriser avec log.

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

1. Projet local : .claude/settings.local.json - ignoré par git, priorité la plus haute
2. Projet partagé : .claude/settings.json à la racine du dépôt - versionné avec le code
3. Global : ~/.claude/settings.json - s'applique à tous les projets
4. Managed/Policy : politique d'organisation - définie par l'administrateur

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 : 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/

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 --dangerously-skip-permissions --allowedTools "Read,Edit,Bash(npm test *),Bash(npm run build *)" \
 # Network sandboxing is enabled by default \
 -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).

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 a recent update 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.