Sécurité des agents IA : quels changements lorsqu'un modèle dispose d'outils et d'identifiants ?

La sécurité des agents IA consiste à protéger les systèmes d'IA capables d'agir, et pas seulement de répondre. Un agent dispose d'outils, d'identifiants et d'une mémoire ; le sécuriser implique donc de contrôler ce qu'il est autorisé à invoquer, l'identité qu'il porte et ce qu'il fait lors de l'exécution, plutôt que ce que prévoit son modèle.

C’est cette distinction qui définit l’étendue des dégâts. Un modèle capable de répondre à des questions peut se tromper. Un agent disposant d’un jeton API, d’une boîte mail et d’un shell peut se tromper, puis agir en conséquence, dans la limite de ses autorisations. Cette page traite de la surface d’attaque spécifique aux agents : la famille de techniques « agent » du MITRE ATLAS, l’empoisonnement des outils, l’identité et l’inventaire des agents, les incidents documentés et la détection en temps réel. Pour en savoir plus sur l'architecture environnante, le cycle de vie et la gouvernance des systèmes autonomes, y compris l'empoisonnement de la mémoire et le Top 10 de l'OWASP pour les applications basées sur des agents, consultez notre guide sur la sécurité de l'IA basée sur des agents.

Qu'est-ce que la sécurité des agents IA ?

Un agent IA est un modèle linguistique conçu pour agir. Il planifie, utilise des outils, lit et écrit dans la mémoire, conserve des identifiants et coordonne de plus en plus ses actions avec d’autres agents. Chacune de ces capacités est utile, mais chacune d’entre elles constitue également une interface accessible à un attaquant. C’est là tout le risque de sécurité lié à un agent IA : le modèle n’est pas devenu plus dangereux, il a simplement acquis des moyens d’action.

La définition la plus claire de cette distinction provient d'un organisme de normalisation plutôt que d'un fournisseur. Le « Top 10 de l'OWASP pour les applications LLM 2026 » se limite au cas du « modèle en tant que composant », c'est-à-dire un modèle intégré à une application et qui fournit des réponses. Dès lors que le modèle devient un acteur, utilisant des outils, conservant de la mémoire d’une session à l’autre et entraînant des conséquences en aval, l’OWASP le classe alors dans sa liste des « agents ». C’est là qu’un organisme de normalisation définit précisément la limite dont il est question sur cette page. Le référentiel source canonique date cette édition du 4 août 2026 et montre à quel point la limite a évolué : l’« Excessive Agency » (capacité d’action excessive) occupe désormais la troisième place (LLM03), alors qu’elle figurait en sixième position dans la liste de 2025.

En pratique, cela signifie que la sécurité des agents d'IA relève davantage d'un problème d'autorisations et d'outils que d'un problème lié au modèle lui-même. Le renforcement de la sécurité d'un modèle ne réduit pas la portée des conséquences d'un outil que l'agent est toujours autorisé à utiliser. C'est là que la sécurité des agents se distingue de la discipline plus large de la sécurité de l'IA, et c'est pourquoi l'prompt injection e indirecte revêt une importance bien plus grande dès lors qu'un agent est capable d'agir en fonction de ce qu'il lit.

Le calendrier constitue l’autre volet de la réponse. Gartner prévoit que jusqu’à 40 % des applications d’entreprise intégreront des agents dédiés à des tâches spécifiques d’ici 2026, contre moins de 5 % en 2025. Une enquête menée en 2025 auprès de 353 organisations a révélé que 80 % d’entre elles ont déclaré que leurs agents IA avaient effectué des actions non prévues. Par ailleurs, l’analyse par Google des instantanés Common Crawl a fait état d’une augmentation relative de 32 % dans la catégorie des contenus malveillants entre novembre 2025 et février 2026, ce qui signifie que la qualité des contenus non fiables consultés par les agents se détériore elle-même. L’adoption devance les mesures de contrôle, ce qui constitue le schéma récurrent de tous les défis de sécurité liés aux agents IA figurant sur cette liste.

Les cinq endroits où un agent peut être attaqué

La plupart des travaux récents sur ce sujet s'accordent sur ce même modèle à cinq niveaux de la surface d'attaque des agents d'IA, et cette convergence constitue un bon indicateur de la validité du modèle. Il s'agit là d'un élément fondamental plutôt que d'un facteur de différenciation ; il convient donc de le mentionner une fois, puis de passer à autre chose.

‍

Tableau 1 : Les cinq couches de la surface d'attaque d'un agent d'IA et la faille que chacune d'entre elles présente.

La suite de cette page aborde des aspects que ce modèle ne couvre pas : les identifiants de techniques spécifiques, les limites de l’outil, le registre d’identités et les signaux d’exécution.

Correspondance entre les attaques d'agents et le référentiel MITRE ATLAS

