Des identifiants en clair dans des dépôts publics, et un fichier de configuration qui n'était pas censé sortir du disque. L'affaire n'est pas une intrusion : c'est un accident de routine, répété des milliers de fois.
Claude Code secrets leak : le fichier qui part avec le projet
Ars Technica a publié le 9 novembre une enquête sur des fichiers de configuration Claude Code présents dans des dépôts GitHub publics, avec des identifiants en clair à l'intérieur. Le même jour, Cybernews a repris le sujet sous l'angle des agents IA qui laissent fuiter des secrets. GitGuardian, de son côté, nomme le fichier en cause, settings.local.json, et cite des identifiants Docker Hub parmi les secrets exposés.
Le point important est ce que cette histoire n'est pas. Il ne s'agit pas d'une faille dans Claude Code, ni d'un serveur d'Anthropic compromis. Les fichiers ont été publiés par des utilisateurs, dans des dépôts qu'ils ont eux-mêmes ouverts au public.
Ce qui reste, et c'est déjà beaucoup : des accès qui traînent à portée de moteur de recherche, souvent sans que leur propriétaire le sache.
Comment un Claude Code settings.local.json finit dans un dépôt public
Le fichier vit dans le dossier du projet, au même niveau que le code. C'est son premier défaut.
Il contient des choses utiles au quotidien : les règles d'autorisation qui évitent de valider chaque commande, des valeurs d'environnement, et la déclaration des serveurs MCP que l'agent peut appeler. Certaines de ces valeurs sont des clés, des jetons, parfois des identifiants de base de données.
Le second défaut est la commande. Un git add -A, lancé par habitude ou par script, embarque tout ce qui n'est pas explicitement ignoré. Un .gitignore mal tenu, et le fichier part avec le reste.
Le troisième est la nature du fichier. Il porte un nom technique, il est petit, il ressemble à de la configuration banale. Personne ne le relit en revue de code, parce qu'il n'apparaît pas comme du code. Il apparaît comme un réglage.
AI agent secret leak : pourquoi le sujet dépasse Claude Code
Le cadrage « agents IA qui fuient des secrets » est commode, et il contient une part de vrai. Les assistants de code lisent le projet, écrivent dedans, et parfois y déposent leur propre configuration. Un agent qui travaille dans un dépôt a plus de raisons qu'un simple éditeur d'y laisser des traces.
La mécanique, elle, est plus ancienne que l'IA générative. Les fichiers .env, les clés AWS laissées dans un script de déploiement, les clés privées commitées par erreur : GitHub en héberge depuis des années, et les scanners de secrets existent précisément pour ça.
La différence tient au volume et à la nouveauté. Un outil adopté en quelques mois par des équipes entières produit beaucoup de fichiers identiques, avec les mêmes erreurs. Et comme l'outil est récent, peu de gens ont encore le réflexe de vérifier ce qu'il dépose dans l'arborescence.
Claude Code GitHub security : ce qu'il faut chercher dans vos dépôts
Trois vérifications suffisent pour savoir où vous en êtes, et elles prennent moins d'une heure.
Une heure, pas une semaine.
La première est une recherche par nom de fichier. Sur GitHub, la recherche de code accepte un chemin : settings.local.json fait remonter tous les fichiers de ce nom dans les dépôts auxquels vous avez accès. Il faut lancer la recherche en incluant les dépôts archivés et les forks, où les vieux commits survivent longtemps.
La deuxième est l'historique. Un fichier supprimé hier reste lisible dans le commit de la veille. Un git log -p sur les chemins de configuration, ou un scanner dédié comme ceux de GitGuardian, donne la liste des secrets qui ont existé un jour.
La troisième est le périmètre des jetons trouvés. Un jeton Docker Hub, par exemple, peut publier des images, en supprimer, ou modifier les dépôts d'une organisation. Ce n'est pas la même chose qu'un droit de lecture sur un dépôt privé, et le risque se mesure à cette portée.
La rotation des jetons Claude Code avant le nettoyage de l'historique
L'ordre des opérations décide de l'efficacité. Réécrire l'historique pour effacer un commit donne l'impression d'avoir réglé le problème, alors que le jeton, lui, reste valide.
La bonne séquence démarre par la révocation. On supprime le jeton chez le fournisseur, on en émet un nouveau, on le place dans un gestionnaire de secrets, et on met à jour le déploiement. Ensuite seulement, on nettoie le dépôt.
Un jeton publié est un jeton compromis, même s'il n'est resté en ligne que quelques minutes. Les robots qui balaient GitHub en permanence n'attendent pas les articles de presse, et une clé peut servir dans l'heure qui suit sa publication.
Deuxième étape, donc : vérifier les journaux d'accès du service concerné, à la recherche d'appels qui ne viennent pas de chez vous. Troisième étape : ajouter le fichier au .gitignore et le signaler dans le modèle de projet, pour que la prochaine recrue ne recommence pas.
Ce que l'affaire Claude Code ne dit pas
Trois inconnues restent, et il faut les nommer.
Combien de ces jetons fonctionnent encore ? Les articles parlent de milliers de secrets exposés, sans dire combien fonctionnent toujours. Un jeton révoqué il y a deux ans ne vaut rien, et un jeton oublié vaut de l'or.
La deuxième est la réponse d'Anthropic. Rien n'indique qu'un correctif ait été livré, ni qu'un fichier d'exclusion par défaut soit prévu. La question mérite d'être posée, parce qu'un outil qui écrit sa configuration dans le dossier du projet pourrait l'ignorer automatiquement, comme le font déjà plusieurs outils de l'écosystème JavaScript.
La troisième est la procédure côté entreprise. Si un jeton exposé donne accès à des données personnelles de clients, le RGPD impose de notifier la CNIL dans les 72 heures. Beaucoup d'équipes françaises ne le savent pas, et traitent l'incident comme un simple ménage de dépôt.
En attendant, le réflexe utile est simple : ouvrir la configuration de Claude Code, regarder ce que contient le fichier local, et vérifier ce que votre .gitignore protège réellement. Le reste, y compris la question des responsabilités, se décidera ailleurs.
