Docker Sandbox Kit: la nueva especificación que da autoridad legible a los agentes de IA

Docker acaba de publicar la especificación Sandbox Kit v3, un formato abierto (licencia Apache 2.0) que permite empaquetar todo lo que un agente de inteligencia artificial necesita para operar: reglas de red, credenciales, volúmenes y herramientas, como una imagen OCI estándar. Esto significa que la configuración de seguridad y permisos de un agente viaja con él y se comporta igual en cualquier entorno que cumpla la especificación. Para una pyme que empieza a usar agentes para tareas repetitivas, esta novedad puede marcar la diferencia entre un experimento controlado y un riesgo operativo.

El problema de los permisos invisibles

Cuando un agente de IA trabaja en nuestro nombre, necesita accesos: montar un directorio, usar un token, abrir un puerto, llamar a una API. Cada permiso parece razonable por separado, pero en conjunto amplían la superficie de ataque. Lo peor es que esos permisos suelen quedar dispersos en historiales de shell, paneles de control o la memoria de quien los configuró. No hay un archivo que los documente, no se pueden revisar ni versionar. Si mañana ese agente falla o alguien más debe replicar el entorno, la tarea se vuelve un rompecabezas.

La propuesta de Docker ataca justamente esa fragilidad: un Kit es un archivo legible que declara qué puede hacer el agente y a qué no puede acceder. Al ser una imagen OCI, se construye, se descarga, se firma y se escanea con las mismas herramientas que ya usamos para contenedores. La ventaja para una pyme es enorme: se puede versionar en un repositorio, revisar en un pull request y fijar por digest para garantizar que siempre se ejecute la misma configuración.

De contenedores a sandboxes: por qué un agente no es una aplicación

Un contenedor tradicional empaqueta una aplicación que ejecuta una tarea fija. Un agente, en cambio, decide qué hacer a continuación: instala paquetes, abre puertos, prueba caminos alternativos cuando algo se bloquea. Es un actor probabilístico que interactúa con el sistema operativo, la red y las credenciales de forma dinámica. Por eso un contenedor común no es suficiente: comparte el kernel con el anfitrión y el límite de aislamiento es el mismo que el agente está explorando.

Docker Sandbox resuelve esto con una microVM que tiene su propio kernel. El límite queda por debajo de cualquier cosa que el modelo pueda alcanzar o reescribir. Dentro de ese sandbox, se le puede dar root al agente y dejarlo trabajar sin miedo, porque el daño se detiene en la frontera de la microVM. Pero un sandbox vacío no es un entorno: falta definir qué agente corre, qué herramientas tiene, qué servidores MCP usa y exactamente qué puede tocar. Eso es lo que un Kit viene a llenar.

Lo que un Dockerfile no puede decir

Un Dockerfile describe cómo se construye y empaqueta el software, pero no dice nada sobre el exterior: redes, credenciales, volúmenes, contexto. Esa mitad de la historia ha vivido en banderas de docker run, archivos Compose, configuraciones de CI y la memoria de alguien. Un Kit escribe esa información junto con el contenido, en una anotación del manifiesto OCI. Así, la autoridad del agente se vuelve legible y transportable.

El ejemplo que da Docker es esclarecedor: un Kit para GitHub CLI declara que el agente puede acceder a github.com y api.github.com, pero niega explícitamente los métodos DELETE bajo /repos/**. El token que permite abrir un pull request no puede borrar el repositorio. Además, la credencial es gestionada por proxy: dentro del sandbox solo hay un centinela, y el valor real se inyecta en las peticiones a los dominios permitidos. Esta granularidad es oro para una pyme que quiere automatizar sin exponer sus repositorios o datos sensibles.

Implicaciones prácticas para una pyme

La especificación introduce dos conceptos clave: asks y conforming runtime. Un Kit no se otorga permisos a sí mismo; cada entrada es una solicitud y el anfitrión decide si la concede. Un runtime conforme, que implemente el comportamiento descrito, bloquea los hosts que no estén en la lista. Sin un runtime conforme, la anotación es inerte: solo una imagen sin aplicación de reglas. Docker Sandboxes es el primer runtime conforme, pero al ser un formato abierto, otros pueden sumarse.

Para una pyme que está dando sus primeros pasos con agentes de IA, esto significa que pronto podrá definir políticas de acceso claras, versionarlas y reutilizarlas. Ya no dependerá de la memoria de un técnico ni de configuraciones dispersas. Además, la composición de Kits se basa en un grafo de dependencias declarado, no en el orden de los comandos, lo que garantiza que el mismo conjunto de Kits siempre produzca el mismo entorno. Esto reduce errores y facilita la auditoría.

Si estás explorando cómo integrar agentes en tus procesos, este es el momento de pensar en la gobernanza. En Altya Studio podemos ayudarte a diseñar una estrategia de automatización con IA que incluya sandboxes, permisos versionados y buenas prácticas de seguridad desde el inicio. La potencia de los agentes no tiene por qué venir acompañada de incertidumbre.

Fuente: www.docker.com