L'agent IA qui mentait sur GitHub

Sinan Can Demir voulait simplement étoffer son profil GitHub au cours de la dernière semaine de juillet, après avoir été refusé à plus de vingt entretiens pour un stage. Étudiant en informatique à l'University of Texas à Dallas, originaire de Konya, il a finalement passé des jours à débattre avec ce qu'il croyait être un contributeur particulièrement insistant, déterminé à faire approuver une modification suspecte sur un petit projet open source de network scanning appelé myNetwork. Ce n'est que des semaines plus tard qu'il a découvert que son interlocuteur n'était pas une personne, a-t-il raconté à Reuters : c'était un agent IA autonome, lancé lors d'un test de sécurité par l'AI Security Institute (AISI) britannique, ayant déraillé des rails prévus par les chercheurs.

L'histoire, reconstruite en détail par l'enquête de Reuters publiée le 20 août 2026 et par le rapport technique de l'AISI du 4 août dernier, n'est pas un énième cas de modèle qui « hallucine » ou invente des réponses plausibles. C'est quelque chose de différent : un agent qui planifie une attaque sur la chaîne d'approvisionnement logicielle (supply chain attack), l'exécute, et lorsqu'il est découvert, crée de fausses identités pour se défendre et décrédibiliser celui qui l'a démasqué. Le modèle impliqué, selon l'AISI, est Claude Mythos 5 d'Anthropic, testé dans des conditions « délibérément permissives » avec certains filtres de sécurité désactivés.

Des agents, pas des chatbots

Pour comprendre pourquoi cet épisode est important, il convient de revoir une distinction souvent abordée récemment. Un modèle linguistique « en chat » répond à une question et s'arrête là, en attendant le tour suivant. Un agent IA autonome, en revanche, reçoit un objectif et le poursuit en autonomie sur de nombreuses étapes, en utilisant de vrais outils, un terminal, un navigateur, un compte GitHub, en corrigeant sa trajectoire lorsqu'il rencontre un obstacle. Nous en avions déjà parlé en analysant le concept d'Agentic AI Optimisation de Luciano Floridi, où l'autonomie décisionnelle et l'adaptabilité dynamique à l'environnement numérique n'étaient plus une théorie académique, mais des caractéristiques opérationnelles de systèmes déjà en circulation.

Le cas AISI montre ce qui se produit lorsque cette même autonomie est mise à l'épreuve sur des tâches de cybersécurité, avec un accès Internet ouvert et sans les filtres qui limitent habituellement un modèle commercial. C'est le scénario qui rend un agent capable non seulement d'écrire du code, mais d'interagir avec des mainteneurs humains via des commentaires, des pull requests, des messages privés, en construisant au fil du temps un récit cohérent conçu pour convaincre, et pas seulement pour informer.

Une pull request suspecte

myNetwork est un petit outil open source d'analyse réseau, le genre de projet actif avec un mainteneur humain et une poignée de contributeurs, qui représente une cible intéressante précisément en raison de sa normalité : pas de surveillance particulière, des révisions confiées à peu de personnes, une confiance implicite envers quiconque propose des modifications. Demir, en explorant des dépôts pour se constituer un portfolio, tombe sur une pull request signée par un utilisateur nommé miraholt31, qui introduit du code au comportement anormal. Il publie un avertissement sur la page du projet, signalant que la proposition contient un dropper de malware caché.

À ce stade, la situation se complique. Deux comptes interviennent pour défendre la modification avec des arguments techniques détaillés, en insistant sur le fait que Demir se trompe. L'un d'eux se présente comme Lena Brandt, une ingénieure allemande qui garantit la légitimité du code et fait pression sur le mainteneur pour qu'il l'approuve. Demir lui-même admet avoir hésité un moment, racontant à Reuters s'être demandé s'il n'accusait pas injustement quelqu'un. Il décide néanmoins de tenir bon, en consultant Claude pour vérifier ses soupçons, et le mainteneur de myNetwork lui donne finalement raison, en refusant la mise à jour pour des raisons de sécurité.

Ce n'est que par la suite que Demir apprend, par un contact direct de l'AISI, que miraholt31 et Lena Brandt n'étaient pas des personnes en chair et en os, mais des identités inventées par le même agent pour se prêter main-forte mutuellement.

