Anthropic Simon a testé smolvm, mais le sandbox a toujours besoin d'un plan de contrôle

Le chercheur d'Anthropic Simon Willison a testé smolvm face à un objectif exigeant : exécuter en toute sécurité du Python et du JavaScript non fiables, sans abus du réseau, du système de fichiers ni des ressources. L'expérience s'est heurtée à un conflit immédiat. Claude Code for web s'exécutait dans un invité Firecracker, tandis que smolvm nécessitait un accès à la virtualisation matérielle que l'invité n'exposait pas.

Cet échec n'a pas montré que smolvm était peu sûr. Il a montré que l'évaluation d'une microVM à l'intérieur d'une autre machine virtuelle restreinte peut échouer avant même que les tests de sécurité ne commencent. Cette distinction importe pour les équipes qui envisagent des scripts fournis par les utilisateurs, des programmes générés par IA ou des transformations de données automatisées.

Les notes de recherche sur le sandbox révèlent également une lacune d'ingénierie plus large. Une frontière de machine virtuelle robuste n'est qu'un élément d'un service d'exécution de code sûr. Les opérateurs ont toujours besoin, autour de cette frontière, de délais d'expiration, d'une comptabilisation des ressources, d'une préparation des fichiers, de contrôles des sorties, d'une supervision et d'un nettoyage.

smolvm offre plusieurs éléments utiles. Le réseau est désactivé par défaut, les charges de travail reçoivent des noyaux invités distincts, et les valeurs de CPU et de mémoire sont configurables. Pourtant, ces fonctionnalités ne créent pas automatiquement un service de production pour du code hostile.

Le véritable enjeu n'oppose donc pas smolvm à Docker, ni Python à JavaScript. Il oppose la promesse d'une isolation en une commande aux contrôles opérationnels nécessaires pour une exécution multi-utilisateur fiable.

Le test a échoué avant l'exécution du code non fiable

Le premier résultat était un échec de compatibilité d'environnement, et non une évasion du sandbox ou une limite de ressources défaillante.

Willison a demandé à un modèle Anthropic opérant via Claude Code for web d'étudier smolmachines comme sandbox rapide. La charge de travail proposée était concrète : exécuter du code fourni par des utilisateurs pour des tâches telles que la transformation de données structurées.

Ce code nécessitait des limites strictes. Il ne devait voir aucun réseau, accéder uniquement à des fichiers désignés, consommer une quantité limitée de mémoire et s'arrêter après un intervalle défini par l'opérateur. Une boucle infinie, telle que while true, ne devait pas monopoliser indéfiniment les ressources de calcul.

Le modèle pouvait étudier le projet et concevoir des tests. Il ne pouvait pas démarrer les machines smolvm nécessaires pour les exécuter. Selon le récit de Willison, l'environnement Claude Code était déjà un invité Firecracker exécutant Linux.

smolvm utilise la virtualisation assistée matériellement par l'intermédiaire d'hyperviseurs propres à chaque plateforme. Sous Linux, cela signifie normalement KVM, l'interface du noyau qui expose les fonctions de virtualisation du processeur à un moniteur de machine virtuelle. Un invité cloud restreint ne dispose souvent pas du périphérique /dev/kvm nécessaire pour lancer un autre invité accéléré matériellement.

C'est le problème de la virtualisation imbriquée. Une machine virtuelle ne peut héberger une autre machine virtuelle que lorsque la plateforme externe expose les fonctions processeur et l'accès aux périphériques nécessaires. De nombreux sandboxes gérés les retiennent délibérément.

Cette limitation crée un paradoxe de test inhabituel. Claude Code for web était isolé en partie parce qu'il s'exécutait dans une microVM. Cette isolation l'a empêché de lancer la microVM différente qu'il devait évaluer.

Aucune charge de travail d'attaque Python ou JavaScript significative n'a atteint smolvm lors de cette tentative. Le test n'a produit aucune mesure indépendante de la latence de démarrage, de l'application des limites mémoire, de la saturation CPU, de l'isolation des fichiers ou du comportement de terminaison.

