Glossaire
Mis à jour
Qui le publie et quand a-t-il été publié ?
La liste est produite par le OWASP Gen AI Security Project dans le cadre de son Initiative de Sécurité Agentique, d'où provient le préfixe ASI. Elle a été publiée le 10 décembre 2025 pour le cycle 2026, après plus d'un an de recherche et de révision impliquant plus de 100 chercheurs et professionnels de la sécurité. Elle coexiste avec le Top 10 de l'OWASP pour les applications LLM (qui traite des risques au niveau du modèle et des invites de commande) sans pour autant le remplacer. Veuillez noter que l'OWASP mène également un projet distinct intitulé Agentic Skills Top 10 ; il convient donc de vérifier à quelle liste un document donné fait référence.
Quels sont les dix risques ?
ASI01 Détournement des objectifs de l'agent (Agent Goal Hijack), où un attaquant manipule les objectifs de l'agent via le contenu qu'il lit. ASI02 Mauvais usage et exploitation des outils (Tool Misuse and Exploitation), où des outils légitimes sont enchaînés ou appelés de manière imprévue. ASI03 Abus d'identité et de privilèges (Identity and Privilege Abuse), où un agent détient plus d'autorisations que ne le requiert sa tâche ou emprunte la session d'un utilisateur. ASI04 Vulnérabilités de la chaîne d'approvisionnement agentique (Agentic Supply Chain Vulnerabilities). ASI05 Execution de code imprévue (Unexpected Code Execution). ASI06 Empoisonnement de la mémoire et du contexte (Memory and Context Poisoning). ASI07 Communication inter-agents non sécurisée (Insecure Inter-Agent Communication). ASI08 Défaillances en cascade (Cascading Failures). ASI09 Exploitation de la confiance homme-agent (Human-Agent Trust Exploitation). ASI10 Agents malveillants (Rogue Agents).
En quoi cela diffère-t-il de la sécurité des LLM ?
La sécurité au niveau des invites de commande s'intéresse à ce que le modèle dit. La sécurité agentique s'intéresse à ce que le système fait. Un agent lit du contenu non approuvé, détermine sa propre étape suivante, appelle des outils et modifie l'état d'autres systèmes ; le périmètre de sinistre d'une attaque réussie est donc opérationnel et non conversationnel. L'ASI01 illustre ce changement : une instruction malveillante dissimulée dans un document ou une page web que l'agent récupère peut réorienter son objectif, et aucun filtrage des résultats ne permet de détecter cela, car le résultat préjudiciable est une action entreprise par l'agent, et non un texte qu'il renvoie.
Quel est le lien avec la gouvernance de l'IA ?
La plupart de ces dix risques relèvent autant de failles de gouvernance que de failles d'ingénierie. L'abus d'identité et de privilèges est une décision d'attribution de droits. Les agents malveillants et les défaillances en cascade relèvent de ce qu'un agent est autorisé à faire sans validation humaine et de ce qui se produit lorsque plusieurs agents interagissent. L'exploitation de la confiance homme-agent concerne le niveau d'autorité qu'une interface suggère que l'agent possède. Les contrôles qui traitent de ces aspects se situent au niveau de la couche d'approbation et d'autorisation, c'est pourquoi cette liste est devenue un cadre de référence utile pour les politiques de gouvernance agentique, et pas seulement pour l'audit de sécurité.
Comment les équipes doivent-elles l'utiliser ?
Traitez-la comme une liste de contrôle à deux moments clés. Lors de la phase de cadrage, lorsqu'un cas d'usage agentique est proposé, passez en revue les dix points et consignez ceux qui s'appliquent ainsi que les mesures de contrôle correspondantes. Lors de la phase de révision, utilisez-la pour structurer les simulations d'attaques (red-teaming), car plusieurs éléments décrivent des attaques qui n'apparaissent que lorsque l'agent est confronté à des données hostiles. Aligner ces dix points sur un cadre de contrôle existant, qu'il s'agisse du NIST AI RMF ou de la norme ISO/IEC 42001, permet d'éviter de gérer la sécurité agentique comme un programme distinct du reste de la gouvernance de l'IA.
Exemple
Une équipe de support déploie un agent qui lit les e-mails des clients, consulte les dossiers de compte et émet des remboursements. En examinant la liste à la réception, l'équipe identifie trois vulnérabilités actives. La règle ASI01 s'applique car un client peut insérer des instructions dans un e-mail que l'agent lira, de sorte que le contenu non approuvé est séparé du contexte d'instruction. La règle ASI03 s'applique car l'agent s'est vu attribuer le même rôle de base de données qu'un administrateur humain ; ses autorisations sont donc limitées aux enregistrements et opérations spécifiques dont il a besoin. La règle ASI02 s'applique car l'outil de remboursement accepte un montant arbitraire ; un plafond de valeur ainsi qu'une étape de confirmation humaine au-delà de ce plafond sont donc ajoutés. Les mesures de contrôle sont enregistrées pour ce cas d'usage, fournissant ainsi les mêmes éléments de preuve au réviseur de sécurité et à l'auditeur.