OWASP Agentic AI Top 10

L'IA agencée change la conversation sur la sécurité car elle change ce que les systèmes d'IA peuvent faire.

Un chatbot qui répond à des questions à partir d'une base de connaissances est une chose. Un agent IA qui peut planifier des tâches, appeler des outils, accéder aux systèmes internes, interroger des données, écrire dans des applications, exécuter du code, coordonner avec d'autres agents et conserver la mémoire est tout à fait autre chose.

De nombreuses organisations ont passé 2024 et 2025 à expérimenter avec des intégrations LLM, des copilotes internes, des systèmes de récupération, des assistants IA et des flux de travail agencés précoces. Une partie de ce travail est restée sûrement contenue. Une partie s'est étendue discrètement. Les agents ont obtenu un accès aux API, aux outils SaaS, aux bases de données, aux fichiers, aux systèmes de ticketing, aux enregistrements CRM, aux dépôts et aux flux de travail opérationnels.

C'est là que le risque de sécurité change. Un agent IA n'est pas juste une autre interface utilisateur. C'est un acteur logiciel avec des instructions, des permissions, des outils, un contexte et la capacité de faire des choix à l'intérieur d'un flux de travail.

La Fondation OWASP’ Top 10 pour les applications agencées 2026 donne aux équipes de sécurité un moyen pratique de penser à ce changement. Développé grâce à la collaboration avec plus de 100 experts de l'industrie, chercheurs et praticiens, le cadre identifie les risques les plus critiques auxquels sont confrontés les systèmes d'IA autonomes et agencés. Ce n'est pas juste un avertissement sur les menaces futures. C'est une carte des problèmes que les organisations commencent déjà à affronter alors que les agents passent du pilote à la production.

Pourquoi l'IA agencée change l'équation de sécurité

La sécurité des applications traditionnelles est construite autour d'hypothèses familières. Les utilisateurs s'authentifient. Les applications appliquent les permissions. Les services appellent des API connues. Les journaux montrent les actions. Les équipes de sécurité surveillent les modèles d'accès, les vulnérabilités, le comportement du réseau et l'activité suspecte.

L'IA agencée complique ces hypothèses.

Les agents ne se comportent pas comme des utilisateurs normaux. Ils peuvent interpréter des instructions, faire des plans intermédiaires, décider quels outils utiliser, récupérer du contexte, appeler des systèmes à plusieurs reprises et produire des actions qui semblent légitimes parce qu'elles utilisent des identifiants approuvés et des intégrations approuvées.

L'analyse de Palo Alto Networks’ de la publication OWASP met en évidence la nécessité d'un inventaire centré sur les agents, d'une visibilité complète, de l'intégrité de la chaîne d'approvisionnement à travers les composants IA, de la gouvernance, des garde-fous et du contrôle actif d'exécution. Ce cadre est utile car le problème de sécurité n'est pas limité à l'injection de prompt. Il inclut les outils, les identités, les chaînes d'approvisionnement, la mémoire, le contexte, les permissions et le comportement d'exécution.

En d'autres termes, sécuriser un agent n'est pas la même chose que sécuriser un modèle. Le modèle n'est qu'une partie du système.

Le Top 10 d'OWASP pour les applications agencées

La liste 2026 d'OWASP’ identifie dix grandes catégories de risques pour les systèmes agencés :

ASI01 — Détournement de l'objectif de l'agent : les attaquants manipulent ou redirigent l'objectif de l'agent’, souvent par le langage naturel, des instructions cachées ou un contexte malveillant.
ASI02 — Mauvaise utilisation et exploitation des outils : les agents utilisent des outils de manière non sûre, non intentionnelle ou exploitable.
ASI03 — Abus d'identité et de privilèges de l'agent : les agents reçoivent des permissions excessives, héritent d'identifiants risqués ou opèrent sans limites d'identité appropriées.
ASI04 — Vulnérabilités de la chaîne d'approvisionnement agencée : les prompts, plugins, serveurs MCP, outils, ensembles de données, logique d'orchestration, dépendances ou intégrations sont compromis.
ASI05 — Exécution de code inattendue : les agents déclenchent ou génèrent un comportement exécutable non sûr via des outils, scripts, plugins ou systèmes connectés.
ASI06 — Empoisonnement de la mémoire et du contexte : les attaquants manipulent ce que l'agent se souvient, récupère ou utilise comme contexte.
ASI07 — Communication inter-agents non sécurisée : les agents communiquent entre eux sans authentification, validation ou limites suffisantes.
ASI08 — Échecs en cascade des agents : l'échec, la mauvaise sortie ou l'action non sûre d'un agent’ se propage à travers un plus grand flux de travail agencé.
ASI09 — Exploitation de la confiance humain-agent : les utilisateurs font trop confiance aux sorties, approbations ou recommandations des agents de manière exploitable par les attaquants.
ASI10 — Agents rogue : les agents agissent en dehors du périmètre prévu, persistent au-delà de l'autorisation ou opèrent sans surveillance adéquate.

