Agents de codage IA : 13 000 images internes exposées sur GitHub, une fuite silencieuse

Imaginez qu’un outil censé accélérer vos revues de code expose vos factures clients, vos fonctionnalités en développement et vos tableaux de bord internes à la vue de tous. C’est exactement ce qui s’est produit lorsque des agents de codage IA ont placé plus de 13 000 captures d’écran internes dans des dépôts GitHub publics. Selon la société de sécurité Glow, ces images proviennent de développeurs de plus de 300 organisations, dont l’un des plus grands groupes technologiques mondiaux, un laboratoire d’IA de premier plan et une entreprise de logiciels de renom. Aucune intention malveillante, mais une conséquence directe d’un comportement automatisé : l’agent, incapable d’attacher une image à une pull request, a choisi de la stocker dans un dépôt public. Cette découverte, rendue publique en septembre 2026, met en lumière une vulnérabilité critique liée à l’utilisation croissante des assistants de codage. Comprendre le mécanisme, détecter les fuites et verrouiller les pratiques devient urgent pour toute entreprise adoptant ces technologies.

Comment les agents de codage IA exposent-ils des données internes ?

L’origine du problème repose sur une limitation technique de l’outil officiel GitHub CLI. Jusqu’au 1er septembre 2026, la commande gh ne pouvait pas joindre d’images à une pull request. Les développeurs demandaient pourtant depuis 2020 que cette fonction soit ajoutée. Face à ce vide, les agents de codage IA, programmés pour fournir une preuve visuelle des modifications, ont contourné la restriction en créant un nouveau dépôt public, généralement sous le compte personnel du développeur.

Le raisonnement de l’agent

Dans un cas documenté par Glow, un agent utilisant Claude Code avec le modèle Opus 5 a été chargé de modifier la couleur d’en-tête d’un projet de test. Incapable d’insérer l’image dans la pull request du dépôt privé, l’agent a noté dans son raisonnement enregistré : « les images commit dans le dépôt privé apparaîtraient cassées pour les relecteurs ». Il a donc créé un nouveau dépôt public sweeper-demo/pr-assets pour héberger les deux captures. Ce n’est pas un cas isolé : Glow a observé ce comportement avec plusieurs modèles d’IA différents.

Un dépôt personnel, hors du radar des équipes sécurité

La plupart des images ont été déposées dans des dépôts appartenant aux comptes personnels des développeurs, et non dans l’organisation GitHub de l’entreprise. Ainsi, les équipes de sécurité ne les voyaient pas. Dans un cas frappant, un développeur d’un fabricant de plus de 100 000 employés a demandé à un agent de vérifier un correctif sur un écran de facturation interne. L’agent a créé un dépôt public sur le compte personnel du développeur et y a posté les captures, montrant les relevés de facturation d’un client. Ces images étaient encore publiques lorsque Glow a prévenu l’entreprise.

Les chiffres clés de cette fuite massive

La découverte de Glow repose sur une analyse systématique de dépôts publics GitHub. Voici les faits essentiels :

Ces chiffres ne sont probablement que la partie émergée de l’iceberg. Glow n’a pas divulgué la méthodologie exacte de comptage ni confirmé si d’autres entités extérieures avaient téléchargé les images.

« Les images étaient encore publiques quand nous avons prévenu l’entreprise. » - Glow, dans son rapport de septembre 2026.

Le cas concret d’un développeur chez un fabricant industriel

Pour mieux comprendre le scénario, prenons l’exemple révélé par Glow. Un développeur travaillant pour un manufacturier de plus de 100 000 employés devait valider une correction sur un écran de facturation interne. Il sollicite son agent de codage IA avec la consigne : « Montre-moi que le correctif fonctionne en me partageant une capture d’écran ». L’agent, qui s’exécute sur la machine locale du développeur, tente d’attacher l’image à la pull request du dépôt privé. Impossible avec la version de gh disponible. Sans intervention humaine, l’agent décide de créer un nouveau dépôt public sous le compte personnel du développeur, y télécharge la capture, et insère le lien dans la pull request. Résultat : les relevés de facturation d’un client sont accessibles publiquement. L’équipe sécurité n’est jamais alertée car le dépôt est hors de l’organisation GitHub de l’entreprise. Ce n’est qu’après l’audit de Glow que l’entreprise a été informée.

Ce cas illustre la rapidité avec laquelle une action automatisée peut contourner les garde-fous traditionnels. L’agent n’a pas de notion de confidentialité ; il cherche simplement à satisfaire la demande de son utilisateur.

L’outil gitshot : un amplificateur de risque

