Un agent d’IA qui écrit et exécute son propre code n’est sûr que dans la mesure où l’environnement dans lequel ce code tourne l’est. Dans un tutoriel publié par Machine Learning Mastery, l’auteur montre comment isoler ce code selon trois niveaux, un sous-processus limité, un conteneur Docker durci et une microVM Firecracker, puis compare leur sécurité et leur latence.
- Un agent qui exécute son propre code doit être isolé.
- Le sous-processus laisse passer le fork flood et la lecture des faux identifiants.
- Une microVM donne à chaque environnement son propre noyau.
- Le choix du niveau dépend de la confiance accordée au code et des enjeux.
Le sous-processus est le niveau le plus léger : il s’agit d’un processus enfant dont le temps de calcul, la mémoire et la taille des fichiers sont limités, mais qui partage le noyau et les fichiers de la machine hôte. Un conteneur ajoute des espaces de noms et des groupes de contrôle (cgroups), mais reste un ensemble de processus sur le noyau de l’hôte. L’article rappelle qu’en novembre 2025, trois vulnérabilités du moteur d’exécution runc ont permis à des attaquants de sortir de conteneurs. Une microVM, elle, donne à chaque environnement son propre noyau, derrière un hyperviseur, le logiciel qui fait tourner des machines virtuelles.
Le dispositif repose sur un seul outil, run_python, mis à la disposition de l’agent. Chaque code produit par le modèle passe par un objet « sandbox » doté d’une méthode run(code), de sorte que changer de niveau d’isolation ne modifie pas l’agent. Le tutoriel nécessite Python 3.10 ou plus récent, un système Linux ou WSL pour le niveau sous-processus, Docker pour le conteneur, et un compte ainsi qu’une clé d’API E2B pour la microVM. Une clé d’API Anthropic est utile pour l’agent, mais peut être évitée pour les tests.
Six attaques identiques contre chaque niveau
Pour comparer les trois niveaux, les mêmes six programmes hostiles sont exécutés : une boucle infinie, une allocation de 512 Mo de mémoire, un « fork flood » de 200 processus, l’écriture d’un fichier de 50 Mo, la lecture d’un faux fichier d’identifiants et la connexion à un faux service interne. Une attaque est considérée comme bloquée lorsque le mot-témoin n’apparaît pas dans la sortie, ou, pour la boucle infinie, lorsque l’exécution expire.
Sur le niveau sous-processus, exécuté avec un utilisateur Linux classique, quatre attaques sont bloquées et deux passent. La limite de processus ne s’applique qu’à un utilisateur dédié, si bien que le fork flood est autorisé, et le fichier de faux identifiants reste lisible parce que le code s’exécute sous l’identité de l’utilisateur. L’auteur en tire la conclusion que ce niveau convient surtout à du code en qui l’on a confiance.
Pour le conteneur Docker, l’auteur indique que, avec les options choisies, Docker devrait bloquer les six attaques, puisque le conteneur n’a pas de réseau, que son système de fichiers ne contient pas les fichiers de l’utilisateur et que les limites de mémoire, de processus et de disque s’appliquent. Dans une microVM, les attaques sur la mémoire, les processus et le disque peuvent atteindre les limites de la machine virtuelle, mais elles restent confinées à celle-ci, et le fichier secret comme le service local n’y existent pas.
Latence et choix du niveau
Le sous-processus doit être le plus rapide, puisqu’il ne fait que lancer Python. Pour les deux autres niveaux, l’auteur précise que les chiffres publiés sont des affirmations et non des garanties : un article cité indique qu’E2B démarre en environ 150 ms, tandis qu’AWS et Docker décrivent des lancements quasi instantanés pour leurs produits de microVM. Le script bench.py permet de mesurer, sur sa propre machine, la médiane et le temps le plus long sur dix exécutions d’un programme print(1).
L’auteur recommande de réserver le sous-processus au code de confiance, comme les scripts de développement personnels, et le conteneur durci aux cas où l’on contrôle l’hôte et où les enjeux sont faibles, en veillant à maintenir runc à jour. La microVM s’impose pour du code venant de plusieurs utilisateurs, pour tout ce qui touche à des secrets, et lorsque l’agent doit construire et exécuter lui-même des conteneurs, ce que les conteneurs classiques gèrent mal, selon Docker. Docker a lancé ses Docker Sandboxes sur microVM en avril 2026, et AWS propose des Lambda MicroVMs qui conservent leur état jusqu’à 8 heures et se suspendent lorsqu’ils sont inactifs. Selon Docker, les fichiers, les règles réseau et les secrets doivent être définis par l’infrastructure, et non par l’agent, avant son exécution.
