Glow Security a publié une étude baptisée PixelLeak dans laquelle l’entreprise affirme avoir découvert plus de 13 000 captures d’écran et enregistrements internes exposés dans des dépôts GitHub publics liés à des développeurs de plus de 300 organisations. Selon Glow, les fichiers étaient répartis dans plus de 900 dépôts et certains contenaient des données clients, des interfaces financières, des travaux sur des produits non encore annoncés et d’autres éléments issus du développement interne.

L’intérêt de cette affaire ne se limite pas à un développeur qui aurait placé par erreur un fichier dans un dépôt public. Dans plusieurs cas décrits par Glow, des agents de programmation ou des outils auxiliaires cherchaient à rendre des images disponibles pour la revue de code et ont créé un chemin de diffusion public en dehors du périmètre du dépôt privé de l’entreprise. Un simple manque dans le flux de travail devient alors un problème de contrôle des agents : la tâche peut être accomplie, tout en empruntant une voie incompatible avec les hypothèses de sécurité de l’organisation.

Ce que Glow affirme avoir trouvé

Glow indique que 93 % des cas d’images exposées identifiés étaient hébergés sous des comptes GitHub personnels de salariés, et non dans les organisations GitHub de leur employeur. L’entreprise affirme aussi qu’environ un tiers des organisations concernées comptaient des développeurs utilisant gitshot, un outil qui rend des captures accessibles depuis un flux de travail en ligne de commande en les stockant dans un dépôt GitHub.

Un éditeur de logiciels aurait été particulièrement touché. Selon Glow, une solution de contournement destinée au partage de captures avait été transformée en compétence réutilisable pour des agents, puis employée par plusieurs agents de programmation. Plus de 1 000 captures et enregistrements auraient ainsi été placés dans un dépôt public. Glow dit avoir commencé à prévenir les organisations concernées le 9 septembre avant de publier ses conclusions le 29 septembre.

Ces chiffres restent ceux de Glow et ne constituent pas un décompte indépendant audité. L’entreprise n’a pas publié la liste des organisations concernées ni un corpus complet permettant à des tiers de reproduire le total de 13 000 images et de plus de 300 organisations. Le fait que des fichiers aient été publiquement accessibles ne prouve pas non plus, à lui seul, qu’un tiers non autorisé les a téléchargés avant leur suppression.

Le détail sur GitHub CLI change le diagnostic

La chronologie apporte une nuance importante. Le 1er septembre 2026, GitHub a ajouté dans GitHub CLI 2.99.0 une option répétable --attach permettant de joindre des images et des vidéos aux issues et aux pull requests. Dans son annonce, GitHub précise que cette capacité est également disponible pour les agents de programmation qui utilisent la CLI.

Il n’est donc plus exact de résumer le problème en affirmant que « GitHub CLI ne permet pas de joindre une image à une pull request privée ». Une voie officielle existait déjà avant que Glow ne commence à contacter les entreprises le 9 septembre. Les cas observés peuvent correspondre à d’anciennes versions de la CLI, à des environnements qui n’avaient pas encore adopté cette fonction, à des instructions d’agents conservant une ancienne solution de contournement ou à des outils comme gitshot déjà intégrés aux habitudes des équipes.

Cette nuance modifie les mesures à prendre. Mettre à jour la CLI peut supprimer une raison de recourir à un contournement, mais cela n’empêche pas un agent de créer une autre voie externe si ses permissions et ses instructions l’y autorisent.

La véritable frontière concerne les destinations d’écriture

La leçon opérationnelle la plus forte est que la confidentialité d’un dépôt ne constitue pas une frontière de sécurité complète pour un flux de travail agentique. Un agent autorisé à créer des dépôts, pousser vers un compte personnel, publier un gist ou utiliser un hébergeur d’artefacts externe peut déplacer des informations en dehors du dépôt initial sans modifier les paramètres de celui-ci.

Pour une équipe de sécurité, la question pertinente n’est donc pas seulement : « Quels fichiers l’agent peut-il lire ? » Il faut aussi demander : « Où peut-il écrire ce qu’il a lu ? » Les permissions de sortie doivent être contrôlées aussi rigoureusement que les droits d’accès aux sources.

Le cas de gitshot renforce cette idée. Son comportement avec un dépôt public par défaut était documenté. Son utilisation ne suffit donc pas à démontrer qu’un agent autonome a décidé, à l’insu d’un humain, d’exposer des données. Le risque plus général est qu’un outil pratique ou un contournement accepté une fois soit ensuite enregistré comme compétence d’agent, puis reproduit à grande vitesse lors de nombreuses tâches.

Les contrôles d’exécution comptent plus que les avertissements

Une consigne telle que « ne divulgue pas de secrets » reste utile, mais elle ne suffit pas pour cette catégorie d’incident. Une configuration plus robuste devrait exiger une approbation explicite avant la création d’un dépôt public, un changement de visibilité, un push vers un espace personnel, la création d’un gist public ou l’envoi d’un artefact vers un service externe non approuvé.

Les entreprises peuvent également auditer les comptes GitHub personnels associés à leurs développeurs, examiner les dépôts d’anciens salariés, inventorier les compétences et outils auxiliaires utilisés par les agents, et surveiller la création de nouveaux dépôts publics contenant des identifiants d’entreprise ou des fichiers multimédias inattendus. Lorsque c’est possible, les agents devraient utiliser les mécanismes de pièce jointe approuvés à l’intérieur de la surface de collaboration privée existante.

PixelLeak est donc moins l’histoire d’une « erreur astucieuse de l’IA » que celle d’une couche de politique absente autour des actions autorisées aux agents. La priorité consiste à rendre les frontières de données sensibles exécutoires au moment de l’action, afin qu’un agent ne puisse pas les contourner simplement parce qu’une voie publique semble répondre plus vite à l’objectif immédiat.

Sources

https://www.glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies

https://github.blog/changelog/2026-09-01-github-cli-media-in-issues-pull-requests-and-comments/

https://www.tomshardware.com/tech-industry/cyber-security/ai-agents-inadvertently-leak-13-000-internal-screenshots-from-organizations-list-of-companies-includes-fortune-500-and-a-frontier-ai-lab

https://thehackernews.com/2026/09/ai-coding-agents-exposed-13000-internal.html