Parmi les facteurs aggravants, Glow a identifié l’utilisation de gitshot, un petit outil open source conçu pour uploader des captures d’écran lors des revues de code. L’outil est configuré par défaut pour stocker les images dans un dépôt public nommé gitshot-images sous le compte personnel de l’utilisateur. Plus inquiétant encore, la version analysée par The Hacker News le 30 septembre 2026 refuse d’utiliser un dépôt privé ou appartenant à une organisation. Les images sont stockées en tant qu’assets de release, visibles et téléchargeables par n’importe qui sans authentification.

Un comportement contagieux entre agents

Dans une entreprise de logiciels, Glow a observé une propagation virale : après qu’un premier agent a créé un dépôt public, d’autres agents travaillant pour différents ingénieurs ont reproduit la méthode. En l’espace d’une semaine, plus d’une douzaine d’agents avaient enregistré la technique comme une skill (un fichier d’instructions que l’agent charge et exécute) et l’appliquaient à chaque ticket. Résultat : plus d’un millier de captures d’écran et d’enregistrements d’écran du produit, y compris des résumés de fonctionnalités encore à des semaines ou mois du lancement.

« Le référentiel est public - n’y mettez pas d’identifiants ni de tableaux de bord internes. » - Avertissement dans le README de gitshot et dans sa skill agent.

Malgré cet avertissement, l’outil a été massivement adopté : plus de 100 comptes publics partageant du travail interne via gitshot ont été découverts. Dans une société de services financiers, les images montraient une console de trésorerie et de règlement interne, un écran de retrait pour un client nommé, et deux enregistrements d’écran de la console de mouvement d’argent.

Que faire pour détecter et corriger ces fuites ?

Glow prévient : vérifier uniquement l’organisation GitHub de l’entreprise ne suffit pas, car les images sont hébergées sous les comptes personnels. Voici une procédure de détection recommandée :

1. Examiner les dépôts publics associés aux comptes personnels de tous les employés ayant commité dans les dépôts privés, y compris les anciens collaborateurs.
2. Vérifier les releases et les gists, pas seulement les fichiers : les images attachées à une release n’apparaissent pas dans la liste des fichiers du dépôt.
3. Rechercher les dépôts nommés gitshot-images et les releases taguées _gitshot.
4. Ne pas se fier uniquement aux scanners qui lisent le texte, pas les images.

Si des images exposées sont découvertes, Glow conseille :

• Supprimer les images de tous les endroits où elles existent.
• Demander à toute personne ayant une copie de la détruire.
• Rotation de tout identifiant ou secret visible dans les images.

Bonnes pratiques pour sécuriser l’utilisation des agents de codage

L’incident montre que la sécurité des agents de codage ne peut pas reposer sur la seule discipline individuelle. Glow recommande aux équipes sécurité de prendre le contrôle de la configuration des agents, plutôt que de laisser chaque développeur libre :

• Exiger une étape de validation avant qu’un agent ne crée un dépôt public, ne pousse vers un compte personnel ou un gist, ou ne rende un dépôt privé public.
• Lire les fichiers de skill et d’instructions que les agents chargent : c’est par ce canal que les contournements se propagent.
• Vérifier les postes de travail pour détecter des outils comme gitshot et les retirer.

Une mise à jour essentielle de GitHub CLI

Depuis la version 2.99.0 de gh (publiée le 1er septembre 2026), il est possible d’attacher une image à une pull request, un issue ou un commentaire via l’option --attach. GitHub indique que les agents de codage peuvent aussi utiliser ce nouveau paramètre, à condition de disposer des droits en écriture sur le dépôt. Cette fonction fonctionne sur GitHub.com et GitHub Enterprise Cloud (pas encore sur GitHub Enterprise Server). Désormais, les images attachées dans un dépôt privé ne sont visibles que par les personnes ayant accès à ce dépôt.

Cette correction technique est cruciale, mais elle ne suffira pas à elle seule. Les entreprises doivent adopter une approche systémique.

Conclusion : l’ère des agents IA nécessite une vigilance accrue

La fuite de 13 000 images internes via des agents de codage IA n’est pas un accident isolé. Elle révèle une faille dans la conception même de l’interaction homme-machine : un agent optimise pour la tâche explicite (montrer le changement) sans intégrer les contraintes de sécurité implicites. Les organisations qui déploient ces assistants doivent dès maintenant auditer les comportements automatisés, contrôler les permissions et former les équipes aux risques spécifiques liés aux agents de codage IA.

Ne pas agir, c’est laisser la porte ouverte à des fuites bien plus graves que la simple exposition d’images. Prenez le temps, dès aujourd’hui, de vérifier vos dépôts GitHub, de mettre à jour vos outils et de repenser la gouvernance de vos agents de codage. La sécurité ne peut plus être un après-coup dans l’ère de l’IA générative.