Les agents de code IA laissent fuiter des secrets : vérifiez vos dépôts

Si vous utilisez Claude Code ou n'importe quel autre agent de code IA, consacrez d'abord dix minutes à vos dépôts. Cherchez les fichiers de configuration d'agent qui ont été commités, faites tourner tous les identifiants qu'ils contiennent et activez le secret scanning de GitHub. Les clés volées sont revendues très vite (Unit 42 décrit un cas qui a pris quelques minutes) : les vérifications passent donc avant l'histoire.

Commencez par vérifier vos dépôts

Commencez par le fichier au cœur de l'affaire Claude Code : .claude/settings.local.json. La société de sécurité Apiiro en a trouvé 104 185 copies dans 103 617 dépôts publics, et 1 122 de ces copies contenaient au moins un secret (The Hacker News). Voici comment chercher le vôtre.

1. 1Recherchez ce fichier par son nom dans toute votre organisation GitHub (remplacez par le nom de votre organisation ; nécessite la CLI GitHub).
2. 2Vérifiez si le fichier a déjà été commité dans chaque dépôt sur lequel vous travaillez, y compris dans les anciennes branches. L'historique conserve ce que le dernier commit a supprimé.
3. 3Parcourez les approbations enregistrées à la recherche de tout ce qui ressemble à un mot de passe, un token ou une chaîne de connexion.
4. 4Analysez tout l'historique, et ajoutez une règle pour les mots de passe tapés dans les commandes, que les jeux de règles par défaut laissent souvent passer.

# 1. Find the files across an organization
gh search code --owner YOUR-ORG --filename settings.local.json

# The same search in the GitHub web search box
#   org:YOUR-ORG path:.claude/settings.local.json

# 2. Was it ever committed, on any branch?
git log --all --oneline -- .claude/settings.local.json .claude/settings.json

# 3. List what you have approved with "don't ask again"
jq -r '.permissions.allow[]' .claude/settings.local.json

# 4. Grep the folder and its history for the usual suspects
grep -rEn 'PGPASSWORD=|sshpass -p|mysql -p|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{20,}' .claude/
git log --all -p -- .claude | grep -E 'PGPASSWORD=|sshpass -p|mysql -p|AKIA[0-9A-Z]{16}'

Ce sont des appels git, jq et grep standard, mais considérez leur résultat comme une piste, pas comme un verdict. La recherche de code de GitHub ne voit que ce qui se trouve aujourd'hui sur une branche, c'est pourquoi l'étape 2 existe.

Pour l'analyse, Gitleaks et TruffleHog sont les deux outils utilisés par Apiiro. Lancez-les sur l'historique, puis ajoutez une règle personnalisée : les règles par défaut repèrent une clé, mais pas un mot de passe placé après une option.

gitleaks git --redact -v .
trufflehog git file://.

# .gitleaks.toml
[extend]
useDefault = true

[[rules]]
id = "password-inside-command"
description = "Password passed on a command line"
regex = '''(PGPASSWORD=|sshpass -p |mysql -p)\S+'''

Cette règle personnalisée vaut le coup. Apiiro a passé les deux outils sur tous les fichiers trouvés : gitleaks a signalé 564 des 1 122 fichiers contenant des secrets, TruffleHog 643, et aucun des deux n'en a détecté 215, surtout des mots de passe tapés après PGPASSWORD=, sshpass -p ou mysql -p (The Hacker News).

Apiiro recommande aussi aux équipes de sécurité de traiter .claude/, .cursor/, .gemini/, .specstory/ et les fichiers de mémoire des agents comme des fichiers contenant des secrets, au même titre que .env. Nous lancerions la même recherche pour chaque agent installé dans votre équipe : une transcription enregistrée par Cursor, GitHub Copilot ou Codex peut aussi contenir une clé collée.

Comment un clic d'approbation met un mot de passe dans votre dépôt

Claude Code demande l'autorisation avant d'exécuter la plupart des commandes shell. Choisissez « Yes, and don't ask again » et il écrit une règle d'autorisation dans .claude/settings.local.json. Selon la documentation d'Anthropic, une approbation Bash donnée ainsi dure « de façon permanente par dépôt et par commande » (Claude Code docs). Le piège, c'est la forme de la règle. Ce peut être un motif comme npm test *, ou la commande exacte, et quand la commande exacte contient un mot de passe, celui-ci est désormais enregistré en clair.

