AgentCorruption AWS une étude a montré comment un agent Amazone Bedrock AgentCore exposé pouvait révéler des identifiants temporaires de rôle et ouvrir des accès vers des agents voisins au sein du même compte et de la même région AWS. Publiée par Zenity Labs le 8 octobre 2026, l’attaque contrôlée reposait sur des outils capables d’accéder au réseau et sur des autorisations IAM excessives. Il ne s’agissait pas d’une compromission à l’échelle d’AWS, et aucune exploitation dans la nature n’avait été confirmée au 13 octobre 2026.
Qu’est-ce que l’attaque AgentCorruption AWS ?
AgentCorruption AWS est une chaîne d’attaque contrôlée qui transforme un environnement d’exécution Amazon Bedrock AgentCore doté de capacités réseau en point d’appui pour accéder à des identifiants AWS, à des services, à d’autres agents et à la mémoire. Zenity Labs a démontré cette chaîne au sein d’un même compte et d’une même région AWS en 2026 ; la recherche n’a pas établi d’accès entre des comptes clients sans lien entre eux.
La chaîne a commencé avec un agent accessible depuis l’extérieur et équipé d’un outil HTTP, d’un shell ou d’un outil réseau comparable. Les chercheurs ont demandé à cet agent de contacter l’adresse des métadonnées 169.254.169.254, selon la divulgation de Zenity Labs du 8 octobre 2026.
La réponse de métadonnées exposait les identifiants temporaires d’AWS Security Jeton Service attribués au rôle d’exécution de l’agent : un identifiant de clé d’accès, une clé d’accès secrète et un jeton de session. Zenity a exporté ces identifiants et les a utilisés en dehors de l’environnement d’exécution pour appeler des API AWS avec succès.
Cette distinction est importante. Une invite n’a pas contourné IAM comme par magie. Elle a convaincu du code d’exécution autorisé d’accéder à une source d’identifiants ; les autorisations du rôle ont ensuite déterminé l’ampleur des conséquences. Ce cas confirme l’évolution plus large, qui délaisse les documents de stratégie au profit de une gouvernance de l’IA appliquée par des contrôles à l’exécution.
Comment un agent AWS a-t-il exposé d’autres agents ?
La chaîne AgentCorruption AWS a atteint d’autres agents parce que le rôle d’exécution compromis disposait historiquement d’autorisations étendues pour Amazon CloudWatch Logs, Amazon Elastic Container Registry et AgentCore Runtime. Ces autorisations ont permis à Zenity Labs d’identifier des agents voisins, de récupérer des images de conteneurs et du code source, et d’invoquer des environnements d’exécution internes dans le même compte et la même région lors des tests menés en 2026.
La phase de découverte a extrait des identifiants utiles des journaux et des ressources d’infrastructure. Un accès étendu à Amazon ECR a ensuite exposé les images de conteneurs appartenant à d’autres agents, révélant potentiellement du code applicatif, des définitions d’outils et des hypothèses opérationnelles qui n’étaient pas destinés à un environnement d’exécution accessible au public.
Zenity a également constaté que bedrock-agentcore:InvokeAgentRuntime permettait l’invocation latérale d’agents internes découverts. Un agent exposé à Internet pouvait ainsi devenir appelant d’agents qui n’étaient pas directement exposés à Internet, à condition que le rôle partagé ou généré autorise cette action.
La comparaison ci-dessous distingue chaque autorisation de la conséquence démontrée. Elle montre également pourquoi corriger uniquement l’accès aux métadonnées ne supprime pas le risque architectural.
| Stade | Capacité ou autorisation AWS | Résultat observé | Limite pratique |
|---|---|---|---|
| Accès initial | Outil d’agent capable d’accéder au réseau | Requête vers 169.254.169.254 |
Nécessitait un agent accessible capable d’effectuer la requête |
| Accès aux identifiants | Service de métadonnées de l’environnement d’exécution | Identifiants STS temporaires pour le rôle d’exécution | Les identifiants héritaient uniquement des autorisations de ce rôle |
| Découverte | Accès étendu à CloudWatch Logs et ECR | Identifiants d’agents, images et code source | Démontré au sein du même compte et de la même région |
| Mouvement latéral | bedrock-agentcore:InvokeAgentRuntime |
Invocation d’agents internes | Nécessitait une autorisation sur l’environnement d’exécution cible |
| Accès aux conversations | ListActors, ListSessions et ListEvents |
Énumération des utilisateurs, des sessions et de l’historique à court terme | Limitée par l’autorisation AgentCore Memory |
| Persistance | Accès en écriture à AgentCore Memory | Instructions implantées et redirection ultérieure des conversations | Nécessitait des droits de modification de la mémoire |
Un calcul utile du risque découle directement de ce modèle : un agent exposé et un rôle partagé peuvent créer autant de chemins latéraux que le rôle est autorisé à invoquer. Si un rôle peut invoquer 12 environnements d’exécution, la compromission d’un agent public peut créer jusqu’à 11 cibles d’environnements d’exécution voisins, sans compter les journaux, les images, les mémoires ou les secrets. Ce nombre n’est pas une valeur par défaut d’AWS ; il permet de quantifier votre propre exposition IAM.
AgentCorruption pouvait-il lire des conversations ou assurer une persistance ?
Les tests AgentCorruption AWS ont montré que les autorisations AgentCore Memory pouvaient exposer des utilisateurs, des sessions et l’historique à court terme des conversations, tandis que l’accès en écriture à la mémoire pouvait créer une persistance. En 2026, Zenity Labs a utilisé des opérations de mémoire autorisées pour implanter des instructions, modifier ultérieurement le comportement des agents et établir un canal redirigeant vers l’extérieur les données des conversations suivantes.
Les autorisations comprenant ListActors, ListSessions et ListEvents ont permis l’énumération. Dans un rôle ayant accès à plusieurs ressources mémoire, cela transforme la compromission d’un seul agent en problème de confidentialité impliquant des conversations traitées ailleurs.
L’accès en écriture est plus dangereux que l’accès en lecture, car ses effets peuvent survivre à l’invite malveillante initiale. Une instruction implantée peut influencer des sessions ultérieures après la fin de l’interaction initiale, transformant la mémoire en surface de contrôle plutôt qu’en stockage passif. Des préoccupations similaires apparaissent dans des rapports faisant état d’ agents redirigés vers des comportements d’hameçonnage.
Honnêtement, une autorisation étendue d’écriture en mémoire n’est justifiée que lorsque la conception de l’agent l’exige explicitement. L’accès en lecture et l’accès en écriture devraient être séparés partout où les contrôles des ressources et des actions AWS le permettent, et les ressources mémoire devraient être limitées à un seul agent ou à une seule zone de confiance.
AgentCorruption était-il une vulnérabilité AWS ou un problème de configuration ?
AWS a contesté la description d’AgentCorruption AWS comme vulnérabilité en octobre 2026 et a déclaré que l’accès aux identifiants du rôle d’exécution était un comportement documenté. Zenity Labs a présenté les chemins combinés liés aux métadonnées, au rôle par défaut et à la mémoire comme des problèmes de sécurité. Les éléments disponibles appuient une analyse post-incident architecturale : la fourniture attendue d’identifiants est devenue dangereuse lorsqu’elle a été associée à des outils puissants et à des autorisations excessives.
La documentation AWS datée du 30 juin 2026 indique que les invocations d’AgentCore Runtime sont rejetées, sauf si MMDSv2 est activé via metadataConfiguration.requireMMDSV2=true. La même documentation explique que le code exécuté dans la microVM peut toujours recevoir les identifiants du rôle d’exécution du runtime. MMDSv2 rehausse le niveau de protection, mais ne constitue pas une frontière IAM.
Zenity a indiqué que tous les agents AgentCore nouvellement déployés utilisaient un comportement limité à IMDSv2 depuis le 14 février 2026. The Next Web a rapporté que la validation de Zenity du 29 septembre 2026 avait constaté un rôle d’exécution par défaut plus restreint, dont avaient été supprimées les autorisations utilisées pour les invocations inter-agents, l’accès aux conversations et l’accès à AWS Secrets Manager.
Aucun CVE n’a été signalé. Zenity a déclaré le 8 octobre 2026 qu’AWS avait corrigé ou traité les problèmes signalés, tandis qu’AWS maintenait que le comportement sous-jacent des identifiants était attendu. Il serait donc trompeur de considérer cet épisode comme une vulnérabilité zero-day non corrigée, tout comme il serait réducteur de le qualifier de simple configuration inoffensive, sans tenir compte de la manière dont les valeurs par défaut et les rôles partagés influencent les déploiements réels.
La date de divulgation comporte également une subtilité que de nombreux résumés omettent. Le récit de Zenity indique les 17 et 25 décembre 2025 pour le signalement initial concernant les métadonnées, tandis que The Next Web affirme que le problème général lié au rôle par défaut a été signalé le 12 janvier 2026. Ces dates peuvent correspondre à des découvertes distinctes, mais les sources publiées ne permettent pas de les concilier complètement.
Comment devez-vous sécuriser Amazon Bedrock AgentCore ?
La sécurisation d’Amazon Bedrock AgentCore nécessite MMDSv2, un rôle d’exécution appliquant le principe du moindre privilège pour chaque agent, des communications sortantes restreintes et une séparation entre les runtimes publics et internes. Les recommandations de sécurité AWS disponibles le 13 octobre 2026 préconisent un déploiement dans un VPC, des points de terminaison VPC ou AWS PrivateLink lorsque cela est possible, des ARN de ressources définis avec précision et des audits réguliers des autorisations.
Commencez par l’identité. Remplacez les rôles générés ou partagés par des rôles d’exécution personnalisés qui n’autorisent que le modèle, l’image, le groupe de journaux, la mémoire, le secret et le service en aval dont chaque agent a besoin. Les ressources génériques méritent un examen attentif, même lorsque l’action autorisée semble inoffensive.
Limitez ensuite les communications. Un agent exposé au public ne devrait pas pouvoir énumérer ou invoquer des agents internes simplement parce que les deux s’exécutent dans le même compte et la même Région. La séparation des zones de confiance, des groupes de sécurité et des rôles réduit le risque qu’un incident d’injection de prompt se transforme en déplacement latéral. Le confinement matériel va encore plus loin dans cette logique, comme le montre l’approche de Nvidia en matière d’isolation des agents IA.
La liste de contrôle de l’examen AgentCorruption AWS devrait couvrir les contrôles suivants :
- Vérifiez que chaque runtime nécessite MMDSv2 et identifiez les déploiements plus anciens susceptibles d’être antérieurs au changement d’application de 2026.
- Recherchez dans les politiques IAM les ressources génériques, les rôles d’exécution partagés et les autorisations permettant d’invoquer les runtimes AgentCore voisins.
- Limitez l’accès à CloudWatch Logs et Amazon ECR aux groupes de journaux et aux images attribués à un seul agent.
- Examinez les actions d’AgentCore Memory, en particulier la liste des acteurs, des sessions et des événements, ainsi que toutes les autorisations d’écriture.
- Vérifiez l’accès à AWS Secrets Manager et supprimez les secrets dont le runtime n’a pas besoin pour la tâche qui lui est attribuée.
- Restreignez les règles sortantes des groupes de sécurité et refusez l’accès aux destinations dont aucun outil approuvé n’a besoin.
- Séparez les agents publics et internes par rôle, chemin réseau, ressource mémoire et frontière de session.
Ne vous fiez pas à des instructions de prompt telles que « ne jamais accéder aux métadonnées ». Les prompts régissent le comportement du modèle de manière probabiliste ; IAM et les politiques réseau appliquent les autorisations. La même leçon de sécurité apparaît lorsque les incidents de fuite de données d’agents imposent des restrictions au runtime plutôt qu’une couche supplémentaire d’instructions polies.
FAQ AgentCorruption AWS
AgentCorruption a-t-il été exploité dans la nature ?
Aucune exploitation confirmée d’AgentCorruption dans la nature n’a été identifiée dans les divulgations de Zenity examinées, la documentation d’AWS ou les articles indépendants au 13 octobre 2026. Les éléments publiés décrivent des recherches de sécurité contrôlées plutôt qu’une compromission active de clients.
AgentCorruption a-t-il affecté chaque compte AWS ?
AgentCorruption n’a pas démontré avoir accès à tous les clients AWS ni à des comptes sans lien. Zenity Labs a démontré un accès latéral aux ressources autorisées par un rôle d’exécution au sein du même compte et de la même région AWS.
MMDSv2 interrompt-il toute la chaîne d’attaque ?
MMDSv2 ne remplace pas le principe du moindre privilège appliqué à IAM, car la documentation AWS indique que le code exécuté peut recevoir les identifiants de son rôle d’exécution. MMDSv2 constitue une couche de défense parmi d’autres ; des rôles aux permissions limitées, des contrôles de trafic sortant et l’isolation des agents restreignent ce que des identifiants exposés peuvent permettre.
Devriez-vous renouveler les identifiants du rôle d’exécution d’AgentCore ?
AgentCore utilise des identifiants STS temporaires, mais une exposition présumée justifie tout de même des mesures de réponse aux incidents en 2026 : arrêtez ou isolez l’environnement d’exécution, examinez CloudTrail et les journaux des services, supprimez les autorisations excessives, faites tourner tous les secrets exposés séparément et redéployez avec un rôle aux autorisations limitées.
Un prompt suffit-il à sécuriser un agent AWS ?
Un prompt ne peut pas imposer les autorisations AWS ni les limites réseau. La sécurité d’Amazon Bedrock AgentCore dépend des politiques IAM, des contrôles des métadonnées d’exécution, des groupes de sécurité, de l’architecture VPC, de l’isolation des ressources et de la surveillance.