Claude Code security : 6 réglages avant un projet client

« Claude Code security » recouvre deux choses : l’outil d’Anthropic qui détecte les failles de votre code, et la façon de protéger Claude Code lui-même. Pour un freelance, la seconde compte d’abord, car Claude Code tourne sur l’ordinateur où sont rangés les accès de vos clients : clés API, fichiers .env, dossiers de projet. Six réglages ferment l’essentiel, à poser avant votre premier projet client.

Claude Code Security, l’outil d’Anthropic : ce qu’il fait, qui y a accès

Anthropic a présenté Claude Code Security le 20 février 2026, en aperçu limité pour les comptes Enterprise et Team. Le principe : Claude lit une base de code comme un chercheur en sécurité, propose un correctif pour chaque faille, et un humain valide. Pendant ses essais, l’outil a trouvé plus de 500 failles ↗ (nouvel onglet) dans des projets open source en production.

C’est l’annonce qui remplit le top 10 de Google. Depuis, le service a pris le nom de Claude Security. Il est en bêta publique, réservé aux comptes Enterprise.

Pour vous, trois outils sont déjà à portée de main dans Claude Code :

• /security-review : une passe de sécurité sur les changements de votre branche, à lancer avant un commit ;
• le plugin claude-security (bêta, ouvert à tous les utilisateurs de Claude Code) : plusieurs agents cartographient le dépôt, cherchent les failles, font vérifier chaque trouvaille par d’autres agents et écrivent des correctifs que vous appliquez vous-même ;
• le plugin security-guidance : Claude relit son propre code pendant qu’il l’écrit.

/plugin install claude-security@claude-plugins-official
/claude-security

Le rapport arrive dans un dossier CLAUDE-SECURITY-<date>/ du dépôt, avec un fichier .patch par faille. Aucun correctif ne s’applique tout seul : git apply, une pull request par correctif. Le scan consomme votre forfait, et deux scans du même code peuvent remonter des failles différentes.

Ces outils vérifient le code que vous livrez. Ils ne disent rien de ce que Claude Code a le droit de faire sur votre ordinateur, et c’est là que se jouent les six réglages.

Ce que Claude Code peut toucher sur votre machine

Claude Code agit avec les droits de votre compte utilisateur. Si vous avez rangé le .env d’un client dans un dossier de projet, Claude peut le lire. Si une commande Bash que vous avez validée écrit ailleurs, rien ne l’en empêche : la limite du dossier de travail est une question posée par Claude Code, pas une barrière du système.

Le second risque vient de ce que Claude lit. Une page web, une issue GitHub, un README ou un skill peuvent contenir des instructions cachées (l’injection de prompt). Claude Code en filtre une partie : curl et wget ne sont jamais validés d’office, et WebFetch passe chaque page par un modèle séparé avant que Claude n’en voie le résumé. La documentation le dit elle-même : aucun système n’est totalement à l’abri.

Les permissions sont appliquées par Claude Code lui-même, et le modèle n’y peut rien. Écrire « ne lis jamais le .env » dans votre CLAUDE.md oriente Claude sans rien lui interdire. Seuls les modes et les règles qui suivent bloquent vraiment.

1. Choisir le mode de permission

Une session interactive démarre aujourd’hui en mode auto : un second modèle, le classifieur, examine chaque action avant qu’elle parte et bloque celles qu’il juge dangereuses. Maj+Tab fait tourner les modes ; le détail est dans le guide de Claude Code.

Le dernier mode correspond à --dangerously-skip-permissions. Anthropic le réserve aux environnements isolés, où Claude Code ne peut rien casser. Pour vous l’interdire à vous-même, une ligne suffit dans vos réglages :

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

2. Écrire les règles deny

Les règles se lisent dans un ordre fixe : deny, puis ask, puis allow. La première qui correspond l’emporte, et une règle allow plus précise ne perce jamais une règle deny. C’est ce qui rend le deny sûr.

