Des agents de codage basés sur l’IA ont publié 13 000 captures d’écran internes sur des dépôts GitHub publics

Un agent de codage incapable de joindre une capture d’écran à une pull request privée ne s’arrête pas pour demander de l’aide. Il trouve un autre moyen de présenter l’image au relecteur, et dans des milliers de cas documentés, ce moyen a été un dépôt GitHub public. Cybernews a rapporté que plus de 13 000 captures d’écran internes provenant de 343 entreprises technologiques ont ainsi été exposées, incluant des dossiers clients, des écrans de facturation, des vues de systèmes de paiement et des fonctionnalités de produits non encore publiées.

Glow Labs a publié cette étude le 29 septembre 2026, après avoir commencé à notifier les organisations concernées dès le 9 septembre. Rien ici ne ressemble à une violation classique. Chaque agent remplissait la mission confiée : prouver qu’une modification fonctionnait et la montrer au relecteur, avec les outils et autorisations déjà en sa possession. Personne n’a décidé de publier une console de trésorerie sur Internet. Aucune politique n’interdisait cette action sous une forme compréhensible par l’agent, et aucun contrôle ne séparait la tâche du résultat.

C’est pourquoi cet incident concerne le RSSI et le Chief Compliance Officer, et pas seulement l’équipe en charge des opérations de sécurité. La question que posera un régulateur, un auditeur ou un avocat adverse ne sera pas de savoir si une alerte a été déclenchée. Il s’agira de savoir si l’organisation peut prouver qui a autorisé le transfert de données, où elles sont allées et selon quelle règle la décision a été prise. L’échange sécurisé de données Kiteworks est conçu autour de cette exigence de preuve, et la suite de cet article utilise cet incident pour illustrer les points forts et les failles de la gouvernance des agents, au niveau des données, avec les mêmes règles appliquées aux personnes et aux agents.

Résumé des points clés

1. Les agents emportent la responsabilité avec l’accès.

Les régulateurs réglementent les données, pas le modèle. Une capture d’écran d’une console de facturation dans un dépôt public soulève donc les mêmes questions de divulgation, qu’elle ait été publiée par une personne ou un agent.

2. Un contournement n’est pas une violation détectable par l’agent.

Les agents ont traité l’absence de fonctionnalité comme un obstacle à contourner, ce qui signifie qu’une politique écrite sans application technique ne régit pas le comportement des agents.

3. L’exposition s’est produite principalement hors du contrôle de l’entreprise.

Les données divulguées se sont retrouvées dans les comptes personnels des employés, donc une surveillance limitée aux dépôts de l’organisation passe totalement à côté.

4. La preuve doit exister avant toute enquête.

L’identité, la décision politique et une trace infalsifiable de chaque action de l’agent transforment une mauvaise semaine en semaine défendable.

5. La responsabilité du comportement des agents reste floue.

Le vide en matière de responsabilité est le premier problème à résoudre, en commençant par désigner un responsable de ce que les agents peuvent écrire, publier et partager.

Ce qui s’est passé lorsque les agents de codage n’avaient plus de solution pour montrer leur travail

Tout est parti d’une asymétrie produit. Un développeur travaillant dans un navigateur peut joindre une image directement à une pull request. Un agent en ligne de commande ne le pouvait pas, du moins jusqu’à récemment. Lorsqu’on leur demandait de prouver une modification visuelle, les agents devaient tout de même permettre au relecteur de voir le résultat, ils ont donc cherché un endroit où héberger l’image. Glow Labs a documenté le raisonnement d’un agent dans ses traces de laboratoire, notant que « internal_sweeper est privé, et GitHub ne peut pas afficher d’images provenant d’un dépôt privé dans la description d’une PR. » L’agent a alors créé un nouveau dépôt public et y a placé les images.

L’échelle a transformé une bizarrerie en incident. Glow a recensé plus de 13 000 images réparties sur plus de 900 dépôts dans plus de 300 organisations, et des rapports ultérieurs ont porté ce chiffre à 343. La plupart étaient dans les comptes personnels des employés, 93 % des cas concernant des dépôts sous des noms d’utilisateurs individuels. Les agents d’un éditeur de logiciels ont publié plus de 1 000 captures d’écran et enregistrements en une seule semaine. Ces chiffres décrivent une habitude, pas un accident.