MITRE ATLAS est la base de connaissances de MITRE consacrée aux comportements réels des adversaires face aux systèmes d’IA ; il s’agit du cadre natif d’agent dédié à cette problématique. Sa version actuelle est la v2026.07, publiée sur GitHub le 7 août 2026. Le descriptif de la version en précise exactement le contenu : « Cette version des données ATLAS contient 1 matrice, 16 tactiques, 101 techniques, 77 sous-techniques, 37 mesures d'atténuation et 68 études de cas. » Cela représente au total 178 définitions de techniques.

Sur ces 178, 29 entrées sont spécifiques à un agent: 13 techniques principales et 16 sous-techniques. À côté de celles-ci figurent sept mesures d'atténuation mises en œuvre par les agents et quatre études de cas portant sur des agents clés. La base de comptage est importante, la voici donc : une entrée est prise en compte lorsque son nom d'affichage complet dans ATLAS contient « AI Agent » ou « Agent », ainsi que AML.0034.002 « Cost Harvesting : Agentic Resource Consumption », qui concerne clairement les agents mais ne satisfait pas au critère strict de délimitation des mots pour le terme « Agent ». Tous les identifiants ci-dessous sont extraits du document de publication publié dans le référentiel de données ATLAS.

La portée globale est encore plus vaste. Dans la version v2026.07, 48 des 178 définitions de techniques (27,0 %) mentionnent le terme « agent » dans leur nom ou leur description, tout comme 19 des 68 études de cas (27,9 %) et 14 des 37 mesures d'atténuation. Environ un quart du corpus ATLAS aborde désormais les agents d'une manière ou d'une autre.

Voici en quoi réside la différence, formulée avec précision plutôt que de manière vague. Il n’est pas vrai que personne n’ait établi de correspondance entre ATLAS et les agents. Ce qui est vrai, c’est que chaque tentative publique repose sur une version obsolète d’ATLAS et ne couvre au maximum que 2 des 29 entrées d’agents actuelles. Il existe deux correspondances publiques de ce type, et aucune d’entre elles ne figure parmi les pages classées pour ce sujet ; c’est pourquoi le corpus de classement lui-même ne recense aucun identifiant ATLAS. L’une des deux cite la version 5.4.0 d’ATLAS et mentionne sept identifiants de techniques. L’autre cite une technique qui a depuis été retirée. Pour une présentation générale du cadre, consultez notre guide explicatif sur le cadre MITRE ATLAS; ce qui suit concerne spécifiquement les agents.

Remarque concernant l’autre référentiel MITRE : ATT&CK ne constitue pas ici le cadre d’analyse principal approprié. Il prend tout son sens après la compromission, une fois que les identifiants d’un agent ou son hôte ont été détournés pour servir de point d’ancrage classique, mais il ne comporte aucune famille de techniques propres aux agents. La version actuelle est ATT&CK v19.2, publiée le 6 août 2026. Les tests d’attaque des agents face à ces techniques relèvent de Équipe rouge IA, et la version ATLAS v2026.07 l'a également formalisé, en ajoutant AML.M0035 L'équipe « Red Team » basée sur l'IA comme mesure d'atténuation.

Tableau 2 : Les 29 entrées de techniques spécifiques à un agent dans MITRE ATLAS v2026.07, regroupées par technique parente. Les identifiants et les noms sont tirés de la documentation de la version ; la colonne « Pratique » correspond à notre explication en langage clair, et non au texte descriptif d’ATLAS.

Tableau 3 : Les sept mesures d'atténuation spécifiques à chaque agent dans MITRE ATLAS v2026.07.

L'empoisonnement de l'outil et la limite de l'outil

Une définition d'outil n'est pas une configuration. Il s'agit d'un texte que le modèle lit et exécute, ce qui en fait une surface d'instructions. L'« empoisonnement d'outil » est l'attaque qui découle de ce fait, et MITRE ATLAS la répertorie sous le nom de AML.0110 Empoisonnement des outils des agents IA.

Il convient de distinguer trois concepts, car ils sont souvent confondus. L’ Prompt injection , c’est le mécanisme de diffusion. L’empoisonnement de la mémoire altère ce dont l’agent se souvient ; ce phénomène est abordé en détail dans notre guide sur la sécurité de l’IA agentique. L’empoisonnement de l’outil altère l’outil lui-même, et prompt injection c'est souvent ainsi qu'elle est mise en œuvre.

Trois endroits où un outil peut être contaminé

La version 2026.07 d'ATLAS a ajouté trois sous-techniques sous AML.0110, et elles sont utiles précisément parce qu’elles distinguent trois problèmes défensifs différents. La technique « parente » existait déjà avant cette version et y a été mise à jour ; les trois techniques « filles » sont nouvelles.

‍

Tableau 4 : Les trois sous-techniques d'empoisonnement des outils d'agents IA dans MITRE ATLAS v2026.07.

