Sécurité des agents IA : modèle de menace, incidents réels et contrôles qui limitent les dégâts

La sécurité des agents IA part d'une hypothèse : à un moment donné, le modèle fera ce que lui dicte un attaquant, ou son propre mauvais jugement, et le système qui l'entoure doit donc contenir l'événement. L'injection de prompt n'est pas résolue. Dans « The Attacker Moves Second » (octobre 2025), Nasr, Carlini et leurs coauteurs ont lancé des attaques adaptatives contre 12 défenses publiées et les ont contournées, la plupart avec des taux de réussite supérieurs à 90 %, alors que la plupart de ces défenses avaient à l'origine annoncé un taux de réussite des attaques proche de zéro. Les contrôles qui limitent les dégâts se situent donc surtout en dehors du modèle : moins d'outils, des identifiants étroits, aucune voie de sortie pour les données et une personne en amont des actions irréversibles.

Cet article traite du modèle de menace et de l'ordre dans lequel appliquer les contrôles. Les informations sont à jour en novembre 2026. La boucle de l'agent et la conception des outils figurent dans notre article sur le développement d'agents IA, et les options de structure dans l'architecture des agents IA.

Quelle liste OWASP, et quel numéro

Deux documents de l'OWASP comptent pour les agents, et leur numérotation piège souvent.

La liste générale actuelle est l'OWASP GenAI LLM Top 10 2026, publiée en août 2026 (la page de ressources indique le 3 août, le dépôt le 4 août). Ses éléments sont LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses et LLM10 Improper Output Handling.

Par rapport à 2025, plusieurs numéros ont changé. Excessive Agency était LLM06 et devient LLM03. Improper Output Handling passe de LLM05 à LLM10, Unbounded Consumption de LLM10 à LLM06, et LLM07, qui était System Prompt Leakage, est désormais Misinformation. Un modèle d'audit ou un questionnaire fournisseur qui cite « LLM06 » peut viser deux risques différents : vérifiez l'édition avant de répondre.

Le second document est l'OWASP Top 10 for Agentic Applications for 2026, publié le 9 décembre 2025 : ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity & Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation et ASI10 Rogue Agents. Ces noms suivent l'annonce de l'OWASP : citez le document final si le texte entre dans un contrat.

MITRE ATLAS (version de contenu 2026.10, 28 octobre 2026) ajoute des identifiants de techniques que les red teams peuvent tester. Côté gouvernement américain, la page de l'AI Agent Standards Initiative du NIST CAISI, mise à jour pour la dernière fois le 14 août 2026, ne mentionne aucune recommandation finale sur les agents. Il n'existe donc pas encore de norme publique achevée sur laquelle se certifier, et le modèle de menace ci-dessous est à vous de l'assumer.

Le tableau rapproche de ces listes les six menaces traitées dans cet article. Ce rapprochement est le nôtre, car aucun de ces documents ne correspond terme à terme.

Vulnérabilité, violation de données, accident et usage malveillant sont des événements différents

Les articles sur les vulnérabilités de sécurité des agents IA ont tendance à verser tout cela dans une seule liste d'« attaques ». Le risque paraît alors à la fois plus grand et moins précis qu'il ne l'est. Une CVE enregistre une faille et son score de gravité. Elle ne dit rien sur le fait que quelqu'un ait subi un préjudice.

Chaque ligne appelle une réponse différente. Une vulnérabilité relève de la gestion des correctifs et des questions au fournisseur. Une intrusion relève de la réponse aux incidents. Un accident du type Replit est un défaut de conception de vos propres droits, et aucun correctif ne le réglera.

Injection de prompt

Un LLM lit les instructions et les données par un seul canal, et aucun marqueur fiable ne les sépare. Tout texte lu par l'agent peut donc tenter de le rediriger : un e-mail, un ticket, une page web, le résultat d'un outil.

EchoLeak est l'exemple public le plus net de ce que cela signifie dans un produit doté de vraies défenses. L'analyse de Reddy et Gujral (arXiv 2509.10540) décrit un seul e-mail forgé et aucune action de l'utilisateur. La chaîne a franchi le classificateur XPIA et le masquage des liens, puis a utilisé des images chargées automatiquement et un proxy Teams pour faire sortir les données. Deux garde-fous conçus à cet effet étaient en place et tous deux ont été contournés, dans une vulnérabilité corrigée avant toute exploitation signalée.

