Claude Code sécurité : permissions, sandbox et secrets

TL;DR

Claude Code sécurité en entreprise : quatre couches comptent, les règles de permission, la sandbox Bash au niveau du système, les managed settings non contournables et les hooks. Les règles deny seules ne sont pas une frontière. Depuis v2.1.283, les sessions démarrent en mode auto. Nous recommandons une politique centrale qui impose la sandbox et bloque les .env.

Contre quoi la sécurité de Claude Code protège-t-elle ?

La sécurité de Claude Code vise un risque précis : un agent doté d’un accès shell qui exécute des instructions que vous n’avez pas données. Cela couvre l’injection de prompt via des fichiers, des pages web ou des outils MCP, la lecture accidentelle de secrets et l’exfiltration par le réseau.

La page sécurité d’Anthropic décrit le socle. En mode Manual, Claude Code démarre en lecture seule, demande avant toute modification et avant les commandes Bash qui peuvent changer le système, et n’écrit que dans le dossier où il a été lancé. Les commandes comme curl et wget ne sont pas approuvées automatiquement. Les récupérations web passent par une fenêtre de contexte séparée, pour qu’une page piégée n’écrive pas directement dans la conversation principale. Un nouveau dépôt ou un nouveau serveur MCP exige une confirmation de confiance. Anthropic renvoie à un rapport SOC 2 Type 2 et à un certificat ISO 27001 dans son Trust Center.

C’est le comportement pour un développeur isolé. En entreprise, trois problèmes s’ajoutent : les développeurs modifient leurs propres réglages, la CI lance Claude Code sans surveillance, et les valeurs par défaut évoluent à chaque version. Le tableau résume ce que chaque couche impose.

Couche	Ce qu’elle impose	Ce qu’elle ne couvre pas
Règles de permission	Outils, fichiers et domaines autorisés	Un programme appelé autrement, par ex. sh -c
Sandbox Bash	Limites fichiers et réseau au niveau OS pour le shell et ses processus enfants	Outils Read, Edit, Write ; Windows natif
Managed settings	Politique que l’utilisateur, le projet et la CLI ne peuvent pas lever	Postes hors de portée du MDM
Hooks	Contrôles maison avant ou après un appel d’outil	Tout ce que vous n’avez pas scripté
Dev container	Une frontière de machine jetable	Les données montées dans le conteneur

L’article 32 du RGPD exige des mesures techniques adaptées au risque et une procédure pour tester régulièrement leur efficacité. Pour un agent de code avec accès shell, nous le traduisons ainsi : une sandbox imposée, un fichier de politique écrit, un cycle de revue. Le lieu de traitement des requêtes Claude elles-mêmes est une autre question, traitée dans notre article sur la confidentialité des données Claude en entreprise.

Comment fonctionnent les modes de permission et les règles allow et deny ?

Claude Code évalue les règles de permission dans un ordre fixe : deny, puis ask, puis allow. La première correspondance l’emporte. Un Bash(aws *) en deny bat un Bash(aws s3 ls) en allow. Un deny posé dans les managed settings ne peut être levé ni par les réglages utilisateur ou projet, ni par --allowedTools.

La référence des permissions liste six modes. default (affiché Manual) demande au premier usage de chaque outil. acceptEdits valide les modifications de fichiers et les commandes courantes du système de fichiers dans le répertoire de travail. plan lit et propose sans modifier. auto travaille sans demandes de routine, un modèle classifieur examine les actions. dontAsk refuse tout ce qui déclencherait une demande. bypassPermissions saute les demandes, et la documentation le réserve aux conteneurs ou VM isolés.

Le changement que beaucoup d’équipes sécurité ont manqué : depuis v2.1.283, le mode auto est le mode de démarrage intégré des sessions interactives en terminal et dans VS Code, sur tous les forfaits et chez tous les fournisseurs, Bedrock et Google Cloud compris. La page des modes de permission précise que claude -p chez un fournisseur tiers démarre aussi en auto depuis v2.1.285. Sur Bedrock, Google Cloud et Foundry, le mode auto exige Sonnet 5 ou plus récent, Opus 4.7 ou plus récent, ou un modèle Fable, et chaque vérification du classifieur compte dans votre facture de tokens. Anthropic prévient lui-même que le mode auto réduit les demandes sans garantir la sécurité.

Le second piège porte sur ce que vise une règle Bash. Elle compare le texte de commande écrit par Claude, pas le programme.

Règle deny	Arrête	N’arrête pas
Bash(curl *)	curl https://example.com	/usr/bin/curl ..., sh -c 'curl ...'
Bash(rm *)	rm -rf build/	/bin/rm -rf build/, bash -c 'rm -rf build/'
Bash(git push *)	git push origin main	git -C . push origin main

