Les agents de code IA divulguent-ils plus de secrets ? Les chiffres 2026 de GitGuardian et une checklist de 10 minutes

Selon le State of Secrets Sprawl 2026 de GitGuardian, les commits assistés par Claude Code ont divulgué un secret dans 3,2 % des cas, contre une base de 1,5 % pour l'ensemble des commits publics de GitHub. La même présentation compte 24 008 secrets uniques dans des fichiers de configuration liés à MCP sur GitHub public, dont 2 117 valides. Ce sont de vraies mesures, avec des limites : elles décrivent des dépôts publics, elles comparent à tous les commits, et GitGuardian elle-même met en garde contre une lecture de l'écart comme une défaillance de l'outil. Ce guide rapporte les chiffres tels que la source les donne, explique pourquoi les agents et leurs fichiers de configuration changent l'endroit où les secrets finissent, et propose une checklist d'environ 10 minutes.

Qu'a rapporté GitGuardian sur les secrets et les agents de code IA ?

GitGuardian vend de la détection de secrets : elle a donc des données et un intérêt dans le sujet. Les deux sont à garder en tête. Nous citons ses propres publications sans rien y ajouter : la page du rapport State of Secrets Sprawl 2026 et la présentation des résultats par GitGuardian. Les chiffres ci-dessous viennent de ces deux pages, telles que nous les avons lues le 18 octobre 2026.

Quelques remarques pour lire le tableau.

Le 3,2 % est un taux par commit. La présentation parle de « secret-leak rate » sans définir le terme. La lecture naturelle est la part des commits qui contiennent un secret écrit en dur, mais la source ne le précise pas.

La base, c'est tout commit public. Ce n'est pas une base de commits humains soignés, ni de commits de personnes utilisant d'autres outils d'IA. Un écart entre 3,2 % et 1,5 % peut venir de l'outil, du type de projet où on l'utilise, de la part de code relue, ou des trois. Le rapport ne les sépare pas.

GitGuardian ne parle pas de défaillance de l'outil. La présentation dit que l'écart ne doit pas être lu comme une simple défaillance de l'outil : les personnes décident toujours ce qu'elles acceptent, modifient, ignorent ou poussent, et un utilisateur peut passer outre un avertissement ou orienter un modèle vers du code peu sûr.

Les chiffres MCP concernent des dépôts publics. Les 24 008 sont des secrets uniques trouvés dans des fichiers de configuration liés à MCP poussés sur GitHub public. La présentation ajoute que les guides d'installation MCP populaires disent souvent de mettre les clés d'API directement dans les fichiers de configuration, les arguments de ligne de commande ou les chaînes de connexion. Nous n'avons trouvé sur aucune des deux pages de taille d'échantillon, de méthode de collecte ni de période pour ce chiffre. Prenez-le comme un décompte de GitGuardian, pas comme un taux.

Certains détails n'apparaissent que sur une page. La page du rapport ne montrait pas les 3,2 % et 1,5 % quand nous l'avons lue, seulement le résumé « environ le double ». La présentation a les deux, ainsi que les 2 117. Quand un chiffre n'est que sur une page, le tableau la nomme.

Un autre chiffre de la même source change ce que vous faites après une fuite. GitGuardian a retesté des identifiants valides en 2022 et constaté que plus de 64 % fonctionnaient encore en janvier 2026. Une clé divulguée n'expire pas parce que personne ne l'a remarquée.

Pourquoi les agents de code changent-ils l'endroit où les secrets finissent ?

Un agent est un programme qui lit des fichiers, exécute des commandes et envoie une partie de ce qu'il voit à un fournisseur de modèles. C'est son travail. Pour les secrets, trois choses en découlent.

Les agents lisent les fichiers où l'on range les secrets. Un fichier .env est l'endroit habituel des clés locales, et un agent qui explore un projet pour le comprendre ouvre souvent ce fichier. Les valeurs voyagent alors avec le reste du contexte jusqu'au fournisseur. Une règle comme .gitignore garde un fichier hors d'un commit, mais ne promet rien sur ce qu'un agent peut lire, et chaque agent la traite à sa façon.