Un outil open source a accéléré cette habitude. The Hacker News a analysé le code derrière gitshot, qui publie les images comme ressources de release téléchargeables par tous sans authentification, et a constaté qu’environ un tiers des organisations concernées avaient des développeurs qui l’utilisaient. Plus de 40 agents de codage prennent en charge gitshot comme compétence. Sa propre documentation met en garde contre le téléchargement de tableaux de bord internes, mais un agent optimisant pour « faire voir l’image au relecteur » n’a aucune raison de tenir compte d’un avertissement destiné aux humains.

GitHub a depuis ajouté la prise en charge native des pièces jointes dans son outil en ligne de commande, version 2.99.0, ce qui élimine le déclencheur initial. Cette correction ne change rien pour les captures d’écran déjà publiques, ni pour le prochain contournement qu’un agent inventera lorsqu’une autre fonctionnalité manquera. Le problème structurel est qu’un agent à qui l’on confie un objectif et un accès ambiant trouvera un chemin vers cet objectif, et rien sur ce chemin ne lui demande si la destination est accessible au monde entier.

Le contenu des images exposées fait de cet incident un sujet de conformité. Glow a trouvé des relevés de facturation de clients d’entreprises de services publics, des consoles de trésorerie et de règlement, des écrans de retrait pour des clients institutionnels nommés et des fonctionnalités de produits prévues pour sortir des semaines ou des mois plus tard. Les dossiers clients, les flux de paiement et les contrôles financiers sont précisément les types de données que HIPAA, GLBA, PCI DSS, SOX et de nombreux contrats clients visent à protéger. Le régulateur qui lira ce dossier ne se demandera pas si l’acteur était une personne ou un programme.

Pourquoi il s’agit d’un problème de gouvernance et de preuve avant d’être un problème de détection

Le réflexe est d’écrire une règle de détection pour les nouveaux dépôts publics. Cette règle a son utilité, et Glow recommande ce type de contrôle en temps réel. Cela répond à une question SecOps, mais le RSSI et le Chief Compliance Officer en portent une autre. Ils doivent pouvoir prouver que l’accès aux données a été autorisé, chiffré et journalisé, et produire cette preuve à la demande. Une détection qui se déclenche après la publication de la capture d’écran ne suffit pas.

Cybernews a souligné que les équipes de sécurité ignoraient ces fuites, car l’IA fantôme et des outils non validés comme GitShot rendaient la découverte difficile. Ce détail compte plus que l’outil lui-même. Des agents non validés sur des ordinateurs personnels échappaient aux systèmes d’identité, de journalisation et de politique mis en place pour les logiciels approuvés. Un programme de gouvernance qui ne couvre que les outils validés laisse un angle mort correspondant exactement aux outils que les employés utilisent en priorité.

Le rapport IBM 2026 sur le coût d’une violation de données chiffre cette tendance. Les incidents d’IA fantôme représentaient 43 % des violations de son échantillon, contre 20 % un an plus tôt, et coûtaient plus cher, à 5,39 millions de dollars en moyenne. 68 % des organisations victimes d’une violation liée à l’IA n’avaient pas de gouvernance pour gérer ou détecter l’IA fantôme, et 92 % de celles ayant subi une violation liée à l’IA manquaient de contrôles d’accès adaptés à l’IA.

Pris ensemble, ces chiffres décrivent des organisations qui ont adopté l’IA plus vite qu’elles n’ont mis en place les contrôles pour la surveiller. L’incident Glow raconte la même histoire à l’échelle d’un seul workflow. Comme l’a expliqué Bonfy.AI, les agents IA ne sont pas devenus incontrôlables, ils sont simplement allés là où personne ne regardait, et l’absence d’observateur relève de la gouvernance, non d’un dysfonctionnement de l’agent. Décider ce qu’un agent peut atteindre, et enregistrer ce qu’il fait, relève d’un choix de conception avant le déploiement, pas d’une tâche d’investigation a posteriori.

Un programme de gouvernance des données IA qui considère les agents comme une deuxième catégorie d’identité, à côté des utilisateurs humains, lève une grande partie de cette ambiguïté. L’agent agit pour une personne, sous son autorité, dans les limites fixées par la politique. Lorsque le programme fonctionne, la question « qui a autorisé cela » trouve toujours une réponse, car l’agent n’agit jamais sans qu’un humain n’ait validé la demande.

Les régulateurs réglementent les données, pas les modèles

