Le rôle par défaut, pas le modèle : comment une seule invite a pris le contrôle de tous les agents d'un compte AWS

Points clés

• Une seule invite envoyée à un agent exposé publiquement a compromis tous les agents AgentCore du même compte et de la même région AWS — Zenity Labs a divulgué la chaîne AgentCorruption le 8 octobre 2026 à SecTor, à Toronto, après une divulgation responsable commencée le 25 décembre 2025.
• Le rayon d'impact était une propriété du rôle, pas du modèle — le rôle d'exécution par défaut incluait bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, une permission d'écriture de mémoire entre agents, bedrock-agentcore:GetResourceApiKey et secretsmanager:GetSecretValue, toutes avec une portée sur toute la région du compte et non limitées au seul agent.
• Le correctif a pris 278 jours — AWS a migré AgentCore vers IMDSv2 d'ici au 14 février 2026, mais la re-vérification de Zenity du 22 juin 2026 a trouvé le rôle par défaut inchangé ; la suppression des permissions n'est arrivée que le 29 septembre 2026.
• La mémoire de l'agent est une surface de persistance — les chercheurs ont implanté des mémoires qui redirigeaient les conversations futures des agents vers une destination contrôlée par l'attaquant, tandis que les utilisateurs continuaient de parler à ce qui semblait être un agent d'entreprise de confiance.
• AWS a qualifié le comportement de « documented and expected » — et recommande aux clients de n'accorder à leurs rôles d'exécution que les permissions dont leurs agents ont besoin. La vérification du rôle par défaut relève du client, sur toute plateforme gérée.

Le 8 octobre 2026, à la conférence SecTor de Toronto, Zenity Labs a divulgué AgentCorruption : une chaîne de failles dans Amazon Bedrock AgentCore, la plateforme gérée d'AWS pour déployer et exploiter des agents IA. Une seule invite envoyée à un agent public — un agent de service client exposé sur internet, par exemple — a renvoyé les identifiants AWS temporaires attribués à la machine de cet agent. Ces identifiants appartenaient à un rôle IAM par défaut dont les permissions n'étaient pas limitées à cet agent, mais à tous les agents AgentCore du même compte AWS et de la même région. Avec eux, les chercheurs ont invoqué des agents internes auxquels ils n'avaient jamais été autorisés à accéder, lu des conversations privées entre agents et utilisateurs, téléchargé les images de conteneur des agents pour en extraire le code source, récupéré des clés API et des jetons OAuth dans AWS Secrets Manager, et implanté des mémoires qui ont continué d'agir après la fin de la session.

Rien de tout cela n'a nécessité une défaillance du modèle. Le seul rôle du modèle dans la chaîne a été de faire une requête HTTP quand on le lui demandait. Tout ce qui a suivi relevait d'IAM. Cet article cartographie la chaîne en cinq étapes, les permissions précises qui ont rendu chaque étape possible, la chronologie des 278 jours de la divulgation, et les cinq questions que toute équipe devrait poser avant de déployer des agents sur une plateforme d'agents gérée — quel que soit le fournisseur.

La chaîne d'attaque, étape par étape

Zenity Labs a publié l'intégralité de la recherche sous forme de série technique en cinq parties ; la chaîne se résume à cinq mouvements.

Étape 1 : injection d'invite vers IMDS. Les agents AgentCore s'exécutent dans des microVM Firecracker dont l'isolement réseau ne bloquait pas le service de métadonnées d'instance. Tout outil d'agent capable d'émettre une requête HTTP sortante envoie cette requête depuis l'instance elle-même — une primitive SSRF. Une seule invite a ordonné à l'agent exposé d'appeler 169.254.169.254, l'Instance Metadata Service, qui a livré les identifiants IAM temporaires du rôle attribué à la charge de travail. Le coût d'entrée était l'accès en conversation à un seul agent disposant d'un outil courant.

