if ( !emtpy($headline_subheadline ) ) : ?>
Les agents sont constamment amenés à révéler leurs informations d’identification, et la correction d’une voie d’attaque en laisse d’autres ouvertes.
endif; ?>
Tout au long de cette année, Amazon Web Services (AWS) a dû à plusieurs reprises corriger des failles de sécurité des agents autonomes, qui ont ensuite réapparu sous des formes légèrement différentes, selon les chercheurs en cybersécurité de l’unité 42 de Palo Alto Networks et de Zenity Labs.
Mais le problème ne vient pas d’AWS, qui semble réagir rapidement pour répondre aux rapports de sécurité, mais plutôt de la nature essentielle des agents d’IA autonomes et de la difficulté de contrôler ces agents. Le fait qu’un hyperscaler doté des ressources massives d’Amazon ne semble pas pouvoir anticiper le problème illustre le défi agentique auquel sont confrontés tous les responsables informatiques et cybersécurité des entreprises.
Problèmes avec AgentCore
Le 18 septembre 2026, par exemple, les chercheurs en cybersécurité de l’unité 42 de Palo Alto Networks ont signalé un problème « où l’utilisation de configurations par défaut dans AWS AgentCore Harness pourrait permettre aux attaquants de diriger les actions d’un agent via une injection rapide pour exfiltrer les informations d’identification en clair gérées par AgentCore Identity ».
La description du problème révélée dans le rapport illustre la faille agentique par excellence : l’accès même qui permet aux agents d’exercer leurs fonctions crée également un risque de sécurité majeur.
« L’outil shell intégré du harnais, qui est activé par défaut, atteint le même espace mémoire où les informations d’identification sont résolues en texte brut », explique le rapport. « Les outils intégrés contribuent en grande partie à ce qui rend le harnais si autonome et productif. L’agent peut écrire des fichiers et exécuter du code pour accomplir un véritable travail. Mais la même portée qui rend les outils intégrés utiles les rend dangereux lorsque les gens les laissent involontairement en marche. »
« Nous avons constaté que l’outil shell s’exécute en tant que root à l’intérieur du harnais, donc dès qu’un attaquant demande à l’agent d’exécuter une commande, cette commande hérite du même accès root », ajoute-t-il. « Rien ne doit être mal configuré pour que cela se produise. C’est l’état prêt à l’emploi. »
Le rapport de l’Unité 42 indique que la réponse d’Amazon était ambiguë quant à savoir si l’entreprise avait effectivement comblé ce trou : « Nous avons divulgué cette découverte à AWS. AWS a examiné et clôturé le rapport comme étant informatif dans le cadre du modèle de responsabilité partagée AgentCore », a-t-il noté.
Plusieurs mois plus tôt, le 7 avril, l’unité 42 avait également alerté AWS sur une voie différente vers l’exfiltration des informations d’identification.
Dans sa description de ce problème, il a déclaré avoir trouvé une régression de sécurité critique dans laquelle AgentCore Runtime utilisait un service de métadonnées microVM (MMDS) qui manquait d’application des jetons de session.
« Avant notre divulgation et les correctifs d’AWS, cette configuration aurait pu permettre à un attaquant d’exploiter des vulnérabilités Web standard, telles que la falsification de requêtes côté serveur (SSRF), pour extraire directement des informations d’identification sensibles, mettant ainsi l’ensemble de l’environnement en danger », écrivait alors l’Unité 42.
Zenity a réussi à obtenir qu’un agent renvoie un ensemble complet d’informations d’identification STS temporaires : un ID de clé d’accès, une clé d’accès secrète et un jeton de session appartenant au rôle d’exécution de l’agent. « Ces informations d’identification ne sont pas limitées au bac à sable. Nous les avons exportées sur notre propre machine, entièrement en dehors d’AgentCore, et avons confirmé qu’elles étaient actives », indique le rapport.
L’agent a fourni des données comprenant des autorisations de lecture ECR, « nous nous sommes donc authentifiés auprès du registre et avons extrait l’image. À partir de là, le code source de l’agent, ses dépendances et tout ce que ses développeurs ont intégré étaient à nous d’inspecter, en tant que root », indique le rapport.
« À ce stade, une réaction raisonnable est : « Alors ne donnez pas aux agents un outil HTTP brut » », a noté Zenity. « Cela n’aide pas. L’échec de l’isolation se situe au niveau de la plate-forme, pas au niveau de l’outil, donc tout ce qui peut générer du trafic sortant atteint IMDS de la même manière. Nous avons reproduit le résultat identique à travers plusieurs outils, y compris l’outil shell intégré de Strands. »
Mais, selon le rapport Zenity, l’agent partageait également les informations d’identification d’autres agents.
« AgentCore nomme chaque référentiel d’après son agent (« bedrock-agentcore-
« Nous avons découvert que le rôle détenait des autorisations d’accès READ, WRITE et DELETE à divers services AgentCore et AWS dans la région AWS », indique-t-il. « Cela nous a permis d’invoquer d’autres agents et de nous déplacer latéralement dans la région, de lire toutes les conversations privées de tous les utilisateurs et agents, d’empoisonner la mémoire et de conserver la persistance, de récolter des informations d’identification et des clés API qui peuvent déverrouiller l’accès au-delà d’AWS et exécuter des actions destructrices dans la même région.
L’état du correctif n’est pas clair
Il n’est pas tout à fait clair dans quelle mesure cette exposition existe encore aujourd’hui. Selon le calendrier publié par Zenity, ses chercheurs ont découvert une grande partie de cela fin 2025 et ont communiqué les détails à AWS le 25 décembre. AWS a répondu avec une mise à jour en février 2026, mais Zenity a déclaré qu’il avait peut-être simplement fermé un chemin limité vers l’exposition, laissant d’autres ouverts aux attaques.
Zenity a confirmé que depuis le 8 octobre, les autorisations de l’environnement AWS avaient été corrigées et qu’il n’était plus exposé au chemin d’attaque qu’ils avaient découvert.
Mais une chronologie plus précise fournie par Zenity illustre trois choses : la complexité de la sécurisation des environnements agentiques ; les défis liés à la réparation de ce trou et à ce que le trou reste réparé ; et les difficultés à déterminer si un trou a été véritablement comblé.
Après les rapports Zenity et Palo Alto, AWS a mis à jour son environnement en février, pensant avoir résolu le problème. Mais un e-mail du 8 octobre de Tamir Ishay Sharbat, directeur de la recherche en sécurité chez Zenity, a déclaré que le correctif de février n’avait en fait pas résolu la faille.
« Après nos divulgations, AWS a rapidement mis à jour AgentCore pour utiliser IMDSv2 uniquement le 14 février 2026. Cette mise à jour a corrigé le vecteur d’entrée initial qui nous a permis d’accéder aux informations d’identification en premier lieu », a-t-il écrit, mais « le 22 juin, nous avons vérifié le rôle par défaut d’AgentCore et avons constaté que ses autorisations restaient inchangées ».
Cependant, a-t-il écrit, les vérifications ultérieures de Zenity ont confirmé qu’AWS a résolu le problème d’autorisations entre le 22 juin et le 29 septembre.
Interrogé sur ce que les RSSI et DSI devraient faire face aux problèmes mentionnés dans le rapport, le directeur technique de Zenity, Michael Bargury, a répondu dans un e-mail que le problème était difficile car, d’une part, une défense solide signifie une forte isolation des agents. Mais, a-t-il noté, « les agents ont besoin d’autonomie et de connectivité pour être utiles. Les deux sont en contradiction, comme le montre cette recherche. Les entreprises doivent être conscientes de ce conflit inhérent et planifier leurs contrôles de sécurité en conséquence. »
AWS a décliné une demande d’entretien, mais a envoyé par courrier électronique une brève déclaration dans laquelle il souligne à nouveau que les agents ont fait ce qu’ils étaient censés faire. Il lui a également été demandé de commenter le rapport Zenity ; en réponse, un porte-parole a déclaré : « AWS est au courant des recherches publiées sur Amazon Bedrock AgentCore, qui décrivent de manière inexacte le comportement attendu et documenté comme une vulnérabilité. Un agent ne peut accéder aux ressources d’un autre compte AWS que si le développeur accorde explicitement des autorisations sur le rôle d’exécution de l’agent et sur la ressource cible. Comme meilleure pratique, nous recommandons aux clients d’accorder à leurs rôles d’exécution uniquement les autorisations dont leurs agents ont besoin. «
Les analystes et les consultants ont trouvé les détails des deux rapports préoccupants, mais pas surprenants, étant donné le grand nombre de problèmes d’agents qu’ils ont observés jusqu’à présent. Mais de tous les détails publiés, le problème de mémoire était le plus déconcertant pour certains.
Frank Dickson, analyste principal chez Dickson Research, a déclaré : « C’est l’empoisonnement de la mémoire qui m’inquiète le plus. Une mémoire empoisonnée transforme un agent utile en un candidat mandchou, attendant la bonne conversation pour l’envoyer quelque part où il ne devrait pas aller. Vous pouvez faire pivoter une clé volée. Il est beaucoup plus difficile de savoir à quelles mémoires faire confiance. »
Nik Kale, membre de la Coalition for Secure AI (CoSAI) et membre du comité du programme AI Security (AISec) de l’ACM, a également estimé que le problème de mémoire était le plus grave.
« Un identifiant volé expire au bout de quelques heures, mais pas une mémoire empoisonnée », a souligné Kale. « Il continue de diriger les conversations longtemps après que chaque clé ait été tournée. »
De vieilles erreurs refont surface sous de nouvelles formes
Fred Chagnon, directeur de recherche principal chez Info-Tech Research Group, a déclaré qu’il considérait les différents problèmes d’agent AWS comme « une leçon sur la façon dont les anciennes erreurs de configuration de plate-forme réapparaissent sur de nouvelles plates-formes et de nouvelles manières ».
Par exemple, a-t-il déclaré, la faille de sécurité AWS qui a utilisé SSRF pour atteindre le service de métadonnées et voler les informations d’identification d’une charge de travail « est essentiellement le modèle derrière la violation de Capital One en 2019 : SSRF, informations d’identification de rôle volées et un rôle surprivilégié qui a transformé un point d’ancrage en un accès beaucoup plus large. »
Mais avec le problème actuel, a déclaré Chagnon, « le déclencheur est différent : un agent doté d’un shell ou d’un outil HTTP récupérera une URL lorsqu’il lui sera demandé, donc l’invite elle-même constitue l’exploit. »
Et, a-t-il ajouté, « le plus gros problème est le rayon d’explosion. Un agent compromis a atteint chaque agent, conversation et secret du compte et de la région ».
Le plus difficile est de savoir ce que les RSSI et les DSI des entreprises devraient faire à ce sujet. L’un des défis les plus anciens de l’informatique consiste à jongler avec des environnements dans lesquels l’autorité, les contrôles et l’accès sont partagés, avec l’hyperscaler, comme dans les premiers déploiements cloud initiaux, prenant certaines décisions à l’insu ou sans la permission de ses plus grands locataires d’entreprise.
« La responsabilité ici est partagée. Isoler le bac à sable et garder le matériel de la plate-forme hors des métadonnées de l’instance est le travail d’AWS, et aucun client ne peut résoudre ce problème », a expliqué Chagnon. « Les autorisations par défaut sont quelque chose que l’ingénieur cloud peut et doit remplacer, mais la plupart ne le feront pas. Un rôle par défaut avec un accès générique reste le risque. AWS pourrait fournir des valeurs par défaut de moindre privilège définies par agent et limiter l’accès aux métadonnées à partir du bac à sable. »
Cependant, a-t-il ajouté, dans le modèle de responsabilité partagée, la responsabilité de ces contrôles incombe à l’entreprise. Les RSSI doivent rédiger leurs propres règles de moindre privilège et traiter les outils Shell et HTTP comme à haut risque. Ils doivent restreindre la sortie, garder les images secrètes et définir l’identité de chaque agent et l’utilisation des outils afin que les anomalies soient mises en évidence.
« Les entreprises ne peuvent pas plus corriger les failles des plateformes cloud qu’elles ne peuvent réparer ou compenser la litanie des failles des logiciels d’entreprise », a-t-il déclaré. « Mais ils peuvent décider et concevoir l’ampleur des dégâts qu’un agent compromis peut causer. »
Le gros problème : les agents travaillaient comme prévu
Dickson a ajouté que le gros problème avec les situations AWS n’était pas que les agents fonctionnaient mal, mais qu’ils fonctionnaient exactement comme prévu.
« L’agent a fait exactement ce qu’on lui demandait. C’est là le problème », a-t-il déclaré. « Zenity Labs a trouvé une chaîne : un agent qui peut accéder au réseau, un service de métadonnées qui y répond avec les propres informations d’identification cloud de l’agent et un rôle d’exécution par défaut avec bien plus d’autorisations que n’importe quel agent n’en a besoin. Chaque lien est une erreur familière. Les enchaîner transforme un agent public en une carte-clé d’hôtel qui ouvre chaque pièce du bâtiment. «
Kale accepta.
« Extraire des informations d’identification d’un service de métadonnées est le 101e hacking dans le cloud, et ce qui est nouveau, c’est que les chercheurs n’ont pas eu besoin de trouver un bug pour y parvenir. Ils ont simplement demandé à l’agent dans un anglais simple », a déclaré Kale. « Une fois que cela est possible, la solidité des murs du bac à sable cesse d’être une question intéressante. La véritable frontière est l’identité que porte l’agent, et si cette identité s’étend à d’autres agents, une conversation peut avoir un impact sur tout un environnement. »
Justin Greis, PDG du cabinet de conseil Acceligence, a déclaré qu’il insisterait auprès des RSSI d’entreprise sur l’importance de contrôler l’accès aux données secondaires.
« Le rayon d’action d’un agent mal gouverné peut être bien plus grand que celui auquel la plupart des organisations sont habituées avec les applications traditionnelles », a-t-il déclaré. « Ce qui ressort de cette recherche est l’effet d’amplification. Le problème n’était pas simplement qu’un agent puisse être manipulé. Le problème est que la compromission d’un agent crée potentiellement un chemin vers des informations d’identification plus larges, d’autres agents, du code source, des informations sensibles et une manipulation persistante du comportement. C’est là que cela devient un problème exécutif plutôt qu’une simple vulnérabilité technique. »
Il a suggéré que les DSI et les RSSI se posent des questions clés, et insistent pour y répondre, telles que l’identité sous laquelle l’agent opère, ce à quoi il peut accéder, ce qu’il peut modifier, ce dont il peut se souvenir et quels autres agents ou systèmes il peut atteindre.
« Et, » a-t-il ajouté, « plus important encore, que se passe-t-il si l’information est compromise ? »
