ASI02 : détournement et exploitation des outils d’un agent

ASI02, deuxième entrée du Top 10 OWASP des applications agentiques, décrit le mésusage d’outils parfaitement légitimes par un agent parfaitement autorisé. Rien n’est forcé, rien n’est volé : l’agent reste à l’intérieur de ses privilèges et applique un outil d’une manière que personne n’avait prévue. Il supprime des données qu’il avait le droit de supprimer, appelle six mille fois une API qu’il avait le droit d’appeler, ou transmet à l’extérieur une information qu’il avait le droit de lire. C’est la classe de défaillance la plus banale et la plus sous-estimée du lot, parce qu’elle ne ressemble pas du tout à une attaque.

→ Lire l’explication complète de la marmotte

Le mécanisme : le choix de l’outil n’est pas contrôlé

Un agent outillé dispose d’un catalogue de fonctions, chacune décrite en langage naturel, et choisit à l’exécution laquelle appeler et avec quels arguments. Ce choix est produit par le modèle. Il n’est donc pas vérifié, pas tracé dans un plan validé et pas reproductible. Le référentiel pointe trois facteurs qui transforment ce choix en risque : la mémoire de l’agent, qui fait qu’une décision passée influence les appels suivants ; la sélection dynamique d’outils, qui autorise à résoudre à l’exécution un nom d’outil sur un catalogue mouvant ; et la délégation, qui laisse un agent appeler un outil pour le compte d’un autre.

La conséquence contre-intuitive est que la dangerosité d’un outil ne tient ni à son nom ni à son code, mais à ce que l’agent peut en faire dans une séquence. Une fonction de lecture et une fonction d’envoi sont chacune inoffensive ; mises bout à bout, elles forment une exfiltration. Le référentiel donne l’exemple d’un outil ping, laissé en auto-exécution parce que tout le monde s’accorde à le trouver sans conséquence, et employé en boucle pour sortir des données par les requêtes DNS qu’il engendre. Le cas est pédagogique : il n’existe aucune politique raisonnable qui refuse un ping, et aucune supervision de l’hôte qui s’en alarme.

Cette propriété explique l’exemple le plus inquiétant de l’entrée. Un agent d’automatisation de la sécurité, recevant une instruction injectée, chaîne des outils d’administration légitimes — un interpréteur de commandes, un client HTTP, des API internes — pour extraire des journaux sensibles. Chaque commande est exécutée par un binaire de confiance sous des identifiants valides : la supervision centrée sur l’hôte ne voit ni logiciel malveillant ni exploitation, parce qu’il n’y en a pas.

Ce qui distingue ASI02 de ses voisins

Le référentiel trace une frontière nette, fondée sur ce qui se passe au-delà du mésusage :

si l’agent sort de ses privilèges — escalade, héritage d’identifiants, action au nom d’un autre — on quitte ASI02 pour ASI03, abus d’identité et de privilèges ;
si le mésusage aboutit à exécuter du code arbitraire ou injecté, on relève d’ASI05, exécution de code inattendue ;
si l’outil lui-même est malveillant à la source, c’est ASI04, chaîne d’approvisionnement agentique.

Cette dernière limite est la plus fine et vaut d’être comprise, parce qu’elle sépare deux incidents qui se ressemblent. Le référentiel range sous ASI02 l’empoisonnement de l’interface d’outil : l’attaquant altère à l’exécution le descripteur, le schéma, les métadonnées ou les informations de routage d’un outil par ailleurs légitime, de sorte que l’agent l’invoque sur des capacités falsifiées. L’outil est honnête, sa carte de visite ne l’est pas. Dès que c’est le code de l’outil qui est compromis en amont, on bascule sous ASI04. Comme les définitions d’outils arrivent de plus en plus par des serveurs MCP, le document reconnaît que les deux entrées se recouvrent largement en pratique.

Face au Top 10 LLM, ASI02 prolonge LLM06 (autonomie excessive) en déplaçant la question : LLM06 parle d’une autonomie trop large accordée au modèle, ASI02 du mésusage d’outils légitimes à l’intérieur de plans et de chaînes de délégation. Dans la taxonomie du projet, l’entrée correspond à T2, mésusage d’outil, avec T4 (surcharge de ressources) et T16 (abus de protocole inter-agents) comme facteurs amplificateurs.

