Agents IA : une seule invite a pris le contrôle de tous les agents AWS

Ce qui s'est passé

Des chercheurs de Zenity Labs ont démontré qu'un seul agent d'intelligence artificielle accessible publiquement sur Amazon Bedrock AgentCore pouvait prendre le contrôle de tous les agents présents dans le même compte AWS et dans la même région. Selon le compte rendu de The Decoder, une seule invite suffisait à déclencher cette prise de contrôle.

AWS a depuis corrigé la faille et resserré les permissions appliquées par défaut aux agents. Le point critique tient à la portée de l'attaque : elle ne se limitait pas à l'agent exposé, mais s'étendait à l'ensemble des agents partageant le même périmètre de compte.

Pourquoi c'est important

Les agents d'IA ne se contentent plus de répondre. Ils agissent, appellent des outils, consultent des données et déclenchent des processus. Cette capacité d'action change la nature du risque : une faille exploitable par une simple interaction textuelle peut se propager d'un agent à l'autre, avec des conséquences qui dépassent largement le point d'entrée initial.

Pour les organisations qui déploient des agents dans leurs services clients, leurs processus internes ou leurs opérations numériques, l'enjeu est aussi organisationnel. La question ne porte plus seulement sur la justesse des réponses d'un agent. Elle porte sur les personnes qui peuvent l'utiliser, sur ce qu'il est capable de faire et sur les permissions qui lui sont accordées dès sa mise en service.

Le point de vue Renascence

La plupart des lecteurs retiendront le caractère spectaculaire du titre. Le véritable enseignement concerne les réglages par défaut, c'est-à-dire ce que personne n'a explicitement choisi.

Le principe comportemental en jeu est celui des valeurs par défaut : ce qui est configuré d'origine façonne le comportement réel bien plus que les politiques écrites. Un opérateur centré sur le client devrait donc traiter chaque agent comme un collaborateur doté d'un périmètre minimal, et n'élargir son accès qu'après une décision explicite et documentée. Auditer les permissions avant le déploiement, plutôt qu'après un incident, relève autant de la conception de service que de la sécurité. Un agent qui agit sans que l'on sache précisément ce qu'il peut atteindre n'offre pas une bonne expérience, même lorsque ses réponses sont justes.