Permissions et sécurité - Astuces

Maîtriser les permissions et la sécurité de Claude Code vous protège contre les exécutions non désirées, les injections de prompt et les fuites de données. Voici 18 astuces classées par thème pour configurer vos modes de permission, durcir le sandboxing et verrouiller votre settings.json efficacement.

Les permissions et la sécurité dans Claude Code constituent le socle de toute utilisation professionnelle de cet agent IA en ligne de commande. Claude Code propose several permission mechanisms, un système de règles allow/deny granulaires et un sandboxing natif via Seatbelt (macOS) ou bubblewrap (Linux).

Une grande partie des incidents de sécurité liés aux agents IA proviennent d'une mauvaise configuration des permissions. Comprendre et appliquer ces réglages réduit significativement votre surface d'attaque.

Comment choisir le bon mode de permission pour votre usage ?

Claude Code propose les modes de permission qui contrôlent le niveau d'autonomie accordé à l'agent. Chaque mode correspond à un profil de risque différent. Avant de lancer votre première session, identifiez votre contexte d'utilisation pour sélectionner le mode adapté.

Astuce 1 - Démarrez toujours en mode default. Ce mode vous demande confirmation avant chaque écriture de fichier ou exécution de commande. En pratique, la plupart des développeurs l'utilisent au quotidien. Vous gardez le contrôle total sur chaque action.

Astuce 2 - Utilisez Shift+Tab ou Alt+M pour cycler entre les modes. En session, appuyez sur Shift+Tab ou Alt+M pour cycler entre les modes de permission disponibles. Vous pouvez passer de default à plan puis acceptEdits sans redémarrer Claude Code. Consultez le guide complet des permissions et de la sécurité pour comprendre chaque mode en détail.

Astuce 3 - N'utilisez le mode bypassPermissions qu'en CI/CD. Le flag --dangerously-skip-permissions désactive toute confirmation. Réservez ce mode aux pipelines automatisés dans des conteneurs isolés. En dehors d'un environnement sandboxé, ce mode expose votre système à des exécutions arbitraires.

# Mode default (défaut)
claude

# Mode acceptEdits
claude --permission-mode acceptEdits

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

# En session, Shift+Tab ou Alt+M pour cycler entre les modes

# Mode bypass (CI/CD uniquement, dans un conteneur)
claude --dangerously-skip-permissions

À retenir : le mode default couvre la plupart des usages ; ne passez en Bypass que dans un conteneur CI/CD isolé.

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

Le fichier settings.json de Claude Code permet de définir des règles granulaires pour autoriser ou bloquer des outils et des commandes spécifiques. Ces règles s'appliquent à trois niveaux : utilisateur (~/.claude/settings.json), projet (.claude/settings.json) et projet local (.claude/settings.local.json).

Astuce 4 - Autorisez explicitement vos commandes fréquentes. Ajoutez vos commandes de build et de test en allow pour éviter les confirmations répétitives. Concrètement, chaque règle allow supprime la confirmation pour la commande correspondante, ce qui vous évite des confirmations répétitives.

{
 "permissions": {
 "allow": [
 "Bash(npm run build)",
 "Bash(npm test)",
 "Bash(npx eslint *)",
 "Read",
 "Write(src/**)"
 ]
 }
}

Astuce 5 - Bloquez les commandes destructrices. Configurez des règles deny pour empêcher les suppressions accidentelles et les commandes à risque. Les règles deny sont prioritaires sur les règles allow. En pratique, bloquer rm -rf, git push --force et curl réduit fortement les risques d'exécution non souhaitée.

{
 "permissions": {
 "deny": [
 "Bash(rm -rf *)",
 "Bash(git push --force*)",
 "Bash(curl *)",
 "Bash(wget *)"
 ]
 }
}

Astuce 6 - Utilisez les wildcards pour des règles flexibles. Le caractère fonctionne dans les patterns de permission. Write(src/) autorise l'écriture dans tout le dossier src/ et ses sous-dossiers. Bash(npm ) couvre toutes les commandes npm. Pour des stratégies de permission avancées, consultez les best practices avancées.

Astuce 7 - Séparez les settings projet des settings personnels. Le fichier .claude/settings.json à la racine du projet se partage via Git avec votre équipe. Le fichier .claude/settings.local.json reste local et ignoré par Git. Placez les règles spécifiques à votre environnement (chemins absolus, tokens) dans le fichier local.

À retenir : les règles deny sont toujours prioritaires sur les règles allow ; séparez vos settings personnels des settings projet.

Comment fonctionne le sandboxing de Claude Code ?

