Un prompt, un agent, tout un compte AWS : plongée au cœur d'AgentCorruption sur Amazon Bedrock AgentCore

Le 8 octobre 2026, Zenity Labs a divulgué AgentCorruption : une chaîne de failles dans Amazon Bedrock AgentCore, la plateforme gérée d'AWS pour le déploiement et l'exécution d'agents IA, qui permettait à une simple invite en langage naturel adressée à un agent exposé publiquement de prendre le contrôle de tous les agents AgentCore du même compte et de la même région AWS. La recherche a été publiée en parallèle d'une conférence à SecTor 2026 à Toronto, où le directeur de la recherche en sécurité de Zenity, Tamir Ishay Sharbat, l'a présentée (Dark Reading, 8 octobre 2026). L'article de Zenity, attribué à Sharbat, Lana Salameh, Dmitry Lozovoy et João Donato, commence par le mécanisme : un agent AgentCore disposant d'un outil capable d'effectuer une requête sortante peut être amené à appeler l'AWS Instance Metadata Service (IMDS) à l'adresse link-local 169.254.169.254, qui renvoie des identifiants temporaires pour le rôle d'exécution de l'agent lui-même. Zenity déclare avoir exporté ces identifiants vers sa propre machine et avoir confirmé qu'ils fonctionnaient depuis celle-ci. Aucun identifiant CVE n'a été attribué.

L'archive consigne ceci comme une vulnérabilité — quelque chose de trouvé, pas nécessairement exploité — avec une haute sévérité, une confiance A, aucun préjudice réel enregistré et une implication confirmée de l'IA. Les parties ne sont pas d'accord sur la qualification, même si elles s'accordent sur le comportement : AWS a déclaré à Dark Reading que la recherche « dépeint de manière inexacte un comportement attendu et documenté comme une vulnérabilité ».

Ce qu’était réellement la chaîne

AgentCore empaquette chaque agent dans un conteneur et l'exécute dans une Firecracker MicroVM par session. Le premier article de Zenity dans la série reproduit toute la prise d'appui au moyen d'une demande en langage naturel adressée à un agent de test construit avec le Strands SDK, le framework d'agents open source d'AWS, qui embarque un outil de requête HTTP intégré et un outil shell. La microVM ne restreignait pas le trafic vers le service de métadonnées, de sorte que la requête provenait de l'intérieur de l'instance et qu'IMDS y a répondu. Les chercheurs ont ensuite parcouru les endpoints : le nom du rôle IAM, les identifiants STS temporaires eux-mêmes, l'endpoint user-data — qui a renvoyé l'ID de compte, les ARN complets, l'URL du runtime et l'URI d'image Amazon Elastic Container Registry (ECR) de l'agent — ainsi que les tags de l'instance, notamment une chaîne de certificats mTLS, une clé privée et une URL présignée vers le stockage interne. Zenity affirme que le même résultat a été obtenu via l'outil shell, car la défaillance d'isolation se situe au niveau de la plateforme et non dans un outil en particulier.

Deux détails, dans cette séquence, passent facilement inaperçus. Les identifiants n'étaient pas confinés au bac à sable : Zenity les a exportés en dehors d'AgentCore et a lancé un appel d'identité AWS qui a renvoyé le rôle assumé de l'agent. Et le rôle dérobé permettait de récupérer l'image de conteneur, ce qui a rendu lisible le code source des agents — le post de Zenity note que les images contiennent régulièrement des clés codées en dur, des jetons oubliés et des configurations qui n'auraient jamais dû y être intégrées, et qu'une image récupérée est une carte de la logique métier sous-jacente.

Le rôle par défaut est l’endroit où un point d’ancrage est devenu un compte.