Les agents écrivent de la configuration. Quand un agent ajoute un serveur MCP, prépare un test ou branche une base de données, le changement le plus rapide qui marche est souvent une valeur en clair dans un fichier. Le commit suivant l'inclut. Une personne se serait peut-être arrêtée là. Un agent à qui l'on demande de faire passer le test peut ne pas le faire, et quelqu'un qui relit un long diff peut ne pas voir une ligne de plus.

La configuration MCP met des identifiants dans un nouveau type de fichier. Un serveur MCP doit s'authentifier quelque part, et son fichier de configuration est l'endroit où vivent ses réglages. Les guides qui montrent une clé dans le fichier en font la voie facile. Ces fichiers se commitent aussi facilement : ils sont dans le dossier du projet, souvent sous le nom .mcp.json, à côté du code.

Rien de tout cela ne veut dire que les outils sont négligents. Un nouvel acteur touche désormais les fichiers où vivent les secrets, à grande vitesse, et les protections plus anciennes ont été conçues pour une personne qui tape un commit. Les protections qui fonctionnent encore sont celles qui ne dépendent pas du fait que quelqu'un y pense.

Que faire en 10 minutes ?

Chaque étape a sa durée. Si vous ne faites que les deux premières, vous avez traité l'exposition qui est bien réelle.

1. Trouvez ce qu'un agent peut atteindre (2 minutes)

Depuis le dossier où vous travaillez, lancez :

npx -y zn-gate reach

La commande liste les noms, jamais les valeurs, des secrets de vos fichiers .env, les fichiers d'identifiants de votre dossier personnel, les variables d'environnement dont le nom évoque un secret, et les constats sur les serveurs MCP et les réglages des agents. Elle est en lecture seule et n'envoie rien. Si vous préférez ne pas utiliser d'outil pour cela, cherchez dans votre projet .env, .mcp.json, .cursor/, .codex/ et .claude/ et ouvrez chacun.

2. Renouvelez tout ce qui a été exposé (3 minutes)

Si une vraie clé a un jour été dans un fichier commité, une branche poussée, un chat ou une configuration que vous avez partagée, considérez-la comme exposée. Créez une nouvelle clé chez le fournisseur, mettez à jour les endroits qui l'utilisent, et révoquez l'ancienne. Faites-le même si le dépôt est privé : GitGuardian indique que les dépôts internes ont environ six fois plus de chances que les publics de contenir des secrets écrits en dur, et un dépôt privé peut devenir public ou être copié.

Renouvelez d'abord, rangez ensuite. Supprimer le fichier ou réécrire l'historique git ne sert à rien si quelqu'un a déjà une copie de la clé.

3. Sortez les secrets des fichiers de configuration MCP (2 minutes)

Remplacez chaque valeur en clair d'une configuration MCP par une référence à quelque chose qui est hors du fichier. La forme qui marche dépend de votre client : consultez sa documentation. Beaucoup de clients permettent de passer une variable par son nom ou de développer une variable d'environnement dans l'entrée, et un coffre ou un gestionnaire de secrets peut fournir la valeur au lancement. L'objectif est que le fichier de votre dépôt ne contienne aucune valeur utilisable seule.

Voici la forme du changement, avec un nom d'exemple et sans valeur réelle :

{
  "mcpServers": {
    "example-service": {
      "command": "npx",
      "args": ["-y", "example-mcp-server"],
      "env": { "EXAMPLE_API_KEY": "<set in your environment, not here>" }
    }
  }
}

Si une clé était déjà dans le fichier et que le fichier a quitté votre machine, retournez à l'étape 2.

4. Ajoutez un scanner de secrets avant les commits (2 minutes)