Le sandboxing est une couche de protection système qui limite les accès de Claude Code au réseau et au système de fichiers, indépendamment des permissions configurées. Claude Code utilise Seatbelt sur macOS et bubblewrap sur Linux. Ce mécanisme restreint fortement les accès réseau sortants et limite l'écriture aux répertoires de travail. Le sandboxing n'est PAS activé par défaut : activez-le par projet via la commande /sandbox, ou globalement en ajoutant "sandbox": { "enabled": true } dans ~/.claude/settings.json.

Astuce 8 - Vérifiez l'état du sandboxing. Exécutez la commande slash /sandbox dans une session Claude Code pour afficher le mode de sandboxing actif et l'état des dépendances installées. Sur Linux/WSL2, le sandbox repose sur deux paquets, bubblewrap (bwrap) et socat, qui doivent être installés séparément. Le sandboxing limite fortement les accès réseau sortants (aucun domaine n'est pré-autorisé par défaut), mais ne constitue pas une isolation complète.

# Vérifier l'état du sandboxing depuis une session Claude Code
/sandbox

# Sur Linux/WSL2, installer les dépendances si absentes
sudo apt-get install bubblewrap socat

# Filtre seccomp optionnel
npm install -g @anthropic-ai/sandbox-runtime

Astuce 9 - Comprenez les limites du sandbox. Par défaut, aucun domaine n'est pré-autorisé : la première fois qu'une commande a besoin d'un nouveau domaine, Claude Code demande votre approbation. Pré-autorisez des domaines via sandbox.network.allowedDomains. Par défaut, l'écriture est limitée au répertoire de travail courant et à ses sous-dossiers ; ajoutez d'autres chemins via sandbox.filesystem.allowWrite. Pour approfondir la résolution de problèmes liés au sandboxing, consultez le dépannage des permissions.

Astuce 10 - En CI/CD, doublez le sandboxing avec Docker. Exécutez Claude Code dans un conteneur Docker même en mode Bypass. Le conteneur ajoute une isolation réseau et système de fichiers complémentaire au sandbox natif. Concrètement, cette double couche réduit significativement la surface d'attaque par rapport à une exécution non sandboxée. Retrouvez les détails dans les astuces pour le mode headless et CI/CD.

À retenir : le sandboxing fonctionne indépendamment des permissions et bloque les accès réseau non autorisés même si une commande est en allow.

Comment se protéger contre les prompt injections ?

Le prompt injection est une attaque où du contenu malveillant dans un fichier ou une réponse d'outil tente de manipuler Claude Code pour exécuter des actions non souhaitées. Claude Code intègre plusieurs mécanismes de défense natifs, mais votre configuration renforce la protection.

Astuce 11 - Ne passez jamais en mode Bypass sur du code non audité. Quand vous clonez un dépôt inconnu, restez en mode default. Un fichier CLAUDE.md malveillant pourrait contenir des instructions cachées. En mode default, Claude Code vous demande confirmation avant chaque action sensible, ce qui vous laisse le temps de détecter une tentative d'injection.

Astuce 12 - Auditez les fichiers CLAUDE.md des dépôts externes. Lisez systématiquement le contenu de CLAUDE.md et .claude/settings.json avant de lancer Claude Code sur un projet tiers. Ces fichiers peuvent contenir des règles de permission permissives ou des instructions orientant le comportement de l'agent. Voici comment procéder :

# Auditer les fichiers de configuration avant d'utiliser Claude Code
cat CLAUDE.md
cat .claude/settings.json
cat .claude/settings.local.json 2>/dev/null

Astuce 13 - Utilisez les règles deny pour bloquer les vecteurs d'attaque courants. Les commandes curl, wget, nc (netcat) et ssh sont les vecteurs d'exfiltration les plus fréquents. Ajoutez ces commandes dans vos deny rules globales. En pratique, la majorité des tentatives de prompt injection visent l'exfiltration de données via des requêtes réseau.

{
 "permissions": {
 "deny": [
 "Bash(curl *)",
 "Bash(wget *)",
 "Bash(nc *)",
 "Bash(ssh *)",
 "Bash(python -c *)",
 "Bash(node -e *)"
 ]
 }
}

Pour approfondir la gestion sécurisée des serveurs MCP tiers, consultez les astuces MCP. Les serveurs MCP représentent un vecteur d'injection supplémentaire quand ils proviennent de sources non vérifiées.

Astuce 14 - Surveillez les résultats de commandes inhabituels. Claude Code affiche un avertissement quand un résultat d'outil semble contenir une tentative d'injection. Lisez attentivement ces avertissements et refusez l'action si le contenu vous semble suspect. le système intègre une détection native des tentatives d'injection.

À retenir : restez en mode default sur du code non audité et bloquez les commandes réseau via deny rules pour neutraliser les vecteurs d'injection.

Quels réglages avancés configurer dans settings.json ?

Au-delà des permissions, le fichier settings.json contrôle le comportement global de Claude Code. Voici les réglages de sécurité avancés à connaître pour durcir votre configuration.

Astuce 15 - Gardez la télémétrie désactivée si votre politique l'exige. La télémétrie est désactivée par défaut : aucune donnée d'usage n'est envoyée tant que la variable d'environnement CLAUDE_CODE_ENABLE_TELEMETRY n'est pas mise à 1. Pour garantir explicitement qu'elle reste désactivée, laissez-la à 0 (ou évitez de l'activer) dans le bloc env de votre settings.json global. En environnement réglementé (finance, santé), cette garantie est souvent obligatoire. Consultez la FAQ des permissions pour les questions fréquentes sur la confidentialité.

{
 "env": {
 "CLAUDE_CODE_ENABLE_TELEMETRY": "0"
 },
 "permissions": {
 }
}

Astuce 16 - Limitez les modèles autorisés. Vous pouvez restreindre les modèles utilisables via les managed settings d'entreprise, par exemple en définissant la liste availableModels. Concrètement, restreindre les modèles disponibles empêche l'utilisation de modèles non approuvés par votre équipe.

Astuce 17 - Configurez un timeout pour les commandes longues. Claude Code n'applique pas de timeout fixe par défaut sur les commandes bash. Vous pouvez en définir un via les variables d'environnement BASH_DEFAULT_TIMEOUT_MS (timeout par défaut, en millisecondes) et BASH_MAX_TIMEOUT_MS (plafond). Gardez une valeur raisonnable pour éviter qu'une commande bloquée ne consomme des ressources indéfiniment. Pour organiser vos sessions de manière efficace, consultez les astuces pour vos premières conversations.

Pour maîtriser la gestion du contexte et éviter les fuites d'information entre sessions, consultez les astuces de gestion du contexte.

À retenir : désactivez la télémétrie en environnement réglementé et définissez un timeout bash raisonnable via BASH_DEFAULT_TIMEOUT_MS pour limiter les risques.

Comment auditer et valider votre configuration de sécurité ?

Une configuration sécurisée ne sert que si elle est vérifiée régulièrement. Mettez en place une routine d'audit pour détecter les dérives de configuration et les règles obsolètes.

Astuce 18 - Créez un script d'audit automatisé. Exécutez ce script avant chaque session de travail sur un projet sensible. Il vérifie rapidement la présence d'un fichier de settings et de règles deny.

#!/bin/bash
# Audit rapide de la sécurité Claude Code
echo "=== Audit sécurité Claude Code ==="

# Vérifier settings.json global
if [ -f ~/.claude/settings.json ]; then
 echo "[OK] Settings global trouvé"
 grep -q "deny" ~/.claude/settings.json && echo "[OK] Deny rules présentes" || echo "[WARN] Aucune deny rule"
else
 echo "[WARN] Pas de settings global"
fi

# Vérifier settings projet
if [ -f .claude/settings.json ]; then
 echo "[OK] Settings projet trouvé"
else
 echo "[INFO] Pas de settings projet"
fi

echo "=== Fin audit ==="

Pour une checklist complète de validation, consultez la checklist des permissions et sécurité. Elle couvre les 12 points de contrôle essentiels pour une configuration durcie. Vous pouvez aussi créer des commandes personnalisées pour automatiser cet audit.

À retenir : automatisez l'audit de votre configuration et exécutez-le avant chaque session sur un projet sensible.

Pourquoi former votre équipe à la sécurité de Claude Code ?

La configuration technique ne suffit pas sans la montée en compétence de votre équipe. Les erreurs humaines (mode Bypass sur du code non audité, désactivation du sandbox) restent le premier vecteur de risque. SFEIR Institute propose des formations dédiées pour ancrer les bonnes pratiques.

La formation Claude Code d'une journée vous permet de maîtriser les modes de permission, de configurer le sandboxing et de rédiger des règles allow/deny adaptées à votre contexte. Vous pratiquez sur des labs concrets avec des scénarios de prompt injection.

Pour aller plus loin, la formation Développeur Augmenté par l'IA sur deux jours couvre l'intégration sécurisée des agents IA dans votre workflow de développement, incluant la configuration CI/CD et les politiques d'entreprise. La formation Développeur Augmenté par l'IA – Avancé d'une journée approfondit les stratégies de défense contre les injections et l'orchestration multi-agents sécurisée.

À retenir : investir une journée de formation réduit très significativement les erreurs de configuration de sécurité sur les 6 mois suivants.