Aller au contenu principal
Intelligence artificielleUSUS

Zenity révèle une faille critique dans Amazon Bedrock AgentCore

Des chercheurs de Zenity Labs ont détourné tous les agents IA d'un compte AWS via un seul message adressé à un agent public sur Amazon Bedrock AgentCore. AWS a depuis restreint l'accès aux métadonnées et resserré le rôle d'exécution par défaut.

5 min de lectureMis à jour il y a 3 h
Un seul message dans la fenêtre du service client a poussé l'agent à envoyer ses propres identifiants AWS vers un serveur externe.
Crédit image : Zenity Labs
Dans cet article
  1. Une chaîne de vulnérabilités dans AgentCore
  2. L'agent a livré ses propres identifiants
  3. Des permissions par défaut qui exposaient toute la région
  4. AWS resserre l'accès aux métadonnées et les permissions par défaut
  5. D'autres attaques ont révélé des faiblesses similaires

Une chaîne de vulnérabilités dans AgentCore

Un agent IA accessible publiquement sur Amazon Bedrock AgentCore a suffi aux chercheurs de Zenity Labs pour prendre le contrôle de l'ensemble des agents AgentCore d'un même compte et d'une même région AWS. La plateforme d'AWS sert à exécuter des agents d'entreprise dotés d'outils, de mémoire et de gestion des accès. Selon The Decoder, la société de sécurité a baptisé « AgentCorruption » cette chaîne de vulnérabilités.

Il suffisait à un attaquant de disposer d'un accès par chat à un agent public pour exploiter les failles. D'après Zenity, une seule invite a permis de détourner tous les agents AgentCore du même compte et de la même région, exposant conversations privées, code source et identifiants stockés. Le problème était systémique et touchait des agents équipés d'outils intégrés dans plusieurs comptes AWS.

L'agent a livré ses propres identifiants

AWS exploite un Instance Metadata Service à l'adresse interne 169.254.169.254, qui fournit des identifiants temporaires aux instances et aux charges de travail pour s'authentifier. Quiconque intercepte ces identifiants peut usurper l'instance.

Un agent IA ne devrait normalement pas pouvoir atteindre ce service, mais AgentCore manquait d'isolation, selon le billet technique de Zenity. Les chercheurs ont construit un agent de test avec Strands, un framework open source d'AWS livré avec un outil web. Invité en langage naturel à interroger le service de métadonnées et à envoyer le résultat à un serveur externe, l'agent a obéi. « La frontière du bac à sable que nous étions censés combattre n'existait tout simplement pas », écrivent les chercheurs.

Les identifiants dérobés fonctionnaient sur la machine des chercheurs, hors de la plateforme, qui n'avaient donc plus besoin de l'agent pour poursuivre l'attaque. Le service de métadonnées exposait aussi des certificats et du matériel de clé pour un service interne AWS, ainsi qu'une URL présignée vers un stockage S3 interne n'appartenant pas au compte des chercheurs. Retirer l'outil web n'aurait rien changé, la faille se situant dans la plateforme elle-même, selon Zenity. Les chercheurs ont également mené l'attaque via un outil en ligne de commande.

Des permissions par défaut qui exposaient toute la région

La prise de contrôle a été rendue possible parce que les permissions par défaut d'AgentCore ne se limitaient pas à l'agent qui les recevait. D'après Zenity, elles s'appliquaient à tous les agents du même compte et de la même région, avec des droits de lecture, d'écriture et de suppression autorisant des opérations destructrices.

Avec ces permissions, les chercheurs pouvaient lister chaque agent, télécharger leurs paquets de code en quelques secondes et les invoquer. Ces paquets contiennent souvent des mots de passe ou des clés API oubliés aux côtés du code source, exposant potentiellement bien plus que les agents eux-mêmes. Un attaquant pouvait par exemple passer d'un agent de service client public à un agent financier interne et accéder à ses données. Les chercheurs pouvaient aussi lire toutes les conversations privées entre utilisateurs et agents.