Les règles Bash deny sont donc des garde-fous pour le comportement normal, pas une frontière de sécurité. Pour les fichiers et le réseau, c’est la sandbox qui impose. Les règles allow du .claude/settings.json d’un dépôt ne s’appliquent qu’après acceptation du dialogue de confiance. Les règles deny et ask s’appliquent tout de suite, car elles ne font que restreindre.

Comment isoler Bash dans la sandbox et garder les secrets hors d’atteinte ?

La sandbox impose des limites de fichiers et de réseau au niveau du système d’exploitation, pour chaque commande shell et ses processus enfants. Elle s’appuie sur Seatbelt sous macOS, sur bubblewrap et socat sous Linux et WSL2. Windows natif n’est pas pris en charge. Activez-la, rendez-la obligatoire, listez vos chemins d’identifiants et bloquez les .env pour les outils fichiers.

La règle de lecture par défaut surprend souvent. La documentation de la sandbox indique que les commandes sandboxées peuvent lire tout l’ordinateur par défaut, y compris ~/.aws/credentials et ~/.ssh/. Il n’existe aucune liste de refus d’identifiants intégrée : seuls les fichiers et variables listés dans sandbox.credentials sont protégés. L’écriture se limite au répertoire de travail, aux répertoires ajoutés et à un répertoire temporaire propre à l’utilisateur.

Trois réglages transforment la sandbox en véritable contrôle :

1. sandbox.failIfUnavailable: true empêche Claude Code de démarrer si bubblewrap manque, au lieu d’avertir et de tourner sans sandbox.
2. sandbox.allowUnsandboxedCommands: false supprime l’échappatoire qui permet à Claude de relancer hors sandbox une commande bloquée.
3. sandbox.network.allowManagedDomainsOnly: true n’accepte que la liste de domaines des managed settings et bloque le reste sans demander.

Connaissez les limites. Le proxy intégré décide sur le nom d’hôte et n’inspecte pas TLS par défaut. Anthropic avertit que des domaines larges comme github.com peuvent ouvrir des voies d’exfiltration, domain fronting compris. excludedCommands n’a pas de verrou réservé aux managed settings. Depuis v2.1.282, les entrées des réglages projet et locaux sont ignorées dès que la politique centrale fixe allowUnsandboxedCommands: false, mais les réglages utilisateur d’un développeur peuvent encore ajouter des commandes hors sandbox. docker est incompatible et finit en général dans cette liste.

Pour les secrets, combinez deux mécanismes. Les règles permissions.deny comme Read(.env) retirent les fichiers concernés des recherches, bloquent leur lecture et bloquent aussi Edit et Write sur ces chemins. Elles couvrent cat, head et les redirections. La référence des réglages précise qu’elles ne couvrent ni grep -r pattern . ni les sous-processus arbitraires, d’où l’importance des entrées denyRead et credentials de la sandbox. Troisième mesure : CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1. Cette variable retire les identifiants Anthropic et cloud de l’environnement de Bash, des hooks et des serveurs MCP stdio, tandis que le processus principal les garde pour les appels API. Sur Bedrock, la session AWS qui paie les tokens reste ainsi hors de portée d’une expansion shell.

Comment Claude Code gère-t-il l’injection de prompt ?

Claude Code limite l’injection de prompt par des demandes d’approbation, une fenêtre de contexte séparée pour les récupérations web, et des dialogues de confiance pour les nouveaux dépôts et serveurs MCP. En mode auto, le classifieur bloque les actions qui semblent dictées par un contenu hostile. Rien de cela ne suffit quand un attaquant contrôle la configuration du dépôt.

Le cas le plus risqué est la CI. Avec -p, la vérification de confiance est désactivée. La page des permissions liste ce qu’un dépôt peut fournir lors d’un claude -p ou d’une session SDK dans un dossier jamais approuvé : hooks des fichiers de réglages, bloc env, commandes helper et serveurs de .mcp.json, tous utilisés sans demande. Une pull request qui ajoute un hook exécute donc du code sur votre runner. Pour les pipelines qui traitent du code externe, la documentation donne trois parades : --setting-sources user pour ne lire ni les réglages du projet ni .mcp.json, --bare pour ne charger aucun hook, skill ou serveur MCP du projet, et --settings '{"disableAllHooks": true}'.

Les hooks sont aussi votre propre outil de contrôle. Un hook PreToolUse reçoit l’entrée de l’outil en JSON et peut refuser l’appel. Le code de sortie 2 bloque même si le JSON du hook indique allow, et une règle deny l’emporte toujours sur la décision d’un hook. Un hook ConfigChange peut bloquer en cours de session les modifications des réglages utilisateur, projet et locaux, mais pas celles de la politique centrale, qui s’appliquent toujours. Avec allowManagedHooksOnly: true, seuls tournent les hooks des managed settings et des plugins activés de force. Effet de bord : /goal ne fonctionne plus.

