smolvm: sandbox seguro para código no confiable

¿Por qué ejecutar código de terceros es un problema crítico para tu startup?

Simon Willison acaba de publicar una prueba rigurosa de smolmachines (smolvm v1.8.3) como sandbox para ejecutar transformaciones de datos en Python y JavaScript sin confianza. La conclusión: las máquinas virtuales aisladas por hardware superan a los contenedores de kernel compartido cuando el riesgo de ejecución de código malicioso o con fugas es real.

Esto importa directamente si construyes plataformas donde usuarios finales envían scripts, plugins o procesos de transformación de datos. Un while True malintencionado, una fuga de memoria o un intento de acceso a red pueden costarte horas de incidente operativo, exposición de datos o facturas de nube disparadas.

Willison probó smolvm con parámetros estrictos que cualquier fundador debería considerar:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Imágenes locales sin conexión a internet: la máquina virtual no tiene acceso a red alguna
Límites de CPU y RAM: protección contra bucles infinitos y consumo descontrolado
Timeouts forzados desde el huésped: la propia VM aplica cortes de tiempo
Cuotas de almacenamiento: espacio de disco limitado y predecible
Montajes de solo lectura para entrada: los datos del usuario entran pero no se modifican
Montajes escribibles solo para salida: los resultados salen por un canal controlado
Ejecución sin privilegios: el proceso corre con permisos mínimos (--unprivileged)

Los números de rendimiento son relevantes para aplicaciones en producción: cold starts entre 0.6 y 1.5 segundos, y ejecuciones cálidas alrededor de 50 milisegundos. Eso sitúa a smolvm en un rango competitivo frente a otras soluciones de sandboxing basadas en contenedores ligeros.

El desafío técnico que nadie cuenta: la virtualización anidada

Lo más interesante del experimento no fue el resultado final, sino el obstáculo intermedio. Willison encargó a Claude Fable 5 (ejecutándose dentro de Claude Code for web) que evaluara smolmachines como sandbox rápido y seguro. El entorno de Claude Code resultó ser una invitación Firecracker ya existente (Linux 6.18.5-fc-v20, 4 vCPU, 15 GB RAM), pero sin /dev/kvm ni flags vmx/svm en la CPU. Es decir, sin virtualización anidada disponible.

El plan B fue creativo: usar GitHub Actions, cuyos runners de Ubuntu sí exponen /dev/kvm. Willison creó un workflow temporal, instaló smolvm, ejecutó toda la batería de pruebas y eliminó el workflow al finalizar. Este tipo de solución pragmática —usar infraestructura CI/CD como laboratorio de pruebas— es exactamente el tipo de ingeniería operativa que diferencia a los equipos que escalan.

La lección para founders: no todos los entornos cloud permiten ejecutar VMs. Si tu arquitectura depende de aislamiento por hardware, necesitas verificar la disponibilidad de KVM/VMM en cada capa de tu stack antes de diseñar sobre ella.

¿Qué significa esto para tu startup?

Si tu producto incluye funcionalidades donde los usuarios proporcionan código arbitrario —ya sea para ETL de datos, automatizaciones, generación de contenido o integraciones—, el sandboxing deja de ser un lujo técnico y se convierte en un requisito de seguridad y compliance.

Dos acciones concretas que puedes implementar hoy

Audita tus puntos de ejecución de código externo: identifica todas las interfaces donde un usuario pueda enviar scripts, funciones o configuraciones ejecutables. Para cada uno, evalúa si un fallo de aislamiento podría exponer datos de otros tenants, acceder a secrets o consumir recursos desproporcionados. Prioriza los casos con mayor volumen de usuarios o datos sensibles.
Evalúa opciones de sandboxing según tu caso de uso: si necesitas ejecución esporádica con latencia aceptable, las VMs ligeras como smolvm (con cold starts de ~1 segundo) pueden funcionar. Si requieres throughput masivo y baja latencia constante, las ejecuciones cálidas (~50 ms) son competitivas. Compara también con alternativas basadas en WebAssembly (WasmEdge, Wasmer) o contenedores gVisor/Firecracker, considerando si tu proveedor cloud permite virtualización anidada.

El contexto más amplio: seguridad en infraestructura AI

El ecosistema de startups de IA en 2026 muestra una tendencia clara hacia la infraestructura especializada. Según datos de Crunchbase citados por CRN, los inversores destinaron USD 300.000 millones a 6.000 startups en el primer trimestre de 2026, con el 80% del capital global de venture capital concentrado en el sector de IA.

Dentro de este panorama, empresas como Operant AI están surgiendo específicamente para proteger agentes de IA y APIs LLM en runtime, mientras que Command Zero ofrece plataformas autónomas de seguridad para operaciones empresariales. La línea entre herramientas de desarrollo y herramientas de seguridad se difumina: ejecutar código de terceros de forma segura ya no es un problema secundario, es parte central del diseño de producto.

Para founders hispanohablantes, esto tiene implicaciones adicionales. Muchos productos regionales incluyen funcionalidades de automatización o procesamiento de datos donde los usuarios finales suben scripts personalizados. La adopción de sandboxing robusto puede ser un diferenciador competitivo en mercados regulados (finanzas, salud, gobierno) donde la responsabilidad por fugas de datos o accesos no autorizados es alta.