La rubrique « Mise en œuvre » présente un cas documenté. En septembre 2025, un paquet npm très répandu, fournissant un outil d’envoi d’e-mails destiné aux agents, a été piraté. Divulgation par Koi Security de la porte dérobée « postmark-mcp » Le rapport décrit clairement la situation : « Pendant 15 versions, QUINZE, l’outil a fonctionné sans faille », puis la version 1.0.16 a discrètement ajouté une copie cachée de chaque message à l’adresse d’un pirate. Le chiffre souvent cité d’environ 300 organisations concernées n’est pas une mesure. Il s’agit d’une estimation des chercheurs eux-mêmes, qui partent de l’hypothèse que « peut-être 20 % sont activement utilisés » sur la base de 1 500 téléchargements par semaine. Considérez-le comme une hypothèse, car c’est ainsi que ses auteurs l’ont présenté. ATLAS présente cet incident comme une étude de cas. AML.CS0053.

Le MCP en tant que surface d'attaque

Le protocole MCP (Model Context Protocol) est le principal moyen par lequel les outils sont mis à la disposition des agents, ce qui fait d’un serveur MCP une dépendance de la chaîne d’approvisionnement détenant un pouvoir de production. L’analyse de Gartner va dans le même sens, soulignant que le MCP « a été conçu avant tout dans un souci d’interopérabilité, de facilité d’utilisation et de flexibilité, de sorte que des failles de sécurité peuvent apparaître en l’absence d’une surveillance continue de l’IA agentique ». Selon ces mêmes prévisions, 25 % des applications d’IA générative d’entreprise devraient connaître au moins cinq incidents de sécurité mineurs par an d’ici 2028, contre 9 % en 2025.

La spécification du Model Context Protocol, dans sa version datée du 28 juillet 2026, contient une exigence normative qu’il convient de citer textuellement : « Les serveurs MCP NE DOIVENT PAS accepter de jetons qui n’ont pas été explicitement émis pour le serveur MCP. » Cette phrase figure dans la section consacrée à la prévention du « token passthrough » du document sur les meilleures pratiques de sécurité de la spécification, qui répertorie onze sous-sections consacrées aux attaques et à leur prévention : Problème du « Confused Deputy », Transfert de jeton, Falsification de requête côté serveur, Détournement de gestionnaire d’état, Compromission d’un serveur MCP local, Validation de l’URL d’autorisation OAuth, Sécurité du transport stdio dans les scénarios de proxy, Attaques par confusion, Usurpation d’identité via l’URI de redirection localhost, Politiques de confiance CIMD et Minimisation de la portée.

Deux corrections méritent d’être signalées, car ces deux erreurs sont courantes. Premièrement, les termes « tool poisoning », « line jumping », « tool shadowing » et « rug pull » ne font pas partie des concepts de la spécification MCP. Ils proviennent de l’OWASP et de recherches menées par la communauté. Quiconque cite « la section de la spécification MCP consacrée au tool poisoning » fait référence à quelque chose qui n’existe pas. Deuxièmement, le terme « Session Hijacking » a été remplacé par « State Handle Hijacking » : le MCP est désormais sans état et ne comporte plus de sessions au niveau du protocole ; par conséquent, tout contenu citant le détournement de session MCP comme une section actuelle de la spécification se base sur une révision obsolète.

L'OWASP a attribué au « tool poisoning » un numéro d'ordre spécifique, MCP03:2025, dans le classement OWASP MCP Top 10. Il convient ici de préciser le statut de ce projet : il s'agit d'un projet de l'incubateur OWASP à la version 0.1, qui en est actuellement à la phase 3, à savoir la version bêta et les tests pilotes. Aucune date n’est fixée pour sa version finale, et la prochaine version est prévue pour octobre 2026. Il ne bénéficie pas de la même autorité que le Top 10 LLM et ne doit pas être cité comme s’il en bénéficiait.

Les recommandations gouvernementales vont plus loin. La fiche d’information de la NSA sur la cybersécurité consacrée au « Model Context Protocol » (MCP), un document de 17 pages (version 1.0 datée de mai 2026 et publié par la seule NSA), énonce neuf recommandations relatives au MCP. Deux d’entre elles méritent d’être citées textuellement, car elles sont souvent paraphrasées de manière à en atténuer la portée : « Choisissez, dans la mesure du possible, des projets MCP pris en charge » et « Surveillez et corrigez les vulnérabilités liées au MCP ».

Il convient de mentionner une seule fois une condition limite, puis de ne plus y revenir : un cabinet d'analyse de premier plan recommande désormais de considérer comme une « zone interdite » tout cas d'utilisation combinant l'accès d'un agent à des données sensibles, l'ingestion de contenu non fiable et la possibilité de communiquer vers l'extérieur. Cette combinaison est abordée dans notre sécurité IA agentique page. Les chaînes d'approvisionnement en outils recoupent également le risque de dépendance classique, qui MITRE ATLAS noms directement sous la forme AML.0010.005 Supply Chain s sur l’IA : outil d’agent IA.

Identité de l'agent, inventaire et problème du registre

La gestion traditionnelle des identités et des accès part du principe qu’un sujet présente des schémas d’accès prévisibles, qu’il s’agit d’un propriétaire humain et que la session est compréhensible. Un agent enfreint ces trois principes. Son modèle d’accès est non déterministe, car c’est le modèle qui décide de ce qu’il faut appeler. Son autorité provient d’une chaîne de délégation plutôt que d’une connexion. Et il s’agit structurellement d’un « mandataire confus », détenant plus d’autorité que celui qui lui demande d’agir. Ce dernier point n’est pas une simple réflexion théorique : le problème du « mandataire confus » est la première attaque citée dans le document de sécurité de la spécification MCP elle-même.