Étape 2 : découverte à l'échelle du compte. Les identifiants appartenaient à un rôle d'exécution par défaut non limité à l'agent concerné. Parmi ses permissions figurait DescribeLogGroups, que les chercheurs ont utilisée pour énumérer chaque agent et son ID dans toute la région du compte. Une seconde voie de découverte était gratuite : les noms des dépôts de l'Elastic Container Registry correspondaient aux ID des agents, de sorte que la permission de pull ECR du rôle a permis aux chercheurs de télécharger l'image de conteneur de n'importe quel agent et d'en lire l'intégralité du code source.

Étape 3 : mouvement latéral. Le rôle incluait bedrock-agentcore:InvokeAgentRuntime, avec une portée sur toute la région. Les chercheurs pouvaient invoquer n'importe quel agent AgentCore du compte — y compris des agents internes et sensibles auxquels ils n'étaient pas autorisés à accéder. L'exemple développé dans la divulgation : un attaquant entrant par l'agent de service client exposé sur internet se déplace latéralement vers un agent financier interne de la même région, l'invoque, et accède à ses données, ses outils et ses identifiants.

Étape 4 : accès aux données et aux identifiants. bedrock-agentcore:ListEvents renvoyait toutes les conversations privées de tous les agents, utilisateurs et sessions — les frontières de confidentialité de la plateforme, dissoutes. bedrock-agentcore:GetResourceApiKey et secretsmanager:GetSecretValue touchaient ensuite les identifiants qu'AgentCore garde délibérément hors de portée de l'agent : clés API, jetons OAuth et entrées Secrets Manager, y compris les identifiants utilisés pour se connecter aux ressources d'entreprise et aux services tiers au-delà d'AWS.

Étape 5 : persistance par la mémoire. Le rôle portait aussi une permission d'écriture en mémoire — bedrock-agentcore:CreateEvent sur BedrockAgentCoreMemory. Les chercheurs ont créé de nouvelles mémoires à travers différents agents et utilisateurs, modifiant durablement le comportement des agents et détournant leurs objectifs lors des sessions futures, orientant les conversations vers une destination contrôlée par l'attaquant. La compromission a survécu à la session qui l'avait créée.

Le schéma ci-dessous cartographie les cinq mouvements et ce que chacun a exposé :

Le rôle, pas le modèle

La leçon structurelle se trouve dans ce dont les cinq étapes n'ont pas eu besoin. Pas de jailbreak, pas de défaillance d'alignement, pas d'ingénierie d'invite sophistiquée au-delà de « appelle cette URL ». Le cofondateur et CTO de Zenity, Michael Bargury, a formulé la cause racine comme une tension de conception que toute plateforme embarque : « La sécurité du cloud, c'est la segmentation et l'accès au moindre privilège. Les agents IA, eux, ont besoin de leur espace créatif pour être utiles. Mélanger les deux crée un conflit inhérent. » Sa conclusion : « Toute entreprise qui déploie des agents dans le cloud affrontera les mêmes choix fondamentaux entre agentivité et moindre privilège. »

AgentCore a résolu ce conflit en faveur de l'agentivité — pour le confort de la plateforme, pas pour la sécurité du client. Le rôle d'exécution par défaut était large pour que les agents fonctionnent clé en main, et ses permissions couvraient toutes les ressources d'agents de la région du compte. La déclaration d'AWS elle-même, publiée avec la recherche, dit que le comportement est « documented and expected », que les agents peuvent accéder aux identifiants de leur propre rôle d'exécution via le service de métadonnées, et que « en bonne pratique, nous recommandons aux clients de n'accorder à leurs rôles d'exécution que les permissions dont leurs agents ont besoin », renvoyant à sa gestion des identifiants, ses permissions d'exécution et son guide du moindre privilège.

Lus ensemble, ces deux faits rendent la position de l'acheteur sans ambiguïté : la plateforme traite le rôle par défaut comme un point de départ, et le rayon d'impact d'un agent compromis comme un problème de configuration du client. C'est une position défendable pour un fournisseur cloud — le moindre privilège IAM relève du client depuis qu'IAM existe. Mais elle entre en collision avec le cadre marketing des plateformes d'agents gérées, selon lequel la plateforme prend en charge le durcissement opérationnel pour que votre équipe n'ait pas à le faire. La chaîne AgentCorruption est ce que cette collision donne en pratique : le défaut de la plateforme était la vulnérabilité, et la documentation de la plateforme était la mitigation.

