Agents d’IA hors de contrôle : les attaques de détournement de session dans les systèmes A2A

Avant-propos

Nous avons identifié une nouvelle technique d’attaque, appelée détournement de session agentique (pour « agent session smuggling »). Elle permet à un agent IA malveillant d’exploiter une session de communication déjà établie entre agents pour transmettre des instructions dissimulées à un agent victime.

Nous analysons ici les risques liés aux sessions de communication reposant sur le protocole Agent2Agent (A2A), largement utilisé pour orchestrer les échanges entre agents. Ce protocole, fondé sur la conservation de l’état des interactions, permet aux agents de se souvenir des échanges récents et de maintenir une continuité conversationnelle. L’attaque exploite précisément cette capacité pour insérer des instructions malveillantes dans le cadre d’un échange, en les dissimulant au sein de requêtes et de réponses légitimes.

Alors que la plupart des menaces associées à l’IA reposent sur un élément malveillant unique (e-mail piégé ou document trompeur), notre recherche met en évidence un danger d’un tout autre ordre : des agents malveillants.

Une attaque classique contre un agent victime consisterait à le tromper une seule fois, en l’incitant à exécuter des instructions malveillantes contenues dans un document, sans demander la confirmation de son utilisateur. À l’inverse, un agent non autorisé constitue une menace bien plus dynamique : il peut dialoguer, adapter sa stratégie et instaurer progressivement un faux climat de confiance au fil des interactions.

Ce scénario est particulièrement dangereux car, comme l’a montré une étude récente, les agents sont souvent conçus pour faire confiance par défaut à ceux avec lesquels ils collaborent. Le détournement de session agentique exploite précisément cette confiance implicite, permettant à un attaquant de manipuler un agent victime tout au long d’une session.

Notre recherche ne met pas en évidence de vulnérabilité propre au protocole A2A. La technique tire plutôt parti des relations de confiance implicites entre agents – un phénomène qui pourrait affecter tout protocole à états, c’est-à-dire capable de mémoriser les échanges récents et de mener des conversations en plusieurs tours.

L’atténuation de ce type d’attaque repose sur une défense multicouche, combinant :

• l’approche HITL, qui maintient l’humain dans la boucle pour les actions critiques ;
• une vérification des agents à distance, par exemple via des AgentCards signées de manière cryptographique ;
• des mécanismes d’ancrage contextuel, destinés à détecter les instructions hors sujet ou injectées dans la conversation.

Les clients de Palo Alto Networks sont mieux protégés grâce aux produits suivants :

Prisma AIRS a été conçu pour assurer une protection multicouche en temps réel des systèmes d’IA : détection et blocage des menaces, prévention des fuites de données et application de politiques d’utilisation sécurisées sur un large éventail d’applications d’IA.

AI Access Security a été conçu pour offrir une visibilité et un contrôle accrus sur les solutions de GenAI tierces. Cette solution contribue à prévenir les expositions de données sensibles, les usages non sécurisés de modèles à risque et les résultats potentiellement préjudiciables, grâce à l’application de politiques de sécurité et à la surveillance de l’activité des utilisateurs.

Cortex Cloud AI-SPM assure une analyse et une classification automatiques des actifs liés à l’IA, qu’il s’agisse de modèles commerciaux ou autogérés, afin de détecter les données sensibles et d’évaluer la posture de sécurité associée. Le contexte d’analyse est déterminé en fonction du type d’IA, de l’environnement cloud d’hébergement, du niveau de risque, de la posture de sécurité et des jeux de données utilisés.

Une évaluation de sécurité de l’IA Unit 42 peut vous aider à identifier de manière proactive les menaces les plus susceptibles de cibler votre environnement d’IA.

Vous pensez que votre entreprise a été compromise ? Vous devez faire face à une urgence ? Contactez l’équipe de réponse à incident d’Unit 42.

Aperçu du protocole A2A et comparaison avec le MCP