Les quatre formes qu’on rencontre vraiment

L’outil sur-privilégié. Un résumeur de courriels qui peut aussi supprimer et envoyer, sans confirmation. Un assistant de service client censé consulter l’historique des commandes, mais branché sur une API financière complète, et qui émet donc aussi des remboursements. La cause est toujours la même : on a câblé l’outil sur une clé existante au lieu d’en créer une pour lui.

L’outil sur-porté. Variante plus discrète du précédent : les droits sont bons, le périmètre de données ne l’est pas. Le référentiel cite un connecteur CRM autorisé à lire n’importe quel objet alors que l’agent n’a besoin que des opportunités. C’est exactement le défaut de contrôle d’accès au niveau objet que les API connaissent depuis longtemps, décrit sur le site dans BOLA et le contrôle d’accès des API — ici avec un appelant qui improvise ses requêtes.

L’amplification de boucle. Un planificateur qui réessaie, rappelle, reformule et finit par consommer un budget entier. Le référentiel la classe parmi les mésusages d’outils et non parmi les pannes, à juste titre : le mécanisme est un appel légitime répété. Les plafonds qui l’arrêtent sont ceux décrits dans le denial of wallet sur une API d’IA, à ceci près que l’attaquant peut ici être l’agent lui-même, sans intention particulière.

La résolution de nom trompeuse. Un outil nommé report résolu avant report_finance, et l’appel part au mauvais endroit avec les mêmes arguments. Le typosquattage d’outils ne demande aucune compromission : il suffit d’un catalogue où deux noms se ressemblent et d’un ordre de résolution non spécifié.

Le suivi d’incidents du référentiel donne deux illustrations publiques de la classe. En juillet 2025, un assistant de développement d’Amazon a laissé fuir des secrets par des requêtes DNS, à la suite d’une injection de prompt : l’outil employé était légitime, le canal de sortie aussi. La même année, les travaux rassemblés sous le nom d’AgentFlayer ont montré sur Microsoft Copilot Studio une exfiltration de données obtenue sans clic de l’utilisateur, par le seul enchaînement de capacités accordées à l’agent. Dans les deux cas, la liste des outils autorisés n’avait pas besoin d’être revue : c’est ce qu’on pouvait en faire ensemble qui n’avait pas été examiné.

Réduire : des profils par outil, pas des conventions

Le référentiel est ici inhabituellement concret, et ses recommandations convergent vers une idée : la politique doit vivre à côté de l’outil, sous forme vérifiable, et non dans la tête de l’équipe.

Un profil de moindre privilège par outil : portées, débit maximal, destinations de sortie autorisées. Le document insiste pour que ces profils soient exprimés en politiques IAM ou d’autorisation attachées à chaque outil, plutôt qu’en conventions internes — une convention ne refuse rien à trois heures du matin. Lectures seules pour une base, aucun droit d’envoi ni de suppression pour un résumeur de courriels, opérations minimales quand on expose une API.
Une authentification et une approbation au niveau de l’action : authentification explicite à chaque invocation, confirmation humaine pour tout ce qui supprime, transfère ou publie, et surtout présentation d’un plan d’exécution ou d’un essai à blanc avant validation. Un bouton « approuver » sans diff n’est qu’un test de patience.
Une passerelle de décision avant l’appel, que le document nomme intent gate : les sorties du planificateur sont traitées comme non fiables, un point d’application de politique valide l’intention et les arguments, impose les schémas et les limites de débit, émet des identifiants de courte durée et révoque sur dérive. C’est l’architecture décrite en détail dans comment valider le function calling d’un LLM et dans sécuriser les actions irréversibles des agents LLM.
Des bacs à sable et un filtrage de sortie : exécution isolée, liste d’hôtes autorisés, tout le reste refusé. C’est ce qui aurait coûté cher à l’exfiltration par ping.
Une validation sémantique et des noms pleinement qualifiés : noms d’outils complets, versions épinglées, refus en cas de résolution ambiguë plutôt que choix au hasard, et validation de la sémantique attendue de l’appel — le type ou la catégorie de requête — et non de sa seule syntaxe. Un appel conforme au schéma peut être absurde ; le schéma ne le dira pas.
Des plafonds d’usage en coût, en débit ou en jetons, avec throttling ou révocation automatique, et des identifiants temporaires qui expirent dès l’appel terminé plutôt que des clés durables. Les clés de fournisseurs relèvent du même traitement : voir sécuriser les clés d’API des fournisseurs d’IA.

