Meilleures pratiques de sécurité Claude Code pour les équipes en 2026

Mis à jour le: June 28, 2026

Un agent de codage IA capable de lire votre repo, d'exécuter des commandes shell et d'appeler des services externes est utile précisément parce qu'il a une portée étendue. Cette même portée représente un risque. Une mauvaise interprétation du prompt, une liste blanche négligente ou un serveur MCP non fiable peuvent faire fuiter un token ou effacer une branche. Ce guide s'adresse au développeur ou au responsable de plateforme qui souhaite utiliser Claude Code dans son travail quotidien et dans le CI sans lui donner les clés de la production.

Réponse rapide : comment les équipes maintiennent-elles la sécurité de Claude Code ?

Exécutez l'agent avec le moindre privilège et examinez ce qu'il fait. Concrètement, cela signifie cinq choses :

• Commencer dans un mode de permission restrictif et accorder des outils via une liste blanche étroite, et non une autorisation générale "toujours autorisé".
• Garder les secrets hors du contexte du modèle : pas de clés collées, et une règle deny sur .env et les chemins de secrets.
• Vérifier chaque serveur MCP avant de le connecter, car un serveur non fiable peut lire des données et agir en votre nom.
• Traiter le contenu web récupéré comme une entrée non fiable qui pourrait contenir des instructions d'injection de prompt.
• Dans le CI, donner à l'agent un token à courte durée de vie et limité en lecture, et ne jamais exposer les identifiants de production.

Le reste de cet article transforme chacun de ces points en paramètres concrets, avec un tableau des risques, une référence des permissions et un scénario CI que vous pouvez copier.

Comment fonctionnent concrètement les modes de permission et les listes blanches ?

Claude Code demande avant d'exécuter un outil pour la première fois. Vous décidez si cette décision doit être mémorisée, limitée ou ignorée. Le mode de permission établit la base :

• default affiche des prompts lors de la première utilisation de chaque outil ou commande.
• plan est en lecture seule : l'agent peut lire les fichiers et proposer un plan, mais ne peut ni modifier ni exécuter de commandes. Utilisez-le pour la revue.
• acceptEdits accepte automatiquement les modifications de fichiers, mais demande toujours des prompts pour les commandes shell.
• bypassPermissions ignore tous les prompts. Traitez-le comme étant uniquement en bac à sable (sandbox).

Les contrôles durables résident dans .claude/settings.json sous permissions, avec des règles allow, ask et deny. Les règles sont limitées par outil et motif, vous accordez donc exactement ce dont une tâche a besoin :

