Docker Sandboxes: microVMs para correr agentes de IA sin supervisión

Docker lanzó Sandboxes, una herramienta que corre agentes de código como Claude Code, Codex o Gemini CLI dentro de microVMs desechables que aíslan cada sesión del resto de la máquina. La promesa es directa: dejar que el agente trabaje en modo YOLO, sin aprobar cada comando uno por uno, sin arriesgar el filesystem ni la red del equipo host.

La herramienta llega justo cuando equipos enteros ya delegan tareas largas a agentes autónomos y necesitan un límite de seguridad real entre "el agente hizo lo que quiso" y "el agente rompió algo en producción".

TL;DR

• Docker lanzó Sandboxes, una CLI que aísla agentes de código en microVMs desechables.- Soporta Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode y Kiro de fábrica.- Instalación en macOS: brew trust docker/tap && brew install docker/tap/sbx.- Instalación en Windows: winget install Docker.sbx.- Cada sandbox monta solo el workspace del proyecto; el resto del host queda invisible.- Los agentes pueden instalar paquetes y levantar sus propios contenedores Docker adentro.- Docker AI Governance añade políticas de red, filesystem y MCP a nivel de organización.- No requiere Docker Desktop instalado para funcionar.

Qué pasó con Docker Sandboxes

Docker presentó Docker Sandboxes como una capa de aislamiento dedicada para agentes de código que necesitan ejecutar tareas largas sin supervisión humana constante. La idea central es que cada agente corre dentro de una microVM desechable que monta únicamente el workspace del proyecto, mientras el resto del sistema host permanece invisible para él.

Según la página oficial del producto, la lista de agentes soportados de fábrica incluye Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode y Kiro. Dentro del sandbox, el agente puede instalar paquetes, modificar archivos de configuración y hasta levantar sus propios contenedores Docker, todo sin que el equipo de desarrollo tenga que aprobar cada paso manualmente.

La instalación es deliberadamente mínima: un solo comando en macOS y otro en Windows, sin necesidad de tener Docker Desktop corriendo de fondo.
La instalación de Docker Sandboxes es un único comando, sin Docker Desktop.

Contexto e historia

El problema que resuelve Docker Sandboxes no es nuevo: viene de la tensión entre velocidad y seguridad al delegar tareas a un proceso automatizado. Los contenedores tradicionales comparten el kernel del host, lo que los hace livianos pero también más permeables si un proceso adentro logra escapar del aislamiento. Las máquinas virtuales completas ofrecen aislamiento más fuerte porque virtualizan hardware entero, pero tardan segundos o minutos en arrancar y consumen muchos más recursos.

Las microVMs, popularizadas en la industria por proyectos como Firecracker de AWS, buscan un punto intermedio: aislamiento a nivel de hipervisor con tiempos de arranque cercanos a los de un contenedor. Docker no detalló públicamente en el lanzamiento qué hipervisor usa por debajo de sbx, pero el enfoque general (microVM dedicada por sesión, desechable por diseño) es consistente con esa familia de tecnologías.

Lo que cambia con Sandboxes es el destinatario: no es infraestructura para correr funciones serverless, sino un entorno pensado específicamente para que un agente de código trabaje con la bandera --dangerously-skip-permissions activada por defecto, algo que hasta ahora la mayoría de los equipos evitaba fuera de una VM configurada a mano.

Detalles técnicos y rendimiento

Cada sandbox es una microVM dedicada con el entorno de desarrollo del usuario y solo el workspace del proyecto montado adentro. Nada más del filesystem del host queda expuesto al agente. La red también se puede restringir con políticas propias, aunque para aplicarlas de forma centralizada en todo un equipo hace falta la capa adicional Docker AI Governance.

Un detalle importante: los agentes pueden correr Docker dentro del sandbox. Un agente que necesite levantar una base de datos de prueba o un servicio auxiliar puede hacerlo con contenedores anidados, sin que eso comprometa al host real.
OpciónCuándo usarlaVentajaLimitaciónDocker Sandboxes (microVM)Ejecutar agentes de IA sin supervisión constanteAislamiento fuerte, arranque rápido, desechableDepende del CLI sbx; políticas avanzadas requieren Docker AI GovernanceContenedores clásicos (Docker Desktop)Desarrollo diario sin delegar control total a un agenteComparte el kernel del host, overhead mínimoAislamiento más débil frente a un proceso con permisos ampliosVM tradicional (VirtualBox/VMware)Aislamiento completo de hardware o multi-SOAislamiento máximoArranque lento, consumo alto de recursos
El flujo, de forma simplificada, es este: el host lanza el CLI, el CLI crea la microVM, y dentro de esa microVM corre el agente con permisos amplios, incluyendo la posibilidad de anidar sus propios contenedores.

flowchart TD
    A["Tu máquina host"] --> B["CLI sbx"]
    B --> C["Sandbox microVM"]
    C --> D["Agente de IA: Claude Code"]
    D --> E["Contenedor Docker anidado"]
    subgraph Aislado
    C
    D
    E
    end

💡 Tip: corré sbx sin Docker Desktop instalado: la CLI trae su propio runtime de microVMs.