Ce fichier est censé rester local. D'après la documentation des réglages d'Anthropic, la première fois que Claude Code l'écrit dans un dépôt qui ne l'ignore pas déjà, il ajoute **/.claude/settings.local.json à vos exclusions git globales, et un fichier créé à la main nécessite votre propre ligne dans .gitignore (Claude Code docs). Cela protège un seul ordinateur, pas un clone tout neuf, un fichier créé à la main, ni un fichier commité avant l'existence de la règle d'exclusion.

Plus d'un tiers des secrets trouvés par Apiiro ouvrent directement l'accès à une base de données, dont 379 mots de passe de bases de données. Le reste comprend 43 identifiants SSH pour des serveurs publics, 42 tokens GitHub, GitLab et npm, et 23 clés AWS. Soixante-trois organisations possédaient des fichiers concernés, et dans la moitié des dépôts contenant un secret, le fichier traînait là depuis au moins 217 jours. Apiiro n'a pas testé si ces accès fonctionnent encore, même si une entreprise prévenue a confirmé que sa clé était active.

La réponse d'Anthropic jusqu'ici : un commentaire sur Hacker News

Un rapport de bug déposé en 2025 a été fermé par un bot automatique comme « not planned » après 60 jours sans activité, et les chercheurs d'Apiiro affirment qu'aucun des rapports connexes qu'ils citent n'a reçu de réponse d'Anthropic (The Hacker News). La réponse publique est venue de Hacker News, d'un commentateur qui s'est présenté comme « Boris from the Claude Code team ». Il a écrit que « Historically Claude Code has not done secret scrubbing » (historiquement, Claude Code n'a pas nettoyé les secrets), que l'équipe « is looking into what we can do to prevent this » (cherche ce qu'elle peut faire pour l'éviter), et que dans ce cas « the files were manually created and checked in » (les fichiers ont été créés à la main puis commités). Il a ajouté : « Permission rules are old hat. Everyone should be using auto mode instead. » (Les règles de permission, c'est dépassé. Tout le monde devrait utiliser le mode auto.)

Les données d'Apiiro cadrent mal avec l'explication du fichier fait main. Dans 539 des 1 105 dépôts qu'il a analysés, un commit citant Claude comme co-auteur a modifié le fichier. Une ligne de co-auteur ne prouve pas qui a lancé git, mais elle se concilie mal avec des fichiers créés à la main. Les données de commits nous paraissent plus difficiles à écarter que le commentaire, et nous considérerions ce fichier comme quelque chose que Claude Code peut commiter, jusqu'à ce qu'Anthropic dise le contraire.

Grok Build a fuité deux fois, de deux façons différentes

Deux histoires autour de Grok Build se mélangent, alors qu'elles demandent des correctifs différents. (Selon les articles, l'entreprise s'appelle SpaceXSI ou SpaceXAI.)

