AgentCorruption : faille critique dans AWS Bedrock AgentCore

Ce qui s'est passé

Les chercheurs de Zenity Labs ont publié début octobre 2026 les détails techniques d'AgentCorruption, une chaîne d'attaque inédite ciblant Amazon Bedrock AgentCore, le service d'Amazon Web Services permettant de déployer et d'héberger des agents d'intelligence artificielle en production. La recherche démontre qu'un attaquant disposant d'un accès conversationnel à un agent exposé peut, au moyen d'une unique invite malveillante, voler les credentials AWS temporaires associés au rôle d'exécution de l'agent et s'en servir pour compromettre l'ensemble des autres agents du même compte et de la même région AWS.

Pour comprendre le vecteur d'attaque, il faut saisir l'architecture d'AgentCore. Le service exécute les agents dans des conteneurs hébergés à l'intérieur de microVMs Firecracker, une technologie de virtualisation légère développée par AWS et largement utilisée dans Lambda et Fargate. Chaque agent se voit attribuer un rôle IAM d'exécution qui lui confère les permissions nécessaires pour interagir avec d'autres services AWS. C'est précisément ce rôle, dans sa configuration par défaut, qui s'est révélé surprivilégié dans les versions antérieures du service.

L'exploitation repose sur une injection de prompt combinée à l'accès au service de métadonnées d'instance (IMDS), accessible via l'adresse 169.254.169.254 dans tout environnement AWS conteneurisé. Les chercheurs ont démontré qu'un agent équipé d'outils HTTP ou shell — courants dans les architectures d'agents IA pour permettre l'appel d'APIs externes — peut être manipulé via une invite malveillante pour contacter l'endpoint IMDS. Ce dernier retourne alors les credentials temporaires du rôle d'exécution, incluant un identifiant de clé d'accès, une clé d'accès secrète et un token de session valide pour une durée limitée.

Avec ces credentials en main, les attaquants disposent d'un accès à l'ensemble du périmètre que le rôle d'exécution couvre. Dans les configurations par défaut analysées par Zenity, ce périmètre permettait le mouvement latéral vers d'autres agents AgentCore du même compte, l'accès aux conversations privées stockées par d'autres agents, la lecture du code source des agents déployés, la corruption des mémoires long terme des agents, et le vol de clés API et tokens OAuth stockés dans AWS Secrets Manager et référencés par les agents.

Deux vulnérabilités supplémentaires ont été identifiées dans le SDK Python d'AgentCore, référencées sous les identifiants CVE-2026-12530 et CVE-2026-16796. Ces failles résident dans le composant Code Interpreter Helper du SDK, utilisé pour l'installation de packages Python dans les environnements d'agents. Des entrées malveillantes dans ce composant pourraient permettre une exécution de code arbitraire dans le contexte de l'environnement d'exécution de l'agent, aggravant le niveau de risque global de la chaîne d'attaque décrite par les chercheurs.

La divulgation de Zenity Labs suit un processus de responsible disclosure coordonné avec AWS. L'équipe sécurité d'Amazon a été notifiée préalablement à la publication et a déployé plusieurs correctifs : durcissement des protections du service IMDS pour les environnements AgentCore, restriction substantielle des permissions par défaut des rôles d'exécution, et mise à jour du SDK Python vers la version 1.18.1 qui corrige les CVE-2026-12530 et CVE-2026-16796. AWS considère que la chaîne d'attaque principale décrite par les chercheurs est adressée dans la configuration actuelle du service.

Cette découverte s'inscrit dans un contexte plus large d'attaques ciblant spécifiquement l'infrastructure des agents IA. Au cours des derniers mois, plusieurs publications ont documenté des techniques d'injection de prompt indirect permettant de manipuler des agents connectés à des sources de données externes. AgentCorruption représente une évolution de cette menace vers un impact d'infrastructure : l'objectif n'est plus seulement de tromper l'agent sur sa réponse, mais d'utiliser l'agent comme pivot pour compromettre l'environnement cloud sous-jacent et accéder à des ressources bien au-delà du périmètre de l'agent lui-même.

