OWASP ASI02 : quand un agent retourne ses propres outils contre vous

De quoi s’agit-il ?

ASI02 — Tool Misuse & Exploitation est la deuxième entrée du Top 10 OWASP pour les applications agentiques 2026, publié par l’Agentic Security Initiative du projet OWASP GenAI Security. Là où l’ancien Top 10 OWASP pour les LLM traitait les modèles comme de simples générateurs de texte, la liste agentique s’adresse à des systèmes qui agissent : ils appellent des API, exécutent des shells, interrogent des bases de données, envoient des e-mails. ASI02 désigne le risque qu’un agent utilise un outil qu’il a légitimement le droit d’appeler d’une manière dangereuse, non prévue ou pilotée par un attaquant.

Cet article est une lecture défensive de la catégorie. Il complète notre couverture d’ASI06 (empoisonnement de mémoire et de contexte) et complète le tableau de la façon dont le cadre 2026 décompose le risque agentique. La catégorie a fait l’objet d’un dossier approfondi d’Adversa AI en juin 2026, qui motive cette analyse.

Comment ça marche

L’idée centrale, énoncée clairement dans le matériel OWASP et les guides de Teleport et Adversa, est la suivante : la menace n’est pas que l’agent acquière soudainement des outils non autorisés — c’est qu’il détourne les outils qu’il possède déjà. ASI02 se déclenche dans trois conditions récurrentes :

1. SUR-PRIVILEGE    l'outil détient plus d'autorité que la tâche ne l'exige
                    (outil fichier porté sur $HOME, pas sur le dossier de travail)

2. ENTREE EMPOISONNEE   un descripteur d'outil ou un contenu récupéré
                    porte des instructions qui orientent son usage

3. CHAINAGE NON MAITRISE   plusieurs outils inoffensifs se combinent pour
                    produire un résultat qu'aucun seul n'était autorisé à livrer

Aucune de ces conditions n’exige un exploit logiciel classique. La boucle de raisonnement normale de l’agent est la surface d’attaque : une entrée non fiable (un document, un e-mail, un résultat web, une description d’outil) pousse le modèle à choisir un outil autorisé et à lui transmettre des arguments influencés par l’attaquant. L’outil fait exactement ce pour quoi il est conçu — la faille d’autorisation est en amont, dans ce que l’agent a été autorisé à tenter.

Incidents publiquement documentés correspondant à ce schéma (tous divulgués et discutés en 2025-2026) :

• CVE-2025-54136 (« MCPoison ») — un problème de l’IDE Cursor où une configuration de serveur MCP préalablement approuvée pouvait être silencieusement remplacée par une version malveillante, transformant un outil de confiance en outil hostile.
• Démonstration de tool-poisoning WhatsApp d’Invariant Labs (avril 2025) — un descripteur d’outil MCP malveillant manipulant le choix de l’outil appelé par l’agent.
• Exposition inter-tenants du MCP d’Asana (juin 2025) — une frontière d’outil laissant des données franchir la cloison entre clients.
• Suppression d’une base de production par l’assistant IA de Replit (juillet 2025) — une action destructrice menée malgré une consigne explicite de geler les modifications.

Aucun payload n’est reproduit ici ; c’est la forme qui fait la leçon. Un outil capable, plus un agent sous-contraint, plus une entrée non fiable, égalent un détournement.

Pourquoi c’est important

L’accès aux outils est toute la raison d’être d’un agent — et donc tout son rayon d’impact. Un agent qui peut lire un dépôt, appeler une API cloud et déclencher un webhook réunit, dans la formulation d’OWASP, exactement les ingrédients du dommage : exfiltration de données, élévation de privilèges et actions irréversibles. C’est la même dynamique que Simon Willison appelle la trifecta létale (données privées + entrée non fiable + canal d’exfiltration ou d’action), exprimée comme une catégorie de risque à la conception plutôt que comme un bug isolé.

Si ASI02 mérite sa propre case, c’est qu’elle est invisible pour les contrôles traditionnels. Pas de paquet malformé, pas de chaîne SQL injectée en bordure de réseau, pas de binaire non autorisé. Chaque appel d’outil paraît valide. La défaillance est sémantique — l’agent a fait quelque chose qu’il était techniquement autorisé à faire mais qu’il n’aurait jamais dû faire. Les défenses par filtrage de motifs passent à côté, car les octets sont anodins.

Défenses

OWASP, Teleport et Adversa convergent vers un ensemble de contrôles cohérent. Aucun n’est inédit ; toute la discipline tient à les appliquer tous.

1. Moindre privilège par outil, pas par agent. Limitez chaque outil à l’autorité minimale dont la tâche immédiate a besoin — chemins autorisés, limites de débit, domaines de données précis. Un outil fichier devrait voir le dossier de travail, pas l’ensemble du répertoire personnel.
2. Confirmez les actions destructrices et irréversibles. Exigez une approbation humaine explicite (ou un contrôle de politique) pour les suppressions, transferts, envois et changements de privilèges. Le cas Replit illustre l’absence de ce garde-fou.
3. Validez les arguments des outils par rapport à la sémantique attendue avant exécution — pas seulement le typage, mais « cet argument a-t-il un sens pour cette tâche ? ». Ne transmettez jamais une sortie d’agent non validée vers une commande shell ou base de données.
4. Isolez l’exécution des outils avec contrôle des sorties réseau. Exécutez les outils dans des environnements cloisonnés à réseau restreint, pour qu’un outil détourné ne puisse atteindre ni secrets ni points de terminaison externes hors de son périmètre.
5. Épinglez et attestez les descripteurs d’outils. Traitez la configuration du serveur MCP et les métadonnées d’outil comme une frontière de confiance : signez-les et détectez les substitutions silencieuses (le mode de défaillance MCPoison).
6. Surveillez les schémas d’invocation. Journalisez chaque appel d’outil et alertez sur les chaînes anormales, les pics inattendus ou les séquences combinant des capacités sensibles. Le détournement se révèle dans le schéma, pas dans l’appel isolé.

Le principe unificateur : un appel d’outil est une décision d’autorisation, pas un détail de complétion de texte. Concevez l’autorité que porte chaque outil et la frontière de ce que l’agent peut tenter — et partez du principe que le jugement du modèle sur « devrais-je exécuter ceci ? » finira par être erroné.

Statut

Élément	Référence	Date	Notes
Top 10 OWASP pour les applications agentiques 2026	OWASP GenAI	2025-2026	ASI02 = Tool Misuse & Exploitation, n°2 sur 10
Dossier approfondi ASI02	Adversa AI	2026-06	Définitions, catalogue d’incidents, contrôles défensifs
Synthèse de la catégorie + mitigations	Teleport	2025-12-15	Étapes de mitigation par risque pour les ingénieurs

ASI02 est une catégorie de cadre, pas un CVE unique — elle ne se « corrigera » qu’au rythme où les développeurs adopteront l’outillage à moindre privilège, la validation des arguments et le cloisonnement. La leçon pour quiconque met un agent en production : recensez chaque outil qu’il peut appeler, demandez-vous quel serait le pire usage légitime de chacun, et contraignez l’autorité avant même que l’agent n’y réfléchisse.