Cybersécurité · IA agentique
Agents IA en entreprise : comprendre le Top 10 OWASP des applications agentiques 2026
Un agent connecté à un CRM, une messagerie ou une base documentaire ne présente pas les mêmes risques qu’un assistant limité à une réponse. Le Top 10 OWASP 2026 aide à cadrer cette nouvelle surface d’action.
Un assistant limité à la génération d’une réponse n’a pas le même niveau de risque qu’un agent capable de consulter un CRM, de modifier une fiche client ou d’envoyer un message. Certains assistants utilisent déjà des outils ou des workflows ; la différence importante tient au degré d’autonomie, à la capacité de planification et à la portée des actions possibles.
C’est cette évolution que prend en compte l’OWASP avec son Top 10 for Agentic Applications 2026. Ce référentiel identifie les principaux risques liés aux systèmes d’intelligence artificielle capables de planifier, d’utiliser des outils et d’agir dans des processus complexes. Il ne s’agit pas d’une norme réglementaire, mais d’un cadre de travail utile pour les organisations qui commencent à connecter des agents à leurs applications.
Pour une PME, la question n’est pas de savoir si un agent est impressionnant dans une démonstration. Il faut surtout déterminer ce qu’il peut voir, ce qu’il peut faire et comment l’entreprise peut interrompre ou corriger son action.
Un agent connecté n’est pas un simple chatbot
Un chatbot répond à une demande dans une interface. Un agent peut recevoir un objectif, rechercher des informations, choisir des outils, enchaîner plusieurs étapes et produire un résultat.
Imaginons une demande client reçue par e-mail. Un agent pourrait :
- identifier le client ;
- retrouver son historique dans le CRM ;
- consulter une documentation produit ;
- préparer une réponse ;
- créer une tâche pour un commercial ;
- envoyer le message après validation.
Chaque étape ajoute une possibilité d’erreur et un point d’accès à protéger. La sécurité ne concerne donc plus seulement le modèle d’intelligence artificielle. Elle concerne aussi les comptes utilisés, les outils connectés, les données consultées, les règles métier et les décisions prises entre deux appels.
Le référentiel OWASP ne doit pas être lu comme une liste de catastrophes inévitables. Il sert plutôt à poser les bonnes questions avant de donner davantage d’autonomie à un système.
Les dix risques en un coup d’œil
Le Top 10 OWASP 2026 recense dix familles de risques. Les intitulés ci-dessous reprennent les catégories du référentiel, avec une explication courte :
- ASI01 — Agent Goal Hijack : détournement de l’objectif initial de l’agent ;
- ASI02 — Tool Misuse and Exploitation : mauvais usage ou exploitation des outils ;
- ASI03 — Identity and Privilege Abuse : abus d’identité et de privilèges ;
- ASI04 — Agentic Supply Chain Vulnerabilities : vulnérabilités dans la chaîne de composants et de dépendances ;
- ASI05 — Unexpected Code Execution (RCE) : exécution de code inattendue ;
- ASI06 — Memory & Context Poisoning : empoisonnement de la mémoire ou du contexte ;
- ASI07 — Insecure Inter-Agent Communication : communications non sûres entre agents ;
- ASI08 — Cascading Failures : défaillances en cascade ;
- ASI09 — Human-Agent Trust Exploitation : exploitation de la confiance entre l’humain et l’agent ;
- ASI10 — Rogue Agents : agents qui adoptent un comportement non prévu ou échappent au périmètre défini.
Il ne s’agit pas de dix étapes obligatoires d’un projet, mais d’une grille de menaces. Cinq catégories sont particulièrement parlantes pour une application web ou un outil métier connecté :
Cinq risques particulièrement concrets
ASI01 — Le détournement de l’objectif
Un agent peut recevoir une instruction cachée dans un document, une page Web ou un e-mail consulté pendant son travail. Ce contenu peut tenter de l’amener à ignorer sa mission initiale, à divulguer une information ou à appeler un outil qui n’était pas prévu.
C’est une forme d’injection indirecte. Le contenu consulté ne doit pas être considéré comme une instruction de confiance au même titre que la demande de l’utilisateur ou que les règles de l’application.
ASI02 — Le mauvais usage des outils
Un agent peut appeler un outil légitime dans un contexte inapproprié. Une fonction de recherche, de modification ou d’envoi peut être parfaitement sécurisée sur le plan technique et pourtant trop puissante pour la tâche confiée.
Une bonne intégration ne consiste pas à donner accès à toutes les fonctions d’un CRM. Elle consiste à exposer quelques actions clairement définies, avec des paramètres contrôlés et des règles d’autorisation vérifiables.
ASI03 — Les abus d’identité et de privilèges
Si l’agent utilise un compte unique disposant de droits très larges, une erreur ou une manipulation peut toucher de nombreux utilisateurs et de nombreuses données. Le problème devient encore plus important lorsque l’application ne vérifie pas que l’action demandée correspond bien aux droits de la personne à l’origine de la demande.
L’agent doit agir dans un périmètre limité. Il ne devrait pas pouvoir consulter tout le CRM, supprimer une commande ou modifier un contrat simplement parce qu’il est techniquement connecté à ces fonctions.
ASI06 — L’empoisonnement de la mémoire et du contexte
Certains agents conservent des informations entre deux tâches. Ces mémoires peuvent aider à personnaliser le service, mais elles deviennent aussi une nouvelle surface d’attaque. Une donnée fausse, une instruction malveillante ou une information devenue obsolète peut influencer des décisions ultérieures.
Il faut donc savoir quelles informations sont conservées, combien de temps, qui peut les modifier et comment les supprimer ou les corriger.
ASI08 — Les défaillances en cascade
Un agent peut dépendre de plusieurs services : modèle d’IA, moteur de recherche, CRM, messagerie, base documentaire ou système de paiement. Une erreur sur un maillon peut être transmise au suivant et produire une série d’actions incorrectes.
Un bon fonctionnement doit prévoir des limites : nombre maximal d’actions, délai d’exécution, budget, conditions d’arrêt et retour à un traitement humain.
Les contrôles à mettre en place dans une PME
Le niveau de contrôle nécessaire dépend de la sensibilité des données, des droits accordés et des actions possibles. Pour un cas limité et réversible, une première démarche ciblée peut constituer un niveau de maîtrise raisonnable ; un CRM, des données personnelles ou des actions financières exigent une analyse plus approfondie.
Séparer lecture, préparation et exécution
Un agent peut d’abord être limité à la recherche et à la synthèse. Dans une deuxième étape, il peut préparer une action pour un collaborateur. L’exécution automatique ne vient qu’après des tests satisfaisants et uniquement pour les opérations suffisamment réversibles ou peu sensibles au regard du contexte.
Par exemple, dans un scénario illustratif, un agent peut proposer une réponse à un client sans l’envoyer. Le collaborateur vérifie le contenu, les destinataires et les pièces jointes avant de valider.
Limiter les permissions
Chaque outil doit avoir les droits minimum nécessaires à la tâche. Les comptes, jetons et environnements doivent être séparés lorsque cela est possible. Une autorisation temporaire et ciblée est préférable à un accès permanent et général.
Cette règle vaut aussi pour les données. Un agent chargé de qualifier une demande commerciale n’a pas nécessairement besoin d’accéder aux informations de paie, aux contrats complets ou à l’ensemble des échanges internes.
Valider les entrées et les sorties
Les données reçues par l’agent doivent être contrôlées avant d’être utilisées. Les paramètres transmis à un outil doivent également être vérifiés par l’application, et non uniquement par le modèle.
Une application ne devrait pas considérer qu’une réponse bien formulée constitue une autorisation métier. La décision d’envoyer, supprimer, acheter ou modifier doit rester soumise aux règles de l’application et, selon le niveau d’impact, la réversibilité et le contexte métier, à une validation humaine.
Journaliser les actions
Il doit être possible de retrouver :
- la demande initiale ;
- les données consultées ;
- les outils appelés ;
- les actions exécutées ;
- les validations humaines ;
- les erreurs et les arrêts du processus.
Cette traçabilité sert à comprendre un incident, mais aussi à améliorer le fonctionnement courant. Elle doit toutefois être conçue avec la même attention que les autres données de l’entreprise : un journal peut contenir des informations sensibles. Il faut donc prévoir une durée de conservation, des accès limités et une collecte proportionnée, notamment lorsque l’agent traite des données personnelles.
Tester les scénarios d’échec
Avant de relier un agent à des données réelles, tester des situations concrètes : document contenant une instruction hostile, compte sans autorisation, outil indisponible, réponse ambiguë, boucle trop longue ou demande de suppression.
Les tests doivent utiliser des données non sensibles au départ. Ils doivent vérifier non seulement la qualité de la réponse, mais aussi la capacité du système à refuser une action, à s’arrêter et à demander l’intervention d’une personne.
Que faire avant de connecter un agent à un CRM ?
Un projet raisonnable peut commencer par une courte analyse du processus concerné.
1. Décrire la tâche et le résultat attendu. 2. Lister les données nécessaires et celles qui ne le sont pas. 3. Distinguer les opérations de lecture, de préparation et d’écriture. 4. Définir les actions qui exigent une validation humaine. 5. Prévoir un compte ou un rôle limité pour l’agent. 6. Fixer des limites de coût, de durée et de volume. 7. Définir les actions réversibles, les possibilités d’annulation et le mode manuel de secours. 8. Journaliser les appels avec une conservation et des accès maîtrisés. 9. Mesurer les erreurs, les interventions humaines et le temps réellement gagné.
Cette démarche permet de commencer par un processus borné, plutôt que de connecter immédiatement tous les outils de l’entreprise.
Le Top 10 OWASP n’est pas une certification
Le référentiel OWASP est une ressource de sensibilisation et de conception. Il ne certifie pas une application et ne remplace pas une analyse de sécurité, un audit, une étude juridique ou les règles propres à un secteur.
Il a néanmoins une utilité concrète : il rappelle qu’un agent doit être considéré comme une nouvelle couche d’exécution dans le système d’information. Les contrôles doivent donc porter sur le modèle, mais aussi sur les outils, les identités, les données, la mémoire, les dépendances et les mécanismes d’arrêt.
Comme pour toute application web bien conçue, un outil doit rester compréhensible, administrable et évolutif. Ajouter une capacité d’action à une IA ne dispense pas de documenter les règles métier ni de conserver une possibilité de contrôle humain.
Conclusion
Les agents IA peuvent simplifier certaines tâches et coordonner plusieurs outils. Ils augmentent aussi la portée d’une erreur lorsqu’ils disposent de droits trop larges ou de données mal maîtrisées.
Avant de chercher davantage d’autonomie, il est donc préférable de répondre à quelques questions concrètes : quelles données l’agent peut-il consulter ? Quelles actions peut-il proposer ? Lesquelles peut-il exécuter ? Qui valide les exceptions ? Comment arrêter le processus ?
Le Top 10 OWASP 2026 fournit une base utile pour organiser cette réflexion. Pour une PME, la sécurité d’un agent ne commence pas par un écran spectaculaire. Elle commence par un périmètre limité, des droits précis, des traces exploitables et une personne capable de reprendre la main.