La première date de début 2026. Un chercheur publiant sous le nom cereblab a analysé Grok Build 0.2.93 et rapporté qu'il envoyait des dépôts Git suivis entiers, avec historique de commits, secrets commités et clés d'API, vers un stockage cloud (The Next Web). Selon cette analyse, l'envoi était environ 27 800 fois plus volumineux que nécessaire pour la tâche, et l'option de confidentialité n'aurait rien changé. xAI avait promu l'outil avec cette phrase : « nothing from your codebase transmitted to xAI servers during a session » (rien de votre code n'est transmis aux serveurs de xAI pendant une session). Elon Musk a reconnu les transferts et dit que les données des utilisateurs concernés seraient supprimées. TNW ajoute qu'aucun audit indépendant n'a confirmé cette suppression.

La seconde est celle qui fait l'actualité, et elle n'a rien à voir avec les dépôts. La société de sécurité Claroc a découvert que les liens de partage de Grok Build peuvent être retrouvés par des gens à qui on ne les a jamais envoyés (Claroc). Engadget rapporte que chaque lien utilisait une phrase aléatoire de quatre mots, avec jusqu'à 38 bits d'entropie, placée « à gauche du domaine » (Engadget). Elle se retrouve donc dans le nom d'hôte, et Claroc explique que les services de DNS passif collectent ces requêtes. Les conversations ChatGPT et Gemini partagées gardent leur secret dans le chemin de l'URL, que le DNS ne voit jamais. « Personne n'en devinerait un, écrit Claroc, et personne n'en a besoin, car le jeu de données les liste. »

Les applications exposées contenaient des données bien réelles. Claroc cite une carte de territoires commerciaux de 594 comptes stratégiques, huit propositions publicitaires X, quatre tableaux de bord d'annonceurs en production, l'appli du personnel d'un groupe hospitalier avec une liste de plus de 3 500 employés, et le tableau de garde en direct d'une caserne de pompiers avec le nom et le numéro de matricule de chaque pompier. Parmi les adresses testées, 94,7 % s'ouvraient sans aucune connexion. Claroc estime qu'environ 2 % des applis contenaient des données assez sensibles pour être jugées de gravité élevée ou critique.

Claroc indique que SpaceXSI a retiré les 24 applications créées par ses employés, « mais pas celles des autres utilisateurs et organisations de Grok ». Engadget ajoute que l'entreprise n'aurait pas réagi avant que Claroc ne mentionne Musk et un autre responsable de l'entreprise sur X. Selon l'article de Claroc, SpaceXSI a répondu aux questions d'un journaliste en disant que les applis Grok restent privées tant que leur créateur ne choisit pas de les partager, mais n'avait pas répondu au signalement lui-même. Nous n'avons trouvé aucune déclaration annonçant le retrait des autres applications.

Le correctif côté utilisateur est radical. Considérez tout ce qui est créé ou partagé via Grok Build comme public, supprimez les liens dont vous n'avez pas besoin et faites tourner tout identifiant ayant touché une appli que vous avez partagée. Aucune ligne de .gitignore n'y change rien.

Les clés volées sont revendues en quelques minutes

Unit 42, de Palo Alto Networks, décrit le « token jacking » : des clés d'API d'IA volées sont revendues via des « transfer stations » du marché gris, qui vendent un accès à prix cassé aux modèles de pointe (Unit 42). Parmi les sources de clés citées : des dépôts de code exposés, des infostealers et des paquets npm piégés. Dans un cas, des attaquants ont intégré des identifiants exposés à une transfer station en quelques minutes, et « près d'un million de dollars de frais » ont suivi avant la découverte. Unit 42 indique que les victimes ont « très peu de recours pour récupérer les fonds ». Ses défenses sont les plus banales : des plafonds de dépenses avec alertes, des tokens de courte durée à la place de clés de longue durée, et une revue de tous les comptes privilégiés pouvant modifier les plafonds.

Colmater la fuite : ignorer, détracker, puis renouveler

Renouvelez d'abord, nettoyez ensuite. Une clé révoquée est inutilisable dans tous les forks et copies en cache, alors qu'une clé simplement supprimée du dernier commit reste valide dans l'historique. GitHub recommande de renouveler immédiatement un identifiant exposé, et juge que nettoyer l'historique est « time-intensive and often unnecessary if you've already revoked the credential » (long et souvent inutile si vous avez déjà révoqué l'identifiant) (GitHub docs).

# Rotate the exposed credentials first (table below), then:

# Stop tracking the local file (keeps your copy on disk)
git rm --cached .claude/settings.local.json

# Add to the repo's OWN .gitignore, not just your global excludes
printf '%s\n' '.claude/settings.local.json' '.specstory/' >> .gitignore

git add .gitignore
git commit -m "Stop tracking agent local settings"

# Drop any allow rule that looks like it holds a secret, even if never committed
jq '.permissions.allow |= map(select(test("PGPASSWORD|password|token|secret|key"; "i") | not))' \
  .claude/settings.local.json > .claude/settings.local.json.new \
  && mv .claude/settings.local.json.new .claude/settings.local.json

Réfléchissez avant d'ignorer en bloc .cursor/ ou .gemini/, car certaines équipes y commitent volontairement des règles partagées.

Renouveler les clés chez les principaux fournisseurs