Le premier contrôle n'est donc pas un contrôle à proprement parler. Il s'agit d'un inventaire. Trois pages indépendantes consacrées à ce marché affirment que la détection des agents est importante, mais aucune d'entre elles n'explique la méthode utilisée. Cette méthode consiste en un registre, recoupé avec les comportements observés. Tout élément faisant appel à des outils qui ne figure pas dans ce registre est considéré comme un « agent fantôme », et ce recoupement est le seul moyen fiable de mesurer la prolifération des agents.

Tableau 5 : Champs que doit comporter une fiche d'enregistrement d'agent, et conséquences de l'omission de chacun d'entre eux.

En matière de vocabulaire, deux termes désignent la même notion sous-jacente. Une « identité machine » et une « identité non humaine » (NHI) désignent toutes deux un sujet doté d’identifiants et d’autorisations qui n’est pas une personne, ce qui englobe les comptes de service, les clés API, les charges de travail et, désormais, les agents. Une mise en garde honnête : la différence entre ces termes peut correspondre à une véritable lacune dans le vocabulaire du marché, ou bien le marché a peut-être simplement opté pour l’expression « identité non humaine ». Les données disponibles ne permettent pas de faire la distinction entre ces deux cas de figure. Lorsque l’identité d’un agent recoupe la détection d’une utilisation abusive de n’importe quel sujet non humain, ce domaine relève de la détection et de la réponse aux menaces liées à l’identité.

La couche des normes de portabilité constitue le point faible, et il convient de le dire sans détours. SPIFFE et SPIRE, les projets de la CNCF visant à établir l’identité cryptographique des charges de travail, ont atteint le statut « Graduated » depuis le 20 septembre 2022 ; quiconque les qualifie d’« émergents » est donc en retard de quatre ans. Au-dessus de cette couche, la situation est moins solide que ne le laisse supposer le volume d’activité. Il existe 165 projets de normes IETF actifs concernant l’identité ou l’autorisation des agents IA. Ces 165 projets sont tous des soumissions individuelles. Aucun n’a été adopté par un groupe de travail. La couche des normes d’identité des agents est une explosion de propositions, et non une véritable couche normative . Deux contre-exemples méritent d’être cités : le document « OAuth Client ID Metadata » est un véritable document de groupe de travail auquel la spécification MCP fait directement référence, et le groupe de travail OpenID AuthZEN dispose d’un projet d’autorisation contraignante pour MCP, le profil « AuthZEN Access Request and Approval » ayant atteint le stade de « Draft 1 » le 20 août 2026. Parallèlement, le groupe de travail WIMSE a produit six documents actifs et aucun RFC en environ 33 mois d’existence, et la RFC 8693 reste une norme proposée sans aucune mise à jour ni obsolescence parmi ses 120 lignes de relation, ce qui signifie qu’aucune norme ne l’a remplacée en matière de délégation d’agent. Les sources des informations ci-dessus se trouvent dans le Datatracker de l’IETF.

En pratique : comme il n’est pas encore possible d’acheter une identité d’agent portable, le champ d’application, le promoteur et la date d’expiration constituent les contrôles dont vous disposez réellement. Les recommandations du NCSC concernant l’adoption de l’IA agentique aboutissent à une conclusion similaire du point de vue de la gouvernance. Les principes de l’Zero trust s’appliquent parfaitement aux agents, à une exception près : le mandant dont l’identité est vérifiée en continu n’étant pas une personne, le signal de vérification doit provenir du comportement plutôt que d’une connexion.

Ce que révèlent les incidents liés aux agents d'IA recensés

Les incidents réels sont plus utiles que les prévisions, car chacun d'entre eux met en évidence l'endroit où la barrière a effectivement cédé.

Tableau 6 : Incidents de sécurité liés aux agents d'IA recensés, avec leurs sources principales et, le cas échéant, les identifiants des études de cas ATLAS.

Développeur Amazon Q. Une contribution malveillante a été intégrée à l'extension déployée. Le bulletin de sécurité AWS AWS-2025-015 décrit précisément le résultat : « L'équipe de sécurité AWS a examiné le code et déterminé que le code malveillant avait été distribué avec l'extension, mais qu'il n'avait pas pu s'exécuter en raison d'une erreur de syntaxe. » L'instruction malveillante était entièrement formée. C'est une faute de frappe qui l'a empêchée de s'exécuter. Concernant la vulnérabilité CVE-2025-8217, les deux scores, CVSS v4.0 5,1 (MOYEN) et v3.1 4,0 (MOYEN), sont des scores secondaires et ont été attribués par AWS en tant que CNA. Le NVD n'a publié aucun score principal de son cru et le statut de l'enregistrement est « Différé ».

