Comment enfermer le code d'un agent IA : subprocess, Docker et microVM, trois niveaux de protection

Vous avez donné à votre agent un outil « exécuter du code Python » : à cet instant, vous n'avez plus seulement un assistant, mais un système d'exécution de code à distance, même s'il agit à la demande du modèle. Le modèle peut se tromper, ou recevoir une instruction malveillante glissée dans une page ou un fichier. La question n'est donc pas de savoir si l'agent est intelligent, mais ce qu'un programme malveillant pourra atteindre une fois lancé. Les auteurs de l'analyse publiée sur Machine Learning Mastery y répondent de façon pratique : ils construisent trois bacs à sable et leur font subir les mêmes attaques.

Un seul outil, des backends interchangeables

L'architecture est simple. L'agent ne connaît qu'un outil, run_python : il prend une chaîne de code et renvoie stdout, stderr et le code de sortie. Le code du modèle n'est jamais exécuté dans le processus de l'agent lui-même. Il est envoyé à un objet de bac à sable doté d'une méthode run(code), et toute classe disposant de cette méthode convient. Changer de niveau d'isolation n'exige donc pas de toucher à la logique de l'agent : il suffit de remplacer le backend. Un code de retour non nul est signalé comme une erreur ; le modèle le voit et peut se corriger.

Un principe important issu du blog de Docker, que les auteurs appliquent à tous les niveaux : l'accès aux fichiers, la politique réseau et les secrets sont définis par l'infrastructure avant le lancement de l'agent, et non par l'agent lui-même.

Trois frontières

Subprocess est l'option la plus légère. Il s'agit d'un processus enfant soumis à des limites de temps processeur, de mémoire (espace d'adressage) et de taille des fichiers écrits. Autour de lui :

• lancement en mode isolé python -I dans un dossier temporaire ;
• environnement vierge, sans clés API ni répertoire personnel ;
• unshare --net, soit un réseau privé et vide ;
• sortie redirigée vers des fichiers, afin que la limite de taille de fichier protège aussi contre un flot de print ;
• en cas de dépassement du délai, tout le groupe de processus est tué.

Si le constructeur ne peut pas activer l'isolation réseau, il échoue avec une erreur au lieu de laisser silencieusement le réseau ouvert. Sous root, le code est d'abord rétrogradé à l'utilisateur nobody.

Mais ce niveau comporte une réserve honnête : le noyau et le système de fichiers restent ceux de l'hôte. Le code s'exécute en votre nom sur votre système de fichiers et ne cache pas vos fichiers. La limite du nombre de processus compte tous les processus de l'utilisateur ; elle n'a donc de sens que pour un utilisateur dédié, et sur un ordinateur portable ordinaire elle est ignorée.

Le conteneur Docker ajoute des espaces de noms et des cgroups, mais il s'agit toujours de processus tournant sur le noyau de l'hôte. La documentation Docker indique clairement que, sans réglages explicites, un conteneur n'a aucune limite de ressources ; le bac à sable fixe donc la mémoire, le nombre de CPU et le nombre de processus (dans l'exemple : 256 Mo, un CPU, 64 pid). Et des évasions se produisent : en novembre 2025, trois vulnérabilités de runc permettaient de sortir du conteneur.

La microVM sur Firecracker (dans l'exemple, via E2B) attribue à chaque bac à sable son propre noyau derrière un hyperviseur. Docker parle de frontière matérielle, et AWS affirme que dans Lambda sur Firecracker, le noyau n'est pas partagé entre les sessions. C'est l'option la plus coûteuse en latence, et elle nécessite un compte E2B avec une clé.

Que faire de tout cela

Les auteurs testent chaque niveau avec les mêmes programmes hostiles : épuisement du CPU, de la mémoire, des processus, du disque, tentatives de lecture de fichiers et d'accès au réseau. Ensuite, dans bench.py, ils mesurent le coût en latence du renforcement de l'isolation. La partie accessible de l'article ne contient pas de chiffres de mesure ; lancez donc le benchmark sur votre propre machine : la latence dépend fortement de l'environnement.

La logique pratique du choix est la suivante :

• Subprocess convient aux expériences locales et au code auquel vous faites presque confiance. Linux ou WSL requis.
• Docker avec des options strictes convient aux outils internes où vous acceptez le risque d'évasion.
• MicroVM est le choix pour les entrées tierces non fiables et pour les produits multi-locataires, où une évasion constitue un incident.

Et surtout : ne laissez pas l'agent décider de son propre bac à sable. Les secrets, le réseau et les fichiers sont définis par celui qui déploie l'infrastructure. Si vous préférez une solution prête à l'emploi plutôt qu'un assemblage maison, les auteurs ont un article distinct sur cinq bacs à sable hébergés ; ici, tout est monté à la main pour montrer ce que ces plateformes font réellement sous le capot.