Chaque fournisseur a un bouton dans sa console pour ça, et l'ordre sûr est : créer la clé de remplacement, la déployer, puis supprimer l'ancienne. Supprimer d'abord peut faire tomber la production.

Pour les fournisseurs absents du tableau, dont Anthropic et xAI, nous n'avons pas vérifié les étapes de rotation : suivez leur documentation. Pour les mots de passe de bases de données et les identifiants SSH, l'essentiel de ce qu'a trouvé Apiiro, changez le mot de passe, fermez les sessions ouvertes, puis consultez les journaux d'accès depuis le jour du premier commit du fichier.

Activez les scanners de GitHub et connaissez leurs limites

Le secret scanning examine tout l'historique de chaque branche, ainsi que les issues, pull requests, discussions et wikis. Il est gratuit et automatique sur les dépôts publics ; pour les dépôts privés et internes d'une organisation, il nécessite GitHub Secret Protection (GitHub docs). Quand le format de clé d'un partenaire est détecté, GitHub prévient ce fournisseur, qui peut révoquer la clé sans qu'aucune alerte n'apparaisse dans votre dépôt.

La push protection est la couche qui aurait bloqué beaucoup de ces fichiers avant leur publication. Elle bloque un push contenant un secret détecté. Selon la documentation de GitHub, le réglage au niveau utilisateur est activé par défaut pour les pushs vers des dépôts publics sur GitHub.com, tandis que le réglage au niveau du dépôt est désactivé par défaut et doit être activé par un admin du dépôt, un propriétaire de l'organisation ou un security manager (GitHub docs). Elle analyse les motifs de fournisseurs, des motifs génériques comme les clés privées et les chaînes de connexion, vos motifs personnalisés, et une catégorie détectée par IA pour les secrets non structurés comme les mots de passe, en préversion publique. Cette dernière catégorie semble viser la lacune repérée par Apiiro. Les pushs via l'API REST n'en bénéficient pas ; ceux en ligne de commande, les commits depuis l'interface web et les envois de fichiers, si.

Connaissez aussi la porte de sortie. Par défaut, toute personne ayant un accès en écriture peut contourner un blocage en choisissant un motif, dont « I'll fix it later » (je corrigerai plus tard), ce qui ouvre une alerte et envoie un e-mail aux propriétaires. Si vos agents commitent à votre place, configurez le contournement délégué pour que seules des personnes nommées puissent laisser passer un secret.

Réglages de permissions des agents à changer dès aujourd'hui

Trois habitudes auraient gardé le mot de passe hors du fichier. Approuvez des motifs, jamais des commandes littérales contenant des identifiants. Mettez les secrets dans des variables d'environnement, pour que la commande porte un nom et non une valeur. Et interdisez à l'agent l'accès aux fichiers qui contiennent des secrets. La documentation des réglages d'Anthropic montre la forme à adopter :

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

La commande que votre agent doit exécuter ressemble à psql "$DATABASE_URL" : la règle d'approbation ne stocke donc qu'un nom de variable, rien d'autre. Chargez la variable depuis un gestionnaire de secrets ou votre profil shell, pas depuis un fichier que l'agent peut lire.

Deux détails de la documentation comptent pour les équipes : les règles allow du .claude/settings.json commité attendent que chaque coéquipier fasse confiance au dossier, tandis que les règles deny et ask s'appliquent immédiatement, et les modes auto et bypassPermissions ne prennent pas effet depuis les réglages de projet ou locaux. Les organisations peuvent verrouiller les règles allow avec allowManagedPermissionRulesOnly. Le membre de l'équipe Claude Code cité plus haut dit que le mode auto rend les règles de permission inutiles. Nous garderions quand même les règles deny sur .env : deux lignes, appliquées dès que le fichier est commité.

Pour les autres outils, les noms des réglages diffèrent, mais la question est la même : où l'outil stocke-t-il les approbations, l'historique ou les transcriptions, et cet endroit est-il dans un dépôt ? D'après la documentation, Apiiro a constaté que Claude Code est le seul des 16 agents de code comparés dont il est confirmé qu'il enregistre par défaut la commande approuvée complète dans un fichier du projet. Les quinze autres peuvent quand même fuiter via les transcriptions, les clés collées et les fichiers de mémoire. Notre comparatif des agents de code en terminal et notre article Cursor vs Copilot vs Windsurf détaillent ce que chacun stocke.