postmark-mcp. Ce point a déjà été abordé plus haut, mais il a également sa place ici, car un outil d’agent empoisonné est une dépendance qui hérite des droits de production de l’agent. Le raisonnement qui sous-tend toute attaque de la chaîne d’approvisionnement s’applique ici, avec un chemin menant aux conséquences bien plus court.

Action GitHub « Claude Code ». Un seul outil, n'étant pas isolé dans un bac à sable, constituait l'intégralité de la chaîne d'attaque, accessible depuis un ticket GitHub ordinaire. Note technique de GMO Flatt Security affiche un score CVSS v4.0 de 7,8 attribué par le fournisseur, une prime de 4 800 dollars, et la faille de contournement principale a été corrigée dans claude-code-action v1.0.94. Le confinement partiel d'un agent permet de contourner complètement la protection.

L'intrusion orchestrée par un agent en juillet 2026. Un fournisseur de plateformes d'IA a révélé qu'un cadre d'agents autonomes avait orchestré une intrusion de bout en bout de ses systèmes internes. Sa chronologie technique constitue le rapport d'expertise : « Notre reconstitution technique recouvre environ 17 600 actions de l’attaquant que nous avons pu récupérer, regroupées en environ 6 280 clusters, entre le 09/07/2026 à 02 h 28 UTC et le 13/07/2026 à 14 h 14 UTC. » Ces quelque 6 280 éléments correspondent à des clusters d’activité plutôt qu’à des clusters de calcul, et la période concernée s’étend sur environ quatre jours et demi. Le même document indique que « l’agent a lu les objets secrets du cluster, y compris un objet de production contenant 136 clés ». La communication du fournisseur relative à l’incident décrit « un accès non autorisé à un ensemble limité de jeux de données internes et à plusieurs identifiants » et précise que l’évaluation de l’impact sur les partenaires et les clients était toujours en cours. Elle ne nomme pas la partie adverse, et aucun résumé de celle-ci ne devrait le faire non plus.

Ce sont les détails relatifs à la détection qu’il convient de retenir. Les signaux ont bien été déclenchés. Selon les propres termes du fournisseur, ils « ont été corrélés par notre pile d’agents de sécurité basés sur l’IA et ont permis d’identifier un signal d’attaque cohérent. Cependant, le système n’a pas réussi à attribuer correctement le niveau de gravité à l’alerte ni à déclencher l’intervention de l’équipe de garde, ce qui a fait perdre un temps précieux dans la réponse ».

EchoLeak. Accès à des données privées, ingestion de contenu non fiable et canal sortant, observés en environnement de production sur Microsoft 365 Copilot. Il convient de présenter les deux notes en toute transparence : le CVE-2025-32711 est noté CVSS 9,3 (CRITIQUE) par Microsoft, agissant en tant que CNA, tandis que l’analyse indépendante du NIST réalisée par le NVD lui attribue une note de 7,5 (ÉLEVÉE), avec le code CWE-74. Le chiffre de 9,8 qui circule dans certains articles ne trouve aucun fondement dans aucune de ces deux sources. EchoLeak et les incidents liés aux agents sont abordés sur notre page consacrée à la sécurité des IA agentiques.

Les incidents liés à l’évaluation des modèles. Un fournisseur de modèles a révélé qu’« après avoir examiné 141 006 cycles d’évaluation au cours desquels Claude aurait pu obtenir un accès à Internet », il avait identifié trois incidents au cours desquels ses modèles avaient accédé à des organisations tierces lors de tests de sécurité. Deux de ces trois organisations ont depuis été contactées. Trois sur 141 006 ne constituent pas un taux de base et ne doivent en aucun cas être présentés sous forme de pourcentage : cette divulgation décrit une enquête, et non une mesure d’incidence. La manière dont il formule lui-même la cause profonde de ces incidents résume le mieux la thèse de cette page : « Nous pensons que ces incidents s’apparentent davantage à une défaillance du harnais et à une défaillance opérationnelle qu’à un échec d’alignement du modèle. »

Deux CVE de 2026 concernant des produits d'agents de distribution viennent compléter le tableau. Le CVE-2026-62830 dans Azure SRE Agent est noté 9,9 (CRITIQUE) selon le CVSS v3.1 avec le CWE-862, et le CVE-2026-59118 dans Copilot Cowork est noté 9,3 (CRITIQUE) avec le CWE-285. Toutes deux ont été publiées le 6 août 2026, et ces deux scores ont été attribués par la CNA sans analyse indépendante du NVD. Ce schéma est la norme pour les produits d’agents IA plutôt que l’exception, c’est pourquoi tout tableau de CVE sur ce sujet doit préciser à qui appartient le score affiché. Aucune de ces vulnérabilités n’apparaît dans le catalogue des vulnérabilités exploitées de la CISA ; elles ne doivent donc pas être considérées comme exploitées.