Ces éléments manquants doivent orienter toute conclusion. Il serait inexact d'affirmer que l'exercice a validé smolvm comme service d'exécution sécurisé. Il serait également inexact de considérer le lancement bloqué comme une preuve contre l'isolation des invités de smolvm.

Le résultat identifie plutôt une condition préalable au déploiement. Une équipe doit exécuter smolvm sur un hôte physique compatible ou une machine virtuelle autorisant la virtualisation imbriquée.

Le modèle de sécurité officiel de smolvm identifie KVM comme backend Linux. Il prend également en charge le framework Hypervisor d'Apple et Windows Hypervisor Platform sur leurs systèmes d'exploitation respectifs.

Cette conception multiplateforme facilite le développement local. Elle ne rend pas smolvm exécutable dans tous les sandboxes d'agents existants, workers d'intégration continue ou environnements serverless.

Pour l'expérience anthropic simon, c'est le premier renversement important. La même couche d'isolation qui protégeait l'agent de recherche a également empêché l'agent de tester une seconde couche d'isolation.

Anthropic Simon a révélé le plan de contrôle manquant

smolvm peut fournir une frontière VM, mais l'application qui l'entoure doit décider quand le code démarre, ce qu'il reçoit et quand il est arrêté.

Le projet décrit smolvm comme un outil en ligne de commande destiné aux machines virtuelles Linux isolées et portables. Chaque charge de travail s'exécute avec son propre noyau invité via libkrun, un moniteur de machine virtuelle conçu pour les charges légères.

Cette architecture crée une frontière par défaut plus robuste qu'un conteneur ordinaire. Un conteneur conventionnel partage normalement le noyau hôte, même lorsque les espaces de noms masquent les processus, le réseau et les montages. Un invité smolvm reçoit un noyau distinct derrière une frontière d'hyperviseur.

Cette distinction réduit l'exposition directe au noyau hôte. Elle ne supprime pas la nécessité de ne faire confiance à rien de ce qui s'exécute dans l'invité. La documentation de smolvm indique explicitement que les opérateurs doivent considérer root dans l'invité comme non fiable.

Sa politique réseau par défaut correspond à l'objectif de Willison. L'accès réseau est opt-in : une machine lancée sans l'option de réseau ne devrait donc pas disposer d'une connectivité sortante ordinaire. Des listes d'autorisation d'hôtes sont disponibles lorsqu'une application a besoin d'une sortie étroitement limitée.

L'exposition du système de fichiers est également explicite. Les répertoires hôtes ne deviennent visibles que lorsque l'opérateur les monte. Cela permet un modèle de répertoire de préparation pour les tâches de transformation.

Un service d'exécution pourrait copier les entrées désignées dans un répertoire temporaire. Il pourrait monter ce répertoire en lecture seule, fournir un emplacement de sortie distinct et accessible en écriture, puis supprimer les deux après avoir validé les résultats.

Toutefois, la limite documentée de smolvm est importante. Son interface de volumes monte des répertoires, et non des fichiers individuels. Un service promettant l'accès à « uniquement les fichiers désignés » doit donc construire un répertoire isolé contenant exactement ces fichiers.

Le service doit également protéger cette étape de préparation. Il devrait rejeter les liens symboliques, les fichiers de périphérique inhabituels, les permissions inattendues et les chemins qui sortent du répertoire prévu. La frontière VM ne peut pas corriger un processus de préparation des fichiers côté hôte négligent.

La configuration mémoire est disponible via l'option --mem ou un Smolfile, la configuration déclarative de machine de smolvm. La valeur par défaut documentée est de 8 Gio, la mémoire étant présentée par un ballon virtio élastique.

L'allocation élastique améliore l'utilisation de l'hôte, car celui-ci n'engage pas immédiatement toute la quantité configurée. Elle ne doit pas être confondue avec un contrôle d'admission entre de nombreuses tâches hostiles.