{
  "permissions": {
    "allow": ["Read", "Edit", "Bash(npm test:*)", "Bash(git diff:*)"],
    "ask": ["Bash(git push:*)", "WebFetch"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(curl:*)", "Bash(rm -rf:*)"]
  }
}

Une règle deny l'emporte toujours sur allow, c'est pourquoi les chemins de secrets ci-dessus restent illisibles même si une règle Read large existe. Anthropic documente la syntaxe complète des règles et la précédence dans la documentation [identity and access management docs] de Claude Code (https://docs.anthropic.com/en/docs/claude-code/iam).

Évitez --dangerously-skip-permissions en dehors d'un conteneur jetable. Cela supprime le seul point de contrôle humain qui détecte un mauvais rm ou un appel réseau inattendu. Si vous voulez la vitesse sans ce risque, préférez une liste blanche étroite afin que les commandes de routine s'exécutent sans surveillance pendant que tout ce qui est nouveau attend toujours votre approbation.

Référence des risques et atténuations

La plupart des incidents remontent à quelques motifs récurrents. Associez chacun d'eux à un contrôle avant de déployer l'agent dans toute une équipe.

Le cadre ici suit le OWASP Top 10 for LLM Applications, qui signale l'injection de prompt, la gestion des sorties non sécurisée et une agence excessive comme risques d'agents principaux.

Référence des permissions et de la portée

Ce tableau est ma fiche de triche que je donne aux nouveaux membres de l'équipe. Il couvre les paramètres qui modifient le rayon d'impact d'une seule exécution.

Vérifier les serveurs MCP avant de les connecter

Les serveurs MCP étendent l'agent avec de nouveaux outils : un client de base de données, une intégration de ticketing, un navigateur. Chaque ajout est du code qui peut lire le contexte et effectuer des actions. Un serveur non fiable est le moyen le plus rapide de transformer un agent utile en un chemin d'exfiltration de données, donc la barre pour en connecter un doit être la même que celle que vous appliqueriez à toute dépendance ayant un accès réseau.

Avant d'ajouter un serveur, répondez à cinq questions :

1. Qui le publie, et sa source est-elle publique et maintenue ?
2. Quelles portées demande-t-il : lecture seule, ou écriture et réseau ?
3. Quelles données peut-il voir une fois connecté : juste ce repo, ou toute votre machine ?
4. Les identifiants sont-ils limités en portée et à courte durée de vie, ou s'agit-il d'un token administrateur à long terme ?
5. Pouvez-vous épingler une version pour qu'une mise à jour automatique ne puisse pas élargir silencieusement son accès ?

Connectez les serveurs avec la moindre portée nécessaire pour faire le travail, et gardez les serveurs capables d'écriture ou orientés production hors des configs partagées ou CI. Pour les mécanismes de configuration et un guide plus approfondi, consultez notre Claude Code MCP integration guide. L'article Claude Code productivity tips explique comment garder cette empreinte réduite sans vous ralentir.

Garder les secrets hors de portée du modèle

Le secret le plus propre est celui que le modèle ne voit jamais. Ne collez pas les clés API dans le prompt, et ne demandez pas à l'agent de "lire la clé depuis la config et de l'utiliser". Laissez les identifiants vivre dans l'environnement et référencez-les par leur nom afin que la valeur reste hors du transcript.

Trois habitudes couvrent la plupart des risques :

• Ajouter une règle deny pour .env, *.pem, et tout répertoire secrets/ afin que l'agent ne puisse pas les lire même par accident.
• Utiliser un scanner de secrets pré-commit (tel que gitleaks ou git secrets) afin qu'une clé glissée fasse échouer le commit, et non l'audit.
• Renouveler immédiatement tout ce qui est exposé, puis vérifier les logs et l'historique. Le renouvellement est le seul correctif qui ferme réellement la fenêtre.

Si une clé a déjà atteint un transcript ou un commit, considérez qu'elle est compromise et renouvelez-la. Rechercher l'historique git avec git log -S vous aide à trouver où elle s'est retrouvée.

Scénario : activer Claude Code dans le CI sans identifiants de production

Une équipe veut que Claude Code examine les pull requests dans GitHub Actions. L'objectif est des commentaires d'examen automatisés, avec zéro capacité de déploiement, d'écriture sur la branche principale ou de manipulation de la base de données de production.

Voici la configuration qui maintient le job utile mais confiné :

• Exécuter en mode headless avec claude -p en mode plan afin que l'agent lise le diff et écrive un commentaire, mais ne modifie jamais les fichiers ni n'exécute de commandes de build.
• Accorder uniquement contents: read et pull-requests: write. Pas de job de déploiement, pas de portée d'infrastructure.
• Utiliser le GITHUB_TOKEN à courte durée de vie du job, et non un token personnel, et ne jamais placer les clés de production de base de données ou cloud dans l'environnement de ce job.
• Ajouter une liste deny pour les chemins de secrets et le curl sortant, afin qu'une tentative d'injection de prompt à l'intérieur du diff de la PR ne puisse rien exfiltrer.
• Épingler la version de l'action et de Claude Code, et bloquer toute étape de déploiement derrière un environnement séparé approuvé par un humain.

permissions:
  contents: read
  pull-requests: write
steps:
  - run: claude -p "Review the diff for security issues" --permission-mode plan
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Le job de revue voit le code et publie des commentaires. Il ne peut pas atteindre la production car les identifiants de production ne sont jamais dans la portée. La vue d'ensemble de sécurité Claude Code d'Anthropic décrit cette posture à moindre privilège pour les exécutions automatisées et headless.

Que ne faut-il jamais coller dans un agent de codage IA ?

Certaines entrées n'ont pas leur place près d'un transcript, car tout ce qui se trouve dans la fenêtre de contexte peut être répété, journalisé ou agi.

• Clés API en direct, URL de base de données avec mots de passe, ou identifiants racine cloud.
• PII client ou données réglementées que vous ne mettriez pas dans un ticket de support.
• Clés de signature privées, certificats ou fichiers .pem.
• Chaînes de connexion complètes de production lorsque une réplique en lecture seule ou un fixture local suffirait.

Lorsque l'agent a besoin d'accès, donnez-lui un chemin vers un identifiant limité par portée via l'environnement plutôt que le secret lui-même. Même résultat, rayon d'impact beaucoup plus petit.

Audit, hooks et revue continue

Le moindre privilège établit le plancher ; la revue vous y maintient. Lisez le plan de l'agent avant d'approuver une étape risquée, et lisez le diff avant de committer. Pour des changements plus importants, la même discipline qui rend AI-assisted refactoring sûr s'applique ici : les étapes petites et révisables battent une seule exécution géante sans surveillance.

Ajoutez des garde-fous déterministes avec des hooks. Un hook PreToolUse peut inspecter une commande et la bloquer avant qu'elle ne s'exécute, ce qui est ainsi que vous forcez les règles que le modèle ne devrait jamais outrepasser, comme refuser toute écriture vers un chemin protégé. Associez cela à une piste d'audit afin de pouvoir répondre ce que l'agent a fait, quand et pour qui.

Une liste de contrôle récurrente rapide pour l'équipe :

• Examiner les listes allow et deny de .claude/settings.json selon un calendrier, pas seulement lors de la configuration initiale.
• Re-vérifier les serveurs MCP après des mises à jour majeures.
• Confirmer que les jobs CI s'exécutent toujours en mode plan et ne contiennent aucun secret de production.
• Renouveler les tokens selon une cadence et après toute exposition suspectée.
• Conserver un fichier CLAUDE.md qui énonce les non négociables : pas de force-push vers main, pas d'accès direct à la base de données de prod, pas de secrets dans les prompts.

Pour le flux de travail plus large autour de tout cela, le Claude Code ultimate guide passe en revue la configuration de bout en bout.

Conclusion clé

La sécurité des agents de codage IA est la même pensée du moindre privilège que vous appliquez déjà aux comptes de service, écrite sous forme de règles de permission. Commencez restrictif, élargissez avec une liste blanche étroite, refusez les chemins de secrets, vérifiez les serveurs MCP comme des dépendances, traitez le contenu récupéré comme non fiable et gardez les identifiants de production hors de tout job auquel l'agent peut accéder. Faites cela et Claude Code reste une paire de mains rapides, pas une porte ouverte.