Un scanner qui s'exécute à chaque commit attrape l'erreur qui passe à travers tout le reste. Deux options courantes sont ggshield, de GitGuardian, et gitleaks, qui est open source. Les deux peuvent tourner comme hook de pre-commit. Leurs commandes d'installation changent selon les versions : suivez les instructions actuelles du README de chaque projet. Choisissez-en un, lancez-le une fois sur votre historique, et activez-le pour les nouveaux commits.

Cela ne remplace pas les autres étapes. Un scanner de commits voit ce que vous commitez. Il ne voit pas ce qu'un agent lit sur votre disque et envoie à un modèle.

5. Restreignez ce que l'agent peut lire (1 minute, plus les questions)

Utilisez d'abord les réglages de l'agent lui-même : des règles de permissions et des fichiers d'exclusion existent dans la plupart, et le comportement exact varie. Ensuite, si vous voulez une couche qui marche avec plusieurs agents, zn-gate est une option. Il est open source (MIT), s'exécute sur votre machine et ne demande pas de compte.

npx -y zn-gate init
npx -y zn-gate env shadow .env
npx -y zn-gate check

init trouve Claude Code, Codex CLI, Cursor et OpenCode, montre la configuration de chacun et demande avant chaque changement. env shadow .env déplace les vraies valeurs dans un coffre chiffré local et laisse dans le fichier des marqueurs comme __ZN_STRIPE_KEY__. La première fois, lancez npx -y zn-gate unlock pour créer le coffre. check teste la configuration avec un faux secret dans un dossier temporaire et vous dit si un agent n'est pas protégé. Lancez init dans votre propre terminal : quand un agent ou un script le lance, il n'affiche que les étapes.

Passez ensuite en revue ce à quoi ce projet configure vos agents pour faire confiance :

npx -y zn-gate audit
npx -y zn-gate scan .

npx -y zn-gate audit examine .claude/, .mcp.json, .codex/, .cursor/, les hooks, AGENTS.md et CLAUDE.md, les plugins et les skills. Ajoutez --include-home pour vérifier aussi les réglages de votre dossier personnel. zn-gate scan cherche des secrets divulgués dans les fichiers de configuration et les signale avec l'étape suivante. Les mêmes contrôles peuvent tourner en CI comme GitHub Action.

Que ne couvrent pas ces étapes ?

• Les clés hors de votre machine. Une clé enregistrée dans la console d'un tiers, une variable de CI ou un chat est hors de ce qu'un outil local peut protéger. Limitez ces clés avec des plafonds de dépense et des durées de vie courtes.
• Les secrets que vos outils ne reconnaissent pas. Les scanners cherchent des formats et des noms connus. Un jeton maison sans forme reconnaissable peut passer à travers n'importe lequel, zn-gate compris. Nommer clairement les variables aide.
• Les agents et éditeurs que zn-gate ne prend en charge qu'en partie. La prise en charge varie selon l'agent. Le tableau de compatibilité indique ce que chacun permet. Dans certains éditeurs, zn-gate ne fonctionne que comme serveur MCP que l'agent choisit d'appeler, ce qui n'est pas une protection automatique.
• Ce que les chiffres signifient pour vous. Les chiffres de GitGuardian décrivent GitHub public. Vos dépôts privés peuvent être différents, dans un sens ou dans l'autre.

zn-gate est l'une des façons de faire l'étape 5, et c'est celle que nous construisons. Les autres étapes n'en dépendent pas. Le renouvellement et le scan sont ce qui ferme l'exposition qui existe déjà.

Où en lire plus ?

Les deux pages de GitGuardian citées plus haut sont les sources primaires. Pour les détails de zn-gate, voir la documentation de reach et du scrubber et coffre de secrets. Pour les bases sur la façon de garder un .env hors de portée d'un agent, lisez comment empêcher Claude Code, Codex CLI, Cursor et OpenCode de lire votre .env avec une seule commande. Pour voir comment un hook pouvait être contourné et comment cela a été corrigé, lisez comment un agent de code pouvait lire votre fichier .env de façon indirecte. zn-gate est sous licence MIT, s'exécute en local et ne demande pas de compte : GitHub et Install.