Anthropic Simon probó smolvm, pero el sandbox aún necesita un plano de control

El investigador de Anthropic Simon Willison probó smolvm con un objetivo exigente: ejecutar de forma segura Python y JavaScript no confiables sin abuso de red, sistema de archivos ni recursos. El experimento se encontró con un conflicto inmediato. Claude Code for web se ejecutaba dentro de un guest de Firecracker, mientras que smolvm necesitaba acceso a virtualización por hardware que el guest no exponía.

Ese fallo no demostró que smolvm fuera inseguro. Mostró que evaluar una microVM dentro de otra máquina virtual restringida puede fallar antes incluso de que comiencen las pruebas de seguridad. La distinción importa para los equipos que consideran scripts aportados por usuarios, programas generados por IA o transformaciones automatizadas de datos.

Las notas de investigación sobre sandboxing también exponen una brecha de ingeniería más amplia. Un límite sólido de máquina virtual es solo una parte de un servicio seguro de ejecución de código. Los operadores aún necesitan plazos, contabilidad de recursos, preparación de archivos, controles de salida, monitorización y limpieza en torno a ese límite.

smolvm ofrece varios componentes útiles. La red está desactivada de forma predeterminada, las cargas de trabajo reciben kernels guest separados y los valores de CPU y memoria son configurables. Sin embargo, esas funciones no crean automáticamente un servicio de producción para código hostil.

Por lo tanto, la verdadera competencia no es smolvm contra Docker, ni Python contra JavaScript. Es la promesa de aislamiento con un solo comando frente a los controles operativos necesarios para una ejecución multiusuario fiable.

La prueba falló antes de que se ejecutara el código no confiable

El primer resultado fue un fallo de compatibilidad del entorno, no una fuga del sandbox ni un límite de recursos que no funcionara.

Willison pidió a un modelo de Anthropic que operaba a través de Claude Code for web que investigara smolmachines como un sandbox rápido. La carga de trabajo propuesta era concreta: ejecutar código suministrado por usuarios para tareas como transformar datos estructurados.

Ese código necesitaba límites estrictos. No debía tener acceso a la red, solo acceder a archivos designados, consumir memoria acotada y detenerse tras un intervalo definido por el operador. Un bucle infinito, como while true, no debería ocupar capacidad de cómputo indefinidamente.

El modelo pudo investigar el proyecto y diseñar pruebas. No pudo iniciar las máquinas smolvm necesarias para ejecutarlas. Según el relato de Willison, el entorno de Claude Code ya era un guest de Firecracker ejecutando Linux.

smolvm utiliza virtualización asistida por hardware mediante hipervisores específicos de cada plataforma. En Linux, eso normalmente significa KVM, la interfaz del kernel que expone funciones de virtualización del procesador a un monitor de máquinas virtuales. Un guest de nube restringido a menudo carece del dispositivo /dev/kvm necesario para iniciar otro guest acelerado por hardware.

Este es el problema de la virtualización anidada. Una máquina virtual solo puede alojar otra máquina virtual cuando la plataforma exterior expone las funciones necesarias del procesador y el acceso a dispositivos. Muchos sandboxes gestionados los restringen deliberadamente.

La limitación genera una paradoja de pruebas inusual. Claude Code for web estaba aislado en parte porque se ejecutaba dentro de una microVM. Ese aislamiento le impidió iniciar la microVM distinta que se le había pedido evaluar.

Durante ese intento, ninguna carga de ataque significativa en Python o JavaScript llegó a smolvm. La prueba no produjo mediciones independientes de latencia de arranque, aplicación de límites de memoria, saturación de CPU, aislamiento de archivos ni comportamiento de terminación.

Esa evidencia ausente debería orientar cualquier conclusión. Sería inexacto afirmar que el ejercicio validó smolvm como un servicio de ejecución seguro. También sería inexacto interpretar el inicio bloqueado como evidencia contra el aislamiento guest de smolvm.

En cambio, el resultado identifica un requisito previo de despliegue. Un equipo debe ejecutar smolvm en un host físico compatible o en una máquina virtual que permita virtualización anidada.

El modelo de seguridad oficial de smolvm identifica KVM como backend de Linux. También admite el framework Hypervisor de Apple y Windows Hypervisor Platform en sus respectivos sistemas operativos.

Ese diseño multiplataforma ayuda al desarrollo local. No hace que smolvm pueda ejecutarse dentro de todos los sandboxes de agentes existentes, workers de integración continua o entornos serverless.