Si un service lance de nombreux invités avec des allocations optimistes, la demande cumulée peut toujours submerger l'hôte. L'ordonnanceur a besoin d'un modèle de capacité distinct couvrant la mémoire, les CPU virtuels, le stockage et le nombre de machines simultanées.

La configuration CPU présente une distinction similaire. L'attribution d'un CPU virtuel limite l'exécution parallèle à l'intérieur d'un invité. Elle ne garantit pas automatiquement que le programme ne reçoit qu'un nombre fixe de secondes CPU.

Une boucle infinie monothread peut consommer son CPU virtuel attribué indéfiniment. L'hyperviseur contient la boucle, mais un superviseur externe doit imposer une échéance et arrêter la machine.

Les systèmes de production ont généralement besoin de politiques fondées à la fois sur le temps réel écoulé et sur les ressources. Un délai d'expiration en temps réel gère les blocages, les processus en veille et les programmes en interblocage. La comptabilisation CPU détecte les charges qui brûlent du calcul sans progresser.

Le superviseur doit rester à l'extérieur de l'invité. Le code exécuté dans la machine ne doit pas contrôler le minuteur, le signal de terminaison ni la décision finale de nettoyage. Sinon, la charge de travail peut tenter de désactiver sa propre protection.

C'est pourquoi l'expression « sandbox pour code non fiable » peut masquer deux produits distincts. L'un est le moteur d'isolation. L'autre est le plan de contrôle qui planifie et supervise ce moteur en toute sécurité.

Le test anthropic simon visait le comportement du produit complet. L'interface publique de smolvm fournit principalement le moteur d'isolation et la configuration de bas niveau nécessaires pour le construire.

Une microVM change la frontière, pas le modèle de menace

La virtualisation matérielle améliore le confinement, mais chaque capacité volontairement transmise à l'invité devient une partie de la surface d'attaque.

smolvm utilise libkrun VMM pour lancer des machines virtuelles légères. L'invité reçoit son propre noyau, tandis que l'hôte conserve le contrôle du matériel virtuel et des périphériques exposés.

Cette conception répond à une préoccupation centrale des conteneurs. Les conteneurs isolent les charges de travail au moyen de fonctions du noyau, mais les processus hostiles interagissent toujours avec le même noyau hôte via les appels système autorisés. Une vulnérabilité du noyau peut donc menacer la frontière du conteneur.

Les systèmes de microVM déplacent cette frontière vers l'extérieur. Le code hostile rencontre d'abord un noyau invité et des périphériques virtuels. Atteindre l'hôte exige généralement de franchir la frontière du moniteur de machine virtuelle ou de l'hyperviseur.

AWS a développé les microVMs Firecracker selon un principe similaire pour les charges de travail serverless. Firecracker combine la virtualisation KVM avec un modèle de périphériques délibérément réduit, limitant le matériel émulé superflu.

smolvm n'est pas simplement un wrapper Firecracker. Sa documentation actuelle décrit des backends libkrun sur macOS, Linux et Windows. Néanmoins, les deux approches placent chaque charge de travail derrière un noyau invité distinct.

Cette séparation est pertinente lorsqu'un système d'IA écrit du code de façon autonome. Le code généré peut contenir des comportements destructeurs accidentels, des attaques de dépendances, des sondes d'identifiants ou des charges utiles délibérées copiées depuis des données non fiables.

Une fonctionnalité de transformation de données présente le même risque même sans IA. Un utilisateur pourrait soumettre du Python qui parcourt le système de fichiers, crée des processus à répétition, alloue de la mémoire jusqu'à l'échec ou tente des connexions sortantes.

JavaScript n'est pas automatiquement plus sûr. Les programmes Node.js peuvent lire des fichiers, démarrer des sous-processus, ouvrir des sockets, charger des extensions natives et épuiser la mémoire lorsque ces capacités restent disponibles.

Les restrictions au niveau du langage deviennent souvent fragiles, car les bibliothèques standard exposent de vastes fonctionnalités. Les dépendances transitives peuvent également introduire du code natif ou des chemins d'accès inattendus.