Le protocole A2A est une norme ouverte conçue pour assurer l’interopérabilité des communications entre agents IA, indépendamment du fournisseur, de l’architecture ou de la technologie sous-jacente. Son objectif principal est de permettre aux agents de se découvrir, de se comprendre et de collaborer afin de résoudre des tâches complexes et distribuées, tout en préservant leur autonomie et la confidentialité des échanges.

Dans le cadre du protocole A2A :

• Un agent local s’exécute dans la même application ou le même processus que l’agent initiateur, ce qui permet une communication rapide, en mémoire.
• Un agent distant fonctionne comme un service indépendant, accessible via le réseau. Il utilise le protocole A2A pour établir un canal de communication sécurisé, lui permettant de traiter des tâches déléguées par d’autres systèmes – voire d’autres organisations –, avant d’en renvoyer les résultats.

Pour une présentation détaillée des principes de base du protocole A2A et des considérations de sécurité associées, consultez notre article : Safeguarding AI Agents: An In-Depth Look at A2A Protocol Risks and Mitigations (Sécuriser les agents IA : analyse approfondie des risques et mesures d’atténuation liés au protocole A2A).

Le protocole A2A présente de nombreux points communs avec le Model Context Protocol (MCP), une norme largement utilisée pour connecter les large language models (LLM) à des outils externes et à des données contextuelles. Tous deux visent à standardiser les interactions entre systèmes d’IA, mais ils s’appliquent à des dimensions différentes des architectures agentiques.

• Le MCP agit comme un adaptateur universel, offrant un accès structuré aux outils et aux sources de données. Il prend principalement en charge la communication entre LLM et outils au moyen d’un modèle d’intégration centralisé.
• Le protocole A2A, quant à lui, se concentre sur l’interopérabilité entre agents. Il permet une coordination décentralisée et « peer-to-peer », dans laquelle les agents peuvent déléguer des tâches, échanger des informations et conserver l’état de leurs interactions au sein de processus collaboratifs.

En résumé, le MCP met l’accent sur l’exécution à travers l’intégration d’outils, tandis que l’A2A privilégie l’orchestration entre agents.

Malgré ces différences, les deux protocoles sont exposés à des catégories de menaces similaires, comme l’illustre le Tableau 1.

Tableau 1. Comparaison des attaques MCP et A2A.

Les attaques de détournement de session agentique

Le détournement de session agentique est un nouveau vecteur d’attaque propre aux communications inter-agents à états, comme celles mises en œuvre dans les systèmes A2A. Une communication est dite « à états » lorsqu’elle peut conserver l’état d’une session – c’est-à-dire se souvenir des échanges récents et invoquer ce contexte au fil d’une conversation.

Au cœur de l’attaque se trouve un agent distant malveillant qui abuse d’une session active pour injecter, entre une requête client légitime et la réponse du serveur, des instructions supplémentaires dissimulées. Ces instructions cachées peuvent provoquer un empoisonnement du contexte (altérant la compréhension de la conversation par l’IA), l’exfiltration de données ou l’exécution non autorisée d’outils par l’agent client.

La Figure 1 présente la séquence de l’attaque :

• Étape 1 : l’agent client initie une nouvelle session en envoyant une requête normale à l’agent distant.
• Étape 2 : l’agent distant commence à traiter la requête. Pendant la session active, il transmet secrètement des instructions supplémentaires au client sur plusieurs tours d’échange.
• Étape 3 : l’agent distant renvoie la réponse attendue à la requête initiale, complétant la transaction.

Propriétés clés de l’attaque