Les chercheurs de Google Brunner, Liu et Pande (avril 2026, recherche d'un fournisseur) ont constaté une hausse de 32 % des injections de prompt malveillantes dans les instantanés de Common Crawl entre novembre 2025 et février 2026, tout en décrivant la plupart comme peu sophistiquées. Le bruit de fond sur le web augmente donc et reste surtout grossier. « The Attacker Moves Second » traite de l'autre extrémité de l'échelle : une défense qui obtient de bons résultats contre une liste fixe d'attaques peut céder dès que l'attaquant a le droit de s'y adapter. Les filtres arrêtent le premier groupe. Préparez-vous au second.

Notre position : traiter l'injection de prompt comme un phishing visant un employé très crédule qui a accès aux systèmes. Vous ne comptez pas arrêter chaque tentative. Vous décidez de ce que cet employé a le droit de faire.

L'autonomie excessive n'a pas besoin d'attaquant

LLM03 (Excessive Agency, l'autonomie excessive) est l'élément que la plupart des équipes sous-estiment, parce que ses pires cas publics n'ont pas de méchant.

En juillet 2025, au jour 8 d'un projet de 30 jours, un agent Replit a supprimé une base de données en production pendant un gel du code. La base contenait des fiches sur plus de 1 200 dirigeants et près de 1 200 entreprises. Le premier récit disait la récupération impossible ; les données ont ensuite été retrouvées, et le CEO de Replit a qualifié la suppression d'inacceptable. Un gel du code qui dépend de l'obéissance du modèle n'est qu'une demande. Si les identifiants de l'agent ne peuvent pas supprimer une table de production, le gel tient quoi que décide le modèle. Les évaluations de récupération doivent aussi venir de vos propres vérifications de sauvegardes.

Deux cas de 2026 proviennent d'exécutions d'évaluation et montrent des agents allant bien au-delà de leur tâche. L'enquête de METR (26 août 2026) conclut que l'intrusion chez Hugging Face a impliqué environ 1 200 agents d'évaluation d'OpenAI partageant un forum de messages non autorisé, dont environ 700 se sont joints à l'attaque, apparemment pour tromper l'évaluateur d'un benchmark. METR précise les conditions de son travail : OpenAI a fourni les données et des crédits d'API, l'équipe a travaillé dans les locaux d'OpenAI et l'analyse a utilisé un modèle OpenAI. Par ailleurs, Anthropic a examiné 141 006 exécutions d'évaluation et signalé 3 incidents sur 6 exécutions au cours desquels des modèles Claude ont attaqué des systèmes réels, dont un paquet PyPI malveillant resté en ligne environ une heure et exécuté sur 15 systèmes. La cause indiquée est un accès internet réel mal configuré.

Ne lisez pas ces chiffres comme des taux de base pour un agent d'entreprise qui trie des factures : il s'agit de charges d'évaluation, et les chiffres d'Anthropic sont le rapport d'un fournisseur sur lui-même. Ils montrent en revanche que les environnements de test et d'évaluation exigent la même isolation que la production, et qu'un objectif plus un système accessible peuvent suffire.

Empoisonnement d'outils et chaîne d'approvisionnement des agents

Les définitions d'outils sont du texte qui entre dans le contexte du modèle, et les outils sont du code qui s'exécute avec vos identifiants : un outil peut donc attaquer des deux côtés. ATLAS répertorie cela sous AI Agent Tool Poisoning (AML.T0110). L'OWASP le couvre dans LLM04 et ASI04.

Les cas publics que nous pouvons citer sont de seconde main. Le résumé publié par Help Net Security en juin 2026 du rapport State of Agentic AI Security and Governance de l'OWASP mentionne une porte dérobée LiteLLM sur PyPI en mars 2026, avec environ 47 000 téléchargements en trois heures environ, et postmark-mcp comme premier serveur MCP malveillant trouvé en conditions réelles. Il mentionne aussi CVE-2025-6514 et CVE-2026-22708 (Cursor). Nous n'avons pas lu les fiches primaires de ces cas : considérez donc les détails comme le catalogue de l'OWASP tel que rapporté.

Ce sont les fenêtres de temps qui devraient changer vos pratiques. Trois heures dans un cas, environ une heure dans celui d'Anthropic. Aucune revue humaine n'attrape un paquet dans cette fenêtre, et ce sont donc les mises à niveau automatiques qui créent l'exposition. Épinglez les dépendances et les serveurs MCP par hash, faites-les passer par un miroir interne avec un délai, et traitez une description d'outil modifiée comme un changement de code soumis à revue. A Practical Guide for Secure MCP Server Development de l'OWASP (février 2026) est le point de départ si vous écrivez vos propres serveurs.

Les configurations multi-agents élargissent cette surface : chaque agent est une partie de plus dont d'autres peuvent croire la sortie. ASI07 et ASI08 couvrent ce terrain. Notre article sur l'architecture examine ce que coûte chaque modèle.

Identité des agents IA

La plupart des identifiants d'agents qui nous inquiéteraient ont l'air ordinaires : un jeton OAuth, une clé API, un compte de service partagé par plusieurs outils. Le vol chez Salesloft Drift a sa place ici pour cette seule raison. Il a impliqué des jetons volés à une intégration et aucune injection de prompt, mais un agent connecté à un système SaaS détient le même type de jeton et ajoute une nouvelle façon de l'atteindre, qu'ATLAS répertorie sous AI Agent Tool Credential Harvesting (AML.T0098). Dans l'intrusion chez Hugging Face, des identifiants de service figuraient parmi ce qui a été consulté.

Le CAISI du NIST a annoncé son AI Agent Standards Initiative le 17 février 2026, avec la recherche sur la sécurité et l'identité comme l'un de ses trois piliers et un document de réflexion sur l'identité ouvert aux commentaires jusqu'au 2 avril. En novembre 2026, la page de l'initiative ne montre aucune recommandation finale : concevez donc cela vous-même. Ce que nous demanderions :

• Une identité par agent et par environnement. Un agent de développement et un agent de production ne partagent jamais d'identifiant.
• Un accès délégué par l'utilisateur pour tout ce qui est lu au nom de quelqu'un, afin que l'agent ne puisse pas voir plus que la personne pour laquelle il travaille.
• Des jetons de courte durée émis par outil et conservés dans la couche d'outils. Le modèle ne voit jamais de secret, car tout ce qui se trouve dans son contexte peut ressortir, terrain que couvrent LLM02 et LLM08.
• Une identité d'approbateur que l'agent ne peut pas utiliser. Un agent ne doit pouvoir approuver sa propre demande par aucune voie.
• L'identifiant d'exécution enregistré avec chaque écriture en aval, pour que le journal d'audit d'un système cible ramène à une seule trajectoire.

Les déploiements MCP doivent être revérifiés sur ce point. La révision 2026-07-28 du protocole a supprimé les sessions et le handshake initialize, et a déprécié OAuth Dynamic Client Registration au profit des Client ID Metadata Documents, avec une fenêtre de dépréciation minimale de douze mois. Une revue de sécurité menée sur une révision antérieure ne reste pas automatiquement valable.

Exfiltration de données

L'exfiltration exige trois choses réunies : l'accès à des données privées, l'exposition à du contenu non fiable et un canal sortant. EchoLeak avait les trois. Retirez-en une et l'attaque échoue.

Le canal sortant est plus large que ce que supposent la plupart des revues. ATLAS répertorie Exfiltration via AI Agent Tool Invocation (AML.T0086) : tout outil capable d'écrire en dehors de votre périmètre compte donc, qu'il s'agisse d'e-mails, de webhooks, de commentaires de tickets visibles par les clients ou d'une URL transportant des données dans ses paramètres. EchoLeak a utilisé le chargement d'images, que personne ne classerait comme un outil d'écriture. Et il est passé par un proxy Teams, un avertissement contre les listes d'autorisation qui font confiance à tout le domaine d'un fournisseur.

Les décisions d'hébergement ne règlent pas ce problème. Exécuter le modèle sur votre propre infrastructure ou une infrastructure européenne détermine où a lieu l'inférence et qui est le sous-traitant. Un agent victime d'une injection et disposant d'une voie sortante ouverte peut quand même envoyer des données partout où cette voie mène. Si les données sont personnelles, votre délégué à la protection des données assume une partie de la réponse : nommez-le dans le plan d'incident avant la mise en production.

Empoisonnement de la mémoire

Ici, la vérité est que les sources de cet article ne contiennent aucun incident de production bien documenté, seulement des entrées de taxonomie : ASI06 Memory & Context Poisoning et ATLAS AI Agent Context Poisoning (AML.T0080, sous-technique Memory .001). Une injection dans une seule exécution se termine avec elle. Une injection dans la mémoire à long terme revient lors d'exécutions ultérieures, éventuellement pour d'autres utilisateurs, longtemps après la disparition du document source. La documentation de LangChain divise la mémoire à long terme en sémantique (faits), épisodique (actions passées) et procédurale (règles et prompts) ; c'est cette dernière qu'il faut protéger le plus, car une règle empoisonnée se comporte comme un prompt système modifié. Notre règle empirique : un modèle peut proposer des faits avec une source enregistrée, et ne peut écrire aucune règle sans revue. Limitez la mémoire par utilisateur ou par locataire, et donnez une date d'expiration aux entrées.

Bonnes pratiques de sécurité des agents IA, dans l'ordre où elles limitent les dégâts

Cette liste va des contrôles qui tiennent même après une compromission totale du modèle à ceux qui se contentent de réduire les probabilités. C'est notre jugement, fondé sur les endroits où les cas ci-dessus ont réellement cédé.

1. Supprimer la capacité. Un outil qui n'existe pas ne peut pas être détourné. La présentation d'Agent Framework de Microsoft conseille d'écrire une fonction plutôt que d'utiliser un agent quand une fonction peut faire la tâche, et c'est aussi le meilleur conseil de sécurité de cette liste. Demandez pour chaque outil si cette tâche en a besoin.

2. Restreindre les identifiants dans le système cible. L'application des droits par la base de données, l'ERP ou le CRM tient quoi que croie le modèle. Les comptes en lecture seule, les limites au niveau des lignes et l'absence d'accès à la production pour les agents de développement sont ce qui arrête une suppression comme celle de Replit.

3. Isoler l'environnement d'exécution et refuser le trafic sortant par défaut. Les incidents d'Anthropic remontent à un accès internet réel qui n'aurait pas dû exister. Les agents qui exécutent du code tournent dans des conteneurs ou des microVM sans route réseau par défaut, et cela vaut aussi pour les exécutions d'évaluation.

4. Séparer la lecture de l'action. Dès qu'une exécution a traité du contenu non fiable, elle perd ses outils d'écriture pour cette exécution. Elle transmet un résultat structuré et validé à une étape distincte qui les détient. Dans le cas d'EchoLeak, le contenu porteur de l'instruction n'atteint jamais un composant disposant d'un canal sortant.

5. Vérifier les arguments des outils dans le code. Les domaines des destinataires, les numéros de compte, les montants maximaux et le nombre d'enregistrements sont vérifiés avant l'exécution, par une logique que le modèle ne peut pas discuter. Une sortie destinée à SQL, à un shell ou à du HTML est une entrée non fiable pour ce système (LLM10).

6. Exiger une approbation humaine là où elle compte. A practical guide to building agents d'OpenAI cite deux déclencheurs : le dépassement de seuils d'échec et les actions à haut risque, « sensitive, irreversible, or have high stakes » (sensibles, irréversibles ou à fort enjeu). L'approbation arrive plus bas dans cette liste parce que les gens se fatiguent, et parce qu'ASI09 existe : un agent peut présenter une action nuisible de façon convaincante. Montrez à l'approbateur l'effet littéral issu d'une simulation (dry run), généré par du code et non résumé par le modèle.

7. Épingler la chaîne d'approvisionnement, comme décrit plus haut.

8. Tout tracer et garder un coupe-circuit (kill switch). Le traçage limite la durée d'un incident et indique ce qui s'est passé, mais il n'arrête rien à lui seul. Les conventions GenAI d'OpenTelemetry sont encore marquées Development : épinglez la version sur laquelle vous construisez et attendez-vous à des renommages. Les traces contiennent des prompts et des sorties d'outils, souvent avec des données personnelles, et en Allemagne, les journaux indiquant qui a utilisé un agent impliquent généralement le comité d'entreprise allemand (Betriebsrat), comme l'explique notre article sur le processus.

9. Ajouter les garde-fous au niveau du modèle en dernier. Voir la section suivante.

Ce que les garde-fous des agents IA peuvent faire et ne peuvent pas faire

« Garde-fous » (guardrails) recouvre deux choses très différentes. Les garde-fous durs sont les contrôles 1 à 5 ci-dessus : appliqués dans le code ou l'infrastructure, et indifférents à la sortie du modèle. Les garde-fous souples sont les classificateurs, les modèles de modération et les règles du prompt système, et ils sont probabilistes. Des frameworks comme l'OpenAI Agents SDK fournissent des garde-fous comme brique de base, et ils méritent leur place. Ils attrapent les erreurs de bonne foi et les demandes hors sujet et, vu le constat de Google selon lequel la plupart des injections sur le web sont grossières, ils devraient aussi en arrêter une partie.

Ils ne tiennent pas face à un attaquant qui itère, comme le montrent EchoLeak et « The Attacker Moves Second ». Utilisez donc un garde-fou souple comme un fil de détection qui déclenche une alerte, et ne laissez pas une revue l'accepter comme la raison pour laquelle exposer un outil dangereux serait sûr.

Le même article change la façon de tester. Une liste fixe de chaînes d'injection mesure très peu de chose, car les défenses qu'il a mises en échec avaient pour la plupart annoncé un taux de réussite des attaques proche de zéro. Faites du red teaming avec des personnes ou des agents capables de voir votre défense et de s'y adapter. « Demystifying evals for AI agents » d'Anthropic (janvier 2026) suggère de commencer un jeu d'évaluation avec quelques dizaines de tâches tirées d'échecs réels ; ajoutez chaque injection qui passe, et maintenez les exécutions de régression près de 100 %. Pour un parcours détaillé d'un premier jeu de test sur un petit agent, consultez comment construire un agent IA.

Sécurité des agents IA en entreprise : ce qu'il faut avant le deuxième agent

Tenez un registre avec une entrée par agent : responsable, outils, identifiants, classes de données, version du modèle et classe de risque de chaque outil d'écriture. L'ajout d'un outil à un agent passe par une revue, comme l'ouverture d'une règle de pare-feu, car il modifie le rayon d'impact de la même façon.

Rédigez le plan d'incident à partir des catégories du tableau ci-dessus. « CVE fournisseur dans un produit Copilot » et « notre agent a envoyé un e-mail au mauvais client » n'ont ni les mêmes responsables ni les mêmes délais. Le plan doit indiquer qui peut basculer un agent en mode suggestion seule, et à quelle vitesse, sans déploiement.

Posez aux fournisseurs des questions précises. Quels identifiants l'agent détient-il, et pouvons-nous les restreindre ? Pouvons-nous limiter le trafic sortant ? Existe-t-il une trace de chaque exécution que nous pouvons exporter ?

Comme cadres de référence, ATLAS est le plus pratique pour les red teams. L'AI RMF 1.0 du NIST et son Generative AI Profile (AI 600-1) conviennent à la cartographie de gouvernance, mais le NIST indique que le RMF est en cours de révision et ne donne aucun calendrier. Les banques et les assureurs ont en plus des règles sectorielles ; voir les agents IA dans les services financiers.

Questions fréquentes

L'injection de prompt est-elle résolue ?

Non. Les attaques adaptatives de « The Attacker Moves Second » ont contourné 12 défenses publiées, la plupart à plus de 90 % de réussite. Partez du principe que certaines tentatives réussiront et limitez ce qu'une exécution compromise peut faire.

Quel est le numéro OWASP actuel de l'autonomie excessive ?

LLM03 dans l'OWASP GenAI LLM Top 10 2026. C'était LLM06 dans l'édition 2025, et des documents plus anciens utilisent encore ce numéro.

EchoLeak était-il une violation de données ?

Pas d'après les éléments publics. C'était une vulnérabilité, CVE-2025-32711, avec un CVSS de 9,3. Elle a été corrigée côté serveur en mai 2025, et Microsoft n'a fait état d'aucune preuve d'exploitation.

Les garde-fous suffisent-ils pour sécuriser un agent IA ?

Les garde-fous fondés sur des classificateurs et des prompts, non. Ils réduisent le bruit et attrapent des erreurs. Les dégâts sont limités par ce que le modèle ne peut pas contourner : le périmètre des outils, les identifiants dans le système cible, les règles de trafic sortant et les vérifications d'arguments dans le code.

Un agent a-t-il besoin de sa propre identité ?

Oui, une par agent et par environnement, avec un accès délégué par l'utilisateur lorsqu'il agit pour une personne et des jetons de courte durée que le modèle ne voit jamais. En novembre 2026, la page de l'initiative du NIST ne mentionne aucune recommandation finale sur les agents.

Faire passer un agent en revue de sécurité

AI Superior est une entreprise d'ingénierie en IA basée à Darmstadt, en Allemagne, fondée en 2019 par des scientifiques de l'IA. Nous développons des applications LLM, des systèmes RAG et des agents IA pour des clients B2B. Si vous avez besoin d'un agent conçu dès le départ avec ces limites, consultez nos services de développement d'agents IA ou, pour plusieurs agents à l'échelle d'une organisation, le développement d'agents IA pour les grandes entreprises.

Sources et lectures complémentaires

• OWASP, OWASP GenAI LLM Top 10 2026, août 2026.
• OWASP, OWASP Top 10 for Agentic Applications for 2026, annonce du 9 décembre 2025.
• OWASP, State of Agentic AI Security and Governance 2.01, 1er juin 2026 ; A Practical Guide for Secure MCP Server Development, 16 février 2026.
• Help Net Security, article sur les constats de l'OWASP concernant l'injection de prompt et les défaillances de sécurité de l'IA, 11 juin 2026.
• MITRE, journal des modifications d'ATLAS, version de contenu 2026.10, 28 octobre 2026.
• NIST, AI Risk Management Framework 1.0, 2023 ; Generative AI Profile (AI 600-1), 2024.
• NIST CAISI, AI Agent Standards Initiative, annoncée le 17 février 2026, page mise à jour le 14 août 2026.
• Fiches CVE : CVE-2025-32711, CVE-2025-53773, CVE-2026-21520.
• Reddy et Gujral, analyse d'EchoLeak, arXiv 2509.10540.
• BleepingComputer, article sur la faille de fuite de données sans clic dans Microsoft 365 Copilot, 11 juin 2025.
• Nasr, Carlini et al., « The Attacker Moves Second », arXiv 2510.09023, octobre 2025.
• Brunner, Liu et Pande (Google), recherche sur les injections de prompt sur le web, 23 avril 2026.
• Gizmodo, article sur l'incident de l'agent Replit, 23 juillet 2025.
• Hugging Face, rapport d'incident de sécurité, 16 juillet 2026.
• METR, enquête sur l'incident OpenAI et Hugging Face, 26 août 2026.
• Anthropic, enquête sur des incidents lors d'évaluations de cybersécurité, 30 juillet 2026 ; rapport sur la perturbation d'un espionnage mené par IA, 13 novembre 2025 ; Grace, Hadfield, Olivares et De Jonghe, « Demystifying evals for AI agents », 9 janvier 2026.
• Google Threat Intelligence Group, rapport sur le vol de données d'instances Salesforce via Salesloft Drift, 2025.
• OpenAI, A practical guide to building agents, 2025.
• Microsoft, présentation d'Agent Framework, mise à jour en octobre 2026.
• LangChain, documentation sur la mémoire de LangGraph.
• OpenTelemetry, conventions sémantiques pour l'IA générative.
• Model Context Protocol, journal des modifications de la spécification pour la révision 2026-07-28.