Retour au blog
sandboxcode interpreterévasionagents IA

Sandbox d’agent IA : évasion, réseau et tests

Publié le 2026-11-047 min de lecture
En bref : Un code interpreter laisse un agent écrire et exécuter du code, donc la sandbox devient la dernière barrière entre une injection de prompt et vos systèmes. Les quatre points à vérifier sont l’accès réseau (y compris DNS), les identifiants accessibles depuis la sandbox, le système de fichiers et la frontière du conteneur. Un cas public récent montre qu’un mode « sandbox » sans accès réseau annoncé peut encore laisser passer des requêtes DNS.

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 ?

VoieCe que ça permetContrôle à tester
Réseau sortant (HTTP, DNS, autres protocoles)Exfiltrer des données, joindre un serveur de commandePolitique réseau en refus par défaut, DNS filtré
Identifiants de l’environnementAppeler des API cloud avec le rôle de l’interpréteurRôle sans droit, aucune variable secrète en clair
Service de métadonnées cloudRécupérer des jetons temporairesAccès bloqué depuis la sandbox
Système de fichiers partagéLire les fichiers d’autres sessions ou clientsVolume propre à chaque session, effacé à la fin
Frontière du conteneurÉvasion vers l’hôteMoteur à jour, profils de confinement, utilisateur sans privilège
RessourcesDéni de service, minageLimites de CPU, mémoire, durée, processus
Installation de paquetsCode tiers malveillant ou hallucination de paquetDépôt interne ou liste blanche
Sorties de l’exécutionRendu de contenu piégé dans l’interfaceTraitement 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.

  1. 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é.
  2. 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.
  3. 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.
  4. Tester l’isolation entre sessions. Écrivez un fichier marqueur dans une session, cherchez-le depuis une autre session ou un autre compte de test.
  5. 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 ?
  6. 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.

Sachez ce que votre agent peut faire avant un attaquant.

Rendez-vous découverte de 30 minutes, gratuit : vous décrivez votre agent, je vous dis ce que je testerais et à quel prix. Cinq études de cas sont publiées.

Prendre rendez-vous