Sécurité des agents IA & OWASP

Ce que recouvre la sécurité des agents IA selon l'OWASP

Selon l'OWASP, la sécurité des agents IA désigne la protection systématique des agents IA autonomes contre les menaces qui découlent de leur capacité à planifier par eux-mêmes, à appeler des outils, à écrire dans une mémoire persistante et à agir, avec une validation humaine minimale à chaque étape. Alors qu'un chatbot classique se contente le plus souvent de répondre (un prompt en entrée, une complétion en sortie, éventuellement ancrée via RAG), les agents planifient, raisonnent, choisissent des outils, écrivent en mémoire et agissent. Ce changement de niveau d'abstraction élargit la surface d'attaque selon trois axes : l'autonomie (plans en plusieurs étapes, automodification du contexte et de la mémoire), l'utilisation d'outils (système de fichiers, API, connecteurs de bases de données, sandboxes de code, serveurs MCP, pairs du protocole A2A) et la persistance (mémoires à long terme, bases de données vectorielles, chaînes de confiance d'agent à agent).

L'OWASP le formule ainsi, dans les termes propres au GenAI Security Project (Sotiropoulos et al., 9 décembre 2025) : les systèmes agentiques héritent de tous les risques des LLM et introduisent des classes de vulnérabilités entièrement nouvelles, issues de l'autonomie, de l'intégration d'outils, de la coordination multi-agents et de l'état persistant. Pour les décideurs, l'enseignement central est le suivant : qui lit uniquement le Top 10 LLM sous-estime systématiquement le risque agentique.

Les deux listes OWASP de référence

L'OWASP GenAI Security Project (genai.owasp.org) publie une famille de référentiels de sécurité IA qui se recoupent. Deux d'entre eux sont essentiels pour les agents :

• OWASP Top 10 pour les applications LLM 2025 (LLM01:2025 à LLM10:2025). Couvre les risques liés au modèle et à l'application dans toute application d'IA générative ou de LLM, qu'elle soit conversationnelle, basée sur RAG, de type copilote ou agentique. C'est la référence que la plupart des équipes de sécurité de la région DACH (Allemagne, Autriche, Suisse) connaissent déjà. Depuis le 3 août 2026, une édition 2026 est disponible. Excessive Agency y occupe la 3e place (LLM03:2026). Les correspondances de cette page suivent la numérotation de 2025.
• OWASP Top 10 for Agentic Applications 2026 (ASI01 à ASI10). Publié le 9 décembre 2025 par la même initiative (Agentic Security Initiative), avec plus de 100 contributeurs et un Expert Review Board (notamment NIST, Alan Turing Institute, Microsoft AI Red Team, AWS/CoSAI, Zenity). C'est la colonne vertébrale de la modélisation des menaces propres aux agents.

Remarque importante sur la taxonomie : la liste canonique de décembre 2025 diffère d'un ancien document de travail de l'OWASP (« Agentic AI Threats and Mitigations v1.0 », février 2025, souvent cité comme « 15 agentic threats »). De nombreux articles de praticiens publiés entre le début et le milieu de 2025 utilisent encore cette numérotation provisoire (par exemple « Memory Poisoning comme ASI01 »). Elle relève de versions historiques, pas du Top 10 final. Les anciennes catégories s'intègrent aujourd'hui dans la liste consolidée. Memory Poisoning relève d'ASI06, le contournement du HITL d'ASI09.

ASI01–ASI10 en un coup d'œil

Les dix menaces agentiques canoniques et leurs principales catégories de contrôle :

La logique d'amplification est décisive : selon le mapping de DeepTeam, ASI01 = LLM01 (Prompt Injection) × LLM06 (Excessive Agency), avec en plus une exécution en plusieurs étapes qui démultiplie les dégâts au-delà d'une réponse isolée. ASI03, ASI07 et ASI08 n'ont pas d'équivalent direct dans le Top 10 LLM, et ASI10 n'est que partiellement lié à LLM06:2025.