Reste l’observabilité, sans laquelle rien de ce qui précède ne se vérifie : journaux immuables de toutes les invocations et de tous les changements de paramètres, et surveillance des taux d’exécution anormaux et des enchaînements inhabituels. Le référentiel donne le motif à détecter en priorité, et il est simple à écrire comme à comprendre : une lecture de base de données suivie d’un transfert externe.

Ce que ces mesures ne font pas

Elles n’empêchent pas la composition. Une politique qui examine chaque appel isolément validera chacun des quatre appels d’une exfiltration en quatre temps, puisque chacun est légitime. Il faut donc évaluer la transaction complète et poser des quotas de session, ce qui suppose de savoir ce qu’est une session — question étonnamment difficile pour un agent qui réessaie, délègue et reprend un contexte vieux de deux jours.

Elles ne disent pas non plus quel outil méritait d’exister. C’est le retour du principe de moindre agentivité : la question qui précède toutes les autres est de savoir si l’agent avait besoin de cette fonction. Un agent qui ne peut pas envoyer de courriels n’a pas besoin d’une politique d’envoi de courriels, et c’est la seule protection dont on soit sûr qu’elle tienne. Le raisonnement est développé dans le moindre privilège pour une machine qui improvise.

🐝 Ce qui arrive si on s’en passe

Sans profil de droits propre à chaque outil, l’agent appelle les API cibles avec un identifiant unique et large, et le journal du système cible n’enregistre donc qu’un seul acteur : impossible de dire après coup quelle tâche, quel utilisateur initiateur ou quelle étape de plan a déclenché l’appel. L’enquête se fait alors sur les horodatages, à la main, en espérant que les horloges concordent. Sans plafond par session ni évaluation de la transaction complète, une boucle de relance sur une opération non idempotente — un virement, une création de jeton, un envoi de message — s’exécute autant de fois que le planificateur la réémet, et le premier signal disponible est la facture du mois ou l’appel d’un destinataire. Sans liste de destinations sortantes, enfin, les outils les plus anodins du catalogue suffisent à sortir des données : la supervision de l’hôte ne verra qu’un binaire de confiance faisant son travail habituel.

🦫 Explication de la marmotte 🍫

Un assistant informatique autorisé à agir dispose d’une boîte à outils : envoyer un message, lire une base, supprimer un fichier, appeler un service. Chaque outil lui est donné volontairement, avec des droits précis. Le risque décrit ici n’est pas qu’il obtienne un outil interdit, mais qu’il se serve mal de ceux qu’on lui a confiés.

Cela arrive de trois façons. Soit l’outil a été branché trop large : on voulait qu’il lise les commandes, on lui a donné accès à toute la comptabilité. Soit l’assistant répète un appel des milliers de fois, et ce qui coûtait un centime coûte une fortune. Soit il enchaîne plusieurs outils inoffensifs pour obtenir un résultat qui ne l’est pas : lire une information, puis l’envoyer ailleurs. Chaque geste est permis ; la suite ne l’était pas.

La protection consiste à donner à chaque outil ses propres droits, les plus étroits possibles, écrits noir sur blanc dans le système d’autorisation plutôt que dans un document interne. Pour tout ce qui supprime, paie ou publie, une personne doit voir exactement ce qui va être fait — pas un résumé — et le valider. Les dépenses et le nombre d’appels sont plafonnés, et dépasser le plafond coupe au lieu d’alerter.

Il faut enfin conserver la trace de chaque outil employé, avec ses paramètres, et surveiller les enchaînements inhabituels. Le plus utile à détecter est connu : une lecture de données suivie d’un envoi vers l’extérieur. C’est rarement une coïncidence, et c’est toujours trop tard quand on l’apprend par quelqu’un d’autre.

Pages voisines

La citent

ASI02 : détournement et exploitation des outils d'un agent

Elle cite

: les deux pages se citent l’une l’autre.