Para el experimento de anthropic simon, esta es la primera inversión importante. La misma capa de aislamiento que protegía al agente investigador también le impidió probar una segunda capa de aislamiento.

Anthropic Simon expuso el plano de control que falta

smolvm puede proporcionar un límite de VM, pero la aplicación que lo rodea debe decidir cuándo empieza el código, qué recibe y cuándo termina.

El proyecto describe smolvm como una herramienta de línea de comandos para máquinas virtuales Linux aisladas y portátiles. Cada carga de trabajo se ejecuta con su propio kernel guest mediante libkrun, un monitor de máquinas virtuales diseñado para cargas de trabajo ligeras.

Esa arquitectura crea un límite predeterminado más sólido que un contenedor convencional. Un contenedor convencional suele compartir el kernel del host, incluso cuando los espacios de nombres ocultan procesos, redes y montajes. Un guest de smolvm recibe un kernel separado tras un límite de hipervisor.

La distinción reduce la exposición directa al kernel del host. No elimina la necesidad de desconfiar de todo lo que se ejecuta dentro del guest. La documentación de smolvm indica explícitamente que los operadores deben tratar el root del guest como no confiable.

Su postura de red predeterminada coincide con el objetivo de Willison. El acceso a la red es opcional, por lo que una máquina iniciada sin la opción de red no debería recibir conectividad saliente ordinaria. Hay listas de permitidos de hosts disponibles cuando una aplicación necesita salida de alcance limitado.

La exposición del sistema de archivos también es explícita. Los directorios del host solo se hacen visibles cuando el operador los monta. Esto permite un patrón de directorio de preparación para trabajos de transformación.

Un servicio de ejecución podría copiar las entradas designadas a un directorio temporal. Podría montar ese directorio como solo lectura, proporcionar una ubicación de salida independiente con permisos de escritura y descartar ambos tras validar los resultados.

Sin embargo, la limitación documentada de smolvm es importante. Su interfaz de volúmenes monta directorios, no archivos individuales. Por tanto, un servicio que prometa acceso a «solo archivos designados» debe crear un directorio aislado que contenga exactamente esos archivos.

El servicio también debe defender ese paso de preparación. Debe rechazar enlaces simbólicos, archivos de dispositivo inusuales, permisos inesperados y rutas que escapen del directorio previsto. El límite de VM no puede corregir un proceso descuidado de preparación de archivos en el host.

La configuración de memoria está disponible mediante la opción --mem o un Smolfile, la configuración declarativa de máquinas de smolvm. El valor predeterminado documentado es de 8 GiB, con la memoria presentada mediante un globo virtio elástico.

La asignación elástica mejora la utilización del host porque este no compromete inmediatamente toda la cantidad configurada. No debe confundirse con el control de admisión entre numerosos trabajos hostiles.

Si un servicio inicia numerosos guests con asignaciones optimistas, la demanda agregada aún puede desbordar el host. El planificador necesita un modelo de capacidad independiente que cubra memoria, CPU virtuales, almacenamiento y número de máquinas simultáneas.

La configuración de CPU tiene una distinción similar. Asignar una CPU virtual limita la ejecución paralela dentro de un guest. No garantiza automáticamente que el programa reciba solo una cantidad fija de segundos de CPU.

Un bucle infinito de un solo hilo puede consumir para siempre su CPU virtual asignada. El hipervisor contiene el bucle, pero un supervisor externo debe aplicar un plazo y terminar la máquina.

Los sistemas de producción suelen necesitar políticas tanto de tiempo de reloj como basadas en recursos. Un tiempo de espera de reloj gestiona bloqueos, procesos en espera y programas interbloqueados. La contabilidad de CPU detecta cargas de trabajo que consumen cómputo sin avanzar.

El supervisor debe permanecer fuera del guest. El código que se ejecuta dentro de la máquina no debería controlar el temporizador, la señal de terminación ni la decisión final de limpieza. De lo contrario, la carga de trabajo puede intentar desactivar su propia barrera de protección.

Por eso la expresión «sandbox para código no confiable» puede ocultar dos productos distintos. Uno es el motor de aislamiento. El otro es el plano de control que programa y supervisa de forma segura ese motor.

La prueba de anthropic simon apuntaba al comportamiento completo del producto. La interfaz pública de smolvm proporciona principalmente el motor de aislamiento y la configuración de bajo nivel necesaria para construirlo.

