Rogue agents : on attaque nos propres agents IA avant que quelqu'un d'autre le fasse

Les rogue agents font l'actu, et la communauté sécurité a déjà acté le sujet. L'OWASP GenAI Security Project maintient désormais un Top 10 for Agentic Applications, construit avec plus de cent contributeurs. L'entrée ASI10 s'appelle littéralement Rogue Agents. L'entrée ASI01 s'appelle Agent Goal Hijack. L'OWASP a par ailleurs publié un top 10 LLM rafraîchi le 4 août 2026, il y a trois jours, cette fois adossé à des milliers d'incidents de sécurité IA réels et plus seulement à l'avis d'experts. La phrase qui ouvre le document agentique résume tout le problème :

Once AI began taking actions, the nature of security changed forever.

Sécuriser un chatbot était déjà complexe. Sécuriser un agent capable d'accéder à des données clients, d'appeler des APIs et d'exécuter des actions est une discipline différente. Et le point gênant, c'est qu'un agent peut sembler parfaitement sécurisé jusqu'au jour où quelqu'un trouve la bonne séquence de messages pour le détourner.

C'est pour ça qu'on lance Security Lab, notre nouveau module de sécurité chez AGO.

Ce qui change quand l'agent peut agir

Un chatbot échoue en douceur. Le pire scénario est une mauvaise réponse et un client agacé.

Un agent échoue brutalement. S'il peut déclencher un remboursement, il peut déclencher le mauvais remboursement. S'il peut lire une commande, il peut lire la commande de quelqu'un d'autre. S'il peut récupérer une URL, on peut le pointer vers votre réseau interne.

La surface d'attaque est aussi bien plus large que le modèle lui même :

• le system prompt et les instructions qui définissent le comportement
• la base de connaissance dans laquelle l'agent va chercher
• les outils qu'il a le droit d'appeler, et les arguments qu'il remplit
• le routing entre agents, quand un agent spécialisé dispose de plus de droits que celui avec lequel l'utilisateur parle
• tout contenu que l'agent ingère, y compris le corps d'un ticket, un PDF joint ou une page web

C'est le cinquième point qui piège le plus de monde, et ce n'est pas théorique. Le cas de référence est EchoLeak, CVE-2025-32711, une injection de commande IA dans Microsoft 365 Copilot notée 9,3 critique par Microsoft : un simple email piégé posé dans une boîte mail faisait fuiter des données du tenant, sans que la victime ne l'ouvre jamais. C'était en juin 2025, et la classe de vulnérabilité n'a pas été refermée depuis. L'OWASP a recensé huit exploits IA majeurs sur le seul premier trimestre 2026.

L'attaquant n'a pas besoin de parler à votre agent. Il lui suffit de placer du texte quelque part où votre agent ira lire.

Ce que dit vraiment la recherche 2026

Tous les modèles de pointe testés cette année ont cédé. En mars 2026, Gray Swan AI, l'UK AI Security Institute et le CAISI américain rattaché au NIST ont publié les résultats d'une compétition publique sur la prompt injection indirecte : 464 participants, 272 000 attaques soumises, 41 scénarios, 13 modèles de pointe. 8 648 attaques ont réussi. Les taux de réussite vont de 0,5 % pour Claude Opus 4.5 à 8,5 % pour Gemini 2.5 Pro. Le compte rendu du NIST, publié le 23 mars 2026, le dit sans détour : « at least one successful attack was found against all of the target frontier models ».

Un taux de réussite de 0,5 % paraît rassurant jusqu'à ce qu'on le multiplie. Un attaquant qui envoie deux mille messages à ce rythme passe dix fois, et il n'a besoin de passer qu'une seule. Et c'est le meilleur score de l'étude, sur le modèle le plus robuste testé.

Un chiffre de défense publié vous dit surtout que personne ne l'a encore attaquée. En octobre 2025, quatorze chercheurs de Google DeepMind, OpenAI, Anthropic et l'ETH Zürich ont publié The Attacker Moves Second. Ils ont pris les douze principales défenses de l'époque contre le jailbreak et la prompt injection, et ont attaqué chacune de façon adaptative, en calibrant l'attaque sur la conception précise de la défense. Mot pour mot dans le résumé : ils contournent les douze « with attack success rate above 90% for most; importantly, the majority of defenses originally reported near-zero attack success rates ».