Injection de prompt et Agent Goal Hijack (ASI01)

Avec ASI01, un attaquant manipule les objectifs, le choix des tâches ou les chemins de décision d'un agent, soit par injection de prompt directe, soit indirectement via des instructions cachées dans des documents, un corpus RAG, des e-mails, des invitations d'agenda, des descriptions de PR ou des sorties d'outils. Le fond du problème : les agents et le modèle sous-jacent ne savent pas distinguer de manière fiable les instructions des données ; tout texte que lit l'agent fait partie de la surface d'attaque.

Le tournant documenté est EchoLeak (CVE-2025-32711, CVSS 9.3), révélé par Aim Labs en juin 2025 dans Microsoft 365 Copilot : la première injection de prompt zero-click documentée dans un système en production. Un seul e-mail piégé a contourné le classificateur XPIA de Microsoft et exfiltré, via un proxy Teams autorisé, les contenus les plus sensibles du contexte de Copilot, sans le moindre clic de l'utilisateur (Aim Labs a forgé le terme « LLM Scope Violation » ; analyse technique détaillée : arXiv 2509.10540, Reddy et al., septembre 2025). Microsoft a corrigé la faille côté serveur. Autres cas : GitHub Copilot YOLO Mode (CVE-2025-53773) et CamoLeak dans GitHub Copilot Chat (CVSS 9.6), qui a extrait caractère par caractère des secrets de dépôts privés grâce à un contournement de la CSP passant par le propre proxy d'images Camo de GitHub. L'origine académique de la discipline remonte aux travaux de Greshake et al. (arXiv 2302.12173, 2023) sur l'injection de prompt indirecte.

Exemple DACH : un agent de service client bancaire qui lit une boîte mail partagée peut être amené, par un e-mail de « remerciement » contenant des instructions cachées, à divulguer dans sa réponse suivante des extraits de transactions d'autres clients.

Détournement d'outils (ASI02) et Excessive Agency

ASI02 se distingue subtilement de l'abus de privilèges : l'accès est légitime, l'usage ne l'est pas. L'agent agit dans le cadre de droits autorisés, mais utilise un outil légitime de manière dangereuse : il supprime des données, appelle trop souvent des API coûteuses, exécute des opérations destructives. L'Excessive Agency (LLM06:2025), c'est-à-dire l'octroi d'un pouvoir d'action non contrôlé sans limitation suffisante du périmètre ni supervision humaine, constitue le pont conceptuel vers ASI02 et, en partie, vers ASI10.

Cas documenté : avec l'Amazon Q Code Assistant (CVE-2025-8217, juillet 2025), des attaquants ont compromis un token GitHub et injecté des prompts destructeurs dans l'extension VS Code v1.84.0, qui, avec --trust-all-tools --no-interactive, auraient pu supprimer des systèmes de fichiers et des ressources cloud sans confirmation ; environ 1 million de développeurs avaient installé l'extension. Contre-mesures : moindre privilège par outil, validation de schéma de chaque argument d'outil, listes d'autorisation et de refus par rôle d'agent, désactivation de l'auto-approbation (modes « YOLO ») pour tout ce qui touche aux bases de données, aux paiements, aux communications ou aux déploiements, ainsi que des plafonds de coûts avec circuit breakers.

Memory & Context Poisoning (ASI06)

Contrairement aux chatbots, qui oublient tout d'une session à l'autre, les agents conservent une mémoire persistante : historique des conversations, préférences, contexte appris, bases RAG. Cela crée des surfaces d'attaque persistantes : une seule injection réussie empoisonne durablement la mémoire, la charge utile continue d'agir indéfiniment et chaque session future hérite de la compromission.