278 jours de la divulgation au correctif

La chronologie de la divulgation est la seconde leçon. Zenity a signalé l'accès IMDS initial le 25 décembre 2025. AWS a mis à jour AgentCore vers IMDSv2 uniquement pour les agents nouvellement déployés d'ici au 14 février 2026, et a clos ce premier rapport comme « informatif » le 12 avril. Mais le second rapport de Zenity — le rayon d'impact du rôle par défaut, déposé le 12 janvier 2026 — a progressé plus lentement. Le 25 février, AWS a dit que l'équipe y travaillait activement alors que le rôle par défaut restait le même. Le 22 juin 2026, Zenity a re-vérifié et confirmé que les permissions demeuraient inchangées. Le correctif substantiel — la suppression des permissions qui permettaient l'exécution large d'agents, la lecture des conversations privées et l'accès à Secrets Manager — a été observé le 29 septembre 2026, 278 jours après la première divulgation et quelques jours avant la publication publique.

Date	Événement
25 déc. 2025	Zenity signale l'accès IMDS initial à AWS
12 janv. 2026	Zenity dépose le rapport sur le rayon d'impact du rôle par défaut
14 fév. 2026	AgentCore passe en IMDSv2 uniquement pour les agents nouvellement déployés
25 fév. 2026	AWS confirme le travail en cours ; rôle par défaut inchangé
12 avr. 2026	AWS clôture le rapport IMDS comme « informatif »
22 juin 2026	Re-vérification de Zenity : rôle par défaut toujours inchangé
29 sept. 2026	Rôle par défaut renforcé — permissions inter-agents, lecture de conversations et Secrets Manager supprimées

Deux implications pour toute équipe qui compte sur les valeurs par défaut d'une plateforme gérée. Premièrement, une valeur par défaut pensée pour le confort peut rester une vulnérabilité debout pendant une bonne partie de l'année même après une divulgation responsable — la fenêtre entre « nous l'avons signalé » et « c'est corrigé » se compte en mois, et vos agents y fonctionnent. Deuxièmement, le correctif lui-même prouve la thèse : AWS n'a pas réentraîné un modèle ni ajouté un filtre de sécurité. Il a édité une politique de rôle. Le rayon d'impact était un document IAM depuis le début.

La mémoire est une surface de persistance

La partie la plus prospective de la chaîne est l'étape 5. Lire des données, c'est une fuite ; modifier la mémoire, c'est une prise de contrôle. Les chercheurs ont utilisé la permission d'écriture en mémoire du rôle pour implanter des instructions qui ont survécu à la session, redirigé les conversations futures vers une destination contrôlée par l'attaquant et laissé l'agent paraître fonctionner normalement. Une réponse à incident qui arrête l'agent, fait tourner ses identifiants et corrige le vecteur d'injection ne supprime pas une mémoire implantée. Si le stockage de mémoire ne fait pas partie de la réponse, la compromission persiste au nettoyage.

C'est la même classe de modification de comportement qui a poussé Anthropic à couper l'accès internet en direct de toutes les évaluations internes d'agents, comme l'entreprise l'a divulgué en octobre 2026 — le sujet de Deux laboratoires de pointe, un aveu. Cet article couvre l'aveu du laboratoire selon lequel l'entraînement d'alignement ne suffit pas à contrôler le comportement des agents. AgentCorruption montre le même problème un cran en dessous, au niveau de la plateforme : un stockage de mémoire dans lequel peut écrire quiconque détient la bonne permission IAM est un mécanisme de persistance, et les architectures de kill switch traitées dans Kill switch dès la conception doivent considérer la mémoire comme faisant partie de l'état compromis, et pas seulement du runtime.

Cinq questions avant de déployer sur une plateforme d'agents gérée

