Quelque part dans un dépôt GitHub public, un mot de passe de base de données de production traîne dans un fichier JSON. Il y est depuis 217 jours. Personne ne l'a écrit exprès. Il est arrivé là parce qu'un développeur a demandé à un agent de code IA de vérifier pourquoi le login de staging échouait, que l'agent a proposé la commande évidente, et que le développeur a cliqué sur « Oui, et ne plus demander ».
Ce clic, c'est toute l'histoire.
Le 6 novembre, la société de sécurité Apiiro a publié une recherche montrant que ce schéma exact a laissé 2 539 secrets bien réels exposés dans 1 994 dépôts GitHub publics. Parmi eux : la clé cloud d'administration d'un éditeur de bases de données, sans expiration ; un mot de passe Postgres de production sur Azure ; un token de production Square ; et le mot de passe propriétaire d'une base de données de dossiers médicaux. Soixante-trois organisations, majoritairement des entreprises de logiciel, ont au moins une credential vivante dans une liste d'autorisations publique. Une entreprise a confirmé que sa clé fonctionnait encore quand les chercheurs l'ont appelée.
Ce n'est pas un problème de modèle. C'est un comportement produit, et cela arrive à des équipes qui croyaient être prudentes.
Le mécanisme tient en trois mots
Claude Code demande avant d'exécuter une commande shell. C'est le garde-fou, et il est raisonnable. Mais l'invite propose une option : « Oui, et ne plus demander ». Choisissez-la, et Claude Code écrit une règle d'autorisation dans .claude/settings.local.json, dans le dossier du projet. La règle, c'est la commande, mot pour mot.
Si la commande était PGPASSWORD=hunter2 psql -h prod-db.internal -U admin, alors la règle est PGPASSWORD=hunter2 psql -h prod-db.internal -U admin. L'agent n'a pas décidé d'enregistrer votre mot de passe. Il a enregistré votre commande, et votre commande contenait votre mot de passe.
Apiiro a reproduit le comportement avec les derniers modèles d'Anthropic, Opus 5.5 et Fable 5.1. C'est l'outil autour, pas la couche de raisonnement. Sur les seize agents de code dont les chercheurs ont comparé la documentation, Claude Code est le seul dont il est confirmé qu'il enregistre par défaut la commande complète approuvée dans un fichier du projet.
La protection existe, mais elle ne voyage pas
C'est là que ça devient intéressant, et c'est là que la plupart des analyses s'arrêtent un cran trop tôt.
Claude Code essaie bel et bien de garder ce fichier hors de git. La première fois qu'il l'écrit dans un dépôt, il l'ajoute à votre liste d'exclusions git globale. Sur votre machine, dans votre configuration git, ce chemin est désormais ignoré dans tous les dépôts que vous touchez. C'est de l'ingénierie sincèrement réfléchie.
C'est aussi de l'ingénierie qui ne survit pas au contact du réel.
Les exclusions globales vivent dans la configuration d'un utilisateur, sur un portable. Dès que le fichier est déjà commité, l'exclusion ne sert à rien. Elle ne protège pas un clone sur la machine d'un collègue, ni un dossier devenu dépôt après coup, ni un fork. Et Claude Code n'ajoute jamais le chemin au .gitignore du projet lui-même : la protection ne fait donc pas partie du dépôt. Elle ne voyage jamais avec le code.
Pire : dans 539 des 1 105 dépôts avec un secret confirmé, c'est un commit co-signé par Claude qui a modifié le fichier. L'agent, faisant ce que font les agents, a commité le travail. Le travail contenait sa propre liste d'autorisations.
Ce que disent vraiment les chiffres
Apiiro a scanné 104 185 copies publiques de .claude/settings.local.json dans 103 617 dépôts. Sur ce total, 1 122 fichiers (environ 1,1 %) contiennent un vrai secret : 1 379 credentials distinctes. La répartition mérite qu'on s'y arrête :
- 379 mots de passe de bases de données et 122 clés service-role Supabase, qui ouvrent une base directement
- 103 tokens de compte Supabase, qui contrôlent tous les projets de ce compte
- 43 accès SSH à des serveurs publics, dont plusieurs en root via
sshpass - 42 tokens GitHub, GitLab et npm, 23 clés AWS, 6 clés privées
Plus d'un tiers des credentials exposées ouvrent une base de données. Ce ne sont pas des tokens qu'on fait tourner au trimestre. Ce sont les bijoux de famille, dans un fichier au nom sympathique.
La taille est corrélée au risque de façon brutale : un fichier de plus de 8 Ko sur dix contient un vrai secret, contre moins d'un sur cinq cents sous 500 octets. Plus un développeur clique « ne plus demander » longtemps, plus le fichier s'alourdit. Le fichier exposé médian a été commité pour la première fois 217 jours avant la découverte. Dans 118 dépôts, il est là depuis plus d'un an.
Supprimer le fichier ne règle rien non plus. Les versions antérieures contiennent 734 autres secrets dans 509 dépôts, absents de toute copie actuelle, le plus souvent parce que quelqu'un a fini par supprimer le fichier. Les forks aggravent le tout : 211 forks de 74 dépôts portent les mêmes secrets que l'original. C'est la propriété git classique qui surprend tout le monde la première fois : un secret commité est un secret permanent, et un secret permanent dans un dépôt public est un secret publié.
Votre scanner de secrets est probablement passé à côté
Voici la partie que les équipes sécurité doivent entendre. Apiiro a fait tourner gitleaks et TruffleHog sur les 104 185 fichiers. Sur les 1 122 qui contenaient un vrai secret, gitleaks en a signalé 564 et TruffleHog 643. 215 n'ont été signalés par aucun des deux.
L'angle mort, ce sont les mots de passe à l'intérieur des commandes. Les scanners sont calibrés pour des formats de clé : un préfixe de fournisseur, une longue chaîne aléatoire, un seuil d'entropie. Un mot de passe après PGPASSWORD=, sshpass -p, mysql -p, ou dans un en-tête bearer au cœur d'un appel curl, c'est juste un mot ordinaire dans une ligne de commande ordinaire. Ça ressemble à du shell, parce que c'est du shell.
Et le schéma ne se limite pas à un fichier. La même recherche a trouvé des secrets dans :
- le
.claude/settings.jsonpartagé que les équipes commitent volontairement (298 fichiers sur 76 011) - les transcriptions de chats d'agents exportées de
.specstory, Aider et Cursor (120 fichiers dans 87 dépôts) - les fichiers de mémoire d'agents comme
MEMORY.md(9 dépôts) - les notes de passation et de déploiement (33 fichiers, un tiers écrits par l'agent lui-même)
- les réglages d'auto-approbation de VS Code Copilot (9 dépôts)
L'habitude qui fuit est identique partout : une personne tape un secret dans une commande, et un agent enregistre la commande avec un zèle parfait.
Que faire, dans l'ordre
Faire tourner d'abord. Nettoyer ensuite. Cet ordre n'est pas une préférence, c'est la seule séquence qui fonctionne : dès qu'une credential touche un commit public, elle appartient à quiconque l'a lu, et l'historique s'en souvient.
- Cherchez le fichier dans votre organisation. Interrogez GitHub pour
.claude/settings.local.jsonet.claude/settings.jsondans tous les dépôts, et vérifiez l'historique git même là où le fichier a disparu aujourd'hui. - Faites tourner tout ce que le fichier a contenu un jour — mots de passe, tokens, clés, chaînes de connexion — avant de commencer à supprimer.
- Retirez-le du suivi et ignorez-le.
git rm --cached .claude/settings.local.json, puis ajoutez-le au.gitignoredu dépôt lui-même, pas seulement au global. - Ouvrez le fichier sur votre propre portable, commité ou non, et supprimez chaque règle contenant un secret. La plupart de ces fichiers n'ont jamais touché GitHub et restent en clair sur le disque.
- Arrêtez de mettre des secrets dans les commandes. Référencez
$DB_URLdepuis un gestionnaire de secrets pour que la règle enregistrée contienne un nom de variable et non une credential. - Approuvez des motifs, pas des commandes.
Bash(npm run:*)est une règle.npm run deploy --token abc123est une fuite.
Pour les équipes sécurité, quatre ajouts : traitez .claude/, .cursor/, .gemini/, .specstory/ et les fichiers de mémoire d'agents comme des chemins porteurs de secrets, au même titre que .env, sur les portables comme dans les dépôts ; intégrez-les au scan pre-commit et CI, historique compris ; mettez .claude/settings.local.json dans le modèle .gitignore de votre organisation ; et traitez en priorité les credentials associées à l'adresse d'un hôte public, parce que ce sont celles qui donnent accès depuis n'importe où.
La conclusion que nous répétons
La leçon n'est pas « les agents IA sont dangereux ». Le modèle d'autorisation d'Anthropic est sensé, et l'exclusion globale de Claude Code montre que quelqu'un a pensé à cette panne précise. La leçon, c'est que les réglages de confort deviennent discrètement du stockage. Chaque « ne plus demander » est un enregistrement. Chaque enregistrement a un chemin. Et chaque chemin finit tôt ou tard dans un dépôt, une archive, une couche Docker ou un dossier synchronisé.
Si votre équipe livre avec des agents de code depuis un an, vous avez presque certainement un dossier .claude/ antérieur à toutes les politiques que vous avez écrites depuis. Allez le lire. Pas la version du dépôt : celle du portable devant vous. Puis regardez ce que les scanners en ont dit, et partez du principe qu'ils n'ont rien dit.
La commande que vous avez approuvée une fois tient encore votre mot de passe. Elle le tiendra jusqu'à ce que vous le fassiez tourner.