Preuves à l'appui : l'attaque contre la mémoire de Google Gemini (février 2025, Johann Rehberger) a démontré la « delayed tool invocation » : un document téléversé demandait à Gemini d'enregistrer de fausses informations dès que certains mots déclencheurs apparaîtraient plus tard. L'étude « Invitation Is All You Need! » (Nassi, Cohen, Yair, août 2025) a présenté 14 scénarios d'attaque contre des assistants basés sur Gemini, déclenchés par des e-mails, des invitations d'agenda et des documents partagés. Selon l'analyse de risques des auteurs, 73 % des menaces analysées présentent un risque élevé à critique pour les utilisateurs. Des blogs de sécurité, citant Lakera, décrivent un comportement d'« agent dormant » : les agents compromis développeraient des convictions erronées persistantes sur les politiques de sécurité et les défendraient face aux humains. Contre-mesures : traiter les écritures en mémoire comme sensibles du point de vue de la sécurité, métadonnées de provenance (source, horodatage, chemin d'ingestion, niveau de confiance) pour chaque entrée, isolation par tenant, audits réguliers de la mémoire et procédures d'effacement conformes à l'article 17 du RGPD (droit à l'effacement).

Contre-mesures et human-in-the-loop (ASI09)

Les agents produisent des résultats soignés, au ton assuré. Les humains ont tendance à leur faire confiance. ASI09 (Human-Agent Trust Exploitation) rend précisément cette couche de confiance attaquable : le biais d'automatisation, la déférence envers l'autorité et la « polished hallucination » conduisent les validateurs humains à approuver les recommandations sans les examiner. La couche de supervision, conçue comme un contrôle de sécurité, devient la vulnérabilité. Des éditeurs de solutions de sécurité décrivent un cas, non vérifié de manière indépendante, dans lequel un agent d'achats aurait été convaincu en trois semaines que sa limite d'autorisation s'élevait à 500 000 USD ; l'attaquant aurait ensuite passé pour 5 millions USD de fausses commandes.

Des points de contrôle HITL efficaces exigent une vérification indépendante des éléments de preuve, et pas seulement de la recommandation de l'agent : validations graduées (impact plus élevé → davantage d'approbateurs ou des preuves plus solides), interfaces qui rendent activement visibles le raisonnement, la provenance des sources et le niveau de confiance (pas un simple bouton « Approuver »), ainsi que des « test injections » périodiques pour vérifier que le HITL fonctionne réellement (comme un exercice incendie). Cela correspond directement à l'article 14 du règlement sur l'IA de l'UE (contrôle humain).

De manière transversale, le principe de défense en profondeur s'applique : aucun garde-fou isolé n'est une solution miracle. EchoLeak a contourné le classificateur XPIA de Microsoft ; chaque garde-fou publié (Bedrock Guardrails, Google Model Armor, Gemini Safety) a été contourné en quelques mois par des chercheurs compétents. Il faut plusieurs couches complémentaires : filtres d'entrée (par exemple Llama Guard 4, NVIDIA NeMo Guardrails, Microsoft Prompt Shield, Lakera Guard) + application du périmètre et de la provenance + filtres de sortie + surveillance comportementale. Les garde-fous ajoutent généralement 100–500 ms de latence chacun et présentent des taux de faux positifs plus élevés dans les contextes multilingues de la région DACH (alternance de langues DE/FR/IT/EN). Les affirmations des éditeurs du type « bloque 99,x % des injections de prompt » doivent être traitées comme du marketing tant qu'un red teaming indépendant ne les a pas vérifiées.

Conformité dans la région DACH (à titre informatif, pas un conseil juridique)

Les listes OWASP ne sont pas une certification : « OWASP-compliant » n'est pas une affirmation fiable de la part d'un éditeur ; les éditeurs peuvent mettre en œuvre les recommandations de l'OWASP, pas être « compliant ». Elles se rattachent toutefois proprement au cadre de conformité de la région DACH :