Pour les agents dotés d'une mémoire à long terme, ils pouvaient modifier celle-ci afin d'influencer leur comportement futur. Leur publication sur l'empoisonnement de la mémoire décrit comment ils ont implanté des instructions poussant les agents à transmettre les conversations futures vers une destination externe. Les utilisateurs auraient continué à dialoguer avec un agent apparemment digne de confiance sans rien remarquer.

AWS recommande de conserver mots de passe et clés API à l'écart des agents, dans un stockage sécurisé, mais les permissions par défaut d'AgentCore affaiblissaient cette protection. Selon le billet de Zenity sur le vol d'identifiants, ces permissions permettaient aux agents d'accéder aux identifiants stockés, y compris des clés pour des services hors AWS.

AWS resserre l'accès aux métadonnées et les permissions par défaut

Zenity indique avoir signalé ses conclusions sur AgentCore à AWS le 25 décembre 2025, après quoi AWS a fait d'IMDSv2 la configuration par défaut des nouveaux déploiements AgentCore. IMDSv2 est une version plus sûre du service de métadonnées, par lequel l'attaque de Zenity est entrée. Zenity commercialise par ailleurs une plateforme de sécurité pour agents IA, ce qui lui donne un intérêt économique à signaler des vulnérabilités dans ce domaine.

D'après la version actualisée de Zenity, AWS a aussi modifié le rôle d'exécution par défaut d'AgentCore vers le mois d'août. Ce rôle n'autorise plus les agents à en invoquer d'autres, à lire les conversations privées ni à récupérer des identifiants depuis AWS Secrets Manager. AWS a également restreint nettement d'autres permissions, mais les chercheurs recommandent toujours aux entreprises de créer des rôles personnalisés aux droits plus étroits. Ils détaillent ces recommandations dans leur analyse du rôle par défaut.

Michael Bargury, CTO de Zenity, voit un conflit entre la sécurité du cloud et la souplesse dont les agents ont besoin. « La sécurité du cloud repose sur la segmentation et le moindre privilège. Mais les agents IA ont besoin d'une liberté créative pour être utiles », a-t-il déclaré. Toute entreprise exploitant des agents dans le cloud fait face à cet arbitrage, en particulier lorsque des agents publics et internes partagent un même environnement. Dans cette configuration, une seule vulnérabilité peut compromettre les frontières de sécurité de tout le système.

D'autres attaques ont révélé des faiblesses similaires

Les conclusions sur AgentCore s'inscrivent dans un schéma documenté ailleurs par Zenity, où une entrée d'apparence anodine retourne un agent contre sa propre organisation. Dans ses travaux AgentFlayer, des attaques sans clic ont poussé Salesforce Einstein, Copilot Studio et Cursor à rediriger des données clients ou à divulguer des identifiants. Avec AgentForger, un lien ChatGPT altéré a suffi à créer un agent autonome dans les Workspace Agents d'OpenAI, avec les exigences d'approbation désactivées.

OpenAI a corrigé sa vulnérabilité en quatre jours, tandis que les permissions par défaut trop larges d'AgentCore ont persisté plusieurs mois après le signalement de Zenity. AWS a rendu AgentCore disponible pour toutes les entreprises, et Amazon indique compter Sony et Ericsson parmi ses utilisateurs.

Les recherches sur la mémoire des agents ont documenté des faiblesses comparables. Google DeepMind classe la manipulation de la mémoire à long terme comme une catégorie d'attaque distincte dans sa taxonomie des « AI Agent Traps », constatant que quelques documents empoisonnés dans une base de connaissances suffisent à orienter les réponses. Dans l'étude de red teaming « Agents of Chaos », des chercheurs ont contrôlé à distance un agent OpenClaw via un document modifiable de l'extérieur et lié dans son fichier de mémoire, tandis qu'un autre agent livrait des coordonnées bancaires non masquées.

Sam Altman, PDG d'OpenAI, a déclaré que les agents ne devraient recevoir que le minimum d'accès nécessaire. Selon Zenity, le rôle par défaut d'AgentCore violait ce principe.

Maillage