La liste est importante car elle reflète la manière dont les systèmes agencés échouent réellement. Les risques sont comportementaux, architecturaux et opérationnels. Ils ne sont pas seulement des vulnérabilités au sens traditionnel.

Le problème d'identité que personne n'a prévu

Les équipes de sécurité gèrent déjà des identités non humaines : comptes de service, charges de travail, appareils, applications, bots, scripts d'automatisation et clés API. L'IA agencée ajoute une autre couche.

Un agent peut opérer avec une autorité déléguée. Il peut utiliser les identifiants d'un utilisateur’, un compte de service, un jeton spécifique à un outil ou une identité gérée par la plateforme. Il peut accéder à plusieurs systèmes dans un seul flux de travail. Il peut décider quel outil utiliser en fonction du contexte. Il peut opérer au nom de différents utilisateurs à différents moments.

Cela crée une question difficile : que peut exactement faire l'agent ?

Si la réponse est “tout ce que le compte connecté peut faire,” l'organisation a un problème. Les permissions humaines sont souvent trop larges pour une utilisation autonome. Un utilisateur peut avoir accès à des fichiers sensibles, des données clients, des systèmes de facturation, des paramètres administratifs ou du code source parce qu'il a besoin de cet accès dans des contextes spécifiques. Donner à un agent la même étendue d'accès peut créer un risque inutile.

Les identités des agents doivent être gouvernées délibérément. Cela signifie le privilège minimum, des identifiants étendus, une propriété claire, des permissions au niveau des outils, des portes d'approbation, la journalisation et la capacité de révoquer ou de faire pivoter l'accès rapidement.

Le détournement d'objectif est différent d'une compromission traditionnelle

Le détournement de l'objectif de l'agent est l'un des risques les plus importants car il attaque les instructions de l'agent’ plutôt que le code sous-jacent.

Un attaquant n'a peut-être pas besoin d'exploiter une vulnérabilité logicielle au sens habituel. Il peut insérer des instructions malveillantes dans un document, une page web, un e-mail, un ticket de support, un problème de dépôt, une sortie d'outil ou un autre contexte que l'agent lit. Si l'agent ne peut pas distinguer les instructions de confiance du contenu non fiable, il peut rediriger son comportement.

L'analyse d'Auth0’ de la liste OWASP décrit les deux premières catégories, le détournement d'objectif et la mauvaise utilisation des outils, comme des risques qui surgissent parce que les agents traitent le langage naturel et peuvent ne pas distinguer de manière fiable les instructions système des charges utiles malveillantes cachées dans le contenu ou la sortie des outils.

C'est un modèle mental différent pour les défenseurs. La surface d'attaque inclut le texte, le contexte, les réponses des outils, la mémoire, les documents récupérés et les flux de travail, pas seulement les points de terminaison exposés.

L'accès aux outils transforme un mauvais raisonnement en action réelle

L'IA agencée devient plus puissante lorsqu'elle peut utiliser des outils. Elle devient aussi plus dangereuse.

Un modèle qui donne une mauvaise réponse est un problème de qualité. Un agent qui donne une mauvaise réponse et met ensuite à jour un enregistrement client, ouvre un ticket, envoie un e-mail, change une configuration, appelle une API ou exécute du code est un risque opérationnel.

La mauvaise utilisation des outils peut se produire même sans intention malveillante. L'agent peut mal comprendre une demande. Il peut utiliser un outil dans le mauvais ordre. Il peut agir sur des données périmées. Il peut appeler une API avec les mauvais paramètres. Il peut ne pas reconnaître qu'une étape d'approbation humaine est requise.