• L'article 15 du règlement sur l'IA de l'UE (exactitude, robustesse et cybersécurité) couvre largement les systèmes à haut risque, mais reste technologiquement neutre ; l'injection indirecte, les spécificités des NHI et les cascades multi-agents ne sont pas encore codifiées dans la norme et restent de la responsabilité du déployeur.
• RGPD, article 32 (mesures techniques et organisationnelles) : la plupart des menaces ASI touchent à la confidentialité, à l'intégrité, à la disponibilité et à la résilience. ASI06, par exemple, concerne l'art. 5(1)(d) (exactitude) et l'art. 17 (effacement).
• ISO/IEC 42001:2023 (annexe A, 38 contrôles répartis sur 9 objectifs) fournit les contrôles de référence, notamment A.6.2.4 (V&V), A.6.2.6 (exploitation/surveillance) et A.6.2.8 (journalisation).
• NIS2 / DORA : pour les entités essentielles et importantes, l'article 21(2) de NIS2 exige notamment la sécurité de la chaîne d'approvisionnement (→ ASI04) et le contrôle d'accès (→ ASI03) ; les articles 28–30 de DORA encadrent le risque lié aux prestataires tiers de services TIC, ce qui concerne directement les chaînes d'approvisionnement MCP et agents dans le secteur financier.

Supervision dans la région DACH : le guide d'orientation de la BaFin (18 déc. 2025) et la communication FINMA sur la surveillance 08/2024 ne sont pas contraignants, mais ils déplacent sensiblement la charge de la preuve lors des audits ; tous deux recommandent notamment des tests d'intrusion adversariaux ou des exercices cyber fondés sur des scénarios. En Autriche, la FMA a emboîté le pas avec le document d'information « Nutzung von KI im Finanzsektor » (version 1.0, état au 11 septembre 2026). Ce document n'est pas contraignant non plus. Il établit que les applications d'IA doivent dès aujourd'hui satisfaire aux exigences technologiquement neutres du droit des marchés financiers, DORA comprise, et que l'organe de direction porte la responsabilité ultime y compris pour les risques TIC liés à l'IA. Dans son rapport de situation 2025, le BSI qualifie l'injection de prompt indirecte de vecteur d'attaque actuellement le plus important contre les systèmes LLM et constate qu'aucune mesure unique ne s'avère réellement efficace contre elle.

Perspectives et conseils pratiques

L'OWASP Agentic Top 10 en est à sa version 1.0 (9 décembre 2025) et devrait évoluer au moins une fois par an. Mieux vaut ajouter genai.owasp.org à tes favoris que de considérer la liste comme figée. Trois remarques pratiques, sans détour. Premièrement, MITRE ATLAS, en tant que référentiel des tactiques adverses, accuse un retard de 6 à 12 mois sur le front agentique, en particulier pour ASI07, ASI08 et ASI10. Deuxièmement, la détection dans les déploiements d'agents en production reste faible : la plupart des stacks d'observabilité ont été conçus pour des applications classiques et ne remontent ni anomalies dans les traces de raisonnement, ni violations de provenance lors des écritures en mémoire, ni signaux de dérive comportementale ; conclure « on ne le voit pas dans le SIEM, donc ça n'arrive pas » est dangereusement faux. Troisièmement, l'« AI red teaming » n'équivaut pas à un pentest classique (autres compétences, autres outils comme Garak/PyRIT/DeepTeam, résultats probabilistes plutôt que binaires).

Pour les déployeurs en Europe, le point de départ pragmatique est le suivant : établir l'OWASP Agentic Top 10 comme registre des risques, le mettre en correspondance avec ISO 42001 et l'article 15 du règlement sur l'IA de l'UE, traiter chaque agent comme une Non-Human Identity à part entière dotée d'identifiants à courte durée de vie, mettre en place des garde-fous selon le principe de défense en profondeur, sécuriser les opérations destructives par un véritable HITL et garder un kill switch prêt pour isoler les agents malveillants. Tu trouveras des approfondissements sur l'injection de prompt, le red teaming, le monitoring et les pistes d'audit dans les articles ci-dessous.