Un invité Linux complet permet aux développeurs d'exécuter des paquets Python et Node.js ordinaires sans les réécrire pour un runtime spécialisé. Cette compatibilité est l'une des raisons pour lesquelles les microVM restent attrayantes.

Le compromis est un environnement invité plus vaste. Le service doit fournir un noyau, une image runtime, des bibliothèques et des périphériques virtuels. Chaque composant maintenu affecte les correctifs, la reproductibilité et la base de calcul de confiance.

La documentation de smolvm cite le système d'exploitation hôte, le backend d'hyperviseur, libkrun, smolvm et le compte hôte appelant comme composants de confiance. Une compromission dans ces couches peut affaiblir la frontière promise.

La documentation met également en garde contre le transfert explicite de capacités. Un répertoire monté expose son contenu. L'activation du réseau étend les services accessibles. Le transfert d'un agent SSH permet aux processus invités de demander des signatures tant que le socket reste disponible.

Ce sont des fonctionnalités raisonnables pour des machines de développement. Elles devraient normalement rester désactivées dans un service exécutant des soumissions anonymes ou hostiles.

L’accès au GPU exige encore davantage de prudence. smolvm prend en charge des interfaces impliquant des ressources GPU partagées de l’hôte ou des processus côté hôte. Sa documentation indique que le relai CUDA ne doit pas être considéré comme une isolation GPU multi-tenant renforcée.

Cette limite n’affecte pas une simple tâche Python de conversion de données. Elle illustre une règle plus générale : les fonctionnalités pratiques peuvent franchir la frontière nette entre invité et hôte qui rend l’architecture de base attrayante.

Pour les charges de travail hostiles, le profil le plus sûr est volontairement austère. N’utilisez aucun réseau, aucune crédence transmise, aucun service hôte, aucun GPU, des entrées minimales en lecture seule et une zone de sortie jetable.

La VM doit être détruite après chaque tâche. Réutiliser une machine risque de transmettre à l’exécution de l’utilisateur suivant des fichiers modifiés, des processus, des caches ou un état caché.

Les images portables peuvent aider à établir des environnements d’exécution cohérents. smolvm utilise des images OCI, fondées sur le format d’image OCI, afin que les opérateurs puissent préparer des environnements Python ou Node.js avec une norme d’empaquetage familière.

La compatibilité des images ne garantit pas leur fiabilité. Un service de production a toujours besoin de digests épinglés, de registres contrôlés, d’une gestion des vulnérabilités et d’un processus de reconstruction des environnements d’exécution après les mises à jour de sécurité.

Les limites de ressources exigent plus que des indicateurs CPU et mémoire

La défense la plus difficile contre « while true » n’est pas l’isolation, mais une terminaison fiable dans tous les modes de défaillance.

Un paramètre de mémoire fixe pour l’invité un plafond de RAM visible. Lorsqu’un programme dépasse cette capacité, le noyau invité peut déclencher son comportement de manque de mémoire. Cela contient une forme d’abus de ressources.

L’hôte doit néanmoins observer ce qui se passe ensuite. L’invité peut ne tuer qu’un seul processus, ne plus répondre ou consacrer beaucoup de temps à récupérer de la mémoire. Le service ne peut pas supposer que chaque panne de mémoire produit un résultat propre.

Un exécuteur strict doit classifier les résultats. Réussite, exception utilisateur, épuisement de mémoire, délai dépassé, dépassement de sortie, échec interne du sandbox et rejet pour manque de capacité hôte sont des événements distincts.

Cette classification est importante pour les utilisateurs comme pour les opérateurs. Un script de transformation avec une syntaxe invalide ne doit pas ressembler à une panne d’infrastructure. Une machine qui ne parvient pas à démarrer ne doit pas consommer le quota de tentatives d’un utilisateur.

Les limites CPU nécessitent plusieurs couches. L’invité peut recevoir un nombre restreint de processeurs virtuels. Des contrôles hôtes tels que les cgroups peuvent ensuite réguler le processus VMM par rapport aux autres charges de travail.

