Les sandboxes de Modal : donner à un agent une machine à casser

Donner à un agent IA la capacité d'exécuter du code est facile. Lui donner un endroit sûr pour le faire ne l'est pas. Le 1er octobre 2026, Modal Labs a publié des sandboxes VM complètes pour agents, donnant à chacun un ordinateur entier pour exécuter du code et des outils sans toucher à ce qu'il ne devrait pas. C'est une sortie d'infrastructure, pas de modèle, et elle traite un des problèmes les plus tenaces de l'histoire des agents.

Le problème est simple à énoncer. Un agent qui ne fait que parler est inoffensif. Un agent qui peut agir a besoin d'un endroit pour agir, et les endroits où il pourrait agir, de la base de production à la machine du développeur, sont exactement ceux qu'on ne peut pas laisser casser. Les sandboxes tentent de résoudre cela en donnant à l'agent un monde jetable où une erreur ne coûte qu'un redémarrage.

Pourquoi un conteneur ne suffit pas toujours

La plupart des runtimes d'agents isolent déjà le code, souvent dans un conteneur. Les conteneurs empêchent bien un agent de sortir de sa boîte, mais ils partagent le noyau avec l'hôte et peuvent fuir d'une manière qui compte quand le contenu est imprévisible. Une VM complète est plus lourde mais plus stricte : l'agent obtient son propre système, son propre système de fichiers et sa propre vue réseau, et l'isolation tient à un niveau inférieur.

Pour un agent qui fait un travail ordinaire, la différence peut ne jamais apparaître. Pour un agent qui exécute du code généré, récupère sur internet ou installe des dépendances, la différence est tout l'intérêt. Le sandbox n'est pas là pour rendre l'agent plus rapide, mais pour que, quand l'agent fait quelque chose d'inattendu, le rayon d'explosion soit une seule machine jetable.

{{INLINE1}}

La tendance derrière la sortie

Le timing de Modal reflète un virage plus large. Les agents sont passés des démos aux pipelines, et une fois dans un pipeline, ils obtiennent de vraies permissions. Dès qu'un agent détient des identifiants, la question de l'endroit où il tourne devient une question de sécurité, pas de commodité. C'est pourquoi les derniers mois ont produit un flot régulier d'outils de sandbox, de permissions et de gouvernance. L'industrie construit les parties ennuyeuses qui rendent les agents déployables.

Il y a une ironie à nommer. Le modèle fait les gros titres, mais les couches qui décident si les agents sont fiables sont faites d'ingénierie ordinaire. Des systèmes de mémoire qui gardent le contexte entre sessions, des sandboxes qui contiennent les erreurs, des protocoles de consentement qui enregistrent ce à quoi un utilisateur a consenti : rien de cela n'impressionne en démo, et tout cela sépare un jouet d'une chose qu'une entreprise fera vraiment tourner.

Ce qu'il faut demander avant d'adopter un sandbox

Tous les sandboxes ne se valent pas, et les questions sont pratiques. À quelle vitesse un démarre-t-il, car un démarrage lent transforme chaque appel d'agent en attente. À quoi l'agent peut-il accéder, et peut-on le verrouiller par tâche. Que devient l'état à la fin du travail, et combien est journalisé. Résiste-t-il de façon fiable au code non fiable, ou est-il réglé pour des scripts bien élevés. Les réponses décident si le sandbox est une vraie frontière ou une formalité.

Les sandboxes les plus solides supposent que le code à l'intérieur sera hostile ou cassé, et sont conçues pour qu'aucun des deux ne s'échappe. C'est un objectif différent d'un environnement de développement fait pour être manipulé. Pour le travail d'agents, l'hypothèse d'hostilité est la bonne, car le code généré est imprévisible par nature et les agents prennent leurs instructions à des sources que vous ne contrôlez pas totalement.

Comment cela s'intègre au reste de la pile

Un sandbox est une pièce d'un argument plus large sur l'infrastructure d'agents. Un agent a besoin de mémoire pour reprendre où il s'est arrêté, de permissions pour ne toucher que ce qu'il devrait, et d'un endroit où tourner pour que ses erreurs restent contenues. Chacun est un sujet distinct, et chacun a produit sa vague d'outils cette année. Le sandbox est la pièce du confinement, d'autant plus importante que les agents gagnent en autonomie.

C'est la ligne de tendance. Les premiers agents avançaient pas à pas avec un humain approuvant chaque mouvement. La direction est vers des agents qui tournent plus longtemps, agissent davantage et demandent moins de surveillance. Plus un agent est autonome, plus il a besoin d'une frontière qui ne dépend pas d'un humain qui le rattrape. Une VM complète est un outil plus lourd qu'un conteneur, et la raison de payer ce poids est précisément de cesser de dépendre de la surveillance.

Il y a aussi une dimension de coût rarement discutée. Les sandboxes rendent l'essai bon marché, pas seulement sûr. Un agent qui peut lancer une machine neuve, la casser et la jeter traite l'échec comme gratuit. Cela change sa façon de travailler : plus expérimental, testant plus d'approches, se relevant d'impasses sans qu'un humain nettoie. Confinement et expérimentation sont la même fonctionnalité vue sous deux angles.

Un test pour tout sandbox

Avant d'adopter, faites une expérience simple. Donnez à l'agent une tâche qui exige d'installer un paquet inconnu, de récupérer sur internet et d'écrire sur disque. Regardez ensuite ce que le sandbox peut voir. Peut-il atteindre votre réseau interne par accident. Un job planté laisse-t-il quelque chose. Combien de temps met une instance neuve à démarrer. Ces questions se répondent vite et révèlent si l'isolation est réelle ou cosmétique.

Puis cassez-le exprès. Nourrissez le sandbox de code qui tente de s'échapper, qui lance des processus d'arrière-plan, qui tourne en boucle. Un bon sandbox traite tout cela comme attendu et le contient. Un faible va se bloquer, fuir ou tomber. La volonté de tester ainsi est en soi la marque des équipes qui prennent la sécurité des agents au sérieux, et c'est bien moins cher que de découvrir les limites en production.

Pourquoi cela compte plus qu'il n'y paraît

Le goulot d'étranglement des agents utiles est passé de l'intelligence à la confiance. Les modèles sont assez capables pour beaucoup de tâches réelles, et s'ils n'en font pas plus, c'est que les gens ne sont pas à l'aise à l'idée de remettre les clés. Les sandboxes sont un des outils qui changent ce niveau de confort, car ils permettent à un opérateur prudent de lancer un agent dans un mode où le pire cas est contenu.

Des sorties comme celle-ci ne feront jamais la une. Elles sont la plomberie qui détermine si les démos ambitieuses d'agents de l'année passée deviennent des choses qui tournent un mardi sans que personne regarde. Si vous construisez avec des agents, c'est la couche où investir votre attention, car l'agent qui ne peut pas être contenu ne sera pas cru, et l'agent qui n'est pas cru ne sera pas déployé.