La mayoria de anuncios sobre seguridad para agentes se quedan en dos extremos malos: o son puro miedo corporativo, o son checklist generico que podrias pegar sobre cualquier app. Docker intento algo bastante mas concreto entre el 12 de mayo de 2026 y el 2 de junio de 2026: describio una capa de gobernanza para agentes y luego la aterrizo en una guia practica con cuatro dominios que si cambian decisiones reales de despliegue.

La idea base es incomoda, pero correcta: el agente no vive solo en tu app. Vive en el runtime donde ejecuta comandos, monta archivos, alcanza red, ve secretos y llama tools. Si no controlas esa capa, tu "policy" es mas consejo que enforcement.

Guia oficial de Docker con los cuatro dominios de seguridad para agentes en produccion

La noticia no es el dashboard; es el lugar donde ponen el control

Docker plantea AI Governance como una consola central para decidir cuatro cosas:

que red puede tocar el agente;
que rutas del filesystem puede montar;
que credenciales puede ver durante la sesion;
y que tools o servidores MCP puede invocar.

Eso importa porque el propio post de Docker lo dice sin rodeos: el dano serio de un agente suele entrar por dos caminos. O ejecuta codigo y toca el sistema directamente, o usa una tool para actuar sobre otro sistema. Si solo gobiernas uno de los dos, sigues dejando una salida abierta.

Para un builder pequeno esto se traduce a una pregunta mucho mas simple: tu agente esta aislado de verdad o solo esta obedeciendo un prompt que dice "no hagas X"?

Los cuatro dominios que si deberias revisar

Docker ordena el problema mejor de lo que suele verse en contenido de agentes. No habla solo de "seguridad". Lo parte en superficies separadas.

1. Aislamiento de ejecucion

La documentacion de Sandboxes dice que cada sandbox tiene su propio daemon de Docker, filesystem y red dentro de una microVM aislada. Eso reduce bastante el dano de darle al agente una capacidad operativa real: puede instalar paquetes, correr contenedores y modificar archivos sin tocar tu host.

2. Control de acceso a tools

En el post de seguridad, Docker insiste en algo que muchos equipos todavia minimizan: el agente no solo hereda permisos por API, tambien hereda riesgo por tool selection. Un catalogo o gateway MCP mal curado mete herramientas de mas, credenciales de mas y contexto muerto de mas.

3. Identidad y credenciales

Aqui esta uno de los puntos mas utiles del anuncio. No basta con "guardar secretos en un vault". Tambien importa que secreto ve cada sesion, por cuanto tiempo y hacia donde puede salir. Si el agente puede leer un token amplio y luego tiene salida libre a red, el problema ya no es teorico.

4. Monitoreo de runtime

La parte menos glamorosa suele ser la mas importante. Docker habla de eventos estructurados para cada evaluacion de policy. Eso sirve para algo que casi siempre falta cuando un piloto de agentes escala: evidencia de que paso, quien lo disparo y que regla lo dejo pasar o lo bloqueo.

Donde esto pega para trafico cualificado

Las queries fuertes aqui no son "que es un agente". Son cosas como:

docker ai governance
secure ai agents
mcp tool governance
sandbox policy for ai agents

Ese trafico es mas pequeno, pero mucho mas util. Llega gente que ya esta intentando correr Claude Code, Codex, Cursor o clientes MCP con permisos reales y ya entendio que el riesgo no se resuelve con un README amable.

Ademas, en espanol todavia hay poco contenido que conecte MCP, sandbox, credenciales y red como un solo problema operativo. Casi todo se publica por separado.

Documentacion oficial de Docker Sandboxes con aislamiento de microVM, daemon propio y red separada

Lo que yo haria antes de comprar cualquier narrativa de "agent security"

Usaria este anuncio como checklist, no como propaganda:

Define que carpetas necesita montar el agente y cuales no.
Cierra salida de red por default y abre solo dominios concretos.
Separa secretos por sesion y por tarea, no por maquina completa.
Reduce el numero de tools MCP visibles al contexto que esa persona realmente usa.
Exige logs utiles antes de discutir escala interna.

Si una plataforma no puede responder a esas cinco preguntas, todavia no te esta ofreciendo gobernanza. Te esta ofreciendo comodidad.

Mi lectura

Docker no resolvio todo el problema de seguridad para agentes. Pero si puso el foco en el sitio correcto: el runtime donde el agente corre y las puertas concretas por donde sale del prompt hacia el mundo real.

Eso vuelve esta nota mejor que el hype normal alrededor de "AI security". No intenta vender que el agente es seguro porque alguien lo vigila despues. Intenta mover enforcement a red, filesystem, credenciales y MCP desde el principio.

Si estas armando una base mas practica antes de abrir tools a modelos con mas autonomia, esta noticia conversa bien con nuestra guia de arquitectura de un agente en produccion. Y si tu problema inmediato es bajar riesgo sin matar productividad, el criterio mas sano sigue siendo este: menos tools, menos red, menos secretos, mas aislamiento.