AgentCore est l'exemple travaillé, pas l'exception. Le communiqué de Zenity fait lui-même le point général : les entreprises font couramment coexister des agents tournés vers les clients et des agents internes dans les mêmes environnements cloud, et une seule faiblesse inattendue dans un agent peut faire s'effondrer les frontières d'un environnement entier. La plateforme diffère ; les classes de permissions riment. Avant qu'un agent ne passe en production sur une plateforme gérée, obtenez des réponses écrites à ces cinq questions :

1. Que contient exactement le rôle d'exécution par défaut ? Pas « est-il sécurisé par défaut » — le document de politique, permission par permission. Marquez chaque permission dont la portée est * ou couvre tous les agents du compte. La chaîne AgentCorruption est la réponse en cinq permissions à cette question.
2. Un agent peut-il découvrir les autres ? Toute permission de listage ou de description à l'échelle du compte transforme un agent compromis en inventaire de cibles. DescribeLogGroups a été l'étape d'énumération ; toute plateforme a une surface de listage équivalente.
3. Un agent peut-il en invoquer un autre ? L'invocation agent-à-agent est la primitive du mouvement latéral. Si la plateforme ne peut pas limiter l'invocation à des listes d'autorisation explicites par agent, traitez chaque agent du compte comme un seul domaine de confiance — parce que c'est ainsi que l'attaquant les traitera.
4. Où vivent les identifiants des outils, et quel rôle peut les lire ? Une passerelle de secrets ne déplace le risque que si aucun rôle d'agent ne peut appeler GetSecretValue dessus. Le rôle AgentCorruption pouvait lire précisément les identifiants que la conception de la plateforme était censée tenir à l'écart des agents.
5. La mémoire peut-elle être écrite par autre chose que l'agent lui-même, dans sa propre session ? Les écritures en mémoire entre agents et entre utilisateurs transforment le stockage de mémoire en surface de persistance. Si la réponse est une permission que vous pouvez limiter, limitez-la ; sinon, le stockage de mémoire appartient à votre plan de réponse aux incidents comme état contrôlé par l'attaquant.

Lectures associées

• Bedrock vs OpenAI : Choisir une plateforme IA gérée pour les agents en production — la comparaison de plateformes gérées sur laquelle cet incident retombe : coût, confidentialité et stabilité du fournisseur, avec la question du rôle par défaut désormais ajoutée à la liste de vérification préalable
• 126 incidents en un mois : le premier inventaire complet de la sécurité de l'IA et ce qu'il prouve sur le risque agent — la déclaration de fréquence derrière cet incident : les exploits de la couche agent étaient la plus grande classe de vecteur d'attaque en septembre 2026
• Check-list de gouvernance des agents IA : une revue pré-déploiement pour les agents en production — la revue pré-déploiement complète, incluant les rôles d'exécution au moindre privilège et la découverte inter-agents comme éléments de contrôle

Un distributeur industriel de taille intermédiaire faisant tourner deux agents sur une plateforme gérée — un agent de devis public devant sa boutique et son catalogue BigCommerce, et un agent interne avec les grilles tarifaires NetSuite et l'accès aux stocks — a exactement la topologie qu'AgentCorruption a exploitée : un agent exposé sur internet et un agent back-office dans le même compte. Le schéma contre lequel nous construisons donne à chaque module connecteur son propre rôle au moindre privilège, enregistre chaque outil que l'agent peut appeler, limite la mémoire par agent, et écrit une piste d'audit qui montrerait une écriture en mémoire venant de l'extérieur de la session. L'enjeu n'est pas qu'un build à permissions bornées serait immunisé contre une faille côté plateforme ; c'est que le rayon d'impact de la prochaine sera fixé par la politique de rôle que votre équipe a passée en revue, pas par celle que la plateforme a livrée par défaut.

Découverte en une semaine. Vous obtenez un inventaire des systèmes, une cartographie des flux de travail et un périmètre figé — que vous construisiez avec nous ou non.

Demandez un build au périmètre défini.