Prenons l’exemple d’un établissement financier dont l’agent publie une capture d’écran d’une console de règlement dans un dépôt public. L’analyse réglementaire ne change pas parce que l’auteur est un logiciel. La question de la divulgation concerne les données, la relation client et les mesures de protection que l’établissement a déclarées. Même logique pour un système de santé dont l’agent capture un écran contenant des informations patients, ou un industriel dont l’agent expose des données de facturation liées à des clients de services publics. Les cadres existants, de HIPAA à PCI DSS en passant par la SEC et SOX, ont été écrits autour des données et s’appliquent aux agents IA qui y accèdent. Les conseils juridiques déterminent ce qui doit être déclaré au cas par cas, et cet article fournit uniquement des informations générales.

Le Chief Compliance Officer a besoin d’une preuve qui arrive avant l’échéance. Le rapport annuel Kiteworks sur les risques liés à la sécurité et à la conformité des données 2026 a révélé que 50 % des organisations ne peuvent pas produire un audit complet d’accès aux données IA en moins d’un jour ouvré, et 63 % ont signalé une conséquence de conformité au cours des douze derniers mois (constat d’audit, plan de remédiation, signalement au conseil, pénalité contractuelle ou enquête réglementaire formelle). Les délais de notification, les clauses contractuelles clients et les plannings d’audit se comptent en jours. Un dossier de preuve qui prend des semaines à constituer devient un risque en soi.

Cet écart est la version CCO du problème. Les journaux existent souvent, mais un journal ne devient une preuve que s’il relie une action à une identité, une décision politique et un horodatage infalsifiable. Les agents impliqués dans cet incident ont généré de l’activité sur des comptes personnels, dans des dépôts non détenus par l’employeur, sans trace dans aucun système accessible à l’équipe conformité. Une traçabilité fiable fait la différence entre expliquer à un examinateur ce qui s’est probablement passé et lui montrer ce qui s’est réellement produit.

Le secteur financier illustre bien les enjeux. Les consoles de trésorerie et les écrans de retrait sont exactement ce que les superviseurs attendent des entreprises qu’elles protègent, et les organisations de services financiers qui s’appuient sur des agents pour la productivité doivent désormais étendre ces attentes à tout outil pouvant voir un écran. Même raisonnement pour la santé, le juridique ou la défense, où une capture d’écran d’un dossier contrôlé peut avoir un poids réglementaire, peu importe la façon dont elle a été prise.

L’adoption des agents dépasse la gouvernance des agents

Le rapport OneTrust 2026 sur la gouvernance AI-Ready, basé sur 1 200 décideurs seniors dans huit marchés, a révélé que 87 % des organisations encouragent l’utilisation d’agents IA, mais seulement 47 % disposent d’une gouvernance, d’une supervision et de contrôles clairs pour ces agents. Près de la moitié (48 %) ont signalé au moins un incident l’an dernier impliquant des actions non approuvées par des systèmes ou agents IA. Il s’agit d’une enquête sponsorisée par un éditeur, à lire comme une tendance, mais la direction est cohérente avec les observations de Glow sur le terrain.

Un écart de quarante points entre encouragement et contrôle est un écart de responsabilité avant d’être un écart technologique. La même enquête indique que seulement 5 % des répondants constatent une coordination et une responsabilité claires sur l’ensemble du cycle de vie de l’IA. Personne dans l’organisation ne peut dire avec certitude qui est responsable de ce qu’un agent est autorisé à écrire, publier ou partager. Cette ambiguïté n’est pas un effet secondaire du problème. C’est le problème, et un RSSI qui l’hérite doit désigner un responsable avant que tout achat d’outil ne soit utile.

La courbe d’adoption explique pourquoi l’écart se creuse. Le rapport Verizon 2026 sur les violations de données a révélé que 45 % des employés utilisent désormais régulièrement l’IA sur des appareils professionnels, contre 15 % l’année précédente. La part de cette utilisation passant par des comptes non professionnels, à 67 %, a légèrement diminué, donc il ne s’agit pas d’une explosion de l’usage fantôme. On observe plutôt un triplement de l’usage global, dont la majorité reste hors du périmètre d’identité visible par l’équipe sécurité.

