Quand les agents de code IA deviennent des vecteurs de malware

Les agents de code IA ont changé la façon d'installer des logiciels

Les agents de code IA (des assistants capables d'agir de façon autonome dans l'environnement de développement) font désormais partie du quotidien des équipes : ils recherchent des bibliothèques, configurent des projets, dépannent des installations et mettent en place de nouveaux outils. Un agent peut parcourir GitHub, lire la documentation d'un projet et exécuter des commandes sans que le développeur ne valide chaque étape manuellement.

Ce confort crée un nouveau problème de sécurité. Au cours d'une tâche, l'agent peut rencontrer du code et des instructions, les juger pertinents et agir en conséquence. Un dépôt, un fichier README ou un fichier de configuration devient alors partie intégrante du chemin d'exécution. Prenons une demande simple : ajouter un serveur MCP (Model Context Protocol, un standard permettant de connecter des outils externes à un modèle d'IA). L'agent peut chercher sur GitHub, comparer plusieurs dépôts, en choisir un qui semble pertinent, suivre les instructions d'installation de son README, modifier la configuration et lancer les commandes nécessaires.

Le développeur, lui, n'approuve souvent que la commande finale, sans voir tout ce qui l'a précédée. L'agent a pu suivre des instructions issues d'une source que personne n'a explicitement évaluée. L'agent fait exactement ce qu'on lui a demandé : le problème est que les instructions récupérées en chemin proviennent d'un endroit que le développeur n'a jamais décidé de considérer comme fiable. C'est là que le développement assisté par IA crée un problème de supply chain d'un genre nouveau : l'attaque peut commencer avant même que le code n'atteigne le dépôt, le serveur de build ou le pipeline de production.

Un README peut désormais faire partie de la surface d'attaque

Les fichiers README ont toujours servi à expliquer comment installer les dépendances et configurer un projet. Une preuve de concept du Zero Day Investigative Network de Mozilla a montré comment un dépôt pouvait manipuler un agent de code jusqu'à lui faire ouvrir un reverse shell (une connexion sortante donnant à l'attaquant le contrôle de la machine). Le dépôt contenait des instructions d'initialisation d'un outil Python fictif : après une erreur volontairement provoquée au premier lancement, l'agent suivait les étapes de dépannage suggérées, récupérait des instructions encodées dans un enregistrement DNS TXT et les passait à un shell.

Le point crucial : la charge malveillante n'était pas visible dans le dépôt sous une forme évidente. Elle n'apparaissait que plus tard dans le processus d'exécution, une fois l'agent engagé dans les instructions du projet. L'approbation d'une commande par le développeur perd alors beaucoup de sa valeur : il peut valider une commande d'installation d'apparence familière sans savoir tout ce qu'elle finira par exécuter.

Les README ne sont pas les seuls vecteurs. Les fichiers AGENTS.md, les guides de contribution, les descriptions d'issues, les commentaires de code et les fichiers de configuration spécifiques aux outils peuvent également influencer les actions d'un agent. Les recherches de GitHub sur l'injection de prompt dans VS Code ont montré comment du contenu non fiable introduit dans un workflow assisté par IA peut influencer un agent et potentiellement exposer des fichiers, des jetons d'authentification ou l'exécution de commandes. Dès qu'un agent peut lire le contenu d'un projet et agir en conséquence, la documentation fait partie du chemin d'exécution.

Les dépôts malveillants n'ont pas besoin d'avoir l'air malveillants

Comme les agents servent de plus en plus à trouver des logiciels et des outils, le processus de recherche lui-même devient une cible. La campagne FakeGit l'illustre : des chercheurs ont identifié des milliers de dépôts GitHub malveillants se faisant passer pour des outils d'IA légitimes, des « skills » ou des serveurs MCP. Certains reprenaient des noms de projets connus et copiaient la structure de dépôts crédibles. Ces dépôts délivraient in fine du malware, mais l'essentiel de l'attaque se jouait en amont : rendre les projets suffisamment visibles et convaincants pour qu'un système d'IA les recommande.

Certains de ces dépôts ont effectivement été remontés par des agents de code lors de recherches de logiciels ordinaires. Un agent cherchant une fonctionnalité donnée pouvait tomber sur un dépôt malveillant, le traiter comme une option légitime et transmettre ses instructions d'installation au développeur. Les chercheurs ont baptisé cette technique « AgentBaiting » (l'appâtage d'agents). Pour les équipes qui s'appuient sur des agents pour découvrir des outils, la découvrabilité est devenue une composante du problème de sécurité : un projet malveillant qui atteint un agent au bon moment se rapproche bien plus de l'exécution qu'un projet attendant d'être découvert manuellement.

Pourquoi les contrôles de sécurité traditionnels peuvent passer à côté

Les outils de sécurité classiques restent indispensables, mais ils ne voient pas toujours la chaîne complète des actions d'un agent. Une commande peut provenir d'un shell légitime, être exécutée par un outil de développement de confiance, et le dépôt lui-même peut passer un contrôle de sécurité basique. Le problème ne devient visible que lorsqu'on considère ces actions ensemble.

Un antivirus identifie des fichiers malveillants connus ; une protection anti-malware plus large détecte aussi des comportements suspects. Ces contrôles restent utiles, mais ils n'expliquent ni comment le logiciel est arrivé sur la machine, ni pourquoi il a été exécuté. Du point de vue du système d'exploitation, une commande lancée par un agent dans le cadre d'une tâche demandée par le développeur ressemble à une activité de développement ordinaire. Si le déclencheur initial était un dépôt ou une instruction que l'agent a jugés dignes de confiance, l'outil de sécurité ne voit que l'action finale, pas la séquence qui y a conduit.

Ce que les équipes DevOps doivent changer

Plusieurs mesures concrètes se dégagent pour reprendre le contrôle :

• Traiter l'accès de l'agent comme une frontière de sécurité à part entière. Un agent capable d'installer des paquets, de modifier des fichiers et d'exécuter des commandes shell a une portée bien plus grande qu'un agent qui se contente de suggérer du code. Ses droits doivent correspondre à sa tâche : un agent qui relit une pull request n'a pas besoin des mêmes permissions qu'un agent qui prépare une release ou configure un environnement.
• Appliquer les mêmes vérifications de confiance aux découvertes de l'agent qu'aux installations manuelles. Dépôts, paquets et serveurs MCP trouvés par un agent doivent passer les mêmes contrôles que tout logiciel installé par un humain. La popularité d'un dépôt, son activité ou la recommandation d'un agent ne prouvent en rien qu'un projet est sûr.
• Porter une attention particulière à l'exécution, notamment en faisant tourner les agents dans des environnements isolés, afin de limiter l'impact d'une instruction malveillante suivie par erreur.