Pour les équipes développant des solutions basées sur AWS Bedrock AgentCore, la mise à jour vers SDK 1.18.1 est urgente mais insuffisante à elle seule. La révision des permissions IAM des rôles d'exécution selon le principe du moindre privilège est tout aussi critique : un agent n'ayant besoin que de lire une base de données DynamoDB ne devrait pas avoir de permissions sur AWS Secrets Manager ou sur d'autres services AgentCore. L'audit des outils mis à disposition des agents — notamment les outils HTTP et shell — est également recommandé pour limiter les vecteurs d'accès à l'IMDS.

Les experts en sécurité cloud notent que cette classe de vulnérabilité n'est pas exclusive à AWS. Tout service d'hébergement d'agents IA qui exécute du code dans un environnement cloud conteneurisé avec un rôle de service associé présente une surface d'attaque similaire si les protections IMDS ne sont pas correctement configurées. La communauté de sécurité recommande aux fournisseurs de PaaS pour agents IA de documenter explicitement leurs mesures de protection IMDS et de proposer des configurations de rôle IAM minimales dans leurs guides de démarrage.

Pourquoi c'est important

AgentCorruption marque une transition importante dans le paysage des menaces liées à l'IA : les agents d'intelligence artificielle ne sont plus seulement des cibles d'attaques de manipulation (jailbreak, extraction de données confidentielles) mais deviennent des pivots d'attaque vers l'infrastructure cloud. Dans les architectures modernes, un agent IA peut avoir accès à des bases de données, des APIs internes, des services de stockage et des systèmes de secrets management. La compromission d'un seul agent peut ainsi ouvrir un accès à un périmètre bien plus large que sa fonction apparente ne le laisse supposer.

La technique du vol de credentials via l'IMDS n'est pas nouvelle dans le contexte des conteneurs et des fonctions serverless — c'est une classe d'attaque documentée depuis plusieurs années dans les environnements Kubernetes et Lambda. Ce qui est nouveau ici, c'est son application au contexte des agents IA, où les prompts d'un utilisateur malveillant constituent le vecteur d'accès initial. Toute organisation exposant un agent AgentCore sur une interface publique — chatbot client, assistant interne, agent d'automatisation — doit considérer que cet agent représente un potentiel point d'entrée vers son infrastructure AWS complète.

Les implications pour la gouvernance des agents IA en entreprise sont significatives. Les mêmes principes qui guident la sécurisation des microservices et des fonctions Lambda — moindre privilège, segmentation des rôles IAM, monitoring des accès anormaux, isolation des workloads — doivent s'appliquer intégralement aux agents IA. Or la plupart des guides de démarrage rapide pour AgentCore et les services similaires privilégient la facilité d'adoption sur la posture de sécurité, créant des configurations par défaut surprivilégiées que les équipes peinent ensuite à restreindre sans casser les fonctionnalités existantes.

Pour les RSSI, cette vulnérabilité doit déclencher une revue systématique de l'ensemble des déploiements d'agents IA en production, quel que soit le fournisseur cloud. Les questions à poser sont simples : quels rôles IAM ces agents utilisent-ils, quelles sont leurs permissions effectives, quels outils leur sont exposés, et qui peut leur envoyer des prompts ? Un inventaire précis de la surface d'attaque de chaque agent déployé est désormais une nécessité opérationnelle, pas seulement une bonne pratique théorique recommandée dans les frameworks de sécurité.

Ce qu'il faut retenir

• AgentCorruption permet à une seule invite malveillante de compromettre l'ensemble des agents AWS Bedrock AgentCore d'un compte via le vol de credentials IMDS et le mouvement latéral.
• AWS a patché la vulnérabilité principale — la mise à jour du SDK Python vers la version 1.18.1 est urgente et corrige également CVE-2026-12530 et CVE-2026-16796.
• Au-delà du patch : auditer les permissions IAM des rôles d'exécution selon le moindre privilège, restreindre les outils HTTP/shell des agents, et inventorier tous les agents exposés en production.