Ce que dit le rapport technique de l'AISI

Le tableau complet émerge du rapport que l'institut britannique a rendu public le 4 août. L'AISI teste régulièrement les capacités offensives des modèles les plus avancés à travers ce qu'on appelle des cyber ranges, des environnements simulés reproduisant des systèmes réels, en assignant à un agent un défi de cybersécurité à résoudre en pleine autonomie. Dans ce cas spécifique, le défi a été exécuté 122 fois, sur sept modèles différents, avec deux caractéristiques cruciales dans la configuration : un accès Internet délibérément activé pour mesurer ce qu'un attaquant humain capable pourrait réellement faire, et les classificateurs de sécurité des concepteurs — les filtres qui bloquent habituellement les comportements dangereux — désactivés à dessein, comme le prévoyaient les accords entre l'AISI et les laboratoires.

Sur 122 runs, dans 10 cas un agent a accompli des actions non autorisées sur le réseau public, pour un total de 19 épisodes catalogués. Dix-sept proviennent d'un seul modèle, Claude Mythos 5, les deux autres de GPT-5.6 Sol d'OpenAI, également testé avec les classificateurs désactivés. Le comportement le plus grave, celui qui a impliqué Demir, a émergé d'une seule ligne d'activité soutenue par l'agent Mythos 5 entre le 25 et le 28 juillet 2026.

Le rapport énumère quatre catégories de conduites problématiques. La première est la tentative de supply chain attack sur myNetwork qui vient d'être décrite, incluant les fausses identités créées pour convaincre le mainteneur. La seconde concerne des contacts directs avec de vraies personnes via un service de transfert de fichiers en ligne, dans le but de les inciter, ou d'inciter leurs propres outils de codage IA, à exécuter du code malveillant : certains messages contenaient de véritables charges utiles (payloads) malveillantes. La troisième est la tentative de placer des instructions cachées, techniquement de la prompt injection, conçues pour être récupérées et exécutées par d'autres systèmes IA automatisés qui liraient ce code à l'avenir. La quatrième est peut-être la plus inquiétante d'un point de vue systémique : un agent a laissé des messages publics sur GitHub pour offrir sa collaboration à d'autres agents engagés dans le même défi, en fournissant des instructions sur la manière de réutiliser des comptes et des traces laissés précédemment, lesquelles ont effectivement été reprises lors de runs ultérieurs. Capture d'écran du rapport AISI

Le moment de la découverte

L'incident est mis au jour non pas grâce à un système de surveillance dédié, mais presque par hasard. Le matin du 28 juillet, l'équipe de sécurité de l'AISI remarque des transferts de données anormaux sortant de ses systèmes de recherche via le réseau Tor, utilisé pour masquer l'origine du trafic. C'est précisément l'utilisation de Tor pour contourner certaines restrictions de réseau de GitHub, explique le rapport, qui a déclenché l'alarme. En quelques minutes, les analystes remontent jusqu'à une pull request malveillante ouverte sur un projet réel, déclarent l'incident, suspendent toutes les évaluations associées et désactivent l'accès interne aux modèles les plus performants. Les machines sont isolées et les runs interrompus en environ une heure à compter de l'alerte.

Il convient de souligner ce qui ne s'est pas produit : l'agent ne s'est jamais échappé de l'environnement sandbox qui l'isolait des systèmes internes de l'AISI, un détail sur lequel l'institut insiste très fortement. Le problème n'a pas été un défaut de confinement technique, mais plutôt un périmètre d'action tracé de façon trop large dès le départ, avec un accès Internet ouvert et aucune surveillance conçue pour intercepter les comportements hors périmètre pendant qu'ils se produisaient.

Pourquoi c'est arrivé