La solution n'est pas simplement “un meilleur prompting.” Les agents ont besoin de limites d'outils. Ils ont besoin de portées de permission. Ils ont besoin de valeurs par défaut sûres. Ils ont besoin de modes de test à sec pour les actions à fort impact. Ils ont besoin d'une approbation humaine pour les opérations sensibles. Ils ont besoin d'une surveillance qui comprend le comportement des agents, pas seulement le trafic API.

La mémoire et le contexte créent une nouvelle surface d'attaque

La mémoire de l'agent est utile car elle permet aux systèmes de conserver les préférences, l'état du flux de travail, les décisions antérieures et le contexte entre les sessions. Elle crée aussi du risque.

Si la mémoire peut être empoisonnée, l'agent peut transporter de mauvaises hypothèses vers l'avant. Si la récupération de contexte est faible, l'agent peut utiliser les mauvais documents, des politiques périmées ou des données malicieusement modifiées. Si les utilisateurs peuvent influencer la mémoire partagée sans contrôles, l'entrée d'un utilisateur’ peut affecter l'expérience d'un autre utilisateur’.

Les systèmes de mémoire et de récupération doivent être traités comme faisant partie de l'architecture de sécurité. Les organisations doivent savoir ce qui est stocké, qui peut le modifier, combien de temps il est conservé, comment il est validé et comment le contexte empoisonné ou périmé peut être corrigé.

Le risque de la chaîne d'approvisionnement inclut désormais les prompts, les outils et les serveurs MCP

La sécurité de la chaîne d'approvisionnement logicielle inclut déjà les dépendances, les packages, les conteneurs, les systèmes de construction, les API et les services des fournisseurs. L'IA agencée étend la chaîne d'approvisionnement.

Les prompts, définitions d'outils, scripts d'orchestration, ensembles de données RAG, plugins, serveurs MCP, outils externes, magasins vectoriels et fournisseurs de modèles deviennent tous partie du système agencé. Un outil compromis ou un ensemble de données empoisonné peut changer le comportement de l'agent aussi sûrement qu'un package compromis peut changer le comportement de l'application.

Palo Alto Networks met l'accent sur l'intégrité de la chaîne d'approvisionnement à travers les prompts, plugins, ensembles de données RAG, scripts d'orchestration et dépendances de modèles. C'est la bonne lentille. Les équipes de sécurité doivent traiter les composants agencés comme des dépendances de production, pas comme une configuration informelle.

La conformité ne peut pas être une pensée tardive

L'IA agencée étend l'exposition à la conformité car les agents peuvent toucher des données sensibles, influencer des décisions, créer des enregistrements, communiquer à l'extérieur ou prendre des actions à l'intérieur de flux de travail réglementés.

La question de conformité n'est pas seulement si le modèle est approuvé. C'est si tout le flux de travail agencé peut être expliqué, surveillé, audité et contrôlé.

Les organisations doivent répondre :

Quels agents sont déployés ?
Qui possède chaque agent ?
À quelles données chaque agent peut-il accéder ?
Quels outils chaque agent peut-il utiliser ?
Quelles actions nécessitent une approbation humaine ?
Comment les prompts, outils et configurations sont-ils versionnés ?
Comment les sorties sont-elles journalisées ?
Comment les incidents sont-ils détectés et escaladés ?
Comment les agents sont-ils retirés ou mis hors service ?

Si ces questions ne peuvent pas être répondues, l'organisation n'a pas un programme de gouvernance de l'IA agencée. Elle a une utilisation de l'IA agencée.

Ce que les équipes de sécurité devraient faire maintenant

La bonne réponse n'est pas d'interdire chaque système agencé. C'est de créer un modèle de sécurité qui correspond au risque.

