Des chercheurs de Zenity ont découvert qu’un seul prompt suffisait pour prendre le contrôle de tous les agents IA dans un compte AWS.

Des chercheurs de Zenity ont découvert qu’un seul prompt suffisait pour prendre le contrôle de tous les agents IA dans un compte AWS.

Points clés

• Une série de vulnérabilités dans la plateforme Bedrock AgentCore d’Amazon a permis aux chercheurs de prendre le contrôle de tous les agents IA de l’entreprise dans la même région AWS, grâce à un seul message de chat adressé à un agent public.
• Les agents manquaient d’une isolation adéquate et transmettaient les identifiants internes AWS lorsqu’on leur demandait. Comme la plateforme accordait des droits par défaut étendus pour toute la région, les chercheurs pouvaient accéder et manipuler le code source, les mots de passe, les conversations privées et la mémoire à long terme des autres agents.
• AWS a partiellement résolu le problème en rendant plus difficile pour les nouveaux agents de récupérer les métadonnées internes et en renforçant le rôle d'exécution par défaut. Les chercheurs recommandent néanmoins que les entreprises attribuent manuellement à leurs agents AI des rôles plus stricts, avec des droits d'accès minimalistes.

Les chercheurs de Zenity Labs affirment qu’un seul agent IA accessible au public sur Amazon’s Bedrock AgentCore suffisait pour prendre le contrôle de tous les agents AgentCore dans le même compte AWS et région.

Amazon Bedrock AgentCore est la plateforme d’AWS permettant l’exécution d’agents d’IA d’entreprise, avec des outils, de la mémoire et une gestion des accès. La société de sécurité Zenity Labs a identifié une série de vulnérabilités que les chercheurs appellent « AgentCorruption ».

Un attaquant n’avait besoin que d’un accès à la messagerie pour un agent accessible publiquement. D’après les chercheurs, ils ont pris le contrôle de tous les agents AgentCore dans le même compte et région AWS avec une seule commande. Ils pouvaient lire les conversations privées, télécharger le code source et obtenir les identifiants stockés. Selon Zenity, le problème était systémique et affectait les agents équipés d’outils intégrés dans tous les comptes AWS.

L’agent a remis ses propres identifiants

Le point de départ est un problème de cloud bien connu. AWS exécute un Service de métadonnées d’instance à l’adresse interne 169.254.169.254, qui fournit des identifiants temporaires que l’instance ou le travail utilisent pour se connecter à AWS. Quiconque obtient ces identifiants peut se faire passer pour l’instance.

Normalement, un agent IA ne devrait pas pouvoir accéder à ce service. Mais selon le post technique de Zenity, AgentCore ne disposait pas d’une isolation appropriée. Les chercheurs ont créé un agent de test en utilisant Strands, un framework open-source d’AWS incluant une outil web. Ils ont demandé à l’agent, dans un langage simple, de consulter le service de métadonnées et d’envoyer les résultats à un serveur externe. L’agent a respecté les instructions. « La frontière du sandbox dont nous devions lutter ne existait simplement pas », écrivent les chercheurs.

Les identifiants volés ont fonctionné en dehors de la plateforme sur l’ordinateur des chercheurs eux-mêmes, et à partir de ce moment-là, ils n’avaient plus besoin de l’agent. Le service de métadonnées a également exposé d’autres informations sensibles, y compris le matériel de certificat et de clé pour un service interne d’AWS, ainsi qu’un URL signé pointant vers un bucket S3 interne qui ne faisait pas partie de l’accoutrement des chercheurs.

Selon Zenity, ne pas utiliser l’outil en ligne n’aurait pas aidé. L’attaque fonctionne tout aussi bien via un outil de ligne de commande, car la faille se trouve dans la plateforme elle-même.

Un rôle par défaut qui servait de clé maîtresse

Le plus grand dommage provient des permissions que AgentCore attribue par défaut à chaque agent. Selon Zenity, ces permissions ne sont pas limitées à un seul agent mais s’appliquent à tous les agents de la région, couvrant les droits de lecture, d’écriture et de suppression, ainsi que les actions destructives.

Avec ces permissions, les chercheurs pouvaient énumérer chaque agent, télécharger leurs paquets de code en quelques secondes, et l’activer individuellement. Ces paquets contiennent souvent des mots de passe oubliés ou des clés API, ainsi que le code source. Un attaquant pourrait, par exemple, passer d’un agent de service client public à un agent financier interne et accéder à ses données. Toutes les conversations privées entre utilisateurs et agents étaient également lisibles.