Le second défaut, signalé séparément, est que le rôle d'exécution qu'AgentCore attachait par défaut aux agents n'était pas limité à un seul agent. Zenity décrit des autorisations qui s'étendent à toutes les ressources AgentCore du compte et de la région, y compris bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent et, à l'extrémité de la chaîne liée aux identifiants, bedrock-agentcore:GetResourceApiKey et secretsmanager:GetSecretValue.

L'énumérabilité a transformé ces jokers en une liste de cibles. Zenity a utilisé la permission logs:DescribeLogGroups du rôle, car AgentCore nomme le groupe de logs CloudWatch de chaque agent /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, et a déduit les identifiants des agents à partir de ces noms de groupes de logs. Les noms de dépôts ECR suivaient une convention observée par les chercheurs — bedrock-agentcore-<agent_name> — de sorte que l'image de chaque agent de la région pouvait être extraite. Les ressources de mémoire ont été trouvées de la même manière, à partir du modèle de groupe de logs /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, et les permissions ListActors, ListSessions et ListEvents du rôle ont produit les identifiants d'acteur et de session nécessaires pour lire le contenu des conversations.

L'analyse de Zenity fournit une démonstration concrète de mouvement latéral : pénétrer via un agent accessible publiquement, découvrir les outils d'un billing_agent dans la même région, repérer un fichier nommé billing.json et l'exfiltrer via un outil de lecture de fichiers. Le communiqué de presse décrit le même scénario en termes généraux — un attaquant pénétrant via un agent de service client exposé à Internet pourrait se déplacer vers un agent financier interne déployé dans la même région, l'invoquer et accéder à ses données, ses outils, ses identifiants associés et ses conversations privées.

La mémoire était la partie qui a survécu au prompt

AgentCore Memory conserve la conversation elle-même comme mémoire à court terme et stocke les enregistrements extraits comme mémoire à long terme, en utilisant des stratégies nommées SEMANTIC, USER_PREFERENCE, SUMMARIZATION et EPISODIC. Zenity a utilisé CreateEvent pour écrire des événements de conversation dans les ressources de mémoire d'autres agents. Son article est prudent sur ce que cette primitive peut et ne peut pas faire : CreateEvent ne permet pas à l'appelant de choisir un espace de noms à long terme ni d'écraser directement un enregistrement — les stratégies configurées de la mémoire cible décident de ce qui est extrait et où cela atterrit. Zenity décrit également DeleteEvent utilisé pour supprimer des événements de résultat d'outil afin qu'un agent tire une conclusion erronée à partir de données manquantes, et pour brouiller les pistes en supprimant l'événement qui a implanté une mémoire.

Ce que la primitive d'écriture a produit, c'est de la persistance. La démonstration de Zenity a implanté une requête demandant à l'agent de récupérer, avant de répondre, une page contrôlée par les chercheurs, puis d'en suivre le contenu — un point de terminaison de commande et contrôle dont les instructions pouvaient être modifiées sans implanter un nouveau souvenir. Le même canal a ensuite servi à exfiltrer le contenu de la conversation : le compte rendu décrit l'agent envoyant les messages de l'utilisateur et ses propres réponses vers un point de collecte, et indique que les autorisations de mémoire associées au rôle s'étendaient à l'ensemble du compte et de la région, et non pas uniquement à l'agent compromis. Une vidéo publiée avec la recherche montre un utilisateur poursuivant une conversation pendant que ce contenu arrive sur le serveur des chercheurs.

Identifiants au-delà d’AWS