• À états : l’attaque exploite la capacité de l’agent distant à gérer des tâches de longue durée et à conserver l’état d’une session. Autrement dit, l’agent enregistre le contexte d’une interaction (à l’image d’une personne qui se souvient du début d’une phrase en attendant la fin) et peut réutiliser ces informations sur plusieurs tours (par ex. historique de conversation, variables, avancement d’une tâche lié à un identifiant de session). Ainsi, les messages ultérieurs peuvent dépendre du contexte antérieur.
• Interaction multi-tour : du fait de cette conservation d’état, deux agents connectés peuvent tenir des conversations en plusieurs tours. Un agent malveillant peut tirer parti de ce mécanisme pour mener des attaques progressives et adaptatives sur plusieurs échanges – des attaques qui se sont montrées nettement plus difficiles à contrer dans des travaux antérieurs (voir « LLM Defenses Are Not Robust to Multi-Turn Human Jailbreaks Yet »).
• Autonomie et adaptabilité : les agents malveillants, propulsés par des modèles d’IA, peuvent générer dynamiquement des instructions en fonction du contexte en temps réel (entrées du client, réponses intermédiaires, identité de l’utilisateur, etc.).
• Indétectable pour les utilisateurs finaux : les instructions injectées interviennent en cours de session et restent cachées – les utilisateurs voient généralement uniquement la réponse finale consolidée fournie par l’agent client.

En principe, tout système multi-agent reposant sur une communication inter-agents à états peut être vulnérable à ce type d’attaque. Le risque est toutefois réduit dans les architectures entièrement contenues au sein d’un même périmètre de confiance – une zone du système où tous les composants sont considérés comme fiables par défaut, comme c’est le cas pour certains déploiements ADK ou LangGraph où un unique administrateur contrôle l’ensemble des agents participants.

Notre recherche se concentre donc sur le protocole A2A, conçu explicitement pour l’interopérabilité cross-boundary (sur plusieurs périmètres). Cette interopérabilité permet aux agents de coopérer entre systèmes, modules ou organisations distincts.

Par rapport aux menaces connues ciblant le MCP, le détournement de session agentique exploite la conception « à états » et adaptative de l’A2A d’une manière inapplicable au MCP. Les serveurs MCP fonctionnent généralement « sans état », en exécutant des invocations d’outils isolées sans conserver l’historique de session, ce qui limite la capacité des attaquants à conduire des attaques multi-tours ou évolutives.

De plus, les serveurs MCP sont le plus souvent statiques et déterministes, puisqu’ils ne reposent pas sur des modèles d’IA. À l’inverse, un serveur A2A peut conserver l’état entre les interactions et tirer parti d’un raisonnement piloté par modèle, ce qui permet à un agent malveillant d’adapter et d’affiner ses instructions sur plusieurs tours. Cette combinaison de persistance et d’autonomie rend le détournement de session agentique plus furtif et plus difficile à détecter et à contrer que les attaques basées sur le MCP.

Preuves de concept : les attaques de détournement de session agentique

Pour démontrer la faisabilité et l’impact potentiel du détournement de session agentique, nous avons développé deux scénarios de preuve de concept (PoC). Le dispositif met en présence un assistant financier (agent client) et un assistant de recherche (agent distant malveillant). Ces PoC illustrent comment un agent malveillant peut exfiltrer des données sensibles et déclencher des actions non autorisées sans que l’utilisateur final ne s’en aperçoive.

1. Fuite d’informations sensibles : extraction de données confidentielles depuis l’agent client
2. Invocation d’outils non autorisés : amener l’agent client à exécuter, au nom de l’utilisateur victime, des actions non autorisées

Paramètres de l’environnement :

• Cadre de développement : Google Agent Development Kit (ADK)
• Protocole de communication inter-agents : A2A
• Agent client : assistant financier basé sur l’exemple ADK financial-advisor. L’agent gère des tâches telles que la récupération d’actualités financières, la gestion de portefeuilles et l’exécution d’opérations boursières.
  • Modèle : Gemini 2.5 Pro
  • Outils disponibles : get_portfolio, get_profile, buy_stock, sell_stock