Una microVM cambia el límite, no el modelo de amenazas

La virtualización por hardware mejora la contención, pero cada capacidad reenviada deliberadamente al guest pasa a formar parte de la superficie de ataque.

smolvm utiliza libkrun VMM para iniciar máquinas virtuales ligeras. El guest recibe su propio kernel, mientras que el host conserva el control sobre el hardware virtual y los dispositivos expuestos.

Este diseño aborda una preocupación central de los contenedores. Los contenedores aíslan las cargas de trabajo mediante funciones del kernel, pero los procesos hostiles siguen interactuando con el mismo kernel del host a través de llamadas al sistema permitidas. Por tanto, una vulnerabilidad del kernel puede amenazar el límite del contenedor.

Los sistemas de microVM desplazan ese límite hacia fuera. El código hostil encuentra primero un kernel guest y dispositivos virtuales. Llegar al host generalmente exige atravesar el límite del monitor de máquinas virtuales o del hipervisor.

AWS desarrolló microVMs Firecracker en torno a un principio similar para cargas de trabajo serverless. Firecracker combina virtualización KVM con un modelo de dispositivos deliberadamente reducido, limitando el hardware emulado innecesario.

smolvm no es simplemente un wrapper de Firecracker. Su documentación actual describe backends de libkrun para macOS, Linux y Windows. Aun así, ambos enfoques sitúan cada carga de trabajo detrás de un kernel guest separado.

Esa separación es relevante cuando un sistema de IA escribe código de forma autónoma. El código generado puede contener comportamientos destructivos accidentales, ataques a dependencias, sondeos de credenciales o payloads deliberados copiados de datos no confiables.

Una función de transformación de datos enfrenta el mismo riesgo incluso sin IA. Un usuario podría enviar Python que examine el sistema de archivos, cree procesos repetidamente, asigne memoria hasta fallar o intente conexiones salientes.

JavaScript no es automáticamente más seguro. Los programas de Node.js pueden leer archivos, iniciar subprocesos, abrir sockets, cargar extensiones nativas y agotar memoria cuando esas capacidades siguen disponibles.

Las restricciones a nivel de lenguaje suelen volverse frágiles porque las bibliotecas estándar exponen funcionalidades amplias. Las dependencias transitivas también pueden introducir código nativo o rutas de acceso inesperadas.

Un guest Linux completo permite a los desarrolladores ejecutar paquetes convencionales de Python y Node.js sin reescribirlos para un runtime especializado. Esa compatibilidad es una de las razones por las que las microVMs siguen siendo atractivas.

La contrapartida es un entorno guest más amplio. El servicio debe proporcionar un kernel, una imagen de runtime, bibliotecas y dispositivos virtuales. Cada componente mantenido afecta al parcheo, la reproducibilidad y la base de computación de confianza.

La documentación de smolvm nombra el sistema operativo host, el backend del hipervisor, libkrun, smolvm y la cuenta host que lo invoca como componentes de confianza. Un compromiso en esas capas puede debilitar el límite prometido.

La documentación también advierte sobre el reenvío explícito de capacidades. Un directorio montado expone su contenido. Habilitar la red amplía los servicios alcanzables. Reenviar un agente SSH permite que los procesos guest soliciten firmas mientras el socket siga disponible.

Esas son funciones razonables para equipos de desarrollo. Normalmente deberían permanecer desactivadas en un servicio que ejecuta envíos anónimos o adversarios.

El acceso a GPU exige aún más cautela. smolvm admite interfaces que implican recursos de GPU compartidos del host o procesos del lado del host. Su documentación indica que la conexión remota a CUDA no debe considerarse un aislamiento reforzado de GPU para múltiples inquilinos.

Esa limitación no afecta a una simple tarea de conversión de datos en Python. Ilustra la regla más amplia: las funciones de conveniencia pueden atravesar el límite limpio del huésped que hace atractiva la arquitectura básica.

Para cargas de trabajo hostiles, el perfil más seguro es deliberadamente aburrido. No use red, credenciales reenviadas, servicios del host ni GPU; emplee entradas mínimas de solo lectura y un área de salida desechable.

La VM debería destruirse después de cada tarea. Reutilizar una máquina conlleva el riesgo de trasladar archivos alterados, procesos, cachés o estado oculto a la ejecución del siguiente usuario.