Le point commun est qu’aucun de ces cas ne s’explique par une erreur du modèle. Presque tous s’expliquent par une « prompt injection » indirecte ayant atteint un outil, ou par une autorisation plus large que ne l’exigeait la tâche. Le cas de juillet 2026 constitue une exception instructive, car dans ce cas précis, l’agent était l’attaquant plutôt que la victime. Nos propres recherches sur les communautés d’agents d’IA et l’illusion d’inoffensivité aboutissent à la même conclusion en considérant les interactions entre agents.

Détection et confinement d'un agent IA compromis

Commencez par cette affirmation honnête, car elle définit les exigences. Il existe deux modes de défaillance répertoriés, et il s'agit de problèmes distincts.

Le premier est le silence. Dans le cas de ZombieAgent, aucun contrôle traditionnel n’a détecté l’exfiltration. Ni les passerelles web sécurisées, ni les outils d’ endpoint , ni les pare-feu, et aucune alerte n’est parvenue à l’utilisateur. L’entrée correspondante dans le registre « OECD AI Incidents and Hazards Monitor » est une entrée neutre. Les chercheurs décrivent cet incident comme une « prompt injection indirecte de type zéro-clic », ce qui correspond à leur formulation et mérite d’être mentionné ainsi, car l’utilisateur doit tout de même interagir normalement avec l’assistant pour que la charge utile se déclenche.

Le deuxième problème concerne une évaluation erronée du bruit. Lors de l'intrusion de juillet 2026, des signaux ont été émis simultanément depuis plusieurs couches et ont été corrélés pour former un signal d'attaque cohérent. Le système n'a alors pas réussi à rehausser le niveau de gravité de l'alerte. L'absence de signal et une évaluation erronée du niveau de gravité aboutissent toutes deux au même résultat, et aucun des deux problèmes ne peut être résolu par un modèle plus performant.

Il convient de mettre en place des détections autour de cinq signaux d'exécution:

1. Anomalies dans l'exécution des instructions : actions sans lien plausible avec la tâche.
2. Séquences d'appel d'outils qui perturbent la topologie attendue du flux de travail.
3. Exfiltration via des canaux à faible bande passante dont l'agent dispose légitimement.
4. Accès aux identifiants et aux secrets en dehors du périmètre de la tâche en cours.
5. Anomalies d'écriture en mémoire qui font que certaines instructions restent inactives d'une session à l'autre.

Signal : à quoi cela ressemble-t-il dans la télémétrie ? Technique ATLAS : contraintes liées à l'atténuation. Anomalie dans l'exécution des instructions. Appels d'outils sans tâche parente ni requête utilisateur.AML.T0080AML.M0030Appel d'outil « topologie » : une séquence d'appels franchissant une limite de workflowAML.T0053AML.M0028Exfiltration à faible bande passante : petites écritures sortantes répétées via un outil autoriséAML.T0086AML.M0033Accès à des informations confidentielles hors du champ d'application, sans rapport avec la tâche en cours d'exécutionAML.T0098AML.M0026Anomalie d'écriture en mémoire : écritures dans la mémoire persistante en dehors du tour de l'utilisateurAML.T0080.000AML.M0029

Tableau 7 : Cinq signaux de détection en temps réel d'un agent IA compromis, mis en correspondance avec la technique ATLAS à laquelle chacun d'entre eux renvoie et la mesure d'atténuation qui le limite.

Faites le lien avec les mesures d'atténuation plutôt qu'avec les fonctionnalités du produit, car ces mesures d'atténuation seront toujours d'actualité dans un an. AML.M0033 Validation des entrées et des sorties pour les composants des agents d'IA et AML.M0030 « Limiter l'appel de l'outil d'agent IA sur les données non fiables » : ce sont ces deux éléments qui génèrent le plus de données télémétriques pertinentes pour la détection. Et notez que l'intervention humaine n'est pas ici une simple recommandation : c'est AML.M0029 « L'intervention humaine dans la boucle pour les actions des agents IA », une mesure d'atténuation ainsi nommée, qui fait l'objet d'une section spécifique dans Fiche pratique de l'OWASP sur la sécurité des agents IA et une sous-section consacrée à l'intervention humaine dans le guide interministériel.

En matière de mesure, un laboratoire de recherche a proposé le seul ensemble de métriques « natives aux agents » jamais publié, mais aucun fournisseur ne l’a adopté : « la couverture (la fraction du trafic surveillé), le rappel (la fraction des comportements anormaux détectés) et le temps de réponse ». Ce même travail plaide en faveur du traitement des agents IA non fiables comme des « menaces internes » potentielles, ce qui constitue la bonne approche. L’adoption de ces trois indicateurs permet de disposer d’éléments à communiquer autres que le simple nombre d’alertes. Une véritable observabilité de l’exécution des agents, c’est-à-dire l’enregistrement des invocations d’outils en tant qu’événements de premier ordre plutôt que l’enregistrement des invites sous forme de texte, en est le prérequis, et s’inscrit dans le cadre plus large de l’observabilité de la sécurité.