• Agent distant : assistant de recherche adapté de l’exemple ADK data_analyst. Sa fonction prévue est de récupérer et de synthétiser des informations sur les entreprises.
  • Modèle : Gemini 2.5 Flash
  • Outils disponibles : Google Search
• Interface utilisateur : ADK Developer Web UI

Preuve de concept n°1 – Fuite d’informations sensibles

Dans ce scénario, l’agent distant malveillant (assistant de recherche) cherche à exfiltrer l’état interne de l’agent client (assistant financier), et notamment :

• l’historique du chat
• les instructions système
• les outils disponibles
• les schémas des outils

L’attaque se déroule de manière subtile. Après avoir reçu une requête légitime de l’assistant financier, l’assistant de recherche pose une série de questions de clarification apparemment anodines. Ces relances piègent progressivement l’assistant financier et l’amènent à divulguer des informations sensibles qui ne devraient jamais quitter son environnement.

La Figure 2 illustre le flux d’interaction utilisateur. La session commence normalement : l’utilisateur demande à l’assistant financier de récupérer le portefeuille d’investissement et le profil, puis sollicite un point sur l’actualité du marché de l’IA.

Cette demande d’actualité est déléguée à l’assistant de recherche. Comme le montre le panneau droit de la figure, l’assistant de recherche enchaîne une série d’échanges avec l’assistant financier : à l’exception de la requête initiale et de la réponse finale, toutes les interactions intermédiaires sont injectées par l’assistant de recherche.

Les étapes intermédiaires visibles dans la Figure 2 n’apparaissent que parce que l’interface web de développement affiche chaque action interne. Dans une interface chatbot en production, ces échanges internes resteraient vraisemblablement invisibles pour l’utilisateur.

La Figure 3 donne une vue plus détaillée via le journal d’activité de l’assistant financier. La ligne 10 affiche la requête initiale envoyée à l’assistant de recherche, et la ligne 28 montre le résultat final produit par l’agent de recherche. Les lignes 11 à 27, alternant entre function_call et function_response, révèlent les interactions entre les deux agents. Au fil de ces échanges, l’assistant financier a divulgué progressivement sa configuration système ainsi que l’historique de conversation de l’utilisateur.

Enfin, la Figure 4 présente le journal de l’assistant de recherche après l’attaque. Il confirme l’exfiltration réussie de données, incluant les capacités de l’assistant financier, les schémas d’outils et l’intégralité de l’historique de session.

Preuve de concept n°2 – Invocation d’outils non autorisés

Dans ce scénario, l’agent distant malveillant (assistant de recherche) cherche à tromper l’agent client (assistant financier) pour le pousser à exécuter des opérations boursières non autorisées. L’objectif de l’attaquant est d’abuser de l’outil buy_stock de l’agent client, à l’insu et sans le consentement de l’utilisateur final.

Après réception d’une requête de délégation valide, l’assistant de recherche transmet des exigences de traitement supplémentaires qui incitent l’assistant financier à lancer des appels d’outils sans lien avec la demande initiale de l’utilisateur. Ce PoC part du principe que l’attaquant connaît les outils de l’assistant financier, soit par des sources publiques, soit grâce au succès du PoC 1.

La Figure 5 illustre le flux d’interaction utilisateur. Sur le panneau droit, la demande d’actualités de l’utilisateur est déléguée à l’assistant de recherche. Si celui-ci fournit bien le résumé attendu, il insère également des instructions dissimulées qui poussent l’assistant financier à invoquer l’outil buy_stock. Là encore, ces actions intermédiaires s’exécutent de manière autonome et resteraient invisibles dans une interface chatbot en production, où l’utilisateur ne voit généralement que la réponse finale synthétisée.