Las imágenes portables pueden ayudar a establecer entornos de ejecución consistentes. smolvm utiliza imágenes OCI, basadas en el formato de imágenes OCI, de modo que los operadores pueden preparar entornos de Python o Node.js con un estándar de empaquetado conocido.

La compatibilidad de una imagen no establece su confiabilidad. Un servicio de producción sigue necesitando digests fijados, registros controlados, gestión de vulnerabilidades y un proceso para reconstruir los entornos de ejecución tras las actualizaciones de seguridad.

Los límites de recursos requieren más que indicadores de CPU y memoria

La defensa más difícil frente a un “while true” no es el aislamiento, sino una terminación fiable en todos los modos de fallo.

Una configuración de memoria establece un límite para la RAM visible por el huésped. Cuando un programa supera esa capacidad, el kernel del huésped puede activar su comportamiento ante falta de memoria. Eso contiene una forma de abuso de recursos.

El host aún debe observar lo que sucede después. El huésped podría eliminar solo un proceso, dejar de responder o dedicar mucho tiempo a recuperar memoria. El servicio no puede asumir que cada fallo de memoria genere un resultado limpio.

Un ejecutor estricto debería clasificar los resultados. Éxito, excepción del usuario, agotamiento de memoria, tiempo de espera agotado, desbordamiento de salida, fallo interno del sandbox y rechazo por capacidad del host son eventos distintos.

Esa clasificación importa tanto a usuarios como a operadores. Un script de transformación con sintaxis no válida no debería parecer una interrupción de la infraestructura. Una máquina que no logra arrancar no debería consumir el margen de reintentos de un usuario.

Los límites de CPU requieren varias capas. El huésped puede recibir un número restringido de CPU virtuales. Los controles del host, como cgroups, pueden entonces regular el proceso VMM con respecto a otras cargas de trabajo.

Un supervisor de plazos debería finalizar toda la VM tras el intervalo permitido. Matar solo el proceso de Python o Node.js de nivel superior es insuficiente, porque el programa puede crear procesos hijos o procesos en segundo plano.

La terminación también debe escalar. El supervisor puede solicitar primero un apagado ordenado y, después, detener el proceso VMM si el huésped no responde. Debería verificar que los procesos relacionados y los recursos temporales hayan desaparecido.

La salida es otro recurso. Un programa puede imprimir indefinidamente, crear archivos de resultados enormes o generar datos profundamente anidados que consuman memoria del analizador después de terminar la ejecución.

El servicio necesita límites de bytes para la salida estándar, el error estándar y los archivos generados. Debe transmitir o truncar los registros sin almacenar contenido ilimitado en la memoria de la aplicación.

Las cuotas de almacenamiento deberían aplicarse a la capa escribible del huésped y a cada directorio de salida exportado. De lo contrario, una entrada minúscula puede producir suficientes datos para llenar el sistema de archivos del host.

El número de procesos también importa. Una bomba fork crea procesos más rápido de lo que un operador humano puede reaccionar. El kernel del huésped necesita límites de procesos, mientras que el host debería restringir el VMM y sus procesos auxiliares.

Un programa hostil también puede consumir tiempo sin saturar una CPU. Puede dormir para siempre, esperar una entrada inexistente o crear un interbloqueo. Por eso los plazos de tiempo de reloj siguen siendo obligatorios.

El tiempo debe medirse mediante el plano de control externo. Un huésped puede modificar su propio reloj o interferir con procesos internos de vigilancia. El temporizador monotónico del host proporciona una fuente más fiable.

La exportación de archivos debe realizarse solo después de que finalice la ejecución. El host debería inspeccionar los tipos, tamaños, rutas y cantidades de archivos antes de trasladar los resultados al almacenamiento duradero.

Para transformaciones de datos comunes, un contrato de salida más limitado puede reducir el riesgo. El ejecutor podría aceptar un documento JSON, un archivo CSV o un archivo comprimido con límite de tamaño, en lugar de un árbol de directorios arbitrario.

Un servicio también debería limitar la complejidad de la entrada antes de iniciar la máquina. Los archivos comprimidos pueden expandirse mucho más allá de su tamaño cargado, mientras que los formatos maliciosos pueden atacar analizadores fuera del huésped.

Por tanto, la secuencia segura comienza antes de smolvm. Valide y prepare las entradas, cree una máquina nueva, aplique límites de ejecución, detenga la máquina, inspeccione las salidas y destruya el estado temporal.

La observabilidad también debe estar fuera del huésped. Los operadores necesitan identificadores de máquina, digests de imagen, horas de inicio y detención, clasificaciones de salida, picos de recursos y estado de limpieza.