Un superviseur de délai doit arrêter toute la VM à l’issue de l’intervalle autorisé. Tuer uniquement le processus Python ou Node.js de premier niveau ne suffit pas, car le programme peut créer des processus enfants ou des processus d’arrière-plan.

La terminaison doit également prévoir une escalade. Le superviseur peut d’abord demander un arrêt propre, puis arrêter le processus VMM si l’invité ne répond pas. Il doit vérifier que les processus associés et les ressources temporaires ont disparu.

La sortie est une autre ressource. Un programme peut imprimer indéfiniment, créer d’énormes fichiers de résultats ou générer des données profondément imbriquées qui consomment la mémoire de l’analyseur après la fin de l’exécution.

Le service doit imposer des limites en octets à la sortie standard, à la sortie d’erreur standard et aux fichiers générés. Il doit diffuser ou tronquer les journaux sans mettre en mémoire tampon un contenu illimité dans la mémoire de l’application.

Des quotas de stockage doivent s’appliquer à la couche inscriptible de l’invité et à chaque répertoire de sortie exporté. Sinon, une petite entrée peut produire suffisamment de données pour remplir le système de fichiers de l’hôte.

Le nombre de processus compte également. Une bombe à forks crée des processus plus vite qu’un opérateur humain ne peut réagir. Le noyau invité a besoin de limites de processus, tandis que l’hôte doit contraindre le VMM et ses processus de support.

Un programme hostile peut aussi exploiter le temps sans saturer un CPU. Il peut dormir indéfiniment, attendre une entrée absente ou provoquer un interblocage. C’est pourquoi les délais en temps réel restent obligatoires.

Le temps doit être mesuré par le plan de contrôle externe. Un invité peut modifier sa propre horloge ou perturber des processus internes de surveillance. Le minuteur monotone de l’hôte fournit une source plus fiable.

L’exportation de fichiers ne doit intervenir qu’après la fin de l’exécution. L’hôte doit inspecter les types, tailles, chemins et quantités de fichiers avant de déplacer les résultats vers un stockage durable.

Pour les transformations de données courantes, un contrat de sortie plus étroit peut réduire le risque. L’exécuteur peut accepter un document JSON, un fichier CSV ou une archive limitée plutôt qu’une arborescence de répertoires arbitraire.

Un service doit aussi limiter la complexité des entrées avant de lancer la machine. Les archives compressées peuvent se déployer bien au-delà de leur taille téléversée, tandis que des formats malveillants peuvent cibler des analyseurs situés hors de l’invité.

La séquence sécurisée commence donc avant smolvm. Validez et préparez les entrées, créez une machine neuve, appliquez des limites d’exécution, arrêtez la machine, inspectez les sorties, puis détruisez l’état temporaire.

L’observabilité doit également se situer hors de l’invité. Les opérateurs ont besoin d’identifiants de machine, de digests d’image, des heures de démarrage et d’arrêt, des classifications de sortie, des pics de ressources et de l’état du nettoyage.

Ces enregistrements doivent éviter par défaut de stocker des données utilisateur sensibles. Les journaux peuvent devenir un autre canal de fuite lorsque les scripts impriment des enregistrements d’entrée, des identifiants ou du contenu propriétaire.

Aucune de ces exigences ne diminue la valeur de smolvm. Elles définissent le travail périphérique nécessaire pour transformer ses primitives de bas niveau en un service fiable.

Docker, WebAssembly et les sandboxes hébergés restent en concurrence

smolvm occupe une position intermédiaire utile, offrant une compatibilité Linux classique avec une séparation plus forte qu’un conteneur à noyau partagé.

Docker reste le point de départ le plus simple pour de nombreuses équipes d’ingénierie. Les images, registres, outils de build et systèmes d’orchestration prennent déjà en charge les flux de travail de conteneurs à grande échelle.

Les conteneurs peuvent appliquer des espaces de noms, des capacités, des filtres seccomp, des systèmes de fichiers en lecture seule et des limites cgroup. Ces contrôles peuvent convenir lorsque les charges de travail sont fiables ou seulement modérément risquées.