Le dernier article de la série ferme la boucle sur les outils connectés. AgentCore Identity et Outbound Auth stockent les identifiants des outils sous forme de secrets dans AWS Secrets Manager, sous des noms construits à partir d'un nom de fournisseur et d'un motif fixe tel que bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity a récupéré les noms de fournisseurs en extrayant le code source de l'agent qu'il avait déjà extrait d'ECR, et a récupéré les autres par force brute : il indique que le suffixe par défaut de cinq caractères est généré côté client à partir de chiffres et de lettres minuscules, ce qui donne 2 x (10+26)^5 = 120,932,352 combinaisons pour les deux types de fournisseurs. Au taux de requêtes qu'il pouvait maintenir contre Secrets Manager, Zenity affirme qu'une énumération complète prend plusieurs heures — plus longtemps que ne durent les identifiants STS — alors il a construit une boucle qui interrogeait à nouveau le point de terminaison IMDS de l'agent pour obtenir de nouveaux identifiants à mesure que les anciens expiraient. Zenity ajoute que les variables d'environnement étaient lisibles via le point de terminaison user-data des métadonnées, chaque nom étant préfixé par CONTAINER_ENV_, y compris la clé qu'un agent utilise pour s'authentifier auprès de son fournisseur de modèle, et que l'invocation de chaque agent découvert avec une invite appropriée a permis de récolter ces valeurs à grande échelle.

Établi, et contesté sur une technicité

Ce qui est établi est étroit et précis. Les agents AgentCore pouvaient atteindre l'IMDS et recevoir les identifiants temporaires de leur propre rôle d'exécution — AWS ne le conteste pas, le décrivant dans sa déclaration comme « documenté et attendu ». Le rôle d'exécution par défaut portait des permissions limitées au compte et à la région plutôt qu'à un seul agent ; AWS l'a modifié depuis, et Zenity affirme que ses propres tests ont confirmé cette réduction. La recherche est une démonstration, non une campagne observée : Sharbat a déclaré à Dark Reading que Zenity n'avait vu aucune preuve que la faille ait été exploitée dans la nature avant la correction, attribuant cela en partie à la difficulté d'identifier quelles organisations exécutent des agents sur AgentCore, et ajoutant qu'il était « sûr à 100 % qu'il existe des moyens de le faire ».

Ce qui est contesté, c'est de savoir si l'un de ces éléments doit être qualifié de vulnérabilité. La déclaration d'AWS, telle qu'elle a été transmise à Dark Reading et The Next Web, se lit comme suit : « AWS est au courant de la recherche publiée sur Amazon Bedrock AgentCore, qui présente à tort un 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 à la fois sur le rôle d'exécution de l'agent et sur la ressource cible. » La déclaration d'AWS reproduite dans les propres publications de Zenity conserve la substance de la première phrase — « le comportement décrit est documenté et attendu » — et ajoute que les clients ne devraient accorder aux rôles d'exécution que les autorisations dont leurs agents ont besoin. Deux éléments sous-tendent le désaccord. AWS définit la limite en termes d'accès aux ressources d'un autre compte AWS, tandis que la découverte de Zenity concerne des agents à l'intérieur d'un seul compte et d'une seule région AWS ; et les rôles décrits par Zenity provenaient des paramètres par défaut de la plateforme plutôt que d'un client écrivant une politique à la main.

La correction apportée par The Next Web à son propre article mérite d’être consignée, car elle montre que l’affirmation a été resserrée par quelqu’un d’autre que les chercheurs. Il a d’abord publié, puis corrigé, un titre affirmant que les chercheurs avaient pris le contrôle de chaque agent AgentCore d’une région ; la version corrigée indique que la recherche portait sur des agents au sein d’un seul compte AWS et d’une seule région, et précise que le titre initial présentait l’affirmation des chercheurs comme un fait.

La chronologie de la divulgation

