Le 19 août 2026, Simon Willison a chargé Claude (Fable 5, dans Claude Code for web) d'une mission précise : mettre smolmachines à l'épreuve comme sandbox pour exécuter du code Python et JavaScript non fiable, avec des garanties dures sur le CPU, la RAM, le réseau et le système de fichiers. Le produit repose sur des microVM légères (via libkrun) plutôt que sur des conteneurs — et les chiffres obtenus rebattent un arbitrage qu'on pensait tranché depuis longtemps.
L'arbitrage qu'on croyait définitif
Sandboxer les tool calls posait trois couches pour contenir ce qu'un agent a le droit de faire une fois qu'il a décidé d'appeler un tool : dispatch fermé, validation du schéma, isolation par process via proc_open. Cette troisième couche part d'une hypothèse implicite : le tool isolé tourne sur le même noyau que le process principal, juste avec moins de droits. Ça suffit pour une commande shell ou un script interne. Ça ne suffit plus dès que le code exécuté est directement fourni ou généré par le LLM, potentiellement sur instruction d'un contenu externe non maîtrisé — le scénario que couvrait déjà la défense contre l'injection de prompt côté lecture.
La solution la plus stricte a toujours existé : une vraie VM, avec son propre noyau, ne partageant rien avec l'hôte. Le problème, c'était le prix — plusieurs secondes de démarrage, incompatibles avec une boucle agentique qui peut appeler un tool d'exécution de code plusieurs fois par conversation. D'où le choix par défaut des conteneurs : isolation partielle (namespaces, cgroups), démarrage rapide, mais un noyau partagé qui reste une surface d'attaque commune.
| Isolation | Noyau partagé | Démarrage | Cas d'usage typique |
|---|---|---|---|
| Dispatch fermé + validation | — | immédiat | tool à arguments structurés (API, requête préparée) |
Process isolé (proc_open) | Oui | quelques ms | commande ou script interne de confiance modérée |
| Conteneur (Docker, gVisor) | Oui (partiel pour gVisor) | ~100-300 ms | code applicatif isolé, CI |
| MicroVM (libkrun, Firecracker) | Non | 0,6-1,5 s à froid / ~50 ms à chaud | code arbitraire non fiable, généré par un LLM |
Le chiffre qui change la donne
C'est là que les résultats obtenus par l'agent de Simon Willison sont notables : démarrage à froid entre 0,6 et 1,5 seconde, et surtout un démarrage à chaud autour de 50 millisecondes. Toutes les protections annoncées ont tenu — limites CPU/RAM effectives, blocage d'une boucle infinie, absence de réseau, montages en lecture seule pour les entrées. Ce n'est plus la latence d'une VM classique : c'est un ordre de grandeur qui se rapproche du conteneur, sans en partager le noyau.
Concrètement, ça déplace la ligne de décision. Un tool « exécute ce code » n'a plus besoin de choisir entre isolation forte et réactivité — l'argument qui justifiait de rester au niveau conteneur pour tout ce qui n'était pas un batch offline perd de sa force.
Le test a buté sur son propre sujet
Le détail le plus intéressant n'est pas dans les chiffres, il est dans la méthode. Claude Code, l'environnement depuis lequel tournait l'agent chargé de tester smolvm, tourne lui-même dans un guest Firecracker — et ce guest-là ne supporte pas la virtualisation imbriquée : impossible d'y lancer une seconde microVM. Pour mener le test à bien, l'agent est allé chercher un environnement disposant d'un accès réel à /dev/kvm : un run GitHub Actions, monté à la volée comme banc d'essai temporaire.
Rien de malveillant ici — c'est exactement la tâche demandée, menée avec ingéniosité. Mais le réflexe mérite d'être noté pour quiconque conçoit des agents avec une vraie autonomie : un agent qui ne peut pas faire X dans son environnement courant peut se mettre, de sa propre initiative, à chercher un environnement où X devient possible. C'est bénin quand l'objectif est légitime et le résultat vérifiable. C'est précisément le genre de comportement qu'on veut pouvoir observer après coup — la même exigence de traçabilité que celle posée dans l'observabilité d'un agent : savoir qu'un agent a changé d'environnement d'exécution en cours de tâche, et pourquoi.
Ce que ça change concrètement
Pour un agent qui expose un tool « code interpreter » — exécuter un script Python fourni par le modèle pour transformer des données, par exemple — la microVM devient l'option par défaut plutôt qu'un luxe réservé aux environnements offline. Ça ne remplace pas les couches amont : dispatch fermé et validation du schéma restent nécessaires avant même de savoir dans quoi le code va tourner, exactement comme le pose l'article sur le sandboxing des tool calls. Ce qui change, c'est que la couche d'isolation la plus stricte n'a plus le coût qui la réservait aux cas exceptionnels.
Ça reste un composant à orchestrer depuis l'extérieur d'un process PHP classique — une microVM comme smolvm se pilote comme un service à part, pas comme une bibliothèque à inclure. Le tool PHP garde son rôle : valider, dispatcher, puis déléguer l'exécution effective à cette brique externe quand le code à faire tourner ne vient pas de l'auteur.
FAQ
Une microVM remplace-t-elle l'isolation par process décrite pour les tool calls ?
Non, elle s'ajoute pour un cas plus dur : un tool qui exécute du code non fiable, potentiellement issu d'un contenu externe. Dispatch fermé et validation du schéma restent nécessaires en amont, quelle que soit la couche d'exécution choisie ensuite.
Qu'est-ce qui distingue une microVM d'un conteneur classique ?
Le conteneur partage le noyau de l'hôte via des namespaces ; la microVM démarre son propre noyau minimal dans une VM légère (technologies libkrun ou Firecracker par exemple). L'isolation est plus forte, au prix d'un démarrage historiquement plus lent — écart que des solutions comme smolvm réduisent fortement.
Un agent qui change d'environnement pour finir une tâche est-il un problème de sécurité ?
Pas en soi si l'objectif est légitime et le résultat vérifiable, comme dans ce test. Mais c'est un comportement à tracer explicitement : un agent capable de chercher un environnement plus privilégié doit rester observable, pour distinguer un contournement utile d'une dérive.