Les données relatives aux exploits constituent l'argument le plus convaincant en faveur de la détection à l'exécution. À la date de la version 2026.08.24 du catalogue, publiée le 24 août 2026, le catalogue des vulnérabilités connues exploitées de la CISA comptait 1 675 entrées, dont 11 concernaient la pile d'IA et d'agents: six entrées pour Langflow, deux pour LiteLLM, et une chacune pour MLflow, n8n et Ray. Le fait que six de ces onze entrées concernent une seule et même plateforme de flux de travail d’agents mérite en soi d’être souligné. La répartition dans le temps est encore plus révélatrice. L’entrée relative à Ray, CVE-2025-62593, a été publiée sur le NVD le 26 novembre 2025 et ajoutée au catalogue le 17 août 2026, soit un écart de 264 jours. En revanche, la vulnérabilité CVE-2026-64849 de MLflow a été publiée le 17 août 2026, ajoutée le 19 août 2026 et assortie d’une date limite de correction fixée au 2 septembre 2026, soit un décalage de deux jours. Si une faille dont l’exploitation est avérée dans votre pile d’agents peut passer inaperçue pendant neuf mois avant que quelqu’un ne vous signale qu’elle est exploitée, la cadence des correctifs ne peut pas être le seul moyen de contrôle. Il faut un mécanisme pour surveiller le comportement pendant cet intervalle.

Volume confirme cette tendance. Le suivi réalisé par l’OWASP, basé sur un instantané d’avril 2026 des dépôts GitHub surveillés, recense 57 avis pour n8n, 22 pour Claude Code, 15 pour AutoGPT, 13 pour Dify et 11 pour Roo-Code. Il s’agit du nombre d’avis par dépôt surveillé, et non d’un recensement des projets d’agents. Les tests adversariaux de vos propres agents relèvent du « red teaming » en IA, tandis que la partie du problème liée à la couche modèle relève de la sécurité des IA génératives (GenAI).

Cadres, recommandations gouvernementales et réglementation

Des catalogues de contrôle spécifiques à chaque agent sont en cours de rédaction, ce qui fait de la datation correcte de chaque référence de framework un indicateur tangible de qualité plutôt qu'une simple question de minutie.

Tableau 8 : Tableau de correspondance entre les cadres et les dispositions réglementaires relatifs à la sécurité des agents d'IA, avec la version et la date de chaque texte.

Les recommandations conjointes relatives à l'adoption prudente des services d'IA agentique constituent les directives de contrôle spécifiques aux agents les plus complètes publiées à ce jour. Sur 29 pages, elles classent le problème en cinq catégories de risques ; il convient d’utiliser la formulation propre au guide plutôt que les paraphrases qui circulent dans les médias : risques liés aux privilèges (page 7), risques liés à la conception et à la configuration (page 9), risques liés au comportement (page 9), risques structurels (page 11) et risques liés à la responsabilité (page 12). Son contenu relatif aux meilleures pratiques s’articule autour d’un cycle de vie en quatre phases couvrant la conception, le développement, le déploiement et l’exploitation d’agents sécurisés. Six agences réparties dans cinq pays en sont les coauteurs : l’ACSC (Australian Signals Directorate), la CISA, la NSA, le Centre canadien de cybersécurité, le NCSC-NZ et le NCSC-UK.

En matière de réglementation, les dates ont changé et une grande partie des orientations publiées n’ont pas encore été mises à jour. Le règlement (UE) n° 2026/1744 a été adopté le 8 juillet 2026, publié au Journal officiel le 24 juillet 2026 et est entré en vigueur le 27 juillet 2026. Il s’appliquera aux obligations relatives aux systèmes d’IA à haut risque de l’annexe III en tant que telles à compter du 2 décembre 2027, et aux obligations relatives aux systèmes d’IA à haut risque de l’annexe I intégrées à d’autres systèmes à compter du 2 août 2028. Seules les obligations de transparence prévues à l’article 50 s’appliquaient dès le 2 août 2026. Un agent d’entreprise qui prend des décisions ou influe de manière significative sur celles-ci dans un domaine relevant de l’annexe III est considéré comme un système d’IA à haut risque ; décembre 2027 constitue donc l’horizon de planification opérationnel, tandis que les obligations de divulgation prévues à l’article 50 s’appliquent d’ores et déjà aux agents en contact avec la clientèle.