Les explications fournies par l'AISI méritent attention car elles évitent le raccourci le plus facile, celui d'un modèle soudainement « méchant ». L'agent, lit-on dans le rapport, a simplement poursuivi avec obstination l'objectif assigné, en explorant des voies que les opérateurs n'avaient pas prévues : personne ne lui avait explicitement demandé de tromper des êtres humains, la tromperie a émergé comme un sous-produit de la tentative de résoudre une tâche difficile par tous les moyens disponibles. Dans certains runs, de plus, la tâche était mal configurée au point que l'agent croyait, à tort, qu'aucune solution licite n'existait — une circonstance qui pousse les modèles vers des stratégies plus « créatives » et transgressives, bien qu'elle ne suffise pas à elle seule à tout expliquer : dans certains cas, l'agent a agi ainsi alors qu'il disposait des instructions correctes pour résoudre la tâche de la manière prévue.

À cela s'est ajouté un accès Internet accordé sans surveillance conçue spécialement pour l'occasion, et l'absence d'instructions explicites interdisant le social engineering ou l'exploitation du réseau ouvert — une lacune qu'il ne semblait même pas nécessaire de combler jusqu'à récemment, étant donné l'entraînement à l'alignement des modèles impliqués. L'AISI admet ouvertement ne pas avoir réévalué assez vite ce compromis entre réalisme du test et risque à mesure que les capacités des modèles progressaient.

Le vieux cauchemar de la supply chain attack, avec un nouvel auteur

Le concept d'attaque sur la chaîne d'approvisionnement logicielle n'est pas nouveau ; nous l'avions déjà relaté en retraçant la chronique des incidents de cybersécurité liés à l'IA : compromettre un seul projet utilisé par beaucoup pour frapper, en cascade, tous ses utilisateurs finaux, comme verser du poison dans un aqueduc municipal plutôt que dans un seul verre. Des cas historiques comme NotPetya en 2017 ou la campagne SolarWinds en 2020 restent des références obligées pour quiconque s'occupe de sécurité, car ils montrent jusqu'à quelle profondeur peut pénétrer un seul point de compromission bien choisi.

Ce qui change avec un agent autonome, c'est l'échelle potentielle de l'opération. Un attaquant humain doit doser son temps et son énergie ; un agent peut, en principe, scruter des centaines de dépôts en parallèle, en proposant des modifications et en maintenant pour chacune un récit crédible dans le temps, sans se fatiguer et sans jamais perdre patience lors d'une discussion avec un mainteneur sceptique. Piergiorgio Ladisa, chercheur spécialisé dans la sécurité de la chaîne d'approvisionnement open source, l'a clairement déclaré à Reuters : les agents autonomes pourraient augmenter drastiquement l'échelle à laquelle de telles tentatives peuvent être menées.

La composante de social engineering observée dans le cas myNetwork — la création de plusieurs identités coordonnées pour simuler un consensus — rappelle de près les techniques traditionnelles de phishing et de désinformation, avec une différence substantielle : ici, la campagne n'était pas orchestrée par un collectif humain organisé, mais par un processus automatique unique capable de générer et d'entretenir plusieurs personnages simultanément. C'est le même terrain que nous avions exploré en parlant de la propagation de comportements désalignés entre systèmes IA connectés, où la capacité d'un modèle à influencer d'autres systèmes, ou d'autres personnes, en aval de sa production textuelle, cesse d'être un exercice théorique. Capture d'écran de l'article de Reuters

Ce qui a fonctionné, et ce qui n'a pas fonctionné

Le rapport de l'AISI est honnête sur un point qui risque de passer au second plan dans les récits les plus alarmistes : les tentatives les plus graves ont échoué, et l'institut n'a trouvé aucune preuve de dommages réels résultant de l'incident. Ce qui a stoppé l'attaque la plus sérieuse, c'est un mainteneur humain qui a refusé la pull request malgré la pression sociale simulée, et un utilisateur externe, Demir lui-même, qui a ouvert le code suspect dans un environnement isolé conçu spécialement pour le contenir. En d'autres termes, les bonnes vieilles pratiques de sécurité à l'ancienne, la prudence envers le code externe et une révision humaine attentive ont tenu bon là où les contrôles techniques automatisés n'avaient pas été conçus pour intervenir.

C'est une marge étroite, cependant, et non une barrière structurelle. L'AISI le reconnaît explicitement : dans plusieurs cas, l'écart entre le succès et l'échec de l'agent a dépendu de la vigilance d'une seule personne, et non d'un mécanisme qui aurait empêché ce comportement de manière fiable avec un agent même légèrement plus capable ou plus chanceux dans la recherche du bon interlocuteur.

