En 2026, muchos agentes de IA corren en contenedores con acceso a filesystem, APIs internas, socket de Docker y secretos. Muchos equipos siguen llamando a eso «sandbox». No lo es.
Los contenedores sí aíslan procesos y sí gobiernan recursos con eficiencia: para eso están. El fallo está en tratar ese aislamiento operativo como frontera fuerte frente a cargas que pueden comportarse como adversarias. Dejan de ser suficientes cuando lo de dentro ya no es «nuestro código, revisado y confiable».
El problema no es que el modelo genere código. Es que ejecutamos ese código de forma continuada en entornos a los que seguimos tratando como si estuvieran aislados.
En KubeCon EU 2026, la charla de seguridad le puso nombre al error: los contenedores no son una frontera de seguridad; son un mecanismo para controlar el uso de recursos. Palabras que ya habías oído. Rara vez traducidas a arquitectura.
El artículo de Emir Beganovic, «Your Container Is Not a Sandbox: The State of MicroVM Isolation in 2026», dibuja el mapa: escapes en cadena, microVMs en ~125 ms, ecosistema rust-vmm, y por qué el «momento Docker» de los sandboxes de agentes ya está aquí. Este post no es un resumen de Firecracker ni un tutorial de KVM. Es lo que a mí me interesa operativamente: desmontar la falsa tranquilidad de “ya lo he metido en Docker” cuando lo que corre dentro es cada vez más autónomo y menos “vuestro código revisado”.
Una escena concreta
Imagina un agente de código local: clona un repo, ejecuta tests, baja dependencias, abre temporales, habla con Docker y reintenta solo los comandos que fallan. Ahora montas /var/run/docker.sock en ese contenedor para que «el flujo sea más cómodo».
Eso no es un sandbox. Es control del host delegado con pasos extra.
La tesis en una frase
Docker (y OCI/runc en general) empaqueta y comparte kernel. Hasta que confías en el proceso, eso es aceptable. Cuando el proceso genera y ejecuta código que nadie ha leído, a escala, contra APIs y sockets con privilegios, la frontera deja de ser el contenedor y pasa a ser el kernel común —y la superficie de syscall, capabilities, montajes y bugs del runtime.
Eso no es “Docker malo”. Es categoría error: confundir aislamiento operativo (namespaces, cgroups) con aislamiento de adversario cuando el adversario es el propio workload.
Qué estaba bien… hasta que dejó de estarlo
Durante años el trato tácito era: “El runtime lo pongo en contenedor; el host lo cuido yo; el código es nuestro.”
Ese modelo aguanta mientras el interior del contenedor es predecible y el riesgo de bug de kernel asumido frente a la comodidad.
Dos cosas lo erosionan a la vez:
- Escapes y roturas del runtime siguen apareciendo (cadena
runc/buildkit/montajes, toolkits de GPU, carreras con paths enmascarados…). No son “teoría de laboratorio”; son CVEs recientes que terminan en host si el kernel o el runtime cooperan mal. La tabla del post de Emir enlaza varios de 2024–2025; merece leerla como lista de “sí, pasa”. - Los agentes de IA ejecutan herramientas, tocan el filesystem, llaman a APIs y a veces deciden solas qué comando lanzar. El código interior no es auditable como el de un servicio versionado: es estocástico, iterativo y barato de repetir millones de veces. Ahí el contenedor deja de ser solo una decisión de empaquetado y acaba siendo «la caja que la gente cree que es una celda» —el error de categoría en una frase.
En el blog ya tocamos piezas del tablero: ejecución local potente («Cuando el exploit cabe en 732 bytes»), observabilidad y SOC en homelab (SOC proactivo con Wazuh y Kubernetes), y agentes conviviendo con Docker y Ollama (OpenClaw: troubleshooting). Este post enlaza las tres ideas: el riesgo ya no es solo “un intruso remoto”; es “código no confiable con capacidad local”.
Escenarios donde el modelo mental rompe
No hace falta Kubernetes multi‑tenant ni un APT para quedar corto de argumentos:
docker.socken el socket del host. No es “un volumen más”: es API de administración del daemon. Quien lo tenga efectivamente conduce el host desde el guest.--privileged, montajes laxos y capabilities ampliadas. Estás declarando por escrito que no te importa una frontera débil porque necesitas fuerza bruta para que algo funcione. Con agentes, eso escala cómo automatizas el error.- MCP y herramientas con acceso a disco o a repos. El modelo de amenaza incluye prompts, plugins y blobs que nadie revisó línea a línea en cada ejecución.
- Runners CI/CD que construyen imágenes, ejecutan tests arbitrarios y a veces comparten nodo con más cargas de la cuenta.
- “Lo he puesto en un pod” sin políticas de seguridad de pod, sin perfil/seccomp conscientes. Kubernetes orquesta contenedores; no redefine la física del kernel compartido.
En todos esos casos la pregunta correcta no es “¿está dockerizado?” sino “¿qué pasa si el interior es malicioso o simplemente bugueado con intención?”.
Cambio de paradigma (sin humo ni benchmark)
La utilidad práctica está en mover el modelo mental:
| Antes | Ahora |
|---|---|
| “El contenedor es el límite” | “El kernel compartido pasa a ser la frontera de seguridad real —y la superficie de ataque principal” |
| Docker como sandbox | Docker como empaquetado + gobernanza de recursos |
| VM “pesada” vs contenedor “ligero” | MicroVM/subsegundo como opción realista para workloads no confiables (Lambda, patrones tipo Firecracker, ofertas cloud) |
| Host longevo, estado acumulado | Superficies efímeras cuando el agente debe actuar (y fallar) sin arrastrar persistencia hostil |
Esto no significa “contenedores al vertedero”. Significa dejar de venderlos como sustituto de celda cuando el interior es un generador de código.
Dónde encajan gVisor, Kata, Firecracker (sin convertir el post en manual)
- gVisor: kernel en userspace que intercepta syscalls —otro “capa” con trade‑offs de compatibilidad y rendimiento, útil cuando encaja con tu stack.
- Kata / microVMs: guest kernel separado por virtualización hardware; el salto de seguridad es otra clase de bug (y otra economía de explotación), que es precisamente lo que buscas para adversario fuerte.
- Firecracker / Cloud Hypervisor: piezas del ecosistema que explican por qué “levantar una VM” dejó de ser excusa de latencia en muchos diseños cloud.
El post de Emir profundiza en comparativas y en el ecosistema Rust común; aquí solo fijamos la brújula: elegir según modelo de amenaza, no según moda.
Qué hacer en homelab y equipos pequeños (operativo)
- Separar “carga confianza alta” de “generación/ejecución de código ajeno”. Idealmente nodos distintos, cuentas distintas, o al menos namespaces/PSS y políticas deliberadas —no valores por defecto + socket peligroso.
- Tratar
--privilegedydocker.sockcomo decisiones de arquitectura, no como atajo de troubleshooting permanente. - Secrets: variables en contenedor están bien para dev; para agentes persistentes revisa fugas por logs, dumps y MCP con paths anchos.
- Observabilidad: lo que montamos con Wazuh y alertas tiene sentido después de asumir que el perímetro lógico no es el mismo que el perímetro físico (guía operativa reciente sobre Wazuh 5).
- Cuando la tarea sea “sandbox de código”, plantéate explícitamente VM/microVM, sandboxes gestionadas (cloud), o aislamientos dedicados, en lugar de reetiquetar un contenedor como “seguro”.
Conclusión
La industria no está descubriendo de repente un problema nuevo —por fin admite uno viejo: que empaquetar no es lo mismo que aislar frente a un proceso hostil.
Docker no empeoró. Lo que ejecutamos dentro, sí. Pasamos de servicios predecibles a ejecución autónoma de código manteniendo el mismo relato de aislamiento en diagramas y READMEs.
Los contenedores resolvieron el empaquetado. Los agentes de IA reactivaron el problema del aislamiento.
Eso fuerza el reconocimiento porque multiplican código ejecutado sin revisión humana y conviven en los mismos hosts donde seguimos acumlando montajes cómodos y permisos heredados.
El valor no está en repetir otro tutorial de KVM. Está en cambiar el discurso interno: de “¿está containerizado?” a “¿comparte kernel con qué?, ¿con qué privilegios, y quién ejecuta dentro?”. Para el mapa tecnológico 2026 y referencias muy trabajadas, el artículo de Emir enlazado arriba es una base sólida; aquí quería cerrar la brújula operativa con el mismo criterio con el que suele tratarse infraestructura en este blog —sin teatro DevOps.
El contenedor nunca fue la frontera.
Simplemente nos comportamos como si lo fuera.
