Introducción
Un agente de IA como Claude Code o Codex instala paquetes, ejecuta llamadas a APIs externas y consume credenciales en nombre de un usuario. El problema concreto es que los grants que hacen útil a ese agente —bind mounts, tokens de amplio alcance, reglas de firewall abiertas— viven dispersos en el shell history, dashboards internos y la memoria del ingeniero que los configuró. No existe un artefacto revisable, versionable ni auditable que capture qué permisos necesita un agente para funcionar. Docker identificó esta fragmentación como el mismo problema que OCI resolvió para formatos de imagen en 2017 y anunció el 24 de septiembre en WeAreDevelopers que la Sandbox Kit Specification v3, bajo licencia Apache 2.0, se dona a la CNCF. La idea: un agente, sus herramientas y su lista tipada de hosts, credenciales y volúmenes se empaquetan dentro de una imagen OCI ordinaria.
Para equipos de infraestructura y seguridad, esto cambia el modelo de gobernanza de agentes autónomos. En lugar de revisar un Dockerfile genérico o confiar en configuraciones implícitas del runtime, un equipo de seguridad puede auditar un descriptor declarativo con capabilities versionadas, pinneado por digest, que viaja por el mismo registry, scanner y pipeline de firma que cualquier otra imagen. La limitación inmediata: Docker Sandboxes, la implementación en microVM con kernel propio, es hoy el único runtime conforme.
Qué ocurrió
La Sandbox Kit Specification llegó a v3 con un cambio arquitectónico clave: un Kit dejó de ser un tipo de artefacto propio. No tiene media type custom ni archivo sidecar. El manifest contiene una única declaración —vnd.docker.sandbox.kit.descriptor— que permite construir el Kit con docker buildx build, extraerlo con docker pull, escanearlo con Trivy o Grype, firmarlo con Cosign y usarlo como base en un FROM. Fijar el digest del manifest fija contenido y permisos como una unidad atómica; no puede modificarse uno sin invalidar el otro.
Las declaraciones de permisos son capabilities tipadas y versionadas, por ejemplo com.docker.sandbox/network-policy@2 o com.docker.sandbox/credential@1. En el ejemplo de la spec con GitHub CLI, el Kit permite tráfico hacia api.github.com pero deniega DELETE sobre /repos/**. La regla de resolución es explícita: deny gana siempre. Docker construyó Kits de referencia junto con AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks y Snyk, entre otros. El CTO de la CNCF, Chris Aniszczyk, respaldó la donación comparándola con la contribución del formato de imagen y runc que derivó en la creación de OCI.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de plataforma que ya gestionan imágenes OCI en registries internos, la adopción es casi transparente: los pipelines de CI/CD, scanners de vulnerabilidades y herramientas de signing (Cosign, Notary) operan sobre Kits sin modificaciones. El descriptor introduce gramática nueva y semántica por capability que exige capacitación, pero no rompe la toolchain existente. Un equipo de seguridad puede escribir políticas de admisión en Kyverno o OPA que inspeccionen el descriptor y rechacen Kits que declaren capabilities fuera de una lista permitida.
El riesgo operativo principal es la dependencia de un único runtime conforme. Docker Sandboxes ejecuta agentes en microVMs con kernel propio, lo que aísla el agente del host, pero no hay implementación alternativa validada. Si un equipo necesita ejecutar un Kit en Kubernetes, en un entorno AWS con Firecracker, o en un sandbox interno con gVisor, hoy no tiene runtime conforme que interprete el descriptor. La portabilidad del formato está demostrada; la portabilidad de la ejecución, no. Hasta que la gobernanza de la CNCF se formalice en un programa con nivel de madurez definido, Docker mantiene la spec y pide feedback sobre duties que no se pueden expresar.
Detalles técnicos
Un lanzamiento de un Kit combina un workload Kit —que aporta el root filesystem— con cualquier número de mixin overlays. Los mixins se ordenan por el grafo de dependencias provides/requires, no por el orden de flags en la línea de comandos. La resolución falla si un requires no se satisface o si dos Kits proveen el mismo nombre. Las declaraciones superpuestas se reconcilian: las reglas de red se unifican (union), las incompatibles generan error. Cada descriptor se reduce a un conjunto normalizado de grants. Un runtime que gatea actualizaciones puede registrar ese conjunto y bloquear cualquier versión que lo amplíe, incluyendo una que elimine una regla de deny existente.
Las credenciales soportan gestión por proxy: un runtime conforme inyecta el token real en las requests hacia los dominios declarados, y dentro del sandbox solo existe un valor sentinel. El agente nunca ve el secret real. El Kit solo solicita permisos; el host decide si los otorga. Sin un runtime conforme, la anotación en el manifest es inerte: no aplica, no bloquea, simplemente no existe. Docker incluye dos suites de conformance con la spec: una para validar artefactos Kit y otra para validar runtimes. El proyecto vive en el repositorio docker/sandbox-kit-spec y se puede experimentar con el CLI sbx:
# Construir un Kit
docker buildx build -t ghcr.io/org/agent-kit:latest .
# Ejecutar con un Kit de permisos
sbx run ./hello –kit ./gh
# Inspeccionar el descriptor
docker manifest inspect ghcr.io/org/agent-kit:latest | jq ‘.annotations[«vnd.docker.sandbox.kit.descriptor»]’
Las capabilities declaradas siguen un esquema com.docker.sandbox/
{
«com.docker.sandbox/network-policy@2»: {
«allow»: [{«host»: «api.github.com», «methods»: [«GET», «POST»]}],
«deny»: [{«host»: «api.github.com», «methods»: [«DELETE»], «path»: «/repos/**»}]
}
}
Qué deberían hacer los administradores y equipos técnicos
Primero, auditen los agentes de IA que ya corren en su infraestructura. Identifiquen qué tokens, bind mounts y reglas de firewall se conceden de forma ad hoc. Documenten cada grant en un inventario: servicio, scope del token, dominio de red, propietario. Ese inventario es el input directo para escribir los primeros Kits de su organización.
Segundo, clonen el repositorio docker/sandbox-kit-spec y ejecuten los ejemplos con el CLI sbx en un entorno aislado. Valíden la conformance de su runtime actual contra la suite correspondiente. Si usan Docker Sandboxes, confirmen la versión mínima que soporta el descriptor v3. Si no lo usan, evalúen la brecha: hoy no hay runtime alternativo conforme, así que la spec funciona como formato de declaración, no como mecanismo de enforcement.
Tercero, integren la inspección del descriptor en sus pipelines de admisión. Un policy de OPA que rechace imágenes cuyo vnd.docker.sandbox.kit.descriptor declare capabilities no listadas en una allowlist organizacional es viable desde hoy, sin depender del runtime. Complementen con Cosign para firmar Kits y verificar la firma antes de desplegar:
cosign sign –key cosign.key ghcr.io/org/agent-kit:latest
cosign verify –key cosign.pub ghcr.io/org/agent-kit:latest
Cuarto, monitoricen la evolución de la gobernanza en la CNCF. La spec está bajo Apache 2.0 en GitHub, pero no se ha anunciado aceptación formal en un programa ni nivel de madurez. Trátenla como una propuesta técnica en incubación, no como un estándar terminado.
Conclusión
La Sandbox Kit Specification resuelve un problema real: los permisos de agentes de IA no tienen un artefacto portable, versionable ni auditable. Empaquetarlos como imágenes OCI con capabilities tipadas es una decisión arquitectónica sólida que aprovecha toda la toolchain de registry, firma y escaneo que DevOps ya opera. La limitación estructural es que la ejecución depende de un runtime que hoy solo existe en una implementación. Hasta que la CNCF defina gobernanza formal y aparezcan segundos implementadores, la spec entrega un formato de declaración útil para auditoría y políticas de admisión, pero no un mecanismo de enforcement multiplataforma. Para equipos que ya gestionan agentes en Docker Sandboxes, el valor es inmediato. Para el resto, es una señal temprana de hacia dónde va la industria.
Fuentes
- https://www.infoq.com/news/2026/10/docker-sandbox-ai-agent/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global