Esos registros deberían evitar almacenar datos sensibles de los usuarios de forma predeterminada. Los logs pueden convertirse en otro canal de filtración cuando los scripts imprimen registros de entrada, credenciales o contenido propietario.

Ninguno de estos requisitos niega el valor de smolvm. Definen el trabajo adicional necesario para convertir sus primitivas de bajo nivel en un servicio fiable.

Docker, WebAssembly y los sandboxes alojados siguen compitiendo

smolvm ocupa una posición intermedia útil: ofrece compatibilidad con Linux convencional y una separación más fuerte que un contenedor con kernel compartido.

Docker sigue siendo el punto de partida más sencillo para muchos equipos de ingeniería. Las imágenes, los registros, las herramientas de compilación y los sistemas de orquestación ya admiten flujos de trabajo con contenedores a escala.

Los contenedores pueden aplicar espacios de nombres, capacidades, filtros seccomp, sistemas de archivos de solo lectura y límites de cgroups. Esos controles pueden ser apropiados cuando las cargas de trabajo son de confianza o presentan un riesgo moderado.

El kernel compartido sigue siendo la preocupación central para código completamente hostil. Una vulnerabilidad de escape en el kernel del host o en el runtime de contenedores puede exponer otras cargas de trabajo y datos del host.

smolvm cambia esa exposición al asignar un kernel de huésped independiente a cada máquina. También acepta imágenes OCI, lo que reduce parte de la fricción de migración para equipos con entornos existentes de Python o Node.js.

Sin embargo, las plataformas de contenedores cuentan con capas maduras de programación y políticas. La documentación de seguridad de smolvm indica que la herramienta independiente no es en sí misma un plano de control reforzado para múltiples usuarios.

Un equipo que sustituya contenedores por smolvm debe evitar perder salvaguardas operativas durante la transición. Un aislamiento más fuerte bajo un programador más débil todavía puede producir un servicio poco fiable.

WebAssembly sigue otra ruta. Un runtime de WebAssembly comienza con un modelo de capacidades restringido y luego concede explícitamente funciones como el acceso a archivos o a la red.

Ese enfoque puede crear una interfaz más pequeña para cargas de trabajo de transformación compactas. También permite un inicio rápido y una integración precisa en una aplicación.

La compatibilidad es la contrapartida. Los paquetes estándar de Python y Node.js pueden esperar llamadas al sistema Linux, extensiones nativas, subprocesos o comportamientos de runtime que no están disponibles en un entorno WebAssembly restringido.

Un equipo que controle el lenguaje de transformación podría aceptar esas restricciones. Un servicio que prometa amplia compatibilidad con Python y JavaScript las encontrará rápidamente.

Los sandboxes de código alojados ofrecen una tercera vía. Los proveedores empaquetan el ciclo de vida de las máquinas, los tiempos de espera, la política de red, el almacenamiento y las API en servicios gestionados.

Eso puede acortar el tiempo de implementación. También transfiere código y datos sensibles a otro operador, introduce dependencias de servicio y limita el control sobre el diseño de aislamiento subyacente.

Alojar smolvm internamente mantiene el runtime bajo la administración del comprador. También hace responsable al comprador del refuerzo del host, las actualizaciones de seguridad, la planificación de capacidad, la monitorización y la respuesta a incidentes.

La elección debería seguir la carga de trabajo, no la moda. Un evaluador de expresiones restringido no necesita un huésped Linux completo. Un paquete Python complejo con dependencias nativas probablemente sí.

Para transformaciones de una sola ejecución, el inicio de microVM debe seguir siendo pequeño respecto a la duración de la tarea. smolvm afirma que las cargas de trabajo empaquetadas pueden arrancar en menos de 200 milisegundos, pero las mediciones independientes deberían cubrir los hosts e imágenes exactos del comprador.

Los benchmarks deberían incluir la recuperación en frío de la imagen, la creación de la máquina, el inicio del runtime, la preparación de entradas, la ejecución, la validación de salidas y la destrucción. Medir solo el tiempo de arranque del huésped subestima la latencia visible para el usuario.

Los equipos también deberían probar la densidad. Un huésped rápido dice poco sobre un host que ejecuta cientos de envíos simultáneos bajo presión de memoria.

