AWS a construit un sandbox pour le code généré par IA : les MicroVMs Lambda

Les MicroVMs AWS Lambda sont une nouvelle primitive serverless conçue, selon la propre formulation d'AWS, pour exécuter du code généré par les utilisateurs ou par l'IA dans des environnements isolés et persistants. Ce sont ces derniers mots qu'il faut remarquer. Le lancement ne porte pas vraiment sur les fonctions. Il s'agit de donner à un agent IA un endroit sûr pour exécuter le code qu'il vient d'écrire, et le fait qu'AWS ait mis en avant « les utilisateurs ou l'IA » vous indique à qui cela s'adresse.

Si vous construisez des agents, vous avez déjà rencontré ce mur. Le modèle écrit du code, et il faut ensuite l'exécuter quelque part. Exécuter du code non fiable, généré par un modèle, sur votre propre infrastructure, c'est la partie que tout le monde sous-estime, et c'est précisément la partie que les MicroVMs sont conçues pour vous décharger.

Le problème de sandbox que les agents ont vraiment

Un agent capable ne se contente pas de répondre. Il écrit un script, l'exécute, lit le résultat et itère. Les code interpreters, les agents d'analyse de données et les outils de codage autonomes vivent ou meurent tous selon une seule question : où ce code s'exécute-t-il ?

Les réponses naïves sont toutes mauvaises. Exécutez-le dans le processus de votre application et une seule génération hostile ou boguée peut faire tomber l'hôte ou lire les données d'un autre utilisateur. Exécutez-le dans un conteneur partagé et vous êtes à un exploit de noyau d'une fuite inter-tenant, car les conteneurs partagent un noyau. Construisez votre propre flotte de VM et vous venez de vous engager à exploiter l'infrastructure la plus difficile et la moins différenciante de votre stack. Le code généré par un modèle est par définition du code non fiable. Il a besoin d'une véritable frontière d'isolation, pas d'une frontière de courtoisie.

Pourquoi les MicroVMs collent à la forme agentique

Les MicroVMs Lambda s'alignent sur la façon dont les agents se comportent réellement, sur trois axes.

Une isolation qui tient face à une sortie hostile

Chaque session s'exécute dans sa propre MicroVM Firecracker : pas de noyau partagé, pas de ressources partagées, aucun chemin d'un environnement vers un autre ni vers l'hôte. Quand votre agent exécute du code qu'un modèle de langage a produit à partir du prompt d'un utilisateur, c'est la frontière que vous voulez entre « l'agent a fait quelque chose de bizarre » et « l'agent a compromis la plateforme ». Un agent victime de prompt injection qui décide d'exfiltrer ou de détruire reste confiné à une VM jetable.

Un état qui correspond à une tâche multi-étapes

Le travail d'un agent est rarement en une seule passe. Il installe un paquet, charge un jeu de données, écrit des fichiers intermédiaires et y revient trois étapes plus tard. Une MicroVM conserve la mémoire, le disque et les processus en cours d'exécution tout au long de la session, et peut se suspendre avec cet état intact pendant les longues pauses où le modèle réfléchit ou l'utilisateur s'éloigne, puis reprendre quasi instantanément. Les modèles chargés et les jeux de fichiers de travail sont tout simplement toujours là. C'est un bien meilleur ajustement que de réamorcer un conteneur neuf à chaque appel d'outil.

Un démarrage assez rapide pour donner une impression interactive

Parce que chaque MicroVM reprend à partir d'un snapshot Firecracker pré-initialisé au lieu d'un démarrage à froid, même une session de plusieurs gigaoctets revient rapidement. Pour un agent interactif où un humain regarde le curseur clignoter, la différence entre une reprise depuis snapshot et un démarrage de conteneur à froid est la différence entre utilisable et abandonné. Les sessions peuvent durer jusqu'à 8 heures, ce qui couvre confortablement une longue analyse ou une session de codage qui s'étire.

AWS construit toute la boucle de l'agent, pas seulement le runtime

Le lancement des MicroVMs n'est pas arrivé seul. AWS a également livré un guide de configuration d'agent qui relie les agents de codage, Claude Code, Codex, Cursor, Kiro, Copilot, Windsurf, OpenCode, au développement serverless via des plugins, des agent skills et un MCP Server. Lisez les deux ensemble et la stratégie est claire : les agents vous aident à construire l'application serverless, et les MicroVMs sont là où le code que ces agents génèrent peut s'exécuter en toute sécurité. AWS essaie de posséder les deux bouts de la boucle, l'agent qui écrit et le sandbox qui exécute.

Ce que cela ne résout pas

L'isolation est une frontière, pas un cerveau. Une MicroVM empêche le code généré par un modèle de s'échapper de son sandbox. Elle ne fait rien pour empêcher l'agent de faire quelque chose de stupide mais autorisé à l'intérieur de la boîte, ni d'être doté d'identifiants qui laissent le rayon d'impact s'étendre au-delà. Si vous montez de vrais secrets ou confiez au sandbox un rôle IAM trop large, la frontière de la VM n'a aucune incidence sur les dégâts qu'un prompt injecté peut causer via des appels d'API légitimes. Limitez ce que le sandbox peut atteindre aussi strictement que vous l'isolez. Le runtime est la moitié facile ; le moindre privilège pour l'agent reste à votre charge.

À retenir

Pendant l'essentiel du boom agentique, la question du runtime, où le code généré s'exécute-t-il réellement, a été réglée à coups de rustines : un conteneur ici, un processus verrouillé là, un pool de VM maison pour les équipes qui en avaient les moyens. Les MicroVMs Lambda transforment cela en une primitive managée avec isolation au niveau de la VM, sessions persistantes et reprise à la vitesse d'un snapshot, exposée comme un appel d'API. Cela ne rend pas votre agent plus intelligent ni plus sûr dans ce qu'il décide de faire. Cela donne bien au code qu'il écrit un endroit pour s'exécuter qui ne peut pas faire tomber tout ce qui l'entoure, et pour les agents en production, c'était la pièce manquante.

Références

agent setup guide