Une base à poser dans le .claude/settings.json d’un projet client :

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": [
      "Bash(rm *)",
      "Bash(git push *)"
    ]
  }
}

Deux limites à connaître. Une règle Bash compare le texte de la commande : Bash(curl *) n’arrête pas un script Python qui envoie une requête. Et un fichier .claudeignore n’a aucun effet sur les permissions : ses lignes doivent passer en règles Read deny. La commande /permissions liste toutes les règles actives et le fichier d’où vient chacune ; relisez-la à chaque nouveau projet.

3. Activer le bac à sable

Le bac à sable est désactivé par défaut. /sandbox l’active, ou cette ligne dans ~/.claude/settings.json :

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

Cette fois, c’est le système qui tient la barrière : Seatbelt sur macOS, bubblewrap sur Linux et WSL2. Les commandes Bash n’écrivent que dans le dossier de travail et le dossier temporaire, et ne sortent sur le réseau que par un proxy qui vérifie chaque domaine. La liste des domaines autorisés démarre vide.

Le piège : par défaut, une commande dans le bac à sable lit presque toute la machine, ~/.ssh et ~/.aws/credentials compris. Les lignes denyRead ne sont pas optionnelles. Autres limites : le bac à sable ne couvre ni les hooks, ni les serveurs MCP locaux, qui tournent avec tous vos droits ; il n’existe pas sous Windows natif ; et docker n’y fonctionne pas.

4. Sortir les secrets de la portée de Claude

Les règles deny et le bac à sable bloquent la lecture. Le plus sûr reste de ne rien laisser à lire :

• une clé par client et par usage, avec le minimum de droits : lecture seule sur la base de données si Claude n’a qu’à la consulter ;
• aucun secret de production sur votre poste : les clés de production restent chez l’hébergeur (Vercel, Railway), et votre .env local pointe vers une base de test ;
• les dossiers clients hors du dossier de travail, ou en denyRead ;
• une clé changée au moindre doute, après un skill installé trop vite ou une commande validée sans la lire.

Claude Code range vos propres identifiants dans le trousseau macOS, ou dans un fichier lisible par vous seul sur Linux. Ce sont les clés de vos clients qui traînent dans les dossiers.

5. Relire et scanner chaque skill avant de l’installer

0:43

Le Reel part d’un chiffre : 1 skill sur 20 serait malveillant. Il faut corriger la source. Le chiffre ne vient pas d’une étude de NVIDIA mais d’un travail universitaire, « Agent Skills in the Wild » ↗ (nouvel onglet) (Liu et al., janvier 2026), que NVIDIA cite dans la documentation de son scanner. Les chercheurs ont collecté 42 447 skills sur deux grandes marketplaces et en ont analysé 31 132 :

• 26,1 % contiennent au moins une faille ;
• 5,2 %, soit environ 1 sur 19, présentent des motifs graves qui « suggèrent fortement une intention malveillante ». Une forte présomption, pas un malware confirmé un par un ;
• un skill qui embarque des scripts a 2,12 fois plus de chances d’être vulnérable qu’un skill fait seulement d’instructions.

Et ça s’est déjà produit. Début février 2026, Koi Security a audité les 2 857 skills de ClawHub, la marketplace d’OpenClaw, et en a trouvé 341 malveillants ↗ (nouvel onglet). Leur section « prérequis » faisait installer un voleur de mots de passe pour macOS. Le détail est dans l’article sur OpenClaw.

Un skill n’est qu’un fichier texte, mais trois de ses champs lui donnent la main sur votre machine. Relisez-les avant d’installer :

• allowed-tools : les outils que le skill s’autorise sans vous demander. La documentation prévient que ce champ s’applique même dans un dossier auquel vous n’avez pas fait confiance ;
• hooks : des commandes qui restent actives pour toute la session une fois le skill appelé ;
• les lignes !`commande` et le dossier scripts/ : du code qui s’exécute, pas des instructions que Claude lit.

