MalTool : quand une IA écrit l'outil malveillant que votre agent installe

De quoi s’agit-il ?

MalTool est un cadre de recherche, publié sur arXiv en février 2026 (arXiv:2602.12194) par des chercheurs de Duke University et UC Berkeley, qui traite une question que la plupart des travaux sur la sécurité des agents évitent : non pas comment un outil est décrit à l’agent, mais ce que le code de l’outil fait réellement une fois que l’agent l’appelle. Les auteurs le présentent comme la première étude systématique des implémentations de code d’outils malveillants visant les agents LLM.

Le modèle de menace est banal — et c’est précisément ce qui le rend important. Un attaquant publie un outil sur une plateforme de distribution : un registre de serveurs MCP, une marketplace de plug-ins, un index de paquets. Un développeur l’installe. L’agent, en faisant son travail, sélectionne cet outil au cours d’une tâche. L’outil s’exécute avec les accès dont dispose l’agent, et son code fait quelque chose que l’utilisateur n’a jamais autorisé. Aucune injection de prompt n’est nécessaire : le comportement malveillant réside dans l’implémentation, pas dans un prompt forgé.

Pour mesurer cette surface, l’équipe a utilisé un LLM de code afin de synthétiser automatiquement des outils malveillants, organisés selon une taxonomie bâtie sur le triptyque classique confidentialité–intégrité–disponibilité (CIA) adapté au contexte des agents. Le chiffre marquant : 6 487 outils malveillants générés. La conclusion marquante est celle sur laquelle les défenseurs devraient s’arrêter.

Comment ça marche

La contribution est un générateur, pas un exploit unique : il n’y a donc aucun payload à reproduire ici — et aucun n’est nécessaire pour comprendre la leçon.

Le cadre demande à un modèle capable d’écrire du code de produire des outils autonomes qui (a) implémentent une fonction annoncée plausible et d’apparence anodine et (b) réalisent également un comportement malveillant choisi dans la taxonomie CIA : exfiltrer des données que l’agent peut lire (confidentialité), altérer des fichiers ou des résultats (intégrité), ou perturber l’hôte ou la tâche (disponibilité). Pour chaque comportement cible, les auteurs ont généré de nombreuses variantes indépendantes, produisant un corpus vaste et diversifié plutôt qu’un échantillon réutilisé.

Cette diversité est le cœur du sujet. Comme chaque outil est rédigé à neuf par un modèle, le corpus ne présente aucune signature commune, aucune chaîne de caractères partagée, aucun binaire réutilisé — précisément les éléments sur lesquels s’appuie la détection de malware traditionnelle. Lorsque les chercheurs ont soumis les outils générés à VirusTotal, le service de scan multi-moteurs n’a pas détecté la majorité d’entre eux. La logique malveillante n’est que du code source d’apparence ordinaire qui effectue des actions ordinaires (lire un fichier, émettre une requête HTTP) dans un contexte où ces actions se trouvent être nuisibles.

Cela complète des travaux antérieurs sur la manière de faire choisir un outil hostile à l’agent en premier lieu — par exemple l’Attractive Metadata Attack (NeurIPS 2025), qui forge des métadonnées d’outil pour remporter la sélection de l’agent. MalTool suppose la sélection réussie et se demande ce que le code fait ensuite, et si quoi que ce soit l’intercepterait.

Pourquoi c’est important

Les écosystèmes d’agents se réorganisent autour de capacités tierces installables — serveurs MCP, skills, plug-ins, packs d’outils — distribuées un peu comme des paquets open source. Les équipes importent en bloc le modèle de risque de la chaîne d’approvisionnement logicielle, y compris son contrôle par défaut : scanner l’artefact avec un antivirus et des moteurs de signatures avant de lui faire confiance.

