Guide de sécurité Claude Code : autorisations, MCP, sandboxing

Les chatbots traditionnels sont cloisonnés derrière une API : au pire, ils hallucinent. Un agent de codage IA, en revanche, s’exécute dans votre dépôt, votre terminal et (souvent) avec vos identifiants cloud ; il se trouve donc bien plus près d’environnements développeur privilégiés que tout ce que nous appelions un chatbot.

La question est de savoir comment utiliser Claude Code en toute sécurité sans vous ralentir. Avec les bonnes autorisations, des contrôles MCP et un sandboxing correctement ajusté, vous y parviendrez.

Dans cet article, je vous explique concrètement comment fonctionne le modèle de sécurité de Claude Code, où porter votre attention et quelles pratiques le rendent utile sans lui donner plus d’accès que prévu.

Si vous découvrez Claude et Claude Code, inscrivez-vous à notre cours gratuit Claude Code 101 pour acquérir les bases en une après-midi.

Comprendre le modèle de sécurité de Claude Code

Avant d’affiner la moindre règle, vous devez visualiser ce que Claude Code contrôle réellement.

Cinq éléments interagissent : un système d’autorisations qui décide de ce qui est permis, des contrôles d’accès aux outils qui bornent chaque capacité, des autorisations MCP pour les intégrations externes, un sandboxing pour l’isolation au niveau du système, et l’auditabilité pour revoir a posteriori. Chacun résout un problème différent, mais ils s’empilent.

Système d’autorisations

Le système d’autorisations est la couche statique.

Vous déclarez ce que Claude peut faire dans settings.json via trois listes : allow, ask et deny. Les règles sont évaluées dans l’ordre : deny, puis ask, puis allow, et le premier match l’emporte. Une règle deny bloque l’appel même si une règle allow plus large l’aurait autorisé.

Si aucune règle ne correspond, Claude revient au defaultMode de la session (nous parlerons des modes dans la section suivante).

Contrôles d’accès aux outils

Les autorisations s’appliquent aux outils, pas à l’agent dans son ensemble.

Claude Code propose ses propres outils intégrés : par exemple Bash pour les commandes shell, Read, Edit et Write pour le système de fichiers, WebFetch pour les requêtes HTTPS, WebSearch pour les recherches, etc. Chaque règle cite un outil et (facultativement) un spécificateur entre parenthèses, comme Bash(git commit:*) ou Read(./.env).

C’est cela qui rend le « moindre privilège » possible. Vous pouvez autoriser Bash(npm run:*) pour exécuter des tests sans donner à Claude un accès shell complet.

Autorisations MCP

Les serveurs MCP étendent Claude Code avec des outils non prévus à l’origine.

Chaque serveur apporte ses propres outils (un serveur GitHub ajoute des outils de pull request, un serveur base de données des outils de requête, etc.). Le système d’autorisations les couvre aussi, mais avec une autre syntaxe : les règles utilisent le format mcp__servername__toolname au lieu du spécificateur entre parenthèses.

À retenir : MCP double à peu près la problématique, car vous ne décidez plus seulement de ce que Claude peut faire dans votre shell, mais aussi de ce qu’il peut faire avec chaque système externe auquel vous l’avez connecté.

Sandboxing

Le sandboxing est la sécurité au niveau du système d’exploitation sous l’outil Bash.

Les règles d’autorisation disent à Claude ce qu’il doit faire. Le sandboxing impose ce qu’il peut faire, en limitant l’accès au système de fichiers et les appels réseau sortants au niveau de l’OS. Sur macOS, cela fonctionne nativement via Seatbelt. Sur Linux et WSL2, vous devez d’abord installer bubblewrap et socat.

Les deux couches se ressemblent mais couvrent des scénarios différents. Les autorisations empêchent Claude d’essayer, et le sandboxing empêche une tentative de réussir si une injection de prompt l’a tout de même poussé à essayer.

Auditabilité

Dernier élément : pouvoir voir ce qui s’est passé.

La commande /permissions liste chaque règle active et le fichier de configuration d’où elle provient, pour répondre à « pourquoi Claude a-t-il exécuté cela ? ». Des hooks (PreToolUse, PostToolUse, etc.) vous permettent de journaliser chaque appel d’outil vers votre propre système. Pour les équipes, des exporteurs OpenTelemetry envoient l’usage et les appels d’outils vers votre pile d’observabilité existante.