Por tanto, la cuestión competitiva es más amplia que la fortaleza del aislamiento. Incluye compatibilidad, comportamiento de inicio, madurez de la programación, carga operativa y las consecuencias de un escape exitoso.

smolvm merece evaluación porque combina cargas de trabajo Linux conocidas con un límite de VM. El intento de simon de anthropic demuestra que esa evaluación debe realizarse en una infraestructura capaz de exponer las funciones de virtualización necesarias.

Tres pruebas decidirán si smolvm está listo

La próxima evidencia útil debe proceder de pruebas con cargas de trabajo hostiles, no de otra lista de funciones.

La primera señal es una prueba reproducible en un host compatible de bare metal o virtualización anidada. Debería ejecutar suites tanto de Python como de JavaScript mediante el mismo supervisor externo.

Esas suites deberían incluir bucles infinitos, agotamiento de memoria, bombas fork, salida sobredimensionada, sondeos del sistema de archivos, sondeos de red, procesos hijos retrasados y apagados anormales del huésped. Cada caso necesita un resultado esperado.

Un resultado exitoso reforzaría el argumento de que smolvm puede servir como motor de aislamiento para tareas de transformación. Fallos repetidos de limpieza o terminación inconsistente lo debilitarían.

La segunda señal es una aplicación explícita y documentada del ciclo de vida. Un ejecutor de referencia debería mostrar cómo imponer plazos de tiempo de reloj, controles de CPU a nivel de host, límites de memoria, cuotas de salida y destrucción completa de la máquina.

Los indicadores de configuración no bastan. La prueba debería verificar el comportamiento cuando el huésped ignora las solicitudes de apagado, llena el almacenamiento y deja procesos descendientes activos.

Esta señal cerraría la brecha entre las primitivas de VM de smolvm y el servicio que Willison originalmente quería examinar. Sin ella, cada adoptante debe diseñar de forma independiente el supervisor crítico.

La tercera señal es una revisión de seguridad bajo un modelo de amenazas declarado. La revisión debería identificar los componentes de host de confianza, el comportamiento de los archivos montados, la aplicación de restricciones de red, la procedencia de las imágenes y las suposiciones de múltiples inquilinos.

La documentación existente de smolvm ya incluye divulgaciones útiles. Indica que las versiones actualmente carecen de firmas y certificaciones de procedencia, aunque la verificación de checksum está disponible cuando puede descargarse su archivo de checksum.

Esa divulgación ofrece a los evaluadores una cuestión concreta sobre la cadena de suministro. Un operador de producción necesita un método controlado para adquirir, verificar, fijar y actualizar el binario de smolvm y las imágenes de huésped.

Una evaluación también debería distinguir la ejecución local de un solo usuario de la multitenencia hostil. Un desarrollador que ejecuta código generado en un portátil afronta consecuencias distintas de las de un servicio público que acepta envíos anónimos.

Ningún sandbox puede convertir código arbitrario en una carga de trabajo sin riesgos. El objetivo práctico es una contención por capas, capacidades controladas, consumo de recursos limitado y recuperación rápida cuando falla una capa.

El patrón de implementación más prometedor utiliza smolvm como una capa dentro de ese sistema. Un servicio de host valida las entradas, crea un huésped desechable, deniega el acceso a la red, aplica plazos, comprueba las salidas y destruye el entorno.

Para los equipos que crean flujos de trabajo de IA, la lección va más allá de la ejecución de código. Cualquier sistema que permita a un modelo actuar sobre información local necesita límites explícitos sobre lo que el modelo puede leer, escribir y conservar.

Una base de conocimientos consultable puede ayudar a los ingenieros a conservar resultados de pruebas, modelos de amenazas y hallazgos de incidentes. No puede sustituir el aislamiento en tiempo de ejecución, pero puede facilitar la auditoría de las decisiones de seguridad.

Por lo tanto, el experimento anthropic simon debe tratarse como una evaluación inconclusa con un primer hallazgo útil. smolvm no pudo ejecutarse dentro del entorno de Claude Code elegido porque el sandbox externo restringía el acceso a la virtualización.

El siguiente paso no es relajar ese sandbox externo. Es repetir la evaluación en un host compatible dedicado, con un supervisor externo y una suite de pruebas adversariales publicada.

¿Su servicio seguiría deteniendo todos los trabajos, conservaría únicamente las salidas aprobadas y realizaría una limpieza completa cuando el entorno invitado se volviera hostil? Si esa respuesta no se ha medido, el sandbox no está listo para ejecutar código de usuarios.