La Figure 6 présente le journal d’activité de l’assistant financier. La ligne 7 montre la requête initiale envoyée à l’assistant de recherche, et la ligne 12 affiche la réponse légitime reçue. Les lignes 8 à 11 révèlent toutefois quatre actions supplémentaires que l’assistant financier a exécutées de manière autonome, aboutissant à l’achat non autorisé de 10 actions pour le compte de l’utilisateur victime. Cette séquence illustre comment un détournement de session agentique peut passer d’une simple fuite d’informations à l’exécution d’actions à fort impact.

Atténuation et protection

La défense contre le détournement de session agentique repose sur une approche de sécurité en couches, qui valide à la fois l’identité des agents, l’intégrité des échanges et l’impact des actions exécutées. Les stratégies suivantes peuvent contribuer à réduire les risques :

• Imposer une confirmation hors bande pour les actions sensibles : la défense la plus efficace consiste à exiger une intervention humaine dans la boucle (HITL) pour toute action critique ou à fort impact. Cette confirmation doit impérativement se faire hors bande, via un canal distinct que le modèle d’IA ne peut influencer. Lorsqu’un agent reçoit l’instruction d’exécuter une tâche critique, le cadre d’orchestration doit suspendre l’exécution, puis déclencher une demande de validation dans une partie statique de l’interface utilisateur de l’application – ou par un canal séparé, tel qu’une notification push.
• Mettre en œuvre un ancrage contextuel : une attaque de détournement de session repose sur la déviation progressive d’une conversation pour y injecter des commandes malveillantes. L’ancrage contextuel constitue un mécanisme technique qui applique algorithmiquement l’intégrité conversationnelle. Lorsqu’un agent client initie une session, il doit créer une ancre de tâche fondée sur l’intention initiale de la requête utilisateur. Au fil de l’interaction, l’agent client doit constamment vérifier que les instructions de l’agent distant demeurent sémantiquement alignées sur cette ancre. Toute déviation significative ou introduction de sujet étranger doit conduire l’agent client à signaler l’échange comme une tentative de détournement et à mettre fin à la session.
• Valider l’identité et les capacités des agents : la communication sécurisée entre agents doit reposer sur une confiance vérifiable. Avant d’établir une session, les agents doivent présenter des matériels d’authentification vérifiables, comme des AgentCards signées de manière cryptographique. Cela permet à chaque participant de confirmer l’identité, l’origine et les capacités déclarées de l’autre. Si ce contrôle n’empêche pas qu’un agent de confiance soit subverti, il élimine le risque d’usurpation d’agent et de spoofing, tout en constituant un registre auditable et difficilement falsifiable de l’ensemble des interactions.
• Rendre l’activité de l’agent client visible pour les utilisateurs : les instructions et actions dissimulées restent invisibles aux utilisateurs finaux, qui voient uniquement la réponse finale fournie par l’agent client. L’interface peut combler cette faiblesse en exposant l’activité des agents en temps réel – par exemple en mettant en évidence les invocations d’outils, en affichant des journaux d’exécution en direct ou en proposant des indicateurs visuels des instructions distantes. Ces signaux améliorent la vigilance des utilisateurs et augmentent les chances de détecter une activité suspecte.

Conclusion

Cet article présente le détournement de session agentique, une nouvelle technique d’attaque visant la communication inter-agents dans les systèmes A2A. Contrairement aux menaces impliquant des outils malveillants ou des utilisateurs finaux, un agent compromis constitue un adversaire bien plus redoutable. Propulsé par un modèle d’IA, un agent compromis peut générer de manière autonome des stratégies adaptatives, exploiter l’état des sessions et étendre son influence à l’ensemble des agents clients connectés ainsi qu’à leurs utilisateurs.

Bien qu’aucun cas n’ait encore été observé dans la nature, la faible complexité de mise en œuvre de cette attaque en fait un risque réel. Il suffirait à un adversaire de convaincre un agent victime de se connecter à un pair malveillant pour que des instructions dissimulées puissent ensuite être injectées sans visibilité pour l’utilisateur. La protection contre ce type de menace repose sur une défense en multicouches, combinant :