Autorisations et contrôles d’accès de Claude Code

L’essentiel de la sécurité vient des réglages d’autorisations ; c’est donc là que vous passerez le plus de temps à peaufiner.

Accès aux fichiers

Par défaut, Claude peut lire et modifier les fichiers du répertoire depuis lequel vous l’avez lancé.

La lecture est gérée par l’outil Read, et l’édition par Edit et Write. Chacun accepte un motif de chemin entre parenthèses, en syntaxe de type gitignore ; par exemple Read(**/.env) correspond à tous les fichiers .env, et Edit(src/**) couvre tout sous src/.

Un deny sur Read couvre les outils fichiers de Claude Code (Read, Grep, Glob, LS), mais ce n’est qu’un « best effort ». Un script Python ou Node exécuté via Bash peut toujours ouvrir le fichier, car la lecture passe par le shell, pas par l’outil Read. Si un secret est sensible, combinez le deny Read avec un deny Bash sur cat, head et tail pour ces chemins.

Pour étendre l’accès au-delà du répertoire de travail, utilisez additionalDirectories dans settings.json. Ainsi, vous donnez à Claude l’accès à une bibliothèque partagée hors de votre dépôt ou à un fichier de config dans votre répertoire personnel, sans supprimer totalement la frontière du répertoire de travail.

Exécution de commandes

L’outil Bash est celui qu’il faut le plus strictement borner.

Une règle Bash non spécifiée autorise toutes les commandes. Une règle bornée comme Bash(npm run:*) n’autorise que les invocations correspondantes. Le motif « deux-points + astérisque » est requis ici, et Claude Code comprend les opérateurs shell : une règle Bash(safe-cmd:*) ne correspondra pas à safe-cmd && rm -rf /.

Certaines commandes s’exécutent sans demande préalable dans tous les modes, car elles sont considérées comme en lecture seule par défaut. La liste comprend ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd et les formes en lecture seule de git. Vous ne pouvez pas réduire cette liste manuellement, mais vous pouvez ajouter une règle ask ou deny pour l’une d’elles afin d’outrepasser le défaut.

Pour tout ce qui n’est pas pré-approuvé, Claude affiche une demande dans le mode par défaut. L’invite montre la commande exacte et vous permet d’approuver une fois, d’approuver toutes les futures correspondances d’un motif, ou de refuser.

Modes d’autorisation

Les règles d’autorisation sont statiques, mais les modes d’autorisation modifient le comportement des appels non appariés.

Il en existe cinq :

• default : demande à la première utilisation de chaque outil.

• acceptEdits : approuve automatiquement les modifications de fichiers dans le répertoire de travail, tout en contrôlant les commandes shell. Utile lorsque vous faites confiance aux éditions mais pas au shell.

• plan : Claude lit et analyse, mais ne peut pas modifier des fichiers ni exécuter de commandes. Le bon mode pour la relecture de code ou la planification.

• dontAsk : refuse automatiquement tout ce qui n’est pas explicitement dans la liste allow.

• bypassPermissions : saute toutes les demandes. À n’utiliser que dans des environnements totalement isolés, comme un conteneur ou une VM.

Vous pouvez basculer entre les trois modes principaux avec Maj+Tab en cours de session, ou en définir un par défaut dans settings.json :

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Pour les équipes, des paramètres gérés ajoutent une couche que l’utilisateur ne peut pas outrepasser. Le fichier suit le même format JSON et se trouve dans un chemin système :

• /Library/Application Support/ClaudeCode/managed-settings.json sur macOS

• /etc/claude-code/managed-settings.json sur Linux

• C:\ProgramData\ClaudeCode\managed-settings.json sur Windows

Les règles deny dans les paramètres gérés s’appliquent à tous les projets de la machine ; c’est ainsi que vous faites respecter des règles comme « personne ne lit les fichiers .env » ou « personne n’active bypassPermissions » à l’échelle de l’organisation.

Le principe général est celui du moindre privilège, comme pour n’importe quel compte de service. 

Commencez avec l’ensemble minimal d’autorisations permettant d’avancer, et élargissez uniquement lorsque vous butez. Les recommandations d’Anthropic vont dans le même sens : relisez les changements effectués par Claude, auditez vos règles avec /permissions, et conservez des réglages spécifiques au projet dans le contrôle de version afin que l’équipe s’accorde sur ce que Claude peut toucher.

Sandboxing dans Claude Code

Plus vous laissez Claude agir de manière autonome, plus le sandboxing devient pertinent.

L’outil Bash est le plus exposé : les commandes shell peuvent lire tout ce que vous pouvez lire et modifier tout ce pour quoi elles ont des droits en écriture. Le sandboxing impose des frontières au niveau de l’OS à chaque commande Bash et à ses processus enfants ; Claude peut ainsi s’exécuter plus librement à l’intérieur de la frontière, sans votre approbation à chaque appel. Anthropic l’a conçu pour sécuriser les exécutions autonomes.

À noter : le sandbox ne couvre que Bash et ses processus enfants. Il ne restreint pas les outils Read, Edit ou Write, qui restent soumis au système d’autorisations.

Sandboxing natif

Le sandbox natif est intégré à Claude Code et s’active avec /sandbox.

Sur macOS, il utilise Seatbelt et ne nécessite aucune installation. Sur Linux et WSL2, installez bubblewrap pour l’isolation du système de fichiers et socat pour le proxy réseau. Windows natif n’est pas pris en charge ; exécutez donc Claude Code dans une distribution WSL2.

La frontière du système de fichiers est simple : les lectures fonctionnent partout sauf sur les chemins interdits, et les écritures ne fonctionnent qu’à l’intérieur du répertoire de travail et des chemins explicitement autorisés. Si vous essayez d’écrire dans ~/.bashrc depuis le sandbox, vous obtiendrez « Operation not permitted » avant même que Claude n’enregistre l’échec.

La frontière réseau est différente. Le trafic sortant passe par un proxy situé hors du sandbox, qui vérifie chaque requête par rapport à votre liste allowedDomains. Les nouveaux domaines déclenchent une demande d’autorisation, ce qui vous permet de voir précisément ce que Claude essaie d’atteindre.

Une configuration opérationnelle ressemble à ceci :

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

En usage interne chez Anthropic, le sandboxing réduit les demandes d’autorisation de 84 %.

Conteneurs de développement

Les dev containers ajoutent un niveau d’isolation supplémentaire.

Anthropic propose un devcontainer de référence pour Claude Code qui installe un environnement Ubuntu, monte votre dépôt et fournit un shell à l’agent. L’avantage par rapport au sandbox natif est la reproductibilité : toute l’équipe dispose du même environnement, des mêmes outils et du même setup.

En contrepartie, il y a de la charge supplémentaire. 

Vous ajoutez la construction du conteneur, le montage des fichiers et (parfois) une boucle de feedback plus lente. Pour un développeur seul, le sandbox natif suffit généralement. Pour une équipe ou du CI, la configuration vaut l’effort.

Isolation basée sur Docker

Pour des sessions d’agent autonomes de longue durée, Docker peut élargir encore la frontière de sandboxing.

La configuration ressemble généralement à ceci :

• Image de base minimale : supprimez les gestionnaires de paquets et outils réseau non nécessaires à la tâche.
• Utilisateur non-root : Claude ne s’exécute jamais en root ; il ne peut donc pas modifier les fichiers système ni installer des paquets globaux.
• Système de fichiers racine en lecture seule : montez la racine du conteneur en lecture seule, avec uniquement certains répertoires de sortie en écriture.
• Proxy de sortie : faites transiter le réseau sortant par un proxy qui autorise le registre de paquets (npm, PyPI) et refuse le reste, de sorte que des commandes comme npm install fonctionnent mais pas un curl arbitraire.
• Limites de ressources : fixez des limites CPU, mémoire et E/S pour qu’un processus ne puisse pas mettre à genoux l’hôte.

Docker Sandboxes donne à chaque sandbox sa propre microVM avec un démon Docker privé. Le démon hôte ne voit même pas les sandboxes dans docker ps. La frontière se rapproche d’une VM plus que d’un conteneur, ce qui ferme la plupart des voies d’évasion de conteneur qui inquiètent les développeurs.

Stratégies de sandboxing en entreprise

Pour les organisations, la question est comment superposer les techniques de sandbox, pas s’il faut les utiliser.

Voici l’approche la plus courante :

• Les règles d’autorisation sont définies dans managed-settings.json et ne peuvent pas être modifiées par les développeurs.

• Le sandboxing natif s’exécute sous la couche d’autorisations.

• Des dev containers ou Docker s’ajoutent en dessous.

• Pour les contextes à plus forte criticité (accès production, gestion de secrets), une VM dédiée sans montage du système de fichiers hôte constitue la dernière couche.

Claude Code sur le web est une version managée de la même idée. Chaque session s’exécute dans une VM gérée par Anthropic, les identifiants sensibles comme les jetons git sont placés hors sandbox via un proxy, et la frontière est imposée par l’infrastructure.

Sécurité MCP dans Claude Code

MCP est la partie de Claude Code qui évolue le plus vite.

Chaque serveur MCP que vous connectez multiplie ce que Claude peut faire, mais il multiplie aussi la surface qu’une injection de prompt ou une dépendance compromise peut atteindre. 

Par exemple :

• Un serveur MCP GitHub donne à Claude l’accès aux pull requests.
• Un serveur MCP base de données lui donne votre schéma et les requêtes.
• Un serveur Slack lui donne vos canaux.

Rien de problématique en soi, mais MCP nécessite sa propre gouvernance. Le contenu récupéré via un outil MCP (une page web ou une réponse d’API) peut contenir des instructions injectées que Claude exécute comme si vous les aviez saisies. De plus, chaque serveur ajoute des identifiants et une chaîne d’authentification à gérer séparément.

Autorisations d’outils

Les outils MCP utilisent une convention différente des outils intégrés.

Le format de règle est mcp__servername__toolname, sans spécificateur entre parenthèses. Par exemple, mcp__github__create_pull_request autorise exactement cet appel, et un deny sur mcp__github__delete_repo bloque l’outil dangereux. Les listes allow, ask et deny fonctionnent comme pour Bash ou Read.

Les mêmes priorités s’appliquent : deny d’abord, puis ask, puis allow. Un deny en paramètres gérés sur mcp__github__delete_* vaut pour tous les projets de la machine.

Autorisations de ressources

Les serveurs MCP peuvent exposer des ressources en plus des outils.

Une ressource est une donnée que le serveur met à disposition en lecture pour Claude (un fichier dans un outil de gestion de projet, une ligne dans une base, etc.). L’accès aux ressources passe par le même contrôle de confiance que les appels d’outils, et une première connexion à un serveur MCP exécute une étape de vérification avant que ses outils ou ressources ne soient accessibles.

Le bon réflexe est de traiter les ressources comme un autre outil. Si vous ne donneriez pas l’identifiant, ne donnez pas l’accès à la ressource.

Serveurs MCP approuvés

L’Anthropic Directory répertorie des connecteurs qu’Anthropic a évalués selon ses critères d’inscription.

Pour les organisations, un bon schéma consiste à utiliser une liste blanche interne. Deux paramètres vous donnent ce contrôle :

• allowedMcpServers : un motif glob des serveurs que les développeurs peuvent ajouter à leurs projets (par exemple company-* pour n’autoriser que les serveurs maintenus en interne).

• deniedMcpServers : un motif des serveurs qui ne peuvent pas être ajoutés, même si le développeur essaie.

Pour des serveurs obligatoires à inclure dans chaque session, déployez un fichier managed-mcp.json dans les paramètres gérés. Les développeurs ne peuvent ni supprimer ni modifier ces entrées.

Un réglage à éviter dans les dépôts partagés est enableAllProjectMcpServers, qui approuve automatiquement tous les serveurs MCP définis dans .mcp.json. Pratique en solo mais risqué dès qu’on versionne, car une PR malveillante peut ajouter un serveur dans .mcp.json et l’exécuter sans demande.

Accès aux outils en moindre privilège

Même principe que pour les autorisations Bash, appliqué à MCP.

La première question est : avec quel identifiant chaque serveur se connecte-t-il ? Un serveur MCP base de données doit se connecter à une réplique en lecture seule, pas au primaire en écriture. Un serveur MCP d’API doit utiliser un jeton borné au strict nécessaire d’endpoints, pas un jeton personnel avec un accès org complet. Etc.

Les sous-agents sont une autre façon de borner l’accès MCP. Une définition de sous-agent dans .claude/agents/ peut déclarer exactement quels outils il possède (syntaxe mcp:<server>:<tool>) : un « deploy-agent » obtient le serveur d’infra et un « review-agent » seulement Read, Grep et Glob. L’agent ne peut pas appeler d’outils qui ne lui ont pas été attribués.

Gouvernance MCP

Pour une équipe ou une organisation utilisant Claude Code à l’échelle, MCP doit suivre la même gouvernance que toute intégration de production.

Concrètement : un registre de serveurs approuvés avec des propriétaires identifiés, des traces d’audit de bout en bout des invocations d’outils (quels outils MCP ont été appelés, par qui, avec quels paramètres), et une revue périodique de la liste d’approbation. Les exporteurs OpenTelemetry de Claude Code vous donnent des données d’audit dans un format compatible avec votre pile d’observabilité.

Pour les grandes organisations, une passerelle MCP centralisée est la solution la plus propre. 

Les développeurs se connectent à la passerelle au lieu d’enregistrer des serveurs individuels. La passerelle gère l’authentification, impose des accès par rôle au niveau des outils, et émet une piste d’audit unique. Elle résout aussi la prolifération des identifiants, car un jeu de credentials à la passerelle remplace chaque développeur détenant une copie de chaque clé API.

Gestion des secrets et données sensibles

Claude Code peut lire tout ce que vous pouvez lire, ce qui rend les secrets accessibles.

Par défaut, Claude Code peut lire tous les fichiers accessibles à votre compte utilisateur. Cela inclut les fichiers .env de votre projet, les identifiants AWS dans ~/.aws/, les clés privées SSH dans ~/.ssh/, les jetons GitHub dans votre fichier rc du shell, et les variables d’environnement de tout sous-processus créé par Claude. C’est normal et voulu.

Tenez les secrets hors de l’espace de travail

Premier réflexe : s’assurer que les secrets ne sont pas dans le répertoire lu par Claude.

.env est le cas le plus courant : situé à la racine du projet, chargé par tous les outils de dev et contenant précisément ce que vous ne voulez pas exposer à Claude (URL de base de données, clés API). 

Voici quelques schémas utiles :

• Déplacez les secrets dans un répertoire en dehors de l’arborescence de travail, par exemple ~/.config/myapp/secrets.env, et chargez-les via un gestionnaire d’environnement ou une configuration direnv pointant vers ce fichier externe.

• En environnement conteneurisé, conservez un dossier .secrets/ hors du bind mount pour que le fichier soit invisible depuis le conteneur.

• Ajoutez Read(**/.env) et Read(**/.env.*) à votre liste permissions.deny, et couplez-les avec des denies Bash(cat:*/.env) afin qu’un script shell ne puisse pas lire ce que l’outil Read ne peut pas lire.

