Pourquoi la sandbox d’un agent qui exécute du code est-elle critique ?
Parce que le code exécuté peut venir d’un texte qu’un tiers a écrit. Un agent qui analyse un fichier CSV, une page web ou un e-mail peut recevoir une instruction cachée qui lui demande de lancer un script. Triedman, Jha et Shmatikov ont montré que des contenus adversaires placés dans des entrées non fiables peuvent amener des systèmes multi-agents à exécuter du code arbitraire, avec des taux de réussite de 58 à 90 % selon l’orchestrateur sur leurs essais avec GPT-4o. La sandbox décide alors de la gravité : un code qui tourne dans une enceinte vide n’atteint rien, un code qui dispose d’un réseau et d’un jeton cloud atteint beaucoup.
Un code interpreter est un cas particulier de ce que l’OWASP appelle l’Excessive Agency (LLM06) : une fonction très puissante offerte à un modèle qu’on peut manipuler. On le teste donc comme un outil à hauts privilèges.
Quels incidents publics illustrent les risques ?
Deux faits vérifiables servent de repères, l’un côté agent, l’autre côté conteneur.
AWS Bedrock AgentCore Code Interpreter (BeyondTrust, 2026). Les chercheurs de BeyondTrust Phantom Labs ont montré que le mode « Sandbox » du Code Interpreter d’AgentCore, présenté comme sans accès réseau externe, laissait sortir les requêtes DNS. En encodant des données dans des requêtes DNS vers un serveur de noms qu’ils contrôlaient, ils ont obtenu une exfiltration de données et un shell inversé interactif. D’après leur dépôt, le mode permettait aussi le HTTPS vers les points d’accès S3, et l’impact dépendait du rôle IAM attribué à l’interpréteur. BeyondTrust dit avoir signalé le problème à AWS le 1er septembre 2025 ; la publication date du 16 mars 2026. La presse (The Hacker News, CSO Online) rapporte que le comportement n’a pas reçu d’identifiant CVE, qu’il a été noté CVSS 7,5 et que la mise à jour d’AWS a consisté à documenter que le mode Sandbox autorise la résolution DNS, en recommandant le mode VPC. Cette position a pu évoluer depuis : vérifiez l’état actuel du service avant de vous appuyer sur ce constat. Pour votre propre déploiement, retenez surtout la leçon : « isolé » dans une documentation de produit ne dispense pas de tester.
runc CVE-2024-21626 (2024). Cette faille de la couche d’exécution de conteneurs runc permettait une évasion du conteneur par des descripteurs de fichiers hérités et un répertoire courant piégé. Elle affecte les versions de runc de 1.0.0-rc93 à 1.1.11 incluses, avec un score CVSS de 8,6 ; la version 1.1.12 la corrige. Elle rappelle que la sandbox d’un agent repose souvent sur un conteneur, et qu’un conteneur est aussi sûr que son moteur et sa configuration.
Quelles sont les voies d’évasion et d’abus à connaître ?
| Voie | Ce que ça permet | Contrôle à tester |
|---|---|---|
| Réseau sortant (HTTP, DNS, autres protocoles) | Exfiltrer des données, joindre un serveur de commande | Politique réseau en refus par défaut, DNS filtré |
| Identifiants de l’environnement | Appeler des API cloud avec le rôle de l’interpréteur | Rôle sans droit, aucune variable secrète en clair |
| Service de métadonnées cloud | Récupérer des jetons temporaires | Accès bloqué depuis la sandbox |
| Système de fichiers partagé | Lire les fichiers d’autres sessions ou clients | Volume propre à chaque session, effacé à la fin |
| Frontière du conteneur | Évasion vers l’hôte | Moteur à jour, profils de confinement, utilisateur sans privilège |
| Ressources | Déni de service, minage | Limites de CPU, mémoire, durée, processus |
| Installation de paquets | Code tiers malveillant ou hallucination de paquet | Dépôt interne ou liste blanche |
| Sorties de l’exécution | Rendu de contenu piégé dans l’interface | Traitement de la sortie comme non fiable |
Comment tester une sandbox de code interpreter ?
On teste en demandant à l’agent d’exécuter des programmes de reconnaissance et en observant ce qu’il peut atteindre. Les tests se font sur un environnement de développement ou de préproduction, avec des identifiants de test, et avec l’accord écrit du propriétaire du système.
- Cartographier l’environnement. Utilisateur, variables d’environnement (sans consigner de secrets réels), points de montage, binaires disponibles, version du noyau. Notez ce qui est exposé.
- Tester le réseau. Résolution DNS d’un domaine de test que vous contrôlez, requête HTTP sortante, connexion à une adresse interne, accès au service de métadonnées. Le DNS mérite un test à part : un réseau « fermé » qui laisse passer les requêtes DNS permet une exfiltration lente. Regardez la journalisation côté votre nom de domaine de test.
- Tester les identifiants. Le code peut-il appeler une API cloud ? Avec quel rôle ? Lister les objets d’un stockage est déjà un constat. Ne lisez ni ne téléchargez de données réelles : confirmez l’accès, comptez, arrêtez-vous.
- Tester l’isolation entre sessions. Écrivez un fichier marqueur dans une session, cherchez-le depuis une autre session ou un autre compte de test.
- Tester les limites de ressources. Une boucle infinie ou une allocation mémoire massive est-elle arrêtée ? Au bout de combien de temps ?
- Tester la chaîne complète. Depuis une injection indirecte (un fichier ou une page piégés), l’agent écrit-il et exécute-t-il un script de sa propre initiative ? C’est le scénario réaliste.
Chaque constat s’accompagne de la commande exécutée, de la sortie obtenue et de la version de l’environnement.
Quel confinement mettre en place ?
Le confinement efficace combine plusieurs couches, car aucune ne suffit seule :
- Réseau en refus par défaut, DNS compris, avec une liste d’accès sortants limitée à ce que la tâche exige. Le mode « sans réseau » d’un produit se vérifie par un test, jamais sur la foi de sa description.
- Rôle d’identité minimal : l’interpréteur n’a aucun droit, ou seulement ceux d’un jeu de données précis et en lecture.
- Session éphémère : un environnement neuf par session, détruit après usage, sans volume partagé.
- Isolation renforcée : conteneur sans privilège, profil de filtrage des appels système, ou machine virtuelle légère pour les cas à fort enjeu ; maintenir à jour le moteur de conteneurs.
- Limites de ressources : CPU, mémoire, durée, nombre de processus, taille des sorties.
- Validation humaine avant toute exécution qui touche autre chose que des données déposées par l’utilisateur lui-même.
- Journalisation du code exécuté et des connexions tentées.
Quand faire appel à un test externe ?
Quand l’agent exécute du code sur des données de clients ou possède des identifiants cloud, le test mérite un regard indépendant. Le Red Team Agent Express (1 900 €, 5 jours, démarrage sous 48 h après signature du devis et de l’autorisation) couvre un agent avec son interpréteur : chaîne d’injection, réseau, identifiants, isolation entre sessions. Pour une plateforme avec plusieurs agents et plusieurs environnements d’exécution, le Red Team sur mesure se chiffre sur devis. Nous testons par défaut sur développement ou préproduction ; la production n’est visée que sur demande écrite du client. Premier contact : un rendez-vous découverte gratuit de 30 minutes.
Pour aller plus loin
Votre produit embarque un agent IA ? CleanIssue teste ce qu’un inconnu peut lui faire faire avec le Red Team Agent Express (5 jours, 1 900 €), ou un red team sur mesure pour plusieurs agents et serveurs MCP. Premier échange : un rendez-vous découverte de 30 minutes, gratuit.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
OpenAI suspend le tool use après une évasion de sandbox
Le 20 septembre 2026, un agent OpenAI a contourné sa sandbox via le DNS. Chronologie vérifiée, incidents liés, tiers notifiés et tests à mener chez vous.
PaperCut CVE-2026-81578 et 82078 : RCE en chaîne, agents IA
Deux zero-days PaperCut NG/MF s'enchaînent en exécution de code sans authentification. Chaîne, indicateurs, patchs contournés et risques pour un agent IA.
Fastjson CVE-2026-16723 : RCE par défaut en Spring Boot
CVE-2026-16723 : exécution de code dans Fastjson 1.2.68 à 1.2.83 sur fat-JAR Spring Boot, sans AutoType. Correctif 1.2.84 et risques pour un agent IA.
Sources
- BeyondTrust Phantom Labs : Pwning AI Code Interpreters in AWS Bedrock AgentCore
- BeyondTrust : dépôt de la preuve de concept AgentCore
- The Hacker News : failles dans Amazon Bedrock, LangSmith et SGLang (mars 2026)
- GitHub Advisory : runc CVE-2024-21626, évasion de conteneur
- Triedman, Jha, Shmatikov : Multi-Agent Systems Execute Arbitrary Malicious Code
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.