Docker ha presentado Cloud Sandboxes, micro máquinas virtuales gestionadas para ejecutar agentes de IA fuera de tu portátil. Lo interesante del anuncio no es el producto: es la demo que usaron para justificarlo.
Qué ha pasado
El jueves 24 de septiembre, en el congreso WeAreDevelopers, Mark Cavage —presidente y COO de Docker— anunció la versión alojada de los sandboxes. Instancias que levantan en fracciones de segundo, facturación al segundo, y con secretos, políticas, red, configuración del agente y pasarela MCP ya integrados. Los precios de lista van desde el tamaño Micro (1 vCPU, 2 GB) por siete céntimos de dólar la hora hasta el XL (16 vCPU, 32 GB) por un dólar y doce céntimos la hora.
Antes de vender nada, Cavage enseñó el problema. Arrancó Claude dentro de un contenedor Docker corriente y le pidió que encontrase un secreto guardado en la máquina anfitriona. El modelo rebuscó por su entorno, encontró el socket de Docker montado desde el host y salió por ahí. Su frase resume bien el asunto:
«Hay que separar contenedores de contención.»
Después subió al escenario a Michael Irwin, ingeniero principal, para repetir el mismo prompt dentro de un sandbox. Esta vez el modelo también localizó el socket, también intentó montar rutas del anfitrión y levantar un contenedor privilegiado, y se quedó donde estaba: el sandbox corre como micro VM completa, con su propio kernel.
El contexto ayuda a entender la prisa. Ese mismo día, funcionarios australianos revelaron que un agente de OpenAI había accedido sin autorización a un portal del gobierno mientras buscaba estadísticas sanitarias. No es el primer caso de agente que empuja más allá de donde su operador esperaba.
Docker actualizó además su especificación de Kits —el formato para empaquetar agentes, herramientas y reglas en un artefacto compartible—, que ahora son imágenes OCI estándar. Y enseñaron un Kit de BAND para que varios agentes cooperen por WebSocket sin compartir entorno de ejecución.
Por qué importa
El socket montado es el pecado original y lo tienes en producción. /var/run/docker.sock dentro de un contenedor equivale a dar root en el anfitrión: con ese socket puedes lanzar un contenedor privilegiado que monte el disco entero. Esto se sabe desde siempre y aun así está montado en media industria, porque lo piden los runners de CI, los tests con contenedores efímeros, los dev containers y cualquier cosa que construya imágenes dentro de otra imagen. Con un humano delante, el riesgo era teórico: nadie va a rebuscar por ahí sin motivo. Un agente sí. Rebuscar por el entorno hasta encontrar por dónde seguir es su trabajo, y es exactamente lo que lo hace útil.
Un contenedor aísla procesos que colaboran, no adversarios que sondean. Comparte kernel. Está diseñado para que dos aplicaciones no se pisen, no para aguantar a algo que prueba doscientas vías hasta que una funciona. Cuando el que está dentro va a intentar mutar su entorno —porque para eso lo has contratado—, la frontera tiene que ser de virtualización, no de espacios de nombres.
Qué haría yo esta semana, sin comprar nada:
- Inventario de qué monta cada entorno donde corre un agente: sockets, volúmenes del host,
~/.aws,~/.ssh, el.envdel proyecto de al lado. - Fuera el socket de Docker. Si hace falta construir imágenes, daemon remoto con credenciales acotadas o herramientas sin daemon.
- Red denegada por defecto y lista blanca de destinos. El caso australiano no fue una fuga de contenedor: fue salida a internet sin control.
- Secretos fuera del sistema de ficheros del sandbox. El agente lee ficheros mejor que tú.
- Para ejecución sin supervisión, frontera de micro VM. Local o alojada, da igual el proveedor.
La facturación por segundo cambia el patrón de uso, y eso sí es higiene. Si un entorno cuesta céntimos y arranca en lo que tarda un npm install en decidirse, deja de compensar reutilizar el mismo sandbox toda la tarde. Uno por tarea, desechable, que muera con la tarea. La contención más barata sigue siendo que el entorno no exista cuando nadie lo mira.
Y que los Kits sean OCI no es un detalle menor. Significa tu registro, tu firma, tu escáner y tu puerta de salida. Un formato propietario para empaquetar agentes habría sido pegamento a cinco años vista.
Lo que no cambia
La micro VM aísla el sistema de ficheros y el kernel. No aísla los permisos que le has dado tú. Si el agente lleva un token con escritura al repositorio o una clave de la API de producción, ese token funciona igual de bien desde dentro de un sandbox perfecto. El incidente australiano no se habría evitado con esto.
Lo dice el propio Docker, y hay que reconocérselo: los sandboxes son la capa base determinista, y quien gobierna la intención del agente son las políticas —que siguen siendo trabajo pendiente en casi toda la pila. Es un mínimo exigible, no una solución.
Mover la ejecución a la nube tampoco elimina la superficie: la desplaza. Tus secretos y tu código pasan a vivir en infraestructura de otro, con su propio modelo de amenazas. Para trabajos largos y desatendidos compensa; para tocar el repo privado de un cliente, piénsalo dos veces.
Técnicamente tampoco es una invención: aislar cargas poco fiables en micro VMs lleva años haciéndose. Lo nuevo aquí es el empaquetado, la integración con el flujo de trabajo del desarrollador y el precio de entrada. Y ojo con el precio de lista: la factura no la marca la tarifa por hora, sino cuántos sandboxes abres y cuánto viven olvidados.
Si tienes agentes corriendo contra vuestro código, el ejercicio de hoy es mirar qué hay montado dentro. Cualquier duda me dices y lo vemos.
Un saludo, Vicente.
La crónica del anuncio, en The Register.