Cómo empezar a probar Docker Sandboxes

Instalar Docker Sandboxes toma un solo comando según el sistema operativo. En macOS:

brew trust docker/tap && brew install docker/tap/sbx

Ese comando agrega el tap oficial de Docker a Homebrew y luego instala el binario sbx. En Windows, el equivalente es:

winget install Docker.sbx

Al momento del lanzamiento, Docker no publicó un instalador por gestor de paquetes equivalente para Linux en la página oficial del producto; quien use Linux debería revisar la documentación oficial para la vía soportada en su distribución.

Una vez instalado, el patrón general para lanzar un agente dentro de un sandbox sigue la misma lógica que documenta Docker: crear la microVM y correr el CLI del agente en modo permisivo adentro de ella, por ejemplo:

# patrón ilustrativo, verificar sintaxis exacta en la documentación oficial
sbx run -- claude --dangerously-skip-permissions

Para confirmar que el sandbox realmente aísla al agente, lo más simple es comparar el filesystem visible desde adentro (solo el workspace del proyecto) contra el filesystem real del host: si el agente puede listar directorios fuera de su proyecto, el aislamiento no está funcionando como se espera.

⚠️ Ojo: usar --dangerously-skip-permissions fuera de un sandbox le da a tu agente acceso total a tu sistema real: la bandera solo es segura dentro del aislamiento que ofrece Sandboxes.

Impacto y análisis

Docker publicó testimonios de socios que ya integran Sandboxes en sus propios productos. Gavriel Cohen, creador de NanoClaw, resumió la filosofía detrás del lanzamiento: "you don't trust agents with security, you build walls around them", y calificó a Docker Sandboxes como esa infraestructura de aislamiento a nivel de plataforma.

Ben Navetta, líder de ingeniería en Warp, señaló que Sandboxes permite a los agentes hacer tareas largas sin comprometer la seguridad, y que Warp está integrando la herramienta para que los agentes corran con un entorno consistente, ya sea local o en la nube.

El movimiento encaja con una tendencia más amplia: a medida que más equipos corren agentes en modo autónomo durante horas sin revisión humana constante, la superficie de riesgo de un solo proceso con permisos amplios crece. Docker apuesta a que el aislamiento por microVM, más rápido de levantar que una VM completa, se vuelva el estándar por defecto para ese tipo de carga de trabajo.
Cada sandbox monta solo el workspace del proyecto, nada más del host.

Qué sigue

Para organizaciones que necesitan más que el aislamiento por sandbox individual, Docker ofrece Docker AI Governance como capa adicional: políticas de acceso a red para los entornos de sandbox, controles y restricciones de acceso al filesystem, y gobierno centralizado de MCP a nivel de toda la organización, definidos una vez y aplicados en la máquina de cada desarrollador.

Docker Sandboxes tampoco depende de Docker Desktop para funcionar, lo que sugiere que la compañía está posicionando esta pieza como infraestructura independiente, orientada específicamente a equipos que ya trabajan con agentes de código en producción o en CI.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré brew trust docker/tap && brew install docker/tap/sbx hoy mismo y lanzá tu primer agente en modo YOLO dentro de un sandbox aislado.

Preguntas frecuentes

¿Qué es un sandbox para agentes de código con IA?

Es un entorno microVM aislado que protege el filesystem y la red de tu máquina de lo que haga el agente adentro. Docker Sandboxes monta solo el workspace del proyecto: el resto del disco queda fuera del alcance del agente.

¿Qué agentes soporta Docker Sandboxes?

De fábrica soporta Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode y Kiro. También se pueden definir sandboxes personalizados para otros agentes.

¿Qué significa "YOLO mode" y es seguro usarlo?

YOLO mode es correr el agente con la bandera --dangerously-skip-permissions, sin que pida aprobación por cada acción. Es necesario para que el agente trabaje rápido y sin supervisión, pero es riesgoso fuera de un entorno aislado. Sandboxes lo vuelve seguro al encerrar al agente en una microVM dedicada.

¿En qué se diferencia un sandbox de una máquina virtual tradicional?

Los sandboxes corren completamente aislados dentro de microVMs, dando más aislamiento que un contenedor sin pagar el costo completo de levantar una VM tradicional. Eso les permite hacer cosas que necesitan más permisos de forma segura, como correr sus propios contenedores Docker adentro.

¿Qué controles de seguridad se pueden configurar?

Se pueden definir políticas de red y filesystem propias. Para aplicarlas de forma centralizada en todo un equipo (con políticas de acceso a red, reglas de filesystem y gobierno de MCP) existe Docker AI Governance, pensado para organizaciones.

¿Necesito Docker Desktop para usar Sandboxes?

No. Docker Sandboxes funciona de forma independiente, sin depender de Docker Desktop instalado en la máquina.

Referencias

• Docker Sandboxes: página oficial del producto: anuncio, demo interactiva y FAQ de la herramienta.- Documentación oficial de Docker: referencia técnica completa de la plataforma y sus CLIs.- Docker (software) en Wikipedia: contexto histórico sobre contenedores y la plataforma Docker.- Docker en GitHub: repositorios oficiales del proyecto y sus herramientas de CLI.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.