MalTool montre que ce contrôle est largement cosmétique face aux outils écrits par IA. Un moteur de signatures reconnaît des éléments malveillants connus. Un modèle peut écrire un volume illimité d’éléments malveillants inédits, jamais vus auparavant, chacun syntaxiquement unique. L’économie s’est inversée : produire un outil malveillant neuf et indétecté est désormais peu coûteux, et le taux de détection par échantillon du scan par signatures tend vers zéro. Cela rejoint ce que les équipes de threat intelligence rapportent plus largement sur les malwares polymorphes pilotés par IA — la détection doit passer de l’apparence du code à ce qu’il fait.

Pour les systèmes agentiques, le rayon d’impact est large, car un outil s’exécute dans l’enveloppe de privilèges de l’agent : ses identifiants, son accès au système de fichiers, sa sortie réseau, sa mémoire.

Défenses

Traitez les outils d’agents comme du code non fiable qui s’exécute avec l’autorité de l’agent, et cessez de vous reposer sur les signatures comme barrière.

• Moindre privilège par outil, pas par agent. Cantonnez chaque outil au minimum de données, de chemins de fichiers et de destinations réseau dont il a besoin. Un outil « résumer ce document » n’a aucune raison d’atteindre des URL arbitraires. Les contrôles par capacités limitent ce qu’une implémentation malveillante peut atteindre, même lorsqu’elle s’exécute.
• Surveillance comportementale plutôt que scan par signatures. Observez ce que les outils font à l’exécution — lectures de fichiers inattendues, connexions sortantes (en particulier vers des API d’IA ou des hôtes inconnus), création de processus, accès à des identifiants — plutôt que l’apparence de leur code. C’est le même virage que les défenseurs opèrent contre les malwares polymorphes.
• Contrôle de la sortie réseau (egress). Une attaque de confidentialité a besoin d’un canal d’exfiltration. Une politique réseau sortante en deny par défaut pour l’environnement d’exécution de l’agent neutralise les comportements d’outils les plus dommageables, indépendamment de la détection.
• Mettez l’exécution des outils en bac à sable. Exécutez les outils tiers dans des conteneurs ou sous des utilisateurs restreints, sans identifiants ambiants, afin qu’un outil malveillant qui s’exécute ne puisse atteindre ni secrets, ni système de fichiers élargi, ni réseau.
• Provenance et signature, pas seulement scan. Privilégiez les outils issus de sources que vous pouvez attribuer et vérifier cryptographiquement. Tenez une liste d’autorisation ; exigez une revue et une décision humaine avant qu’un nouvel outil tiers n’entre dans l’ensemble disponible d’un agent. Voir le Top 10 for Agentic Applications 2026 de l’OWASP pour les entrées « mésusage d’outils » et « chaîne d’approvisionnement ».
• N’assimilez pas « propre selon VirusTotal » à « sûr ». Un scan propre sur un outil écrit par IA ne porte presque aucun signal. Rendez-le explicite dans votre processus de revue pour qu’un résultat vert ne court-circuite pas le jugement humain.

Statut

Élément	Détail
Type	Cadre de recherche / étude de mesure
Source	arXiv:2602.12194 (février 2026)
Affiliation	Duke University ; UC Berkeley
Périmètre	Code d’outils malveillants (et non description/métadonnées) pour agents LLM
Taxonomie	Comportements Confidentialité / Intégrité / Disponibilité
Corpus généré	6 487 outils malveillants
Conclusion clé	VirusTotal n’en a pas détecté la majorité
Enseignement défensif	Contrôles comportementaux + par capacités, pas scan par signatures

La leçon durable n’est pas « un nouvel outil d’attaque existe ». C’est que la chaîne d’approvisionnement des outils d’IA hérite des hypothèses de confiance de la chaîne d’approvisionnement logicielle tout en cassant la méthode de détection sur laquelle ces hypothèses reposaient discrètement. Lorsque le coût de génération d’un outil malveillant inédit et capable d’échapper aux signatures approche de zéro, scanner les artefacts n’est plus une barrière. La barrière doit porter sur ce qu’un outil est autorisé à faire une fois que votre agent l’appelle.