Utilisez un gestionnaire de secrets

Au-delà des projets de démonstration, la bonne place pour les secrets est un gestionnaire de secrets.

Le schéma est le même quel que soit le fournisseur (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Les secrets sont stockés dans le gestionnaire. Votre shell ou runtime les récupère à la demande et ne les expose qu’au processus qui en a besoin. Claude ne voit jamais la valeur réelle.

Spécifiquement pour Claude Code, cela signifie définir CLAUDE_CODE_SUBPROCESS_ENV_SCRUB pour retirer les identifiants Anthropic et cloud des sous-processus, ou utiliser sandbox.credentials pour désactiver des variables spécifiques lors des commandes en sandbox. Le premier évite de faire passer votre ANTHROPIC_API_KEY dans un script de build, le second couvre plus largement toute variable d’environnement sensible qui glisserait dans une commande shell.

Restreignez l’accès aux dépôts

Troisième levier : au niveau du dépôt.

Si un développeur n’a pas besoin d’écrire dans une configuration réservée à la production, sa session Claude Code non plus. Cela paraît évident, mais par défaut beaucoup d’équipes donnent aux développeurs plus d’accès que nécessaire, et Claude hérite de tout.

Deux mesures concrètes :

• Séparez la configuration de production dans un dépôt dédié à l’accès plus strict, pour que l’environnement de dev où travaille Claude n’ait pas les secrets de production.

• Utilisez des jetons bornés pour chaque service avec lequel Claude interagit. Par exemple, un jeton GitHub pour la relecture de code n’a pas besoin de repo:delete.

Sécurité Claude Code pour les équipes

Un développeur solo peut changer settings.json à sa guise. Une équipe ne le peut pas, car la sécurité globale n’est jamais meilleure que la configuration la plus faible sur la machine la plus faible. Pour les déploiements en équipe ou en organisation, Claude Code propose une couche de contrôle distincte qu’un administrateur pousse et que les utilisateurs ne peuvent pas outrepasser.

Paramètres gérés

Les paramètres gérés sont la base.

Le fichier se trouve dans un chemin système nécessitant des droits administrateur en écriture :

• /Library/Application Support/ClaudeCode/managed-settings.json sur macOS

• /etc/claude-code/managed-settings.json sur Linux

• C:\ProgramData\ClaudeCode\managed-settings.json sur Windows

Les réglages de ce fichier priment sur ceux au niveau utilisateur et projet. Un deny ici s’applique à tous les projets de la machine, et le développeur ne peut pas l’annuler via son propre settings.json. La plupart des organisations distribuent ce fichier via un MDM (Mobile Device Management) ou le même canal de configuration que pour les autres outils dev.

Voici quelques réglages utiles au niveau géré :

• permissions.deny pour les chemins sensibles et les commandes dangereuses

• defaultMode réglé sur default ou plan (jamais bypassPermissions)

• allowManagedPermissionRulesOnly: true pour verrouiller l’ensemble d’autorisations

• enableAllProjectMcpServers: false pour exiger une approbation MCP explicite

• Configuration des exporteurs OpenTelemetry pour le logging

Politiques d’autorisations partagées

Une équipe alignée sur ce que Claude peut faire devrait versionner cet accord.

Les paramètres au niveau projet se trouvent dans .claude/settings.json à la racine du dépôt. Tout ce qui est commité ici s’applique à quiconque exécute Claude dans ce dépôt. C’est l’endroit adéquat pour les allow/deny propres au projet.

Gardez en tête la répartition entre paramètres gérés et projet :

• Les paramètres gérés portent la politique d’organisation (personne n’active bypassPermissions, personne ne lit les .env).

• Les paramètres projet décrivent les conventions de workflow (les tests ici se lancent avec npm test ; le script de déploiement de ce dépôt est interdit, etc.).

Gouvernance d’équipe

Pour un déploiement d’équipe, la couche politique doit avoir un responsable.

La plupart des équipes qui utilisent Claude Code à grande échelle s’appuient sur un petit groupe (souvent sécurité et plateforme) qui possède les paramètres gérés, la liste blanche MCP, les scripts de hooks et la pipeline OpenTelemetry. Le même groupe traite les demandes d’exception et ajuste la politique au fil des nouveaux cas d’usage.

Formalisez ces éléments :

• Quels dépôts sont dans le périmètre ou non, avec des modes selon le risque (un dépôt soumis à la réglementation fonctionne probablement en mode plan, tandis qu’un site marketing peut tourner en acceptEdits).
• Qui peut accorder des exceptions et comment elles sont tracées.
• Une cadence de revue (trimestrielle, souvent) pour revisiter règles d’autorisations, serveurs MCP et incidents.

Journalisation d’audit

Claude Code émet des événements OpenTelemetry pour chaque décision d’outil, connexion de serveur MCP, changement de mode d’autorisation et requête API. Aucune donnée n’est envoyée tant qu’un administrateur n’a pas configuré l’endpoint OTLP dans les paramètres gérés.

Voici un bloc minimal de paramètres gérés pour la télémétrie :

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Par défaut, le contenu des prompts et les paramètres d’outils sont exclus de l’export ; les événements collectés sont des métadonnées, pas la conversation complète. Pour inclure le texte des prompts, définissez OTEL_LOG_USER_PROMPTS=1. Pour inclure les arguments d’outils (souvent utile pour l’audit), définissez OTEL_LOG_TOOL_DETAILS=1. Ces choix ont des implications en matière de confidentialité ; la plupart des équipes les traitent comme des décisions de politique, avec filtrage ou masquage côté backend avant stockage.

Suivi d’usage

Le même flux OpenTelemetry alimente le suivi d’usage.

Claude Code exporte des métriques sur l’usage de jetons, le coût par requête, le nombre de sessions et les taux de décisions d’outils. Agrégées, elles indiquent quelles équipes tirent le plus de valeur, quels workflows produisent le plus de refus, et quels modèles génèrent le coût. Des backends comme Datadog, Honeycomb, SigNoz, Elastic et Splunk ingèrent le format OTLP standard.

Un pic d’événements permission_decision avec decision=deny peut signifier que Claude tente trop… ou que les règles allow de l’équipe sont trop restrictives.

Erreurs de sécurité Claude Code les plus courantes

Un petit nombre de mauvaises configurations expliquent la plupart des incidents Claude Code. Voici lesquelles et comment les corriger.

Autorisations trop larges

Le moyen le plus rapide d’émousser le système d’autorisations est d’autoriser trop largement.

Les demandes par commande ajoutent de la friction, et la « solution » facile est un large Bash(*) en allow ou un defaultMode: bypassPermissions. Ces deux options annulent l’essentiel des protections.

Bornez vos règles allow aux outils et commandes réellement utilisés (par exemple Bash(npm test:*) et Bash(git status)) et laissez le reste passer par une demande. Vous aurez plus d’invites au début, mais après quelques sessions, vous aurez mis en liste blanche vos commandes habituelles et les demandes diminueront fortement.

Accès MCP non restreint

Deuxième erreur : connecter des serveurs MCP sans vérifier les identifiants utilisés ni leur périmètre d’action.

Cela arrive souvent quand on active enableAllProjectMcpServers, qu’on connecte quelques serveurs publics et qu’on n’y revient jamais. Lorsqu’un serveur avec des identifiants faibles finit par exposer une donnée sensible, la connexion est si ancienne dans la configuration que personne ne se souvient l’avoir approuvée.

Le correctif est le même que pour les autorisations : utilisez une liste blanche explicite via allowedMcpServers, un managed-mcp.json interne pour les serveurs communs à tous, et une revue périodique de la liste.

Pas de sandboxing

Si le sandboxing est désactivé, le système d’autorisations est le seul rempart entre Claude et votre système de fichiers.

C’est acceptable pour des sessions interactives courtes où vous approuvez chaque commande. Ça ne l’est pas pour des exécutions autonomes, des sessions où vous avez élargi les allow, ou tout travail manipulant du code externe.

/sandbox l’active. Si des dépendances manquent, le menu vous indique lesquelles installer selon votre plateforme. Une fois activé, les demandes d’autorisation diminuent et l’OS intercepte les cas non couverts par vos allow.

Accepter les changements sans contrôle

acceptEdits est à la fois pratique et risqué.

Quand Claude réécrit une fonction et que vous surveillez, l’auto-acceptation est correcte. Quand Claude itère sur 30 fichiers en une heure, on cesse de lire les diffs et on commence à faire confiance à l’agent. C’est là que les problèmes apparaissent.

Adoptez ces deux habitudes :

• Commitez toujours avant de laisser Claude agir de manière autonome, pour un retour arrière en un git reset.

• Relisez le diff avant chaque commit signé par Claude, pas seulement le diff cumulé en fin de session.

Ignorer les traces d’audit

Une équipe qui exécute Claude Code sans télémétrie ne peut pas répondre à « quelle session a fait ça ? ». Les événements s’accumulent localement et y restent. Le premier besoin d’une piste d’audit est le pire moment pour découvrir qu’elle n’est pas configurée.

Le minimum utile : exporter les événements tool_decision, permission_decision et api_request vers la pile d’observabilité déjà utilisée par l’équipe. Ensuite, construisez tableaux de bord et alertes selon les besoins.

Conclusion

Le pire scénario pour un chatbot est une mauvaise réponse. Pour un agent de codage, c’est une commande shell exécutée en production avec vos identifiants.

Voilà pourquoi les trois piliers comptent :

• Les autorisations décident de ce que Claude est autorisé à faire
• Les contrôles MCP décident des systèmes externes auxquels il peut accéder
• Le sandboxing décide de ce qui se passe quand les deux premiers ne suffisent pas

Chacun couvre un mode de défaillance que les autres ne couvrent pas. Ensemble, ils définissent la véritable frontière dans laquelle Claude opère.

Si vous visez une certification en IA générative, retrouvez comparatifs, meilleurs cours, conseils de préparation et FAQ sur les meilleures certifications en IA générative en 2026.