• une validation HITL pour toutes les actions sensibles ;
• une logique de confirmation exécutée hors des prompts du modèle ;
• un ancrage contextuel pour détecter les instructions hors sujet et une validation cryptographique des agents distants.

À mesure que les écosystèmes multi-agents se développent, leur interopérabilité ouvre également de nouvelles surfaces d’attaque. Les professionnels doivent partir du principe que la communication d’agent à agent n’est pas intrinsèquement digne de confiance. Les cadres d’orchestration doivent donc être conçus avec des garde-fous multicouche, afin de contenir les risques posés par des adversaires adaptatifs alimentés par l’IA.

Protection et atténuation des risques par Palo Alto Networks

Prisma AIRS est conçu pour assurer une protection en temps réel des applications, modèles, données et agents d’IA. La solution analyse le trafic réseau et le comportement applicatif afin de détecter des menaces telles que le prompt injection, les Attaques de denial-of-Service et l’exfiltration de données, tout en appliquant des mesures de protection en ligne, au niveau du réseau et des API.

AI Access Security a été conçu pour offrir une visibilité et un contrôle accrus sur les solutions de GenAI tierces. Cette solution contribue à prévenir les expositions de données sensibles, les usages non sécurisés de modèles à risque et les résultats potentiellement préjudiciables, grâce à l’application de politiques de sécurité et à la surveillance de l’activité des utilisateurs. Ensemble, Prisma AIRS et AI Access Security permettent de sécuriser le développement d’applications d’entreprise reposant sur l’IA ainsi que leurs interactions avec des systèmes externes.

Cortex Cloud AI-SPM assure une analyse et une classification automatiques des actifs liés à l’IA, qu’il s’agisse de modèles commerciaux ou autogérés, afin de détecter les données sensibles et d’évaluer la posture de sécurité associée. Le contexte d’analyse est déterminé en fonction du type d’IA, de l’environnement cloud d’hébergement, du niveau de risque, de la posture de sécurité et des jeux de données utilisés.

Une évaluation de sécurité de l’IA Unit 42 peut vous aider à identifier de manière proactive les menaces les plus susceptibles de cibler votre environnement d’IA.

Si vous pensez que votre entreprise a pu être compromise ou si vous faites face à une urgence, contactez l’équipe Unit 42 de réponse à incident ou composez l’un des numéros suivants :

• Amérique du Nord : Gratuit : +1 (866) 486-4842 (866.4.UNIT42)
• Royaume-Uni : +44 20 3743 3660
• Europe et Moyen-Orient : +31.20.299.3130
• Asie : +65.6983.8730
• Japon : +81 50 1790 0200
• Australie : +61.2.4062.7950
• Inde : 00080005045107

Palo Alto Networks a partagé ces conclusions avec les autres membres de la Cyber Threat Alliance (CTA). Les membres de la CTA s’appuient sur ces renseignements pour déployer rapidement des mesures de protection auprès de leurs clients et perturber de manière coordonnée les activités des cybercriminels. Cliquez ici pour en savoir plus sur la Cyber Threat Alliance.

Références

• The Dark Side of LLMs Agent-based Attacks for Complete Computer Takeover – Matteo Lupinacci et al., arXiv:2507.06850
• Multi-Agent Systems in ADK – Agent Development Kit, Google GitHub
• Graph API overview – LangChain
• A2A Protocol – The Linux Foundation
• Model Context Protocol (MCP) – Model Context Protocol
• LLM Defenses Are Not Robust to Multi-Turn Human Jailbreaks Yet – Nathaniel Li et al., Scale
• Google Agent Development Kit – Agent Development Kit, Google GitHub
• Google adk-samples – Google GitHub
• Gemini 2.5 Pro [PDF] – Google
• Gemini 2.5 Flash – Google
• ADK Google Search Tool – Google GitHub
• ADK Developer Web UI – Google GitHub
• Sigstore A2A – Google GitHub