AgentCorruption : un prompt, un rôle IAM par défaut et la prise de contrôle des agents d'un compte AWS AgentCore

De quoi s’agit-il ?

Le 8 octobre 2026, Zenity Labs (auteurs : Tamir Ishay Sharbat et Lana Salameh) a publié « AgentCorruption », une série de recherches sur Amazon Bedrock AgentCore, la plateforme gérée d’AWS pour déployer des agents d’IA. Les travaux ont aussi été présentés à SecTor 2026 à Toronto, et Dark Reading ainsi que The Next Web les ont relayés la même semaine.

L’affirmation centrale : un seul prompt envoyé à un agent exposé publiquement pouvait conduire à un accès sur d’autres agents du même compte et de la même région AWS. Deux précisions pour garder la juste mesure : la recherche portait sur un compte et une région, et AWS conteste qu’il s’agisse d’une vulnérabilité, estimant le comportement documenté et attendu. Aucun CVE n’a été attribué.

Fonctionnement

Zenity décrit une chaîne de trois faiblesses, chacune banale prise isolément.

D’abord l’accès initial. Les agents s’exécutent dans des MicroVM Firecracker et, selon Zenity, l’isolation réseau n’empêchait pas un outil d’agent émettant des requêtes HTTP d’atteindre le service de métadonnées d’instance (IMDS). Un agent doté d’un outil de requêtes web ou d’un shell pouvait donc recevoir l’instruction, en langage courant, de renvoyer ses propres identifiants temporaires. C’est un schéma de falsification de requête côté serveur (SSRF) appliqué à un agent : le modèle, piloté par une entrée non fiable, fait office de « falsificateur ».

Ensuite, un rôle par défaut trop large. Zenity indique que le rôle d’exécution par défaut n’était pas limité à un seul agent mais couvrait les ressources AgentCore de tout le compte et de la région. Avec ces identifiants, les chercheurs ont pu énumérer les agents (via la liste des groupes de journaux), récupérer des images de conteneurs, invoquer d’autres agents, lire les événements de conversation de plusieurs utilisateurs et sessions, et obtenir des clés d’API et des valeurs de Secrets Manager censées rester hors de portée de l’agent.

Enfin, la persistance par la mémoire. Lorsque la mémoire à long terme était activée, la permission de créer des événements mémoire permettait d’insérer un faux événement modifiant durablement le comportement d’un agent d’une session à l’autre.

Rien de tout cela n’exige un jailbreak au sens classique : le prompt devait seulement amener l’agent à utiliser un outil qu’il possédait déjà.

Pourquoi c’est important

Ce cas illustre un schéma récurrent sur les plateformes d’agents : les outils s’exécutent avec l’identité cloud de l’agent, de sorte que toute voie d’injection de prompt devient une voie vers des identifiants cloud. Lorsque l’identité est partagée ou sur-dimensionnée, un agent compromis côté client expose les agents internes voisins. Zenity recommande de considérer les agents comme des points d’entrée potentiels.

La chronologie de divulgation est instructive (dates selon Zenity) : signalements les 25 décembre 2025 et 12 janvier 2026 ; IMDSv2 seul pour les agents nouvellement déployés depuis le 14 février 2026 ; premier rapport clos comme « informatif » le 12 avril 2026 ; rôle par défaut inchangé au 22 juin 2026 ; et, le 29 septembre 2026, Zenity a constaté le retrait des permissions d’invocation inter-agents, de lecture des conversations et d’accès à Secrets Manager dans le rôle par défaut. AWS n’a pas qualifié cela de correctif : il s’agit d’une observation de Zenity. Selon Dark Reading, Zenity n’a vu aucune exploitation dans la nature.

Défenses

• Moindre privilège par agent. Attribuez à chaque agent son propre rôle d’exécution, limité aux ressources nécessaires, sans vous appuyer sur le rôle par défaut. C’est aussi la recommandation d’AWS.
• Exiger IMDSv2 et restreindre l’accès aux métadonnées. Les nouveaux agents utilisent IMDSv2 uniquement, mais auditez les déploiements plus anciens. Dans la mesure du possible, bloquez ou filtrez l’accès à 169.254.169.254 depuis les outils des agents.
• Contraindre les outils HTTP et shell. Utilisez des listes blanches de destinations pour les outils de requêtes web et évitez de donner un shell générique aux agents exposés publiquement.
• Séparer les zones de confiance. Ne placez pas agents clients et agents internes dans la même frontière de compte et de rôle.
• Protéger les écritures en mémoire. Limitez qui et quoi peut créer des événements mémoire, et examinez les mémoires stockées à la recherche de contenu ressemblant à des instructions.
• Surveiller. Alertez sur l’usage d’identifiants de rôle depuis des adresses IP inattendues et sur des invocations inter-agents inhabituelles.

Statut

Élément	Détail
Composant	Amazon Bedrock AgentCore (runtime, rôle d’exécution par défaut, mémoire)
Publication	8 octobre 2026 (Zenity Labs) ; Dark Reading mis à jour le 9 octobre avec la réponse d’AWS
CVE	Aucun attribué
IMDSv2	Imposé aux agents nouvellement déployés depuis le 14 février 2026 (selon Zenity et AWS)
Rôle par défaut	Restreint, constaté par Zenity le 29 septembre 2026 ; AWS juge le comportement initial documenté et attendu
Exploitation dans la nature	Aucune signalée par Zenity