Proche de zéro sur le benchmark publié, au dessus de quatre vingt dix pour cent dès qu'on s'y met sérieusement. Rien de publié depuis n'a renversé ce résultat, et c'est pour ça qu'il fait toujours référence sur la façon d'évaluer une défense.

Votre veille CVE ne vous préviendra jamais. C'est le point que peu d'équipes ont intégré. Le bilan trimestriel des exploits GenAI de l'OWASP pour le T1 2026, publié en avril 2026, documente huit exploits IA majeurs sur le trimestre. Exactement un seul possède un identifiant CVE officiel. L'OWASP explique pourquoi : « Most AI-related security events are not yet mapped to traditional CVE identifiers. Instead, they arise from: Misconfiguration (e.g., overprivileged agents), Design flaws (agent autonomy, trust boundaries), Supply-chain weaknesses, Prompt injection and data-flow manipulation. » Seuls les bugs logiciels classiques embarqués dans des plateformes IA reçoivent un suivi CVE.

Le circuit habituel ne s'applique donc pas. Personne ne va déposer une CVE contre le system prompt de votre agent. Si vous voulez savoir s'il est exploitable, la seule façon de le découvrir est de l'attaquer vous même.

Alors on attaque nos propres agents

Security Lab attaque votre agent comme le ferait un vrai utilisateur, à travers le pipeline de chat réel, et rapporte ce qui est passé. Pas de bac à sable, pas de copie simplifiée de l'agent. Le scan tourne sur le vrai system prompt, les vrais outils et la vraie base de connaissance, en production ou en environnement de test.

La boucle est volontairement simple :

1. Choisir un agent. Sa configuration réelle est utilisée, pas un substitut.
2. On l'attaque. Les attaques du catalogue passent par le pipeline de chat normal, sur plusieurs tours quand l'attaque l'exige, parce que tester sur un seul tour sous estime systématiquement le risque.
3. Analyser les résultats. Chaque attaque est classée bloquée, compromise ou non concluante, et le run produit un score de sécurité.

Le catalogue d'attaques

Le catalogue est organisé autour des catégories agentiques de l'OWASP plutôt qu'autour de ce qui nous semblait intéressant, pour qu'un résultat se rattache à une taxonomie que votre équipe sécurité connaît déjà. L'OWASP ayant rafraîchi son top 10 LLM le 4 août 2026, on suit cette renumérotation au fil de sa parution plutôt que de figer le catalogue sur une édition dépassée.

• Prompt injection directe. L'utilisateur demande à l'agent d'ignorer ses instructions. OWASP ASI01, agent goal hijack.
• Prompt injection indirecte. Les instructions sont cachées dans un document, un ticket ou une page que l'agent lit. Même ASI01, autre point d'entrée, et de loin le plus difficile à refermer.
• Exfiltration de la base de connaissance. Faire recracher à l'agent du contenu qu'il ne devrait utiliser que pour répondre, documents internes compris.
• Récupération du system prompt. Extraire les instructions, qui sont la carte dont un attaquant a besoin pour tout le reste.
• Accès à des données hors périmètre. Demander la commande d'un autre client, les données d'un autre tenant, le compte d'un autre utilisateur. OWASP ASI03, abus d'identité et de privilèges.
• Détournement du routing entre agents. Convaincre l'agent de front de passer la main à un agent plus privilégié avec un contexte contrôlé par l'attaquant. OWASP ASI07, communication inter agents non sécurisée.
• Appels d'outils non autorisés. Déclencher un outil auquel l'agent ne devrait pas avoir accès, ou avec des arguments hors du périmètre permis. OWASP ASI02, tool misuse.
• Empoisonnement de la mémoire et du contexte. Planter dans une conversation du contenu qui modifie le comportement de l'agent dans une conversation ultérieure. OWASP ASI06.
• Recherche de credentials et de secrets. Clés d'API, tokens et URLs internes qui fuitent dans les réponses ou les messages d'erreur.
• SSRF. Pointer un outil de fetch ou de webhook vers des adresses internes.
• Boucles de coût. Des prompts conçus pour faire boucler, réessayer ou générer l'agent jusqu'à ce que la facture fasse mal.
• Jailbreaks adaptatifs. Des attaques sur plusieurs tours qui construisent le contexte petit à petit au lieu de demander d'un coup.