MCP mérite sa propre règle. Anthropic examine les connecteurs de son annuaire selon des critères d’admission, mais n’audite la sécurité d’aucun serveur MCP. Utilisez allowManagedMcpServersOnly avec une liste blanche. Pour les agents lancés avec --dangerously-skip-permissions, passez par le dev container. La configuration de référence tourne avec un utilisateur non root et fournit init-firewall.sh, une liste blanche de sortie réseau. Anthropic rappelle qu’un projet malveillant peut malgré tout exfiltrer tout ce qui se trouve dans le conteneur, y compris les identifiants Claude Code de ~/.claude.

À quoi ressemble une configuration managed settings durcie ?

Placez la politique dans managed-settings.json et distribuez-la par MDM ou comme fichier dans le répertoire système. Les managed settings sont au sommet de la hiérarchie. Le modèle ci-dessous impose la sandbox, protège les secrets, désactive le mode bypass et restreint les hooks. Adaptez la liste de domaines et les chemins d’identifiants avant le déploiement.

{
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "blockReadsOutsideWorkingDirectories": true,
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(./secrets/**)",
      "Read(~/.aws/**)",
      "Read(~/.ssh/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": ["Bash(git push *)"]
  },
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    },
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["git.example.internal", "registry.npmjs.org"]
    }
  },
  "env": { "CLAUDE_CODE_SUBPROCESS_ENV_SCRUB": "1" },
  "cleanupPeriodDays": 14
}

defaultMode: "default" démarre les sessions en Manual plutôt qu’en auto. Les développeurs peuvent toujours passer en auto. Si votre politique interdit le classifieur, ajoutez "disableAutoMode": "disable" sous permissions. cleanupPeriodDays: 14 est notre choix. Par défaut, les transcriptions locales restent 30 jours en clair sous ~/.claude/projects/. blockReadsOutsideWorkingDirectories exige v2.1.257 ou plus récent.

Déployez dans cet ordre :

1. Placez le fichier dans /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux et WSL) ou C:\Program Files\ClaudeCode\managed-settings.json (Windows).
2. Lancez /status sur un poste de test. La ligne Setting sources doit afficher Enterprise managed settings (file).
3. Faites un cycle de build et de tests complet dans Claude Code et ajoutez les hôtes nécessaires à allowedDomains. docker et certaines CLI écrites en Go demanderont sans doute excludedCommands.
4. Passez par une équipe pilote, puis toute la flotte. Les profils MDM sont relus toutes les 30 minutes, les fichiers à chaque modification.

Deux points pour Bedrock et Google Cloud. D’abord, les server-managed settings de la console claude.ai n’atteignent pas les sessions qui exportent une variable fournisseur CLAUDE_CODE_USE_*. Passez par le MDM, le fichier ou une passerelle Claude apps auto-hébergée. Ensuite, la page sur l’usage des données indique que métriques, rapports d’erreur et envois /feedback sont désactivés par défaut sur Bedrock et Google Cloud, alors que les enquêtes de session et la vérification de domaine WebFetch restent actives. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC et skipWebFetchPreflight les coupent. La mécanique de distribution et OpenTelemetry méritent leur propre plan de déploiement. Le routage UE lui-même est décrit dans notre guide Claude Code sur Bedrock en Europe.

Exploiter en interne ou externaliser ?

Exploiter la sécurité de Claude Code en interne, c’est maintenir un fichier de politique qui évolue avec le produit. Le changelog liste 27 versions datées de septembre 2026, dont plusieurs ont modifié le comportement des permissions ou de la sandbox. Externaliser se justifie quand personne ne porte la politique des postes.

Les tâches récurrentes, telles que nous les voyons :

Tâche	Fréquence	Rôle habituel
Lire les notes de version, repérer les changements de permissions et de sandbox	Hebdomadaire	Ingénieur plateforme ou sécurité
Retester le modèle sur macOS, Linux, WSL2	À chaque version concernée	Ingénieur plateforme
Traiter les demandes d’ajout de domaines et d’excludedCommands	Hebdomadaire	Ingénieur sécurité
Vérifier que la politique s’applique (/status, claude doctor)	Échantillon mensuel	Équipe IT ou MDM
Incidents : clé divulguée, action suspecte de l’agent	À la demande	Équipe sécurité, DPO
Revoir les pipelines CI qui lancent claude -p	À chaque nouveau pipeline	DevOps

Notre estimation, et non un chiffre sourcé : pour 50 à 200 développeurs, comptez deux à quatre heures par semaine d’un ingénieur plateforme sensibilisé à la sécurité, plus le temps des incidents. Les incidents ont une échéance stricte. Si un agent fait fuiter des données personnelles, l’article 33 du RGPD impose de notifier l’autorité de contrôle si possible dans les 72 heures.

Gardez le sujet en interne si vous exploitez déjà un MDM, disposez d’une équipe de sécurité des postes et gérez vos politiques comme du code dans un dépôt. Cette équipe ira plus vite qu’un prestataire. Externalisez vers un prestataire de services managés quand les postes développeurs ne sont pas sous MDM, quand personne ne trie les notes de version, ou quand Claude Code tourne dans de nombreux pipelines sans surveillance.

Si vous externalisez, exigez ceci dans le contrat :

• SLA : un délai écrit pour évaluer chaque version de Claude Code et pour corriger la politique après un changement touchant la sécurité.
• Contrat de sous-traitance selon l’article 28 du RGPD : le prestataire voit des transcriptions, des journaux et parfois du code lors des incidents. C’est un traitement pour votre compte, il agit comme sous-traitant.
• Liste des sous-traitants ultérieurs : qui d’autre accède à vos journaux ou à votre télémétrie, et où.
• Modèle d’accès : les changements passent par votre MDM avec votre validation, sans accès administrateur permanent aux postes.
• Réversibilité : la politique reste dans votre dépôt en JSON brut avec son historique, pour la reprendre sans tout reconstruire.

Le coût des licences par poste figure dans notre comparatif prix de Claude Code pour les équipes.

FAQ

Claude Code est-il assez sûr pour du code d’entreprise ?

Oui, avec une politique imposée. Sans réglage, les sessions démarrent désormais en mode auto et les commandes sandboxées peuvent lire tout le disque. Avec des managed settings qui activent la sandbox, bloquent .env et les identifiants et désactivent le mode bypass, les risques principaux sont couverts. La revue du code reste votre responsabilité.

Une règle deny sur .env bloque-t-elle toute lecture ?

Non. Read(.env) bloque les outils fichiers de Claude et les commandes reconnues comme cat, mais pas grep -r ni les sous-processus arbitraires. Ajoutez les mêmes chemins dans sandbox.filesystem.denyRead ou sandbox.credentials et activez la sandbox pour que le système d’exploitation applique le blocage.

Combien coûte le durcissement de Claude Code ?

Les réglages sont gratuits. Le coût vient du personnel et des tokens. En mode auto sur Bedrock, Google Cloud ou Foundry, chaque vérification du classifieur compte dans la consommation de tokens. Nous estimons la maintenance de la politique à deux à quatre heures par semaine pour 50 à 200 développeurs. Ce chiffre est le nôtre, pas celui d’Anthropic.

Sandbox ou dev container : lequel faut-il ?

La sandbox sur les postes des développeurs. Elle limite les commandes shell sans changer la façon de travailler. Le dev container quand Claude tourne sans surveillance ou avec --dangerously-skip-permissions. Le conteneur est la frontière la plus forte, mais tout ce qui y est monté peut encore être exfiltré.

Claude Code envoie-t-il de la télémétrie avec Bedrock ?

Par défaut, ni métriques, ni rapports d’erreur, ni envois de feedback. Les enquêtes de session et la vérification de domaine WebFetch restent actives, et cette vérification n’envoie que le nom d’hôte. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC et skipWebFetchPreflight: true désactivent les deux.

Les développeurs peuvent-ils contourner les managed settings ?

Pas pour les règles de permission ni pour les interrupteurs booléens de la sandbox. Les managed settings ont la priorité la plus haute, y compris sur les options de ligne de commande. Les clés de type tableau comme excludedCommands fusionnent entre niveaux, donc un développeur peut les élargir. allowManagedDomainsOnly et allowManagedReadPathsOnly verrouillent les listes réseau et lecture.

Sources

1. Documentation Claude Code : Security (1 octobre 2026)
2. Documentation Claude Code : Configure permissions (1 octobre 2026)
3. Documentation Claude Code : Permission modes (1 octobre 2026)
4. Documentation Claude Code : Sandboxing (1 octobre 2026)
5. Documentation Claude Code : Settings reference (1 octobre 2026)
6. Documentation Claude Code : Environment variables (1 octobre 2026)
7. Documentation Claude Code : Hooks reference (1 octobre 2026)
8. Documentation Claude Code : Deploy managed settings (1 octobre 2026)
9. Documentation Claude Code : Server-managed settings (1 octobre 2026)
10. Documentation Claude Code : Data usage (1 octobre 2026)
11. Documentation Claude Code : Development containers (1 octobre 2026)
12. Changelog Claude Code (1 octobre 2026)
13. RGPD (règlement (UE) 2016/679), EUR-Lex (1 octobre 2026)