Pour couper l’exécution de commandes par les skills, une ligne : "disableSkillShellExecution": true. Pour bloquer un skill précis : une règle deny Skill(nom). La façon d’écrire et de ranger vos propres skills est dans le guide des skills Claude Code.

SkillSpector, le scanner de NVIDIA

Le scanner montré dans le Reel existe : SkillSpector ↗ (nouvel onglet), open source (licence Apache 2.0). Il vérifie 71 motifs répartis en 17 catégories (injection de prompt, exfiltration de données, chaîne d’approvisionnement…) et rend un score sur 100 : de 0 à 20, sûr ; de 21 à 50, prudence ; au-dessus de 50, « ne pas installer ». Il ne lance jamais le skill qu’il analyse.

uv tool install git+https://github.com/NVIDIA/skillspector.git
skillspector scan ./le-skill/ --no-llm

Sans --no-llm, une seconde passe confie l’analyse à un modèle ; le fournisseur se choisit, et l’option claude_cli reprend votre session Claude Code, sans clé API. Branché en serveur MCP (claude mcp add skillspector -- skillspector mcp), il donne à Claude un outil pour scanner un skill avant de l’installer.

Je l’ai passé sur deux de mes skills, en analyse statique. Mon skill interroge, onze lignes d’instructions : 0 sur 100, sûr. Mon skill de blog, celui qui pousse les articles de ce site : 100 sur 100, critique, « ne pas installer », 52 alertes. Rien de malveillant dedans. 36 alertes venaient du cache Python (__pycache__) que je n’avais pas nettoyé, et que le scanner traite à raison comme du code qu’il ne peut pas lire. Les autres décrivaient ce que fait vraiment le skill : il lit des clés dans le .env, lance yt-dlp et ffmpeg, envoie des requêtes à une API.

Le score dit où regarder. La conclusion, elle, vous revient : un skill qui agit fera toujours monter le compteur, et il reste à vérifier que chaque accès sert la tâche annoncée. NVIDIA liste aussi ses limites : le scanner peut manquer des motifs écrits dans une autre langue que l’anglais (vos skills en français, donc), ne lit ni les images ni le code compilé, et ne remplace pas un bac à sable.

6. Plugins et serveurs MCP : savoir ce que vous installez

Un plugin va plus loin qu’un skill. La documentation l’écrit en première ligne : un plugin installé peut exécuter n’importe quel code sur votre machine, avec vos droits. Ses hooks, ses serveurs MCP et les exécutables de son dossier bin/ tournent hors du bac à sable. Et la mise à jour automatique peut changer les fichiers que vous aviez relus.

Avant d’installer, quatre gestes :

1. claude plugin marketplace list : d’où vient la marketplace. Seuls les noms réservés à Anthropic (claude-plugins-official, entre autres) viennent de ses dépôts ; toutes les autres sont tierces ;
2. /plugin, puis le plugin : la section « Will install » liste ses skills, hooks et serveurs ;
3. dans son dépôt, lisez hooks/hooks.json, .mcp.json et tout le dossier bin/ ;
4. claude plugin details <nom> une fois installé, pour l’inventaire exact.

Ce que les plugins apportent à un projet client est dans le guide des plugins, et la mécanique des hooks dans l’article sur les hooks.

Pour les serveurs MCP, Anthropic est clair : il relit les connecteurs de son annuaire avant de les lister, mais n’audite la sécurité d’aucun serveur MCP. Écrivez les vôtres ou prenez ceux de fournisseurs de confiance, comme ceux de l’article sur le MCP. Un .mcp.json dans le dépôt d’un client déclenche une demande d’approbation : lisez la commande ou l’URL de chaque serveur avant d’accepter. Et une règle mcp__serveur__* en deny coupe tous les outils d’un serveur d’un coup.