Claude Code et son option « Don't Ask Again » ont exposé des mots de passe dans 1 122 fichiers publics sur GitHub

Vous avez probablement cliqué cent fois sur « Don't Ask Again » pour que l'agent cesse de vous solliciter à chaque commande. C'est pratique. Mais les chercheurs d'Apiiro ont montré que cette commodité avait un prix : 1 122 fichiers contenant des mots de passe, divulgués précisément par ce type d'autorisations de Claude Code, ont été découverts sur des dépôts GitHub publics.

Précision importante : nous ne disposons que du titre et du signal provenant de Hacker News — 114 points et 85 commentaires — et non du rapport complet. Le mécanisme décrit ci-dessous est donc le plus probable, mais ses détails doivent être vérifiés dans la source originale.

Comment un mot de passe se retrouve sur GitHub

Imaginez une session classique. Vous demandez à l'agent de se connecter à une base de données et d'exécuter une migration. Il construit une commande dans laquelle le mot de passe apparaît directement dans la chaîne de connexion, par exemple dans un paramètre ou une variable d'environnement. Claude Code demande votre autorisation. Vous choisissez « Don't Ask Again » afin de ne plus avoir à confirmer cette action à chaque fois.

Pour mémoriser votre choix, l'outil inscrit une règle d'autorisation dans le fichier de configuration du projet. Si cette règle est associée à une commande précise, la commande entière, secret compris, est enregistrée dans le fichier. La suite est habituelle : git add, commit, push. Le fichier de configuration se trouve dans le dépôt aux côtés du code et, si le dépôt est public, le mot de passe devient accessible à tous.

Il est important de noter que personne n'a commis d'erreur manifestement stupide. L'utilisateur n'a pas collé son mot de passe dans le README et n'a pas commité de fichier .env. Le secret a fuité comme effet secondaire d'une fonctionnalité pratique que personne ne considère comme un espace de stockage de données.

Pourquoi cette fuite est plus grave qu'une fuite ordinaire

Les scanners de secrets classiques recherchent des motifs connus dans le code et les fichiers de configuration de l'application. Les fichiers de paramètres des agents constituent souvent un angle mort : ce ne sont ni des fichiers source ni des fichiers .env, si bien que les règles et les pratiques de l'équipe ne s'y appliquent pas.

Le problème comporte un deuxième niveau. Les agents insèrent volontiers des identifiants dans la ligne de commande, car c'est la manière la plus simple d'accomplir une tâche. Tout mécanisme qui mémorise les commandes se transforme alors en journal de secrets. Ce risque ne concerne pas uniquement Claude Code : il touche tout assistant qui stocke, à proximité du projet, une liste d'actions autorisées.

Le chiffre de 1 122 doit également être interprété avec prudence. Il correspond uniquement aux fichiers trouvés par une recherche publique. Les dépôts privés, les forks et les fichiers déjà supprimés mais toujours présents dans des caches ne sont pas inclus. L'ampleur réelle du problème est donc probablement supérieure.

Ce qu'il faut faire immédiatement

Premièrement, recherchez dans vos dépôts le répertoire contenant les paramètres de l'agent et examinez les commandes autorisées. Considérez comme compromis tout élément ressemblant à un mot de passe, un jeton ou une chaîne de connexion : commencez par renouveler la clé, puis procédez au nettoyage. Supprimer simplement la ligne du dernier commit ne suffit pas, car elle reste présente dans l'historique git.

Deuxièmement, séparez les paramètres partagés des paramètres locaux. Les règles que l'équipe souhaite partager doivent être stockées séparément des autorisations personnelles, et le fichier local doit figurer dans .gitignore.

Troisièmement, ajoutez un scanner de secrets au pre-commit et à la CI, en incluant explicitement les fichiers de configuration des outils d'IA dans le périmètre d'analyse. C'est une assurance peu coûteuse.

Quatrièmement, ne transmettez pas de secrets à l'agent dans la ligne de commande. Fournissez-les par l'intermédiaire de variables d'environnement issues d'un gestionnaire de secrets ou au moyen de jetons temporaires à courte durée de vie. Ainsi, même une commande mémorisée ne contiendra rien de précieux.

À retenir pour les équipes produit et les fondateurs

Cet incident illustre bien comment la commodité des autorisations dans les outils agentiques crée une nouvelle surface d'attaque. Si vous développez votre propre agent, réfléchissez précisément à ce que vous enregistrez lorsque vous mémorisez le choix d'un utilisateur : un modèle de commande ou son texte littéral, et vérifiez si ces données sont stockées dans un fichier qui sera ajouté à git par défaut. Le masquage des secrets avant l'écriture et le stockage du fichier dans un emplacement sûr demandent quelques jours de travail ; une fuite touchant un millier de dépôts coûte bien davantage.