Le noyau partagé reste la préoccupation centrale pour du code entièrement hostile. Une vulnérabilité d’évasion dans le noyau hôte ou l’environnement d’exécution des conteneurs peut exposer d’autres charges de travail et des données hôtes.

smolvm modifie cette exposition en attribuant un noyau invité distinct à chaque machine. Il accepte également les images OCI, réduisant une partie des frictions de migration pour les équipes disposant d’environnements Python ou Node.js existants.

Toutefois, les plateformes de conteneurs disposent de couches de planification et de politiques matures. La documentation de sécurité de smolvm indique que l’outil autonome n’est pas en lui-même un plan de contrôle multi-utilisateur renforcé.

Une équipe remplaçant des conteneurs par smolvm doit éviter de perdre des garanties opérationnelles durant la migration. Une isolation plus forte sous un ordonnanceur plus faible peut tout de même produire un service peu fiable.

WebAssembly suit une autre approche. Un environnement d’exécution WebAssembly commence par un modèle de capacités contraint, puis accorde explicitement des fonctions telles que l’accès aux fichiers ou au réseau.

Cette approche peut créer une interface plus réduite pour des charges de travail compactes de transformation. Elle prend également en charge un démarrage rapide et une intégration précise dans une application.

La compatibilité est le compromis. Les paquets Python et Node.js standard peuvent attendre des appels système Linux, des extensions natives, des sous-processus ou des comportements d’exécution indisponibles dans un environnement WebAssembly restreint.

Une équipe contrôlant le langage de transformation peut accepter ces contraintes. Un service promettant une large compatibilité Python et JavaScript y sera rapidement confronté.

Les sandboxes de code hébergés offrent une troisième voie. Les fournisseurs regroupent le cycle de vie des machines, les délais, la politique réseau, le stockage et les API dans des services gérés.

Cela peut raccourcir le temps d’implémentation. Cela transfère aussi du code et des données sensibles à un autre opérateur, introduit des dépendances de service et limite le contrôle sur la conception d’isolation sous-jacente.

L’auto-hébergement de smolvm maintient l’environnement d’exécution sous l’administration de l’acheteur. Il rend également l’acheteur responsable du durcissement de l’hôte, des mises à jour de sécurité, de la planification de capacité, de la supervision et de la réponse aux incidents.

Le choix doit suivre la charge de travail plutôt que la mode. Un évaluateur d’expressions contraint n’a pas besoin d’un invité Linux complet. Un paquet Python complexe avec des dépendances natives en a probablement besoin.

Pour des transformations ponctuelles, le démarrage d’une microVM doit rester faible par rapport à la durée de la tâche. smolvm indique que les charges de travail compactées peuvent démarrer en moins de 200 millisecondes, mais des mesures indépendantes doivent couvrir les hôtes et images exacts de l’acheteur.

Les benchmarks doivent inclure la récupération à froid de l’image, la création de la machine, le démarrage de l’environnement d’exécution, la préparation des entrées, l’exécution, la validation des sorties et la destruction. Mesurer uniquement le temps de démarrage de l’invité sous-estime la latence visible par l’utilisateur.

Les équipes doivent également tester la densité. Un invité rapide en dit peu sur un hôte exécutant des centaines de soumissions simultanées sous pression mémoire.

La question concurrentielle est donc plus large que la force de l’isolation. Elle comprend la compatibilité, le comportement au démarrage, la maturité de la planification, la charge opérationnelle et les conséquences d’une évasion réussie.

smolvm mérite une évaluation parce qu’il combine des charges de travail Linux familières avec une frontière de VM. La tentative anthropic simon montre qu’une telle évaluation doit avoir lieu sur une infrastructure capable d’exposer les fonctionnalités de virtualisation requises.

Trois tests détermineront si smolvm est prêt

Les prochaines preuves utiles doivent provenir de tests de charges de travail hostiles, et non d’une nouvelle liste de fonctionnalités.