Pour les agents dotés d’une mémoire à long terme activée, les chercheurs ont pu manipuler directement cette mémoire. Selon leur article sur le poisonage de la mémoire, ils ont inséré des instructions qui faisaient en sorte que les agents transmettent les conversations futures à un destination externe. Les utilisateurs continueraient à parler avec un agent qui semblait fiable, sans remarquer qu’il y avait un problème.

Les mesures de protection pour les mots de passe et les clés API ont également échoué. AWS recommande de stocker les identifiants séparément des agents dans un coffre sécurisé, mais les permissions par défaut permettaient un accès direct à ce coffre, selon la publication de Zenity sur le vol de identifiants. Cela inclut également les clés pour les services externes à AWS.

AWS corrige les déficiences

Zenity indique qu’elle a rapporté les résultats de AgentCore à AWS le 25 décembre 2025. Après ce rapport, AWS a fait de IMDSv2 la version par défaut pour les déploiements de AgentCore. IMDS est le Instance Metadata Service, un service interne de AWS que les charges de travail utilisent pour récupérer des informations en temps réel et des identifiants temporaires. C’était également la première étape dans l’attaque menée par Zenity. IMDSv2 est une version plus sûre, et les agents nouvellement déployés fonctionnent désormais par défaut avec celle-ci. Zenity vend sa propre plateforme de sécurité pour agents d’IA, ce qui permet à l’entreprise de se concentrer sur la découverte des failles dans ce domaine.

Le rôle d’exécution par défaut trop large d’AgentCore était un autre problème. Selon le compte mis à jour de Zenity, AWS a modifié ce rôle en août. La version mise à jour ne comprend plus les permissions permettant aux agents d’appeler d’autres agents, de lire les conversations privées ou de récupérer des identifiants depuis AWS Secrets Manager ; en outre, les autres permissions ont été considérablement renforcées. Les chercheurs recommandent néanmoins que les entreprises créent leurs propres rôles plus restreints pour leurs agents. Plus de détails se trouvent dans leur analyse du rôle par défaut.

Zenity CTO Michael Bargury perçoit une tension fondamentale. « La sécurité dans le cloud consiste en la segmentation et en l’accès au moindre privilège. Mais les agents d’IA ont besoin de liberté pour être utiles », a-t-il déclaré. Toute entreprise utilisant des agents dans le cloud doit faire face à ce compromis. Comme les agents publics et les agents internes partagent souvent le même environnement, une vulnérabilité unique peut bouleverser les limites de tout le système.

Un schéma de agents se retournant contre leurs propriétaires

Le bug AgentCore correspond à une série de découvertes de Zenity qui suivent un schéma similaire : une entrée ayant l’apparence d’une entrée inoffensive peut faire que l’agent s’oppose à sa propre organisation. Sous le nom AgentFlayer, les chercheurs ont utilisé des attaques à zéro clic pour faire rediriger les données clients de Salesforce Einstein, Copilot Studio et Cursor, ou pour voler les identifiants. Avec AgentForger, une seule lien manipulé de ChatGPT suffisait pour créer un agent autonome au sein des Workspace Agents d’OpenAI, avec les exigences d’approbation désactivées.

La comparaison ne semble pas favorable pour AWS. OpenAI a corrigé sa vulnérabilité en quatre jours, tandis que les permissions par défaut excessives d’AgentCore ont persisté pendant des mois après le rapport de Zenity. Cela affecte une plateforme que AWS a ouverte à toutes les entreprises, et dont Amazon affirme qu’elle est utilisée par Sony et Ericsson, entre autres.

L’agent de mémoire qui devient une vecteur d’attaque correspond aux découvertes de la communauté de recherche. Google DeepMind classe la manipulation de la mémoire à long terme comme sa propre catégorie d’attaque. taxonomie des « pièges d’agents IA ». Quelques documents empoisonnés dans une base de connaissances suffisent pour déformer les réponses de manière ciblée. Dans l’étude de red-teaming « Agents de Chaos », Un agent OpenClaw a été contrôlé à distance via un document modifiable externe lié dans son fichier de mémoire, et un autre agent a remis les coordonnées bancaires non supprimées. Sam Altman, PDG d’OpenAI, a expliqué lui-même la mesure contre-mesure évidente, en disant que les agents ne devraient avoir que l’accès minimal nécessaire. Selon Zenity, le rôle par défaut d’AgentCore a violé précisément ce principe.

Actualités en IA Sans Hype – Sélectionnées par des humains

Inscrivez-vous à THE DECODER pour une lecture sans publicités, un bulletin informatique sur l’IA toutes les semaines, notre rapport exclusif « AI Radar » six fois par an, un accès complet à l’archive, et un accès à notre section de commentaires.