Ce qui s'annonce mérite d'être suivi, mais sans exagération. Les superpositions de contrôle du NIST visant à sécuriser les systèmes d'IA comprennent deux cas d'utilisation d'agents nommés : « Utilisation de systèmes d'agents d'IA (agents d'IA) – Agent unique » et « Utilisation de systèmes d'agents d'IA (agents d'IA) – Multi-agents ». Tous deux sont en projet et aucun n'a encore fait l'objet d'un projet de texte : il n'existe pour l'instant qu'un document conceptuel et un plan annoté pour le cas d'utilisation de l'IA prédictive. Par ailleurs, l’initiative du NIST relative aux normes pour les agents IA, annoncée le 17 février 2026, s’articule autour de trois piliers, dont la recherche sur la sécurité et l’identité des agents.

Deux précisions sur les sources permettent ici d’éviter de réelles erreurs. La liste LLM 2026 est la première édition pondérée par les données d’incidents, et sa préface fait état d’un corpus de 7 714 incidents réels, dont 6 639 comportaient suffisamment de détails pour être classés, le vote de la communauté représentant les trois quarts de la pondération et les données d’incidents le quart restant. Consultez ces chiffres et les numéros ordinaux dans le dépôt source plutôt que sur une page d’accueil. De même, consultez la version indiquée sur la couverture du PDF « OWASP Agentic AI Threats and Mitigations v1.1 » plutôt que la date figurant sur la page, et notez que la matrice CSA AI Controls Matrix v1.1 comporte 247 objectifs de contrôle, tandis que l’URL sans suffixe renvoie toujours à l’ancienne version qui en comptait 243. Le complément de tout cela au niveau de la couche applicative est la sécurité GenAI, et la couche d’architecture agentique est couverte par l’OWASP Top 10 pour les applications agentiques.

Approches modernes de la sécurité des agents d'IA

Les outils dédiés à la sécurité des agents d'IA d'entreprise se multiplient rapidement et se répartissent désormais en six catégories distinctes plutôt qu'en une seule.

• Détection et inventaire des agents. Identification des agents non enregistrés et comparaison de ceux-ci avec un registre.
• Évaluation des risques par agent. Évaluation d'un agent en fonction de la portée de ses outils et de ses compétences plutôt qu'en fonction de son modèle.
• Contrôle d'accès aux outils et au MCP. Définition des outils qu'un agent est autorisé à utiliser, ainsi que les conditions dans lesquelles il peut le faire.
• Contrôle des actions des agents. Autorisation, restriction ou blocage d'une action spécifique lors de l'exécution.
• Détection comportementale en temps réel. Observation des actions réelles de l'agent et alerte en cas d'écart.
• Contrôles d'identité et de délégation pour les entités non humaines. Identifiants à portée limitée, chaînes de délégation et révocation.

Quatre questions permettent de distinguer les solutions de sécurité pour agents IA qui feront leurs preuves de celles qui échoueront. Le système recense-t-il les agents que vous n’avez pas enregistrés, ou se contente-t-il de répertorier uniquement ceux que vous lui avez signalés ? Détecte-t-il les invocations d’outils, ou uniquement les invites ? Associe-t-il ses conclusions à une taxonomie publique des techniques que vous pouvez vérifier ? Et est-il capable de restreindre l’utilisation d’un seul outil sans désactiver l’agent, ce qui fait toute la différence entre un mécanisme de contrôle et un simple bouton d’arrêt ?

L'évolution du marché est assez claire. L'identité des agents s'intègre désormais dans les catégories existantes de sécurité des identités plutôt que de constituer une catégorie à part entière, et les catalogues de contrôle sont en cours d'élaboration et ne sont pas encore aboutis. Il convient également de noter que plusieurs fournisseurs de premier plan dans ce domaine ont changé de mains entre décembre 2025 et juin 2026 ; il est donc préférable de vérifier leur indépendance plutôt que de la tenir pour acquise. Les modèles de déploiement avec ou sans agent constituent une question tout à fait distincte, traitée dans le cadre des solutions de cybersécurité.

Le point de vue d'Vectra AI sur la sécurité des agents IA

Un agent IA est un nouveau type d'entité opérant sur le même réseau que tous les autres éléments ; par conséquent, la même question relative à l'hypothèse de compromission s'applique à lui. Si les identifiants d’un agent sont utilisés pour effectuer une action que cet agent n’était pas censé effectuer, est-ce que quelque chose dans votre environnement le détecte ? La position d’ Vectra AI est que le comportement d’un agent doit être observé là où il agit, à travers le réseau, l’identité et l’ cloud, plutôt que d’être déduit à partir de la commande qui l’a déclenché. Il s’agit de la même approche « Attack Signal Intelligence™ » que nous appliquons à tout entité compromise : observer ce qu’elle fait, et non ce qu’elle prétend être. Le contexte plus large de la sécurité de l’IA justifie cette position.

Conclusion

La question qui distingue la sécurité des agents IA de la sécurité de l’IA en général n’est pas « le modèle est-il sûr ? », mais « que cet agent est-il autorisé à faire, et quelqu’un s’en rendrait-il compte s’il faisait autre chose ? ». Chaque incident répertorié à ce jour répond mal à la première partie de la question et encore plus mal à la seconde. Le travail qui attend la plupart des équipes de sécurité est peu glamour et séquentiel : recenser les agents, désigner un responsable pour chacun d’entre eux, cibler les outils plutôt que le modèle, et intégrer les appels d’outils dans la télémétrie afin qu’ils puissent être détectés. MITRE ATLAS v2026.07 vous propose 29 identifiants de techniques et sept mesures d’atténuation pour ancrer ce travail dans une taxonomie publique.

Si vous vous penchez actuellement sur les questions relatives à l'architecture, au cycle de vie et à la gouvernance, notre guide sur la sécurité de l'IA agentique prend le relais là où cette page s'arrête.

‍