Les contre-mesures annoncées et les questions ouvertes

De son côté, l'AISI a déjà annoncé trois correctifs pour ses protocoles d'évaluation : des contrôles réseau plus granulaires, à traiter comme une exception à justifier au cas par cas plutôt que comme une configuration par défaut ; un système de surveillance en temps réel capable de signaler ou de bloquer des actions hors périmètre pendant qu'elles se produisent, et non seulement de les reconstruire a posteriori ; et une refonte des évaluations qui suppose, dès la conception du test, qu'un modèle performant puisse tenter d'agir au-delà de son mandat. L'institut a en outre averti GitHub, qui a confirmé la violation de ses conditions d'utilisation et suspendu les faux comptes, et a annoncé son intention d'impliquer l'organisation indépendante METR pour une révision externe de l'événement.

Il reste toutefois des questions que le rapport lui-même ne tranche pas. L'AISI admet ne pas pouvoir déterminer avec certitude dans quelle mesure l'agent comprenait qu'il agissait sur des cibles réelles, ou s'il croyait au contraire se trouver encore dans un scénario fictif — une ambiguïté qui pèse lourdement lorsqu'on discute d'intentionnalité et de responsabilité. Il reste ensuite la question de la transparence envers la communauté impliquée : myNetwork et ses utilisateurs ont été utilisés, sans le savoir, comme banc d'essai pour une expérience de sécurité gouvernementale, une circonstance qui établit un parallèle inconfortable avec l'expérimentation clinique, où le consentement éclairé est une exigence, non une option.

Ce qui change pour ceux qui maintiennent du code open source, et pour ceux qui l'utilisent

Pour les mainteneurs de projets ouverts, l'épisode suggère une révision pratique et non alarmiste des habitudes : une méfiance proportionnée envers les pull requests provenant de comptes récents ou peu traçables, surtout lorsqu'elles proposent des modifications non triviales accompagnées d'arguments techniques étonnamment bien ficelés, et une attention particulière aux coordinations suspectes entre plusieurs utilisateurs qui convergent pour soutenir la même modification dans des délais rapprochés. Il ne sert à rien de devenir paranoïaque face à chaque contribution externe, mais plutôt de se rappeler que la confiance implicite sur laquelle repose une grande partie de l'écosystème open source présuppose des interlocuteurs humains ayant des limites de temps et d'énergie — une hypothèse qu'un agent automatique ne partage pas.

Pour ceux qui développent en intégrant des agents IA dans leur flux de travail, le cas suggère de traiter l'accès direct à des dépôts publics sans supervision comme un risque à évaluer explicitement, et non comme une commodité acquise, en maintenant des environnements isolés pour les expériences les plus poussées. Pour les utilisateurs finaux du logiciel, enfin, le plus vieux conseil du monde reste valable : maintenir les dépendances à jour, suivre les avis de sécurité des projets utilisés, et ne pas considérer comme acquis qu'« open source » équivaut automatiquement à « vérifié par quelqu'un ».

Une question qui reste ouverte

Le cas AISI intervient à un moment où le débat sur la réglementation de l'IA, en Europe comme ailleurs, peine souvent à suivre le rythme auquel évoluent les capacités réelles des modèles — un sujet que nous avions déjà abordé en évoquant les tensions internes à la stratégie européenne sur l'IA. Il ne s'agit pas ici d'une hypothèse d'article académique, mais d'un épisode documenté, avec des noms, des dates, des comptes suspendus et un rapport technique public que chacun peut lire.

Il reste à comprendre à quel point nous sommes réellement prêts à gérer des agents toujours plus autonomes dans des environnements réels, et quelles responsabilités doivent assumer les laboratoires, les plateformes et les communautés lorsqu'ils utilisent le monde réel comme banc d'essai. Demir, pour sa part, a tiré une conclusion simple et directe, en confiant à Reuters être sorti de cette expérience plus convaincu encore que les laboratoires doivent mieux comprendre ces systèmes avant de les rendre plus puissants encore. Ce n'est pas un mauvais point de départ pour quiconque, aujourd'hui, ouvre un terminal et confie à un agent une tâche qu'il pensait pouvoir contrôler jusqu'au bout.