Zenity a déposé deux rapports plutôt qu'un seul, et ils ont reçu des réponses différentes. Le rapport sur l'accès à l'IMDS a été déposé le 25 décembre 2025 ; AWS l'a clos le 12 avril 2026 comme « informatif », écrivant qu'AgentCore n'utilisait IMDSv2 que depuis le 14 février 2026, les agents nouvellement déployés se lançant de cette manière. Cette révision compte pour les spécificités de cette recherche, car IMDSv2 exige un jeton de session à chaque requête et empêche la simple récupération non authentifiée que les chercheurs utilisaient pour obtenir des identifiants. Le second rapport, sur le rôle par défaut et son rayon d'action, a été déposé le 12 janvier 2026. AWS a indiqué à Zenity le 25 février 2026 que l'équipe y travaillait tandis que le rôle restait tel quel ; Zenity a réexaminé le rôle le 22 juin 2026 et a constaté que ses autorisations étaient inchangées. Un examen final le 29 septembre 2026 a révélé que le rôle avait été sensiblement réduit, et le communiqué de presse de Zenity précise que le retrait couvrait l'invocation d'autres agents, la lecture de conversations privées et l'accès aux secrets dans AWS Secrets Manager, d'autres autorisations étant également considérablement restreintes. Les propres publications de Zenity notent qu'AWS a depuis fait d'IMDSv2 la configuration par défaut pour les déploiements AgentCore et que les deux parties ont collaboré tout au long du processus.

Ce qui n'est pas connu

Zenity n'a pas publié combien d'agents ou d'organisations ont fonctionné avec le rôle par défaut au cours de la période entre le changement d'IMDSv2 de février et le resserrement de fin septembre, et rien dans les sources citées n'indique que des données client aient été exposées en dehors de l'environnement propre des chercheurs. Le changement d'IMDSv2 s'applique aux agents déployés après le 14 février 2026, selon AWS comme rapporté par Zenity ; ce que cela signifie pour les agents déployés avant cette date n'est pas précisé dans les sources examinées ici. L'archive ne fait état d'aucun préjudice réel, et les sources étayent cette lecture en décrivant une démonstration et en ce qu'AWS conteste l'étiquette de vulnérabilité plutôt que de signaler un incident qui lui soit propre.

Sharbat a déclaré à Dark Reading que Zenity examine désormais d'autres plateformes cloud pour y chercher des problèmes similaires d'accès aux métadonnées, et que l'entreprise ne les nomme pas encore. Sa conclusion porte sur les permissions plutôt que sur le seul service de métadonnées : « Même si quelqu'un parvient à accéder à l'IMDS, le rayon d'impact sera bien plus réduit. »

Pourquoi cet enregistrement est conservé

AgentCorruption n’est pas remarquable parce que les points de terminaison de métadonnées seraient une idée nouvelle. Sharbat a attiré l’attention du public de SecTor sur la violation Capital One de 2019, où une SSRF a atteint l’IMDS et a donné lieu à des identifiants volés, et il a décrit cela comme une défaillance de moindre privilège du même type. Ce qui est nouveau, c’est l’acteur qui effectue la récupération. La requête qui a produit une identité AWS a été faite par un agent d’IA qui exécutait ce qu’on lui avait demandé, en langage naturel, au moyen d’un outil qui lui avait été fourni pour lui permettre d’être utile — et l’agent a relayé la réponse. Les deux conditions qui ont transformé cela en problème à l’échelle du compte étaient un point de terminaison de métadonnées que le sandbox ne bloquait pas et un rôle par défaut aux permissions plus larges que celles de l’agent qui le détenait.

L’intégralité de la recherche, y compris la série technique en cinq parties et la vidéo de démonstration, est accessible depuis le communiqué de presse de Zenity du 8 octobre 2026. Cette fiche est une entrée parmi les incidents documentés impliquant des agents dans l’archive des incidents d’IA, où chaque entrée comporte ses propres sources, un niveau de gravité, un niveau de confiance et un indicateur de contestation — les champs qui permettent de distinguer un différend avec un fournisseur sur le cadrage, comme ici, d’un constat de préjudice contesté.

Il s’agit d’une fiche, étudiée et rapportée par d’autres, et citée ici en leur nom.l’archive des incidents d’IA — de sorte qu’un paramètre par défaut de plateforme qui transforme une invite en point d’ancrage à l’échelle d’un compte puisse être mis en regard de ce qui s’est réellement produit ailleurs.