Le 9 octobre 2026, Zenity Labs a précisé que sa démonstration d’Amazon Bedrock AgentCore concernait des agents d’un même compte et d’une même région AWS, et a déclaré que le problème était entièrement mitigé. AWS conteste que cette recherche démontre une vulnérabilité : l’entreprise estime qu’elle présente à tort un comportement attendu et documenté comme une faille.
Zenity circonscrit son constat à un compte et une région
Zenity Labs a indiqué que sa démonstration ne franchissait pas la frontière entre comptes AWS. L’entreprise a également déclaré que le problème avait été entièrement mitigé. AWS, de son côté, a contesté la qualification de vulnérabilité et rappelé que l’accès à des ressources d’un autre compte exige des autorisations explicites sur le rôle d’exécution de l’agent et sur la ressource visée.
Lors d’un examen réalisé le 29 septembre 2026, Zenity dit avoir constaté des changements importants dans le rôle d’exécution par défaut : des permissions permettant d’invoquer d’autres agents, d’accéder à des conversations privées et d’utiliser Secrets Manager avaient été retirées, tandis que d’autres permissions étaient restreintes.
Le test rapporté reposait sur des identifiants temporaires
Pour son test, Zenity dit avoir utilisé un agent fondé sur Strands et équipé d’un outil de requête HTTP. Une consigne l’amenait à interroger l’adresse de métadonnées 169.254.169.254 et à renvoyer la réponse. Selon Zenity, celle-ci contenait des identifiants temporaires STS associés au rôle d’exécution de l’agent ; l’équipe affirme les avoir utilisés depuis l’extérieur du runtime.
Zenity rapporte aussi que le rôle par défaut de la configuration testée accordait des permissions étendues dans la région AWS concernée. Il permettait notamment de lire des images dans ECR, d’invoquer des agents et d’effectuer des opérations sur les données d’AgentCore Memory.
Les accès que Zenity dit avoir obtenus
À partir de ces permissions, Zenity affirme avoir pu répertorier des agents, récupérer leurs images, en invoquer d’autres, lire des événements de conversations privées et modifier des événements liés à la mémoire ou aux sessions. Ces accès sont rapportés pour la configuration testée par Zenity et restent dans le périmètre indiqué par l’entreprise : le même compte et la même région AWS.
Ce qu’AWS documente sur les identifiants et les permissions
La documentation d’AWS explique que le code exécuté dans une micro-machine virtuelle AgentCore peut accéder aux identifiants du rôle d’exécution par l’intermédiaire du service de métadonnées de la micro-machine virtuelle, ou MMDS. AWS recommande de limiter chaque rôle aux actions et aux ressources dont l’agent a besoin. L’entreprise précise aussi que les politiques IAM générées par son interface en ligne de commande sont destinées au développement et aux tests, et non à la production.
Les recommandations de sécurité d’AWS pour AgentCore détaillent ces règles de moindre privilège et les paramètres liés à MMDS.