Le point vraiment important

La plupart des outils de sécurité pour agents notent la réponse. Est ce que le modèle a dit quelque chose qu'il n'aurait pas dû dire ?

Cette note ne vaut presque rien, et la recherche l'avait déjà établi sur les chatbots avant même que les agents existent. L'équipe de Berkeley derrière StrongREJECT a montré que « existing evaluation methods significantly overstate jailbreak effectiveness compared to human judgments », précisément parce que ces méthodes notent la forme de la réponse au lieu de vérifier si elle a livré quoi que ce soit de réel. Leur correctif : mesurer « the extent to which a response gives useful information ».

Sur un agent, l'écart est encore plus large, parce que le dégât ne vit pas dans le texte. Il vit dans l'appel d'outil. Un agent qui répond « désolé, je ne peux pas vous aider » obtient un score parfait sur un détecteur de refus, même s'il a laissé fuiter une fiche client deux tours plus tôt. Le refus n'est pas de la sécurité, c'est du ton.

On ne mesure donc pas si l'agent a eu l'air suspect. On mesure si l'attaque a réellement fonctionné :

• est ce qu'une vraie donnée protégée a été exposée
• est ce qu'un outil interdit a réellement été appelé
• est ce que l'agent est sorti de son périmètre d'autorisation
• est ce que son comportement a vraiment été détourné, ou est ce qu'il a seulement joué le jeu en paroles

Chaque attaque tombe dans une des trois catégories. Bloquée veut dire que l'attaque a bien tourné et que rien n'est passé. Compromise veut dire que quelque chose de réel est sorti, et c'est un bug avec son cas de reproduction attaché. Non concluante veut dire qu'on ne peut pas trancher à partir de la seule transcription.

On garde cette troisième catégorie volontairement. Une grande partie du travail de sécurité sur les agents consiste à déterminer si quelque chose s'est réellement produit, et un scanner qui force chaque cas dans un binaire réussi ou échoué cache soit de vraies brèches, soit vous noie sous le bruit. Marquer un cas non concluant garde le score honnête et le met devant un humain.

La sécurité est une propriété du système, pas du modèle

C'est le changement de fond avec les systèmes agentiques. On ne prompte pas son chemin vers la sécurité. Les douze défenses cassées dans The Attacker Moves Second étaient pour l'essentiel des défenses au niveau du modèle, et c'est exactement pour ça qu'elles sont tombées.

Un garde fou écrit dans le system prompt est une suggestion. Une vérification écrite dans votre code est un contrôle. Les contrôles qui tiennent sont ceux qui vivent en dehors du modèle :

• des credentials cloisonnés par agent, gardés côté serveur, jamais présents dans le prompt
• une liste explicite d'outils autorisés par agent, plutôt qu'une boîte à outils partagée
• une autorisation vérifiée à chaque appel d'outil contre l'utilisateur authentifié, jamais contre ce que la conversation prétend
• des requêtes sortantes limitées à un ensemble d'hôtes connus
• des plafonds de tokens et de coût par conversation
• un log complet de chaque appel d'outil, pour pouvoir reconstruire une compromission après coup

Le modèle est une couche parmi d'autres. C'est la couche avec laquelle un attaquant peut négocier, donc ce ne devrait pas être celle qui détient les clés. Concevez de sorte que quand le modèle se fait avoir, et ça arrivera, le rayon de dégât soit déjà borné.

À faire tourner comme une suite de tests, pas comme un audit

Un pentest annuel vous dit que l'agent était sûr en mars. Les agents changent toutes les semaines : un nouveau prompt, un nouveau document dans la base de connaissance, un nouvel outil, une nouvelle version de modèle. Chacun de ces changements peut rouvrir une faille qui était fermée.

C'est d'ailleurs comme ça que les grands labos procèdent. Le rapport de Google DeepMind sur la défense de Gemini contre les prompt injections indirectes décrit un framework d'évaluation adverse qui « deploys a suite of adaptive attack techniques to run continuously against past, current, and future versions of Gemini ». En continu, et sur les versions futures. Pas un rapport, un processus qui tourne.