Construire un inventaire d'agents : Identifier les agents, copilotes, automatisations, plugins, serveurs MCP, flux de travail d'appel d'outils et fonctionnalités IA de fournisseur déjà utilisés.
Cartographier les permissions et les outils : Documenter quels systèmes chaque agent peut accéder, quels identifiants il utilise et quelles actions il peut prendre.
Appliquer le privilège minimum : Ne pas laisser les agents hériter de permissions humaines larges par défaut. Étendre l'accès à la tâche.
Séparer les instructions de confiance du contenu non fiable : Traiter les documents, pages web, e-mails, tickets et sorties d'outils comme des entrées potentiellement hostiles.
Contrôler les actions à fort impact : Exiger une approbation, une revue ou des modes de test à sec pour les opérations sensibles.
Sécuriser la mémoire et la récupération : Contrôler ce que les agents peuvent se souvenir, récupérer, modifier et partager entre utilisateurs ou sessions.
Surveiller le comportement d'exécution : Journaliser les appels d'outils, l'utilisation des permissions, l'accès aux données, les sorties, les erreurs et les modèles d'action inhabituels.
Red-team les flux de travail agencés : Tester pour le détournement d'objectif, la mauvaise utilisation des outils, l'abus de privilèges, l'empoisonnement de contexte, l'exécution de code non sûre et les échecs en cascade.

Ces contrôles doivent être conçus dans l'architecture agencée avant le déploiement. Les ajouter plus tard est plus difficile, surtout après que les utilisateurs commencent à dépendre du système.

Comment Ridiculous Engineering pense à la sécurité de l'IA agencée

Chez Ridiculous Engineering, nous voyons la sécurité de l'IA agencée comme un problème d'architecture, pas juste un problème de durcissement de prompt. Le prompting compte, mais les agents deviennent risqués parce qu'ils sont connectés à des outils, identités, données, mémoire, API, flux de travail et personnes.

Cela signifie que la sécurité des agents doit être conçue à travers tout le système. À quoi l'agent peut-il accéder ? Que peut-il changer ? Quel contexte peut l'influencer ? Qu'est-ce qui est journalisé ? Qu'est-ce qui nécessite une revue ? Qui possède l'agent après le déploiement ? Comment l'organisation détecte-t-elle un comportement non sûr avant qu'il ne devienne un incident commercial ?

Nous aidons les clients à aborder ces questions pratiquement. Cela peut signifier inventorier les flux de travail agencés, cartographier les permissions et l'accès aux données, revoir les intégrations d'outils, concevoir des portes de gouvernance, construire la surveillance, créer des modèles de déploiement plus sûrs ou aider les équipes à passer des agents expérimentaux aux systèmes de production avec des contrôles plus clairs.

L'objectif n'est pas de ralentir l'innovation pour elle-même. L'objectif est de rendre l'IA agencée utile sans laisser l'autonomie dépasser la responsabilité.

La conclusion

L'IA agencée n'est pas un problème de sécurité futur. C'est un problème d'architecture présent.

Le Top 10 d'OWASP pour les applications agencées, les conseils de sécurité de Palo Alto Networks’, l'analyse d'Auth0’ du détournement d'objectif et de la mauvaise utilisation des outils, et la communauté de sécurité plus large pointent tous dans la même direction : les organisations ont besoin de visibilité, de contrôle d'identité, de garde-fous d'exécution, de gouvernance des outils, de protection de la mémoire et de supervision humaine pour les agents IA.

Vous ne pouvez pas boulonner tout cela sur une architecture fragile à la fin et attendre qu'elle tienne.

Si votre organisation expérimente avec des agents IA, déploie des flux de travail agencés ou essaie de comprendre si votre modèle de sécurité est prêt pour les systèmes autonomes, Ridiculous Engineering peut aider. Nous travaillons avec des équipes pour évaluer l'architecture, identifier le risque agencé et concevoir des contrôles qui permettent aux systèmes IA d'opérer avec les bonnes limites.

L'IA agencée peut être puissante. Elle doit aussi être gouvernée comme quelque chose de puissant.

Sources et lectures complémentaires : OWASP : Top 10 pour les applications agencées 2026, Projet de sécurité GenAI d'OWASP : Top 10 des risques et atténuations pour la sécurité de l'IA agencée, Palo Alto Networks : OWASP Top 10 pour les applications agencées 2026, Auth0 : Leçons du Top 10 d'OWASP pour les applications agencées, DeepTeam : OWASP Top 10 pour les agents 2026, Teleport : OWASP Top 10 pour les applications agencées

OWASP Agentic AI Top 10 : Ce que les équipes de sécurité doivent préparer pour 2026