Le contrôle le plus solide ne dépend pas d'un prompt. Exécutez les agents dans un conteneur ou un bac à sable avec uniquement les identifiants dont la tâche a besoin, des périmètres limités et des durées de vie courtes. Nous avons détaillé la mécanique dans How to Contain an AI Agent.

Aux utilisateurs la rotation, aux éditeurs les réglages par défaut

Taper un mot de passe dans une commande est une erreur de l'utilisateur, et c'est à lui de faire la rotation. Mais un outil qui stocke la commande complète dans un fichier de projet, puis compte sur une exclusion placée dans votre dossier personnel pour la garder privée, a une protection qui ne fonctionne que sur un seul portable.

Les réglages par défaut font office de politique, et ici, c'est le défaut qui a décidé du résultat. Un Claude Code qui nettoierait les secrets avant d'enregistrer une règle, ou qui écrirait la ligne d'exclusion dans le .gitignore du dépôt lui-même, aurait fermé la brèche à la source. Anthropic dit étudier la question (nous voudrions une date). Un rapport de bug fermé par un bot d'inactivité n'a rien de rassurant, et les données de commits ne cadrent pas avec « créés à la main ».

Grok Build est le pire cas dans l'affaire des liens de partage, car l'utilisateur n'a rien fait de mal. Un lien que n'importe qui peut retrouver via le DNS passif n'est pas privé, quoi qu'ait laissé entendre le menu de partage. Et l'envoi massif précédent contredisait un argument marketing qui disait l'inverse. Nous ne mettrions ni liste de clients, ni carte de territoires commerciaux, ni identifiant de production dans Grok Build tant que le problème des liens de partage n'est pas corrigé et qu'un audit externe n'a pas confirmé la suppression. Si cela change, notre avis changera aussi.

Traitez les dossiers d'agents comme des fichiers .env et prévoyez un après-midi pour la mise en place ci-dessus. Vous pouvez comparer les outils eux-mêmes sur notre classement des assistants de code IA, et le volet sécurité de l'écosystème sur le classement des outils de cybersécurité IA.

Une checklist pour toute l'équipe

Cochez ce qui est vrai aujourd'hui et le score vous indiquera par où commencer. Les points à deux points sont ceux que nous traiterions avant le déjeuner.

Questions fréquentes

Est-il sûr de commiter .claude/settings.local.json ?

Non. Il contient vos approbations personnelles et peut contenir des identifiants. D'après la documentation d'Anthropic, Claude Code le garde hors de git lorsqu'il crée le fichier, via une exclusion globale, et une copie créée à la main nécessite votre propre ligne d'exclusion. Ajoutez-le au .gitignore de chaque dépôt et détrackez-le avec git rm --cached s'il a déjà été commité.

Dois-je renouveler mes clés si mon dépôt est privé ?

Oui, si le fichier a un jour contenu un identifiant. Les dépôts privés sont clonés sur des portables et des runners CI, forkés vers d'autres comptes et parfois passés en public. Le secret scanning de GitHub pour les dépôts privés d'organisation nécessite un abonnement payant : il se peut donc que le vôtre n'ait eu aucun contrôle automatisé.

Supprimer le fichier de mon dépôt fait-il disparaître le secret ?

Il disparaît du dernier commit, et de rien d'autre. L'historique, les forks et les caches conservent l'ancienne version, et Apiiro a trouvé 734 secrets qui n'apparaissent que dans d'anciennes versions du fichier. Renouvelez d'abord l'identifiant, et ne réécrivez l'historique que si vous voulez un dépôt propre.

GitHub Copilot, Cursor et Codex ont-ils le même problème ?

Apiiro n'a confirmé ce comportement, l'enregistrement par défaut de la commande approuvée complète dans un fichier du projet, que pour Claude Code parmi les 16 agents comparés. Cela ne disculpe pas les autres. Tout agent qui écrit des transcriptions ou de la mémoire dans votre répertoire de travail demande les mêmes règles d'exclusion.