Le scan doit donc se déclencher sur les événements qui modifient le comportement :

• à chaque changement de system prompt
• à chaque mise à jour de la base de connaissance
• à chaque nouvel outil ou nouvelle permission accordée à un agent
• avant chaque déploiement
• et de façon planifiée, parce que le catalogue d'attaques continue de grandir même quand votre agent ne bouge pas

C'est tout l'intérêt de scorer des runs plutôt que de produire des rapports. Vous obtenez un chiffre qui bouge, et une régression devient visible le jour où elle apparaît au lieu du prochain audit.

La plupart des équipes n'y sont pas encore

L'écart entre déploiement et contrôle se mesure, et il apparaît dans trois jeux de données indépendants.

Presque personne n'a d'outillage conçu pour ça. Pentera a interrogé 300 CISOs et dirigeants sécurité américains pour son AI Security and Exposure Benchmark 2026, publié en février 2026. Seuls 11 % déclarent disposer d'outils de sécurité spécifiquement conçus pour protéger des systèmes IA. Seul 1 % dispose d'un budget de sécurité IA dédié. Pendant ce temps, 75 % « rely on extending controls originally designed for other attack surfaces to cover AI-driven workflows », et 67 % reconnaissent une visibilité limitée sur l'usage réel de l'IA dans leur environnement.

Étirer un pare feu applicatif par dessus un agent ne teste pas si on peut convaincre cet agent d'appeler le mauvais outil. Rien dans la stack traditionnelle ne le fait.

Personne ne sait combien d'agents il fait tourner. Une étude de la Cloud Security Alliance menée auprès de 418 professionnels IT et sécurité en janvier 2026 montre que 82 % avaient découvert des agents jusque là inconnus dans leur environnement au cours de l'année écoulée, et que 65 % avaient connu au moins un incident lié à un agent IA sur la même période. Quand un agent sort de son périmètre, 38 % exigent une validation humaine et 24 % exigent que l'action soit loguée. Seuls 11 % la bloquent automatiquement.

Et les brèches s'accumulent. Le Cost of a Data Breach d'IBM, mené par le Ponemon Institute sur environ 600 organisations victimes chaque année, donne une tendance nette. Dans l'édition 2025, 13 % des organisations déclaraient une brèche sur un modèle ou une application IA, et 97 % d'entre elles n'avaient aucun contrôle d'accès IA en place. Dans l'édition 2026, publiée le 29 juillet 2026 et couvrant les brèches jusqu'à février 2026, ce chiffre dépasse 20 %. Une brèche malveillante sur quatre est désormais assistée par IA, en hausse de 56 % sur un an, pour un coût moyen de 6 millions de dollars, environ un million au dessus de la moyenne mondiale.

Les causes principales que cite IBM pour les brèches visant l'IA sont les APIs, applications ou plug ins compromis à 27 %, et les erreurs de configuration cloud sur les workloads IA à 27 %. Aucune des deux n'est un problème de modèle. Les deux sont des problèmes de système.

Et loguer une action non autorisée n'est pas un contrôle non plus. C'est la trace de ce que vous n'avez pas su empêcher.

Par où commencer, même sans nous

Si vous faites tourner un agent aujourd'hui, trois choses valent le coup dès cette semaine :

1. Écrivez ce que votre agent a le droit de toucher, outil par outil, et vérifiez que c'est le code qui l'applique et pas le prompt.
2. Prenez vos dix pires scénarios, ceux qui vous feraient appeler votre avocat, et transformez chacun en une attaque que vous pouvez rejouer à la demande. Puis rejouez chacune des centaines de fois, parce qu'aux taux de réussite mesurés en 2026, une tentative unique ne vous apprend presque rien.
3. Notez ces rejeux sur l'impact réel, pas sur la formulation de la réponse.

C'est toute l'idée derrière Security Lab, et c'est ce qu'on automatise chez AGO. Les agents qui opèrent à l'intérieur de votre produit valent la peine d'être construits. Ils valent aussi la peine d'être attaqués, régulièrement, avant que quelqu'un d'autre ne le fasse à votre place.

Découvrir comment la plateforme AGO gère la sécurité des agents