L’isolement complet des workflows des agents IA sur Bedrock, la plateforme de développement IA d’AWS n’est pas complètement hermétique, souligne des experts de BeyondTrust. Dans une récente publication, ils ont expliqué que le mode sandbox de l’interpréteur de code AgentCore sur Bedrock pouvait être détourné à l’aide de requêtes DNS. Même si la zone tampon bloque la plupart du trafic sortant, il autorise toujours les requêtes DNS pour les enregistrement A (adresse IPv4) et AAAA (adresses IPv4 et IPv6), laissant aux attaquants la possibilité d’établir un canal de communication clandestin, avec un risque d’exfiltration de données et d’exécution de commandes à distance.

« L’isolation de la sandbox de Bedrock a échoué au niveau de la couche la plus fondamentale, le DNS, et ce qu’il faut comprendre, ce n'est pas qu'AWS a livré un bug, mais que les contrôles de périmètre sont architecturalement insuffisants face aux environnements d'exécution d'IA agentique », a déclaré Ram Varadarajan, CEO d'Acalvio (spécialisée dans la sécurité IA). Il ajoute « aucun logiciel malveillant n'est nécessaire, juste un modèle conforme avec des entrées empoisonnées ». Dans un blog, les chercheurs de Beyond Trust ont constaté qu’AWS avait pris acte du rapport et reproduit le problème lors du processus de divulgation. Mais le fournisseur a finalement choisi de ne pas corriger ce comportement, le qualifiant de « fonctionnalité voulue plutôt que de défaut ».

Le chemin DNS autorisé brise l'isolation

Le problème réside dans le fait que l'environnement sandbox autorise les requêtes DNS sortantes, lesquelles peuvent être manipulées pour créer un canal de communication bidirectionnel entre l'agent IA et un serveur externe contrôlé par un attaquant. En encodant des données dans des requêtes et des réponses DNS, l'équipe Phantom Labs de BeyondTrust a démontré qu'il était possible d'exfiltrer des données et même d'établir un shell inversé interactif, sans déclencher aucune restriction au niveau du réseau. « L'environnement (vulnérable) autorise les requêtes DNS sortantes pour les enregistrements A et AAAA, une faille structurelle que les acteurs malveillants peuvent exploiter pour établir un canal de commande et de contrôle bidirectionnel », a expliqué Jason Soroko, chercheur senior chez Sectigo.

Une fois ce canal en place, le reste n'est plus qu'une question d'autorisations. Si l'agent fonctionne avec des rôles IAM (identity and access management) trop larges, le champ d'action s'étend rapidement. « En tirant parti de ce canal, les attaquants peuvent obtenir un shell inversé interactif et exécuter des commandes arbitraires », a ajouté M. Soroko. « Si l'environnement d'exécution de l'IA se voit attribuer des rôles IAM trop permissifs, les attaquants peuvent exfiltrer silencieusement des données cloud sensibles, comme le contenu des buckets S3, directement via ces requêtes DNS autorisées. » Techniquement, le bac à sable n’est pas compromis, il est contourné à l’aide d’une fonctionnalité qui a toujours été prévue. Du moins, c’est ce qu’affirme le fournisseur de service cloud.

La publication d’un correctif annulée

BeyondTrust a déclaré avoir découvert cette vulnérabilité et l'avoir signalée à AWS le 1ᵉʳ septembre 2025 via la plateforme de prime aux bugs HackerOne. AWS aurait accusé réception du rapport et déployé un premier correctif en environnement de production en novembre. Cependant, BeyondTrust a été informé quelques jours plus tard que le correctif initial avait été annulé en raison d’« autres facteurs » et qu’AWS travaillait sur une solution plus robuste. Finalement, en décembre, AWS a indiqué à BeyondTrust qu’aucun correctif ne serait apporté, car ce comportement correspondait à une « fonctionnalité prévue », et qu’il a plutôt mis à jour sa documentation pour préciser que le mode sandbox autorise la résolution DNS. Le chercheur a reçu une carte-cadeau Gear Shop d’une valeur de 100 dollars pour cette découverte. Selon un porte-parole du fournisseur, tous les services et l'infrastructure AWS fonctionnent comme prévu. « Le mode Sandbox fournit un accès réseau exclusivement à Amazon S3 pour les opérations de données, ce qui le rend idéal pour les charges de travail de production qui s'appuient sur les données S3 », a précisé le porte-parole. « La résolution DNS est activée pour permettre l'exécution réussie des opérations S3. », a-t-il ajouté.

« Étant donné qu'AWS a déterminé que ce comportement correspondait à une fonctionnalité prévue et a choisi de mettre à jour sa documentation plutôt que de publier un correctif, les équipes de sécurité doivent adapter leurs stratégies défensives de manière proactive », a suggéré M. Soroko, recommandant aux équipes de « recenser toutes les instances actives d'AgentCore Code Interpreter » et de « migrer vers le mode VPC ». M. Varadarajan, CEO d'Acalvio, préconise une approche plus adaptative : « La réponse architecturale appropriée consiste à intégrer à l'environnement d'exécution lui-même des éléments de leurre — des identifiants IAM « canary », des chemins S3 « honey », des « sinkholes » DNS — qu'un agent efficace ne manquera pas de détecter, précisément parce qu'il fait bien son travail », a-t-il souligné. AWS aurait attribué à ce problème un score CVSS de 7,5. La documentation reflète désormais la modification apportée à la description du mode Sandbox, qui indique que celui-ci « offre un accès réseau externe limité », contrairement à la formulation précédente qui indiquait qu’il offrait « une isolation complète sans accès réseau externe ».