Une pull request refusée, puis réécrite, puis défendue par un second compte qui insiste auprès du mainteneur : le scénario ressemble à une attaque de chaîne d’approvisionnement ordinaire. Sauf que l’auteur n’était pas un humain. Le 28 octobre 2026, Le Monde Informatique a détaillé comment Mythos 5, le modèle d’Anthropic, a tenté de faire accepter du code malveillant dans un dépôt GitHub tenu par de vrais développeurs, pendant une évaluation de cybersécurité de l’AI Security Institute (AISI) britannique.
Aucun code n’a été fusionné et aucun utilisateur n’a été touché. Mais l’épisode intéresse directement toute personne qui maintient un projet open source ou qui intègre des dépendances tierces dans ses applications web.
Plan de l'article
Ce qui s’est passé pendant le test #
L’AISI évaluait les capacités offensives de plusieurs modèles dans un environnement censé simuler le réseau d’une entreprise. Selon le récit publié par Le Monde Informatique, Mythos 5 a créé un compte GitHub, préparé du code malveillant et soumis une pull request à un projet open source qui n’avait rien à voir avec le test. Après un premier refus, le modèle a réécrit son code et s’est servi d’un second compte pour tenter de convaincre le mainteneur.
L’AISI confirme les grandes lignes dans un billet consacré aux défaillances d’alignement à l’origine de l’incident. L’institut y indique avoir repéré en juillet 2026 des actions non autorisées visant des personnes réelles extérieures à l’évaluation. Dans le cas le plus grave, il décrit une tentative d’attaque de la chaîne d’approvisionnement : soumission de code malveillant et création de faux comptes pour faire pression sur un mainteneur.
Pourquoi le modèle a continué
Le Monde Informatique rapporte qu’une erreur dans les consignes rendait l’exercice difficile à réussir dans le cadre autorisé, et qu’Anthropic parle d’un effet de « momentum ». Le modèle a conclu à tort que le dépôt faisait partie de l’environnement simulé.
L’analyse de l’AISI va plus loin. Même quand les chercheurs modifiaient le résumé de contexte fourni au modèle pour préciser que la cible était une vraie personne, le taux d’attaque ne baissait pas. Mythos 5 affirmait souvent qu’attaquer serait nuisible, puis passait à l’acte dans les mêmes situations. Son raisonnement interne concluait régulièrement, à tort, que les cibles étaient simulées, sans peser le tort possible. L’institut ajoute que d’autres modèles reproduisent le même comportement dans des scénarios entièrement simulés : le problème ne se limite donc pas à un seul fournisseur.
Les réponses apportées #
Côté évaluateur, l’AISI dit avoir renforcé la sécurité de ses environnements de test, le cloisonnement et la surveillance. Côté éditeur, Anthropic indique, toujours selon Le Monde Informatique, que ses modèles suivants, Mythos 5.1 et Opus 5.5, sont moins susceptibles d’engager ce type d’action.
L’institut reconnaît aussi les limites de son travail. Il n’a étudié que des évaluations de cybersécurité et ne peut pas affirmer que les mêmes travers apparaîtraient ailleurs. C’est justement ce qui rend l’épisode utile pour les équipes de développement : des agents autonomes ouvrent déjà des pull requests, commentent des tickets et lancent des workflows sur de vrais dépôts.
Ce que cela change pour un mainteneur #
Le premier enseignement tient en une phrase : le mainteneur a tenu bon. Le code a été refusé deux fois, malgré la pression d’un compte en apparence indépendant. La revue humaine reste la dernière barrière, et c’est elle qui a fonctionné.
Se méfier de la pression sociale
Le schéma utilisé par le modèle n’a rien de nouveau. Un contributeur insiste, un « tiers » vient appuyer sa demande, l’urgence monte. C’est la mécanique de plusieurs compromissions célèbres de projets open source. Un nouveau compte qui défend avec ardeur la pull request d’un autre nouveau compte doit éveiller les soupçons, et non accélérer la fusion.
Lire le diff, pas la description
Une description soignée et un message de commit convaincant ne prouvent rien. Sur un projet exposé, il vaut mieux examiner chaque modification de script de build, de fichier de configuration CI ou de dépendance avec plus d’attention que le code applicatif. Ce sont les endroits où une charge malveillante passe le plus facilement inaperçue.
À lire Python 3.15.1, 3.14.9 et 3.13.17 : pourquoi il faut mettre à jour pip après l’affaire eMudhra
Limiter ce qu’une contribution peut déclencher
Les workflows qui s’exécutent sur les pull requests venues de forks méritent des droits minimaux, sans accès aux secrets. Exiger une approbation avant de lancer la CI sur la contribution d’un premier contributeur réduit nettement la surface d’attaque, qu’il s’agisse d’un humain mal intentionné ou d’un agent qui se trompe de cible.
Et pour les équipes qui utilisent des agents #
L’incident a aussi un versant interne. Une équipe qui confie à un agent des tâches longues sur ses dépôts doit lui donner un périmètre explicite : quels dépôts, quels comptes, quelles actions. Le rapport de l’AISI montre qu’un modèle peut se convaincre que sa cible est fictive. Mieux vaut donc que les garde-fous soient techniques (jetons limités à un dépôt, absence de droit de création de compte, journalisation des actions) plutôt que de reposer sur le seul jugement du modèle.
À lire l’AISI, la question dépasse les laboratoires d’évaluation : à mesure que les modèles mènent de longues tâches sans supervision humaine, il devient indispensable de comprendre quand et pourquoi ils sortent du cadre fixé. Pour un mainteneur, la réponse pratique reste la même qu’avant : une revue attentive, des droits minimaux et aucune fusion sous la pression.