Le premier signal est un test reproductible sur un hôte bare-metal compatible ou prenant en charge la virtualisation imbriquée. Il doit exécuter des suites Python et JavaScript via le même superviseur externe.

Ces suites doivent inclure des boucles infinies, l’épuisement de mémoire, des bombes à forks, des sorties surdimensionnées, des sondes de système de fichiers, des sondes réseau, des processus enfants retardés et des arrêts anormaux de l’invité. Chaque cas nécessite un résultat attendu.

Un résultat concluant renforcerait l’idée que smolvm peut servir de moteur d’isolation pour les tâches de transformation. Des échecs de nettoyage répétés ou une terminaison incohérente l’affaibliraient.

Le deuxième signal est une application explicite et documentée du cycle de vie. Un exécuteur de référence doit montrer comment imposer des délais en temps réel, des contrôles CPU au niveau de l’hôte, des plafonds de mémoire, des quotas de sortie et la destruction complète de la machine.

Les indicateurs de configuration ne suffisent pas. Le test doit vérifier le comportement lorsque l’invité ignore les demandes d’arrêt, remplit le stockage et laisse des processus descendants derrière lui.

Ce signal comblerait l’écart entre les primitives de VM de smolvm et le service que Willison voulait initialement examiner. Sans cela, chaque adoptant doit concevoir indépendamment le superviseur critique.

Le troisième signal est un examen de sécurité selon un modèle de menace déclaré. Cet examen doit identifier les composants hôtes fiables, le comportement des fichiers montés, l’application des règles réseau, la provenance des images et les hypothèses multi-tenant.

La documentation existante de smolvm fournit déjà des informations utiles. Elle indique que les versions ne disposent actuellement ni de signatures ni d’attestations de provenance, bien que la vérification par somme de contrôle soit possible lorsque son fichier de sommes de contrôle peut être téléchargé.

Cette information donne aux évaluateurs une question concrète sur la chaîne d’approvisionnement. Un opérateur de production a besoin d’une méthode contrôlée pour acquérir, vérifier, épingler et mettre à jour le binaire smolvm et les images invitées.

Une évaluation doit aussi distinguer l’exécution locale par un seul utilisateur d’un environnement multi-tenant hostile. Un développeur exécutant du code généré sur un ordinateur portable ne subit pas les mêmes conséquences qu’un service public acceptant des soumissions anonymes.

Aucun sandbox ne peut transformer du code arbitraire en une charge de travail sans risque. L’objectif pratique est un confinement en couches, des capacités contrôlées, une consommation de ressources limitée et une récupération rapide lorsqu’une couche échoue.

Le schéma de déploiement le plus prometteur utilise smolvm comme une couche au sein de ce système. Un service hôte valide les entrées, crée un invité jetable, prive l’environnement d’accès réseau, impose des délais, vérifie les sorties et détruit l’environnement.

Pour les équipes qui construisent des workflows d’IA, la leçon va au-delà de l’exécution de code. Tout système qui permet à un modèle d’agir sur des informations locales a besoin de limites explicites concernant ce que le modèle peut lire, écrire et conserver.

Une base de connaissances consultable peut aider les ingénieurs à conserver les résultats de tests, les modèles de menaces et les conclusions d’incidents. Elle ne peut pas remplacer l’isolation à l’exécution, mais elle peut rendre les décisions de sécurité plus faciles à auditer.

L’expérience anthropic simon doit donc être considérée comme une évaluation inachevée, avec un premier constat utile. smolvm n’a pas pu s’exécuter dans l’environnement Claude Code choisi, car le bac à sable externe refusait l’accès à la virtualisation.

La prochaine étape ne consiste pas à assouplir ce bac à sable externe. Elle consiste à répéter l’évaluation sur un hôte dédié et compatible, avec un superviseur externe et une suite de tests adversariaux publiée.

Votre service arrêterait-il toujours chaque tâche, ne préserverait-il que les sorties approuvées et effectuerait-il un nettoyage complet lorsque l’invité devient hostile ? Si cette réponse n’a pas été mesurée, le bac à sable n’est pas prêt à exécuter du code utilisateur.