La publication AgentCorruption de Zenity du 8 octobre décrit un parcours historique depuis un agent Amazon Bedrock AgentCore public vers des runtimes voisins et une mémoire persistante. La condition décisive était un rôle d’exécution trop large dans le même compte AWS et la même région, pas l’intrusion chez d’autres clients ni le vol d’un mot de passe administrateur.
Une requête réseau induite par prompt exposait des identifiants temporaires ; IAM amplifiait leur portée. Avant publication, les chercheurs ont trouvé les rôles par défaut nettement restreints par AWS. L’étude démontre une faiblesse des anciens réglages testés, pas la vulnérabilité complète de toute installation actuelle.
Le prompt a franchi la frontière de l’identité du workload
AgentCore, généralement disponible depuis octobre 2025, associe runtimes isolés, identité, mémoire, passerelles, navigateur, exécution de code et observabilité. Ces fonctions résolvent de vrais problèmes, mais créent des dépendances d’autorisation au-delà de la microVM.
Dans le test, un outil HTTP suivait des instructions non fiables vers des métadonnées locales. AWS utilise un service link-local ; Firecracker dans AgentCore dispose du MMDS apparenté. Des identifiants temporaires autorisent normalement le code à utiliser des ressources approuvées sans clé permanente dans une image.
La demande venait de l’intérieur et paraissait locale, renvoyant clé d’accès, clé secrète et jeton temporaires. C’est une SSRF : pousser un composant serveur vers une destination inaccessible directement à l’attaquant. L’injection fournissait l’intention, l’outil le réseau et les métadonnées l’identité.
Du texte dangereux seul ne produirait pas cette chaîne. Bloquer l’accès inutile des outils aux métadonnées l’interromprait ; un rôle étroit limiterait les conséquences d’une fuite. AWS indique explicitement que code ou acteurs internes peuvent accéder aux identifiants et demande de minimiser les droits.
Zenity a signalé les métadonnées le 25 décembre 2025. AWS a clos comme informatif le 12 avril 2026, citant IMDSv2 pour les nouveaux déploiements depuis le 14 février. Le jeton préalable bloque beaucoup de SSRF classiques, mais un outil flexible peut réaliser aussi ces étapes. Zenity y voit une friction, pas une confiance résolue.
La documentation actuelle dit refuser les runtimes sans MMDSv2 depuis le 30 juin 2026. Il faut vérifier la configuration réelle, dont requireMMDSV2, sans supposer la migration de tous les anciens environnements. Cette protection reste une couche, pas une justification de privilèges trop larges pour le code légitime.
Des droits étendus ont rendu le point d’appui utile ailleurs
Le deuxième rapport du 12 janvier portait sur le rôle. Liste régionale des groupes CloudWatch et noms AgentCore révélaient selon Zenity identifiants de runtimes et mémoires sans inventaire initial. Droits ECR et dépôts prévisibles reliaient runtimes aux images, exposant potentiellement code et configuration.
Le droit wildcard d’invocation testé atteignait les agents privés du même compte et de la même région. Un bot public pouvait ainsi joindre un agent de facturation plus sensible. Zenity a montré ses outils et billing.json sur une cible de test via des API légitimes, pas un second exploit indépendant.
Les droits mémoire auraient permis de lister acteurs et sessions et lire les événements d’autres agents et utilisateurs. Conversations et dépannage peuvent contenir données personnelles, code, plans, dossiers clients ou identifiants collés. La pertinence d’un secret dans un échange ne détermine pas le droit d’un workload étranger à le lire.
Créer ou supprimer des événements affectait aussi l’intégrité. Un faux contexte pouvait entrer dans une session et des résultats authentiques disparaître. L’isolation de calcul n’interdisait pas à la même identité d’invoquer ou modifier d’autres ressources ; l’isolation d’autorisation est distincte.
AWS a dit le 25 février traiter le problème. Selon les chercheurs, le défaut restait inchangé le 22 juin, mais était fortement limité le 29 septembre : retrait des invocations croisées, conversations privées et accès Secrets Manager, avec d’autres restrictions.
Cela limite nettement les affirmations actuelles. Rôles personnalisés, politiques copiées et anciens déploiements méritent une revue, mais le passé ne prouve pas la même autorité aujourd’hui. Les tests étaient contrôlés ; les éléments publics cités ne démontrent pas d’exploitation large des clients. AWS n’avait pas publié de bulletin dédié à toute la chaîne.
La mémoire pouvait conserver l’influence après expiration
La mémoire courte contient des événements ; les stratégies longues extraient faits, préférences, résumés et leçons. Retenir un dossier ouvert ou un format aide, mais fait de l’historique une entrée des décisions futures, pas seulement une preuve après incident.
Zenity décrit découverte des identifiants via logs, énumération des acteurs, sessions et stratégies, puis ajout d’événements hostiles. L’extraction convertissait certains contenus en souvenirs longs récupérés comme contexte fiable. Il n’était donc pas nécessaire de répéter l’injection initiale à chaque échange.
« Commandement et contrôle persistants » est la qualification des chercheurs dans leur test. Le résultat dépend de configuration, récupération, modèle, outils et droits. Fausse destination, approbation ou synthèse illustrent un risque, pas le contrôle assuré de tous les agents par toute mémoire.
Un événement d’assistant inséré peut sembler une ancienne décision ; un résultat supprimé retire une preuve contraire. Expiration ou rotation empêche les futurs appels API, mais n’efface pas code copié, secrets ou état empoisonné. La réponse doit retrouver sessions, événements, synthèses et mémoires touchés.
AWS recommande validation, garde-fous avant persistance, tests réguliers et moindre privilège. La provenance devrait indiquer utilisateur, agent, session et extraction pour permettre quarantaine. Une préférence de style diffère de coordonnées de paiement ou d’accès, qui exigent création, rétention et revue plus fortes.
Un souvenir ne doit pas autoriser seul une action risquée. Un compte bancaire préféré ne remplace pas une approbation actuelle indépendante. Écritures et suppressions doivent être surveillées avec lectures, volumes inhabituels et motifs interagents, via CloudTrail, logs applicatifs et observabilité AgentCore.
La frontière d’autorisation appartient hors du jugement du modèle
AWS déconseille en production les politiques larges générées par CLI pour le développement et recommande des ARN spécifiques. Le rôle ne devrait pas dépasser les privilèges des personnes ou services autorisés à l’invoquer. L’accès public exige donc des droits particulièrement étroits.
Tout agent public n’est pas automatiquement dangereux. Le langage reste cependant non fiable, y compris prompts hostiles de clients authentifiés et instructions indirectes dans pages et documents. Authentifier reconnaît l’appelant, pas la sûreté de tout son contenu.
Passerelles, garde-fous et intercepteurs aident si aucune autre route autorisée ne les contourne. Si la passerelle est l’entrée, l’appel direct devrait être réservé à son rôle. L’identité utilisateur doit venir de sujets vérifiés, pas d’étiquettes générées par le modèle ou autodéclarées.
IAM ciblé peut bloquer agents, images, logs régionaux et mémoires étrangers. Charges publiques et internes ne doivent pas partager un rôle par commodité ; comptes ou régions séparés peuvent clarifier les limites sensibles.
Les outils sont des interfaces privilégiées, pas des droits donnés par le choix du modèle. L’autorisation doit examiner utilisateur, ressource et opération indépendamment. Des connaissances techniques peuvent relier responsables, politiques, menaces et incidents, sans remplacer un refus imposé.
La revue actuelle nécessite historique et état persistant
La revue doit couvrir rôles, métadonnées, entrées publiques/IAM/JWT, contournement, invocations croisées, ECR et logs, mémoires entre utilisateurs, événements et accès aux jetons ou Secrets Manager. Les politiques de ressource et d’identité se testent ensemble pour le refus attendu, pas d’après un prototype fonctionnel.
L’exposition passée exige les événements du bon intervalle : CloudTrail, invocations, métadonnées, images, mémoires et secrets, plutôt que seulement les politiques actuelles. Des identifiants temporaires laissent des effets durables ; rotation et validation d’état se complètent.
Les prochaines preuves utiles seraient un avis ou une migration AWS formels, une séparation renforcée des outils et endpoints d’identifiants, ainsi que provenance, écritures limitées, alertes et quarantaine collective visibles au client. Ce sont des éléments à vérifier, pas des fonctions présumées livrées.
La question générale est ce qui reste possible après qu’un modèle suit une instruction malveillante. Le service géré réduit la complexité mais ne peut fusionner outils, identité et mémoire en un rôle largement fiable. Des limites déterministes doivent empêcher une réponse manipulée de devenir un incident du compte entier, même si le modèle échoue.
Sources et lectures complémentaires
Chaîne étudiée par Zenity · Identifiants AWS · Analyse du rôle Zenity · Sécurité runtime AWS · Complément : connaissances techniques · Étude d’empoisonnement mémoire · Pratiques mémoire AWS · Reportage AgentCorruption