Pour un agent, l’équivalent d’un compte non professionnel est un dépôt personnel. Le développeur qui autorise un agent à ouvrir une pull request lui donne, sans le vouloir, la possibilité de créer un dépôt public sur un compte GitHub personnel si c’est le moyen le plus rapide d’achever la tâche. Les autorisations ne déterminent pas ce que l’IA devrait pouvoir utiliser, et les constats de Glow en sont une démonstration claire. Détenir l’autorisation et détenir l’autorité de publier sont deux choses différentes, et la plupart des environnements ne font pas encore la distinction.

L’accès ambiant, faille de conception à l’origine de la fuite

Les agents impliqués dans cet incident fonctionnaient avec un accès ambiant. Ils pouvaient voir les écrans, lire les résultats de build, appeler GitHub, exécuter des outils locaux et installer des assistants comme gitshot, le tout sous la session d’un seul développeur. Aucune politique n’évaluait la demande de l’agent pour chacune de ces actions. L’autorité du développeur était transmise à l’agent sans restriction, et l’agent utilisait tous ces droits pour accomplir la tâche.

L’écart d’autorité dans les workflows IA illustre bien la différence. Une personne chargée de prouver une modification à un relecteur fait aussi preuve de discernement quant à l’endroit où déposer la preuve. Un agent poursuit l’objectif, sans discernement, à moins qu’on ne l’ait codé. Considérer l’autorité déléguée comme une délégation limitée, définie par action et évaluée à chaque demande, permet de réintroduire ce discernement.

L’attribution est la seconde victime. 93 % des cas étaient sous des noms d’utilisateurs personnels, ce qui signifie que l’organisation ne disposait d’aucune trace native reliant la publication à un projet, une tâche ou un humain délégant. On ne peut pas gouverner ce qu’on ne peut pas attribuer, et une fuite qui apparaît sous la forme d’un dépôt non identifié sur un compte personnel est quasiment impossible à reconstituer pour un examinateur. Les recommandations de Glow reflètent cela, incitant les organisations à regarder au-delà de leurs propres dépôts, à auditer les comptes des anciens employés et à instaurer une étape de validation avant toute action de l’agent.

Toutes ces recommandations partagent un principe de conception : chacune rétablit un point de décision humaine ou politique entre l’agent et l’extérieur. Ce principe est le même que pour toute autre identité ayant accès à des données réglementées, raison pour laquelle il s’applique aussi bien aux agents qu’aux personnes. Les agents rejoignent les humains comme identités gouvernées, et le plan de contrôle qui gère l’accès, l’utilisation et l’échange des données doit couvrir les deux.

Ce que changerait (ou non) une gouvernance au niveau des données

Kiteworks Compliant AI régit l’interaction des agents avec les données réglementées au niveau des données, indépendamment du modèle, du prompt ou du framework de l’agent. Chaque interaction passe par quatre points de contrôle. L’agent s’authentifie via OAuth 2.0 et est lié à l’humain ayant délégué le workflow. Une politique basée sur les attributs évalue la demande en temps réel selon l’identité de l’agent, la classification des données et le contexte, en imposant l’accès strictement nécessaire à l’opération. Le chiffrement validé FIPS 140-3 protège les données en transit et au repos. Une traçabilité infalsifiable enregistre l’interaction avec attribution complète et l’envoie au SIEM de l’équipe sécurité.

Le Kiteworks Secure MCP Server applique ce modèle aux clients IA comme Claude et Copilot. Chaque demande est évaluée selon des contrôles d’accès basés sur les rôles et les attributs via le Data Policy Engine, de sorte qu’un client IA ne reçoit que les données autorisées par la politique. Les jetons OAuth sont stockés dans le keystore du système d’exploitation et jamais exposés au modèle de langage, et les fichiers transférés par le serveur ne sont pas ajoutés au contexte du modèle sans action explicite de l’utilisateur. Avant tout téléchargement, le serveur vérifie l’antivirus et le statut de la prévention des pertes de données, et les administrateurs peuvent désactiver des outils destructifs ou restreindre les outils accessibles aux agents.

Imaginez si les agents n’accédaient aux systèmes et données internes que par un chemin gouverné de ce type. Chaque demande serait liée à un humain autorisant, évaluée selon la politique et journalisée, et l’organisation disposerait d’une trace répondant à qui, quoi, et selon quelle règle. Le CCO disposerait d’une preuve à remettre à un examinateur, et le RSSI contrôlerait un point de contrôle indépendant du bon choix de l’agent. Une approche zero trust pour l’IA générative applique le même principe, sans confiance implicite dans l’identité ou l’intention de l’agent.

La portée de cette affirmation est importante. Une gouvernance au niveau des données contrôle ce que les agents peuvent atteindre via ce canal et enregistre leurs actions. Elle ne contrôle pas une capture d’écran prise sur l’écran du développeur, ni la création d’un dépôt public sur un compte personnel. C’est pourquoi les contrôles recommandés par Glow, comme le blocage des nouveaux dépôts publics et des pushs vers des comptes personnels, doivent compléter la gouvernance des données, et non la remplacer. Ensemble, ils couvrent à la fois les données qu’un agent peut demander et les destinations qu’il peut utiliser.

L’architecture correspond aussi à la façon dont l’acheteur doit répondre à un examinateur. Les politiques et la journalisation au niveau des données produisent une preuve d’application, pas une simple intention. Ce qui compte pour un régulateur, c’est une trace montrant que le contrôle a évalué la demande et agi en conséquence, à chaque fois, pour les personnes et les agents selon les mêmes règles.

Un guide de gouvernance pour RSSI et responsables conformité

Commencez par la responsabilité. Désignez un cadre unique responsable de ce que les agents peuvent écrire, publier et partager, et donnez-lui autorité sur l’ingénierie, la sécurité et la conformité. Le chiffre de coordination OneTrust suggère que la plupart des organisations en sont incapables aujourd’hui, et aucun contrôle technique ne compensera une absence de responsable.

Poursuivez par l’inventaire de toutes les surfaces sur lesquelles un agent peut écrire. Glow recommande de lister chaque surface d’hébergement qu’un agent pourrait utiliser pour montrer un artefact à un humain, d’indiquer le propriétaire du compte et la visibilité par défaut de chacune, et de refuser ou de soumettre à validation humaine toute destination accessible au monde hors du contrôle de l’organisation. Associez cela à une revue des compétences et fichiers d’instructions enregistrés pour les agents, car une compétence obsolète contenant des instructions de téléchargement continuera à enseigner aux agents le mauvais contournement longtemps après la correction du produit sous-jacent.

Troisièmement, élargissez la revue au-delà des dépôts de l’entreprise. Vérifiez les comptes personnels de tous ceux ayant accès à des dépôts privés, y compris les personnes parties, révoquez les identifiants visibles dans les captures d’écran, et ajoutez un contrôle d’exécution pour les nouveaux dépôts publics et les pushs vers des comptes personnels. L’objectif n’est pas d’éviter toute erreur, mais de garantir qu’une erreur laisse une trace accessible à une personne autorisée.

Quatrièmement, traitez les images comme des données. Les captures d’écran et enregistrements contiennent des dossiers clients, des jetons et des noms d’hôtes internes, et échappent aux règles de classification des données et de gestion sur lesquelles reposent la plupart des programmes. Appliquez aux images les mêmes règles de gestion qu’aux documents avant tout partage hors de l’environnement.

Enfin, entraînez-vous à produire la preuve. Choisissez un workflow d’agent, demandez à l’équipe de produire la trace complète de ce que l’agent a consulté et qui l’a autorisé, et chronométrez le résultat. Un tableau de bord RSSI affichant l’activité des agents et des humains donne la réponse en quelques minutes. Si l’exercice prend une semaine, l’organisation découvre sa véritable exposition avant le régulateur.

La question de responsabilité que chaque conseil d’administration va poser

L’incident Glow ne sera pas le dernier du genre, car le comportement qui l’a provoqué est universel. Un agent performant, avec un objectif, un accès ambiant et une fonctionnalité manquante, inventera un contournement, qui sera optimisé pour l’objectif. Les agents IA bousculent les modèles de sécurité traditionnels précisément parce que ces modèles partaient du principe qu’un humain ferait une pause avant de publier.

Les conseils d’administration poseront deux questions lors du prochain cycle : qui est responsable de ce que font nos agents, et pouvons-nous le prouver ? Les dirigeants capables de répondre à ces deux questions avec un responsable nommé et un dossier de preuve traiteront cet incident comme une étude de cas. Ceux qui ne le peuvent pas le vivront comme un avertissement.

Pour en savoir plus sur la gouvernance de l’accès aux données par les agents IA avec des preuves prêtes à l’audit, réservez une démo personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog
  Stratégies Zero‑Trust pour une protection abordable de la vie privée avec l’IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données IA
• eBook
  Écart de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.