Sandboxes open source pour agents IA : exécuter le code généré sans casser la machine
Un agent IA qui écrit puis exécute du code, c’est puissant : il peut analyser un fichier, lancer un script, appeler une API, corriger son propre résultat. C’est aussi la première porte d’entrée vers la catastrophe : un rm -rf bien placé, une fuite de secrets, un appel sortant non contrôlé. La parade éprouvée se nomme sandbox : un environnement d’exécution isolé, jetable, sans accès au système hôte, dans lequel l’agent peut faire ses essais sans rien casser. Plusieurs briques open source permettent aujourd’hui de bâtir cette couche d’isolation soi-même, sans dépendre d’un service propriétaire.
Pourquoi sandboxer un agent IA
Dès qu’un LLM produit du code à exécuter (Python, Bash, SQL, JavaScript), trois risques apparaissent en même temps. Premièrement, le risque destructif : suppression de fichiers, écrasement de bases, modification de configuration. Deuxièmement, le risque d’exfiltration : lecture de variables d’environnement, de tokens, de fichiers sensibles, puis envoi vers un domaine externe. Troisièmement, le risque de saturation : boucle infinie, fork bomb, consommation mémoire, qui fige la machine. Un sandbox bien configuré coupe les trois en isolant le système de fichiers, le réseau, les ressources CPU et mémoire, et la durée d’exécution.
Les briques open source à connaître
Côté isolation forte, deux technologies dominent. Firecracker, microVM développée par AWS et publiée sous Apache 2.0, démarre une machine virtuelle en moins de 125 ms avec une empreinte mémoire de quelques mégaoctets : c’est ce qui propulse Lambda et Fargate, et c’est l’isolation la plus stricte disponible aujourd’hui. gVisor, runtime Google publié sous Apache 2.0, intercepte les appels système d’un conteneur via un noyau utilisateur écrit en Go : moins strict qu’une VM mais beaucoup plus léger qu’une VM classique.
Côté plateformes prêtes à intégrer dans un agent, plusieurs projets open source apportent une API simple. microsandbox (Apache 2.0) lance des microVM Firecracker à la demande, avec un SDK Python et Node, pensé pour les workflows agentiques. Daytona (AGPL) propose des workspaces de développement isolés, scriptables via API, utilisables comme sandbox d’agent. Codapi (MIT) exécute des extraits de code dans des conteneurs Podman jetables, idéal pour évaluer du code avec quotas par requête.
Côté minimal et auto-hébergé, on peut aussi composer une solution maison avec nsjail ou bubblewrap (utilisé par Flatpak), qui s’appuient sur les namespaces Linux et seccomp pour confiner un processus en quelques lignes de configuration : pas de dépendance lourde, pas de démon, parfait pour intégrer dans un binaire d’agent.
Critères pour choisir
Le bon choix dépend de trois variables : niveau de menace acceptable, latence de démarrage tolérée, et volume d’exécutions concurrentes. Pour des agents qui exécutent du code utilisateur non maîtrisé en SaaS multi-tenant, la microVM Firecracker reste la référence, au prix d’une plomberie d’orchestration plus lourde. Pour un agent interne qui exécute son propre code généré, gVisor ou un conteneur Podman avec seccomp et profil AppArmor bien serré couvrent l’essentiel des risques avec une intégration triviale. Pour des micro-évaluations à très haute fréquence, nsjail est imbattable en latence.
Ce qu’il faut câbler dans tous les cas
Quel que soit le moteur retenu, certains réglages sont non-négociables : couper le réseau sortant par défaut (puis ouvrir explicitement les domaines autorisés via une liste blanche), monter un système de fichiers en lecture seule sauf pour un répertoire de travail jetable, fixer une limite mémoire et CPU stricte, imposer un timeout d’exécution global, supprimer toutes les variables d’environnement sauf celles strictement nécessaires, et journaliser systématiquement l’entrée et la sortie de chaque exécution pour audit.
Pour aller plus loin
Une fois la couche sandbox en place, deux compléments naturels : un proxy egress, type Squid ou Pomerium, qui filtre les appels HTTP sortants par domaine et règle d’authentification, et un système de policy déclaratif type Open Policy Agent (OPA) pour décider à l’exécution si une action est autorisée selon le contexte, l’utilisateur, l’agent et l’historique. L’isolation devient alors une fonction de sécurité multi-couches, pas un simple enfermement de processus.
Bâtir sa propre couche sandbox, c’est reprendre la main sur un sujet trop souvent traité comme une boîte noire propriétaire. Tout existe en open source, tout se compose, tout s’audite : c’est exactement la promesse que devrait tenir une infrastructure d’agents IA digne de production.
#note : tester OpenSVC dans ce contexte.
