L'essentiel
Sur AgentCore, le rayon d'impact d'un seul agent, c'était toute la région. Le 8 octobre 2026, Zenity Labs a publié AgentCorruption, une chaîne de faiblesses dans Amazon Bedrock AgentCore. Les chercheurs ont demandé à un agent public doté d'un outil web ou shell de lire le service de métadonnées d'instance, ont obtenu les identifiants temporaires de son rôle d'exécution et les ont utilisés depuis leur propre machine. Comme le rôle par défaut couvrait l'ensemble du compte et de la région, ces identifiants donnaient accès à tous les autres agents.
À partir de là, les chercheurs ont listé tous les agents, téléchargé leurs images de conteneurs et leur code source, invoqué des agents internes auxquels ils n'avaient pas droit, lu des conversations privées, extrait des clés d'API et des jetons OAuth d'AWS Secrets Manager et implanté de faux souvenirs à long terme qui détournaient les réponses suivantes. Aucune CVE n'a été attribuée.
Comment un seul prompt a-t-il pu prendre le contrôle de tous les agents ?
Le point d'entrée était une fonctionnalité d'agent tout à fait ordinaire. De nombreux agents AgentCore disposent d'un outil capable d'effectuer des requêtes web ou d'exécuter des commandes shell, car c'est précisément ce qui les rend utiles. D'après le compte rendu de Zenity, les environnements d'exécution de ces agents ne bloquaient pas le trafic vers le point de terminaison des métadonnées : une simple demande en langage naturel suffisait pour que l'agent récupère la clé d'accès, la clé secrète et le jeton de session du rôle d'exécution.
La seconde faiblesse a transformé un identifiant divulgué en compromission de toute la flotte. Le rôle d'exécution par défaut portait sur l'ensemble du compte et de la région, et non sur un seul agent. Grâce à lui, les chercheurs pouvaient énumérer tous les agents, récupérer leur code et leurs images, appeler des agents internes, lire les conversations stockées et la mémoire à long terme, et interroger Secrets Manager. Dernière étape, la persistance : ils ont écrit de faux événements de mémoire pour que les agents consultent une page contrôlée par l'attaquant avant chaque réponse. The Next Web et The Decoder ont relayé la chaîne d'attaque le 8 octobre, en s'appuyant sur la série technique en quatre volets de Zenity.
Qu'a changé AWS et quelle est sa position ?
AWS n'a pas traité le signalement comme une vulnérabilité. Dans une déclaration citée par The Next Web et The Decoder, l'entreprise indique qu'un agent ne peut accéder à des ressources d'un autre compte AWS que si le développeur accorde explicitement des permissions à la fois sur le rôle d'exécution et sur la ressource cible, et elle recommande de ne donner aux rôles d'exécution que les droits nécessaires à leurs agents. Selon Zenity, AWS avait d'abord clos le signalement sur les métadonnées comme simplement « informatif ».
Les paramètres par défaut ont tout de même évolué. Les nouveaux agents sont déployés en IMDSv2 uniquement depuis le 14 février 2026, et lors d'une dernière vérification le 29 septembre 2026, Zenity a constaté que le rôle par défaut avait perdu les permissions d'invoquer d'autres agents, de lire les conversations privées et d'accéder à Secrets Manager. Le point essentiel pour les clients : modifier un paramètre par défaut protège les nouveaux déploiements, pas les rôles qui existent déjà dans vos comptes.
Ce que cela change pour les équipes logicielles aux États-Unis et dans l'UE
D'abord, les outils d'un agent sont un chemin d'attaque vers le plan de contrôle du cloud. Un outil de récupération web ou un shell sur un agent public représente fonctionnellement le même risque qu'une faille SSRF (falsification de requête côté serveur) dans une application web. Toute personne capable de discuter avec l'agent peut tenter de lui faire atteindre des points de terminaison internes. Les modèles de menace des agents IA doivent traiter chaque prompt d'un utilisateur non fiable comme une entrée potentiellement hostile, et non comme une conversation.
Ensuite, un « comportement documenté » laisse quand même le risque chez vous. Dans le modèle de responsabilité partagée, AWS considère les rôles à moindre privilège comme l'affaire du client. Lors d'un audit SOC 2, ISO 27001 ou NIS2, un agent doté d'un rôle valable pour toute la région est donc votre écart, pas celui de votre fournisseur. Les équipes qui conçoivent des agents IA en production devraient prévoir un rôle par agent, limité aux ressources exactes qu'il manipule, et tenir les secrets hors de portée de l'agent sauf si un outil précis en a besoin.
Enfin, la mémoire des agents entre désormais dans le périmètre de la protection des données. Une mémoire à long terme empoisonnée survit aux redémarrages et peut détourner discrètement les utilisateurs. Les conversations stockées contiennent souvent des données personnelles au sens du RGPD, et leur lecture non autorisée constituerait une violation à notifier. Les espaces de mémoire ont besoin de contrôles d'intégrité, de journaux d'audit et de règles de conservation, comme n'importe quelle base de données contenant des données clients.
Quelles conséquences pour le marché français ?
En France, la question des agents IA sur un cloud américain se pose rarement sous l'angle de l'IAM : le débat porte surtout sur la souveraineté et l'hébergement des données, avec les offres qualifiées SecNumCloud par l'ANSSI pour les traitements les plus sensibles. AgentCorruption rappelle un point plus terre à terre : même hébergées dans une région européenne, les conversations et les secrets d'un agent restent accessibles à quiconque obtient un rôle trop large dans le compte. Pour les banques, assureurs, acteurs du e-commerce et ESN qui exposent des agents de relation client ou de support, la revue des rôles d'exécution doit figurer dans la mise en production au même titre que le choix de l'hébergement.
Côté obligations, le cadre est connu : si un agent compromis donne accès à des données personnelles, la violation doit être notifiée à la CNIL dans les 72 heures (article 33 du RGPD). Les acteurs financiers relèvent en plus du règlement européen DORA pour la déclaration des incidents TIC majeurs et la gestion du risque lié aux prestataires TIC, qui impose de vérifier activement les paramètres par défaut d'un fournisseur cloud plutôt que de les accepter tels quels. Côté veille, le CERT-FR de l'ANSSI publie régulièrement avis et alertes : une source à suivre en parallèle des publications des chercheurs. Concrètement, les rôles d'exécution des agents doivent entrer dans la politique de gestion des habilitations et dans le périmètre des audits de sécurité, comme tout autre compte de service privilégié.
Que doivent vérifier les utilisateurs d'AgentCore dès maintenant ?
- Inventorier les rôles d'exécution. Lister chaque agent AgentCore et le rôle sous lequel il tourne. Signaler tout rôle partagé par plusieurs agents et tout rôle utilisant des ressources génériques (wildcards) sur le compte ou la région.
- Remplacer l'ancien rôle par défaut. Créer un rôle dédié par agent, limité aux actions et aux ARN de ressources dont il a besoin. Retirer les permissions d'invoquer d'autres agents, de lire les sessions et la mémoire d'autres agents, et de lister ou lire des secrets qu'il n'utilise pas.
- Confirmer IMDSv2 et bloquer l'accès aux métadonnées si possible. Vérifier que les agents plus anciens tournent en IMDSv2 uniquement, et restreindre le trafic sortant des outils pour que les outils web et shell ne puissent pas joindre des adresses link-local comme 169.254.169.254.
- Commencer par les agents publics. Les agents accessibles aux clients ou à des utilisateurs anonymes présentent le risque le plus élevé. Supprimer les outils shell sauf s'ils sont indispensables et limiter les outils web à une liste de domaines autorisés.
- Auditer la mémoire et les journaux. Rechercher dans CloudTrail les événements de mémoire inattendus, les invocations inhabituelles d'agent à agent et les lectures de Secrets Manager depuis des adresses IP inconnues. Faire tourner tout secret qu'un agent sur-privilégié pouvait lire.
Questions fréquentes
Qu'est-ce qu'AgentCorruption ?
AgentCorruption est une chaîne de faiblesses dans Amazon Bedrock AgentCore, divulguée par Zenity Labs le 8 octobre 2026. Un seul prompt adressé à un agent public a permis aux chercheurs d'obtenir les identifiants de son rôle d'exécution depuis le service de métadonnées d'instance et de s'en servir pour contrôler tous les agents AgentCore du même compte et de la même région AWS.
AWS a-t-il corrigé le problème d'AgentCore ?
AWS a modifié les paramètres par défaut plutôt que de publier un correctif. Les nouveaux agents utilisent IMDSv2 uniquement depuis le 14 février 2026, et au 29 septembre 2026 le rôle d'exécution par défaut ne permettait plus d'invoquer d'autres agents, de lire les conversations privées ni d'accéder à Secrets Manager. AWS qualifie ce comportement d'attendu et documenté, et aucune CVE n'a été attribuée.
Les agents créés avant ces changements sont-ils toujours exposés ?
C'est possible. Un nouveau paramètre par défaut protège les nouveaux déploiements, mais les rôles existants conservent les permissions avec lesquelles ils ont été créés. Les équipes doivent vérifier le rôle d'exécution et les paramètres de métadonnées de chaque agent plutôt que de supposer que la mise à jour s'applique à eux.
À quoi un attaquant pouvait-il accéder ?
Dans les tests de Zenity : les images de conteneurs et le code source d'autres agents, des agents internes non autorisés, des conversations privées et des souvenirs à long terme, ainsi que des clés d'API, des jetons OAuth et d'autres secrets stockés dans AWS Secrets Manager. Les chercheurs ont aussi implanté de faux souvenirs pour garder un contrôle persistant.
Comment réduire le risque pour nos agents IA ?
Attribuer à chaque agent son propre rôle d'exécution à moindre privilège, bloquer l'accès des outils aux adresses de métadonnées link-local, limiter les outils web et shell sur les agents publics, garder les secrets hors de portée sauf si un outil en a besoin, et surveiller dans CloudTrail les invocations d'agents et les lectures de Secrets Manager inhabituelles.
Sources
Zenity — Zenity Labs discloses AgentCorruption, a chain of AWS AgentCore flaws
Zenity Labs — AgentCorruption: initial IMDS access
The Next Web — One prompt let researchers take over every AWS AgentCore agent in a region
The Decoder — A single prompt was enough to hijack every AI agent in an AWS account
Dark Reading — ‘AgentCorruption’ puts AWS environments at risk with a single prompt