Agentes de IA en sandbox con Docker: qué aísla y qué no

Docker puede limitar los daños que cause un agente de IA, pero un contenedor no es por sí solo una barrera de seguridad. Los espacios de nombres (namespaces) dan a un proceso una vista restringida de archivos, procesos y redes. Los cgroups pueden limitar recursos si los configuras. Los bind mounts, el socket de Docker, las capacidades elevadas, el modo privilegiado, los dispositivos, los secretos y los ajustes de red pueden volver a abrir el acceso al host o a otros sistemas.

noHuman Team es una aplicación nativa para macOS y Windows, no un sandbox de agentes basado en Docker. Más abajo se explican sus ventajas e inconvenientes en seguridad. Las recomendaciones sobre Docker de este artículo sirven si construyes o gestionas por tu cuenta un agente en contenedor.

Por qué los agentes de IA necesitan límites

Un agente puede escribir archivos, usar gestores de paquetes, ejecutar código generado, visitar páginas no fiables y llamar a servicios externos. Cada capacidad abre una vía a errores o a entradas maliciosas.

Algunos escenarios de riesgo habituales:

• Un comando de limpieza demasiado amplio borra más archivos de los previstos
• Una dependencia o un script descargado lee los secretos disponibles
• El contenido web intenta desviar al agente mediante inyección de prompts
• Una compilación fallida entra en un bucle de reintentos y consume recursos
• Un agente envía material confidencial a un servicio no previsto

Docker puede limitar algunas de estas vías. No puede decidir qué instrucción es de fiar, quitar los secretos que hayas inyectado ni proteger una ruta del host que hayas montado a propósito con permisos de lectura y escritura.

Qué ofrece realmente un contenedor de Docker

En un host Linux, los contenedores usan funciones del kernel como los namespaces y los cgroups. En macOS y Windows, Docker Desktop suele ejecutar contenedores Linux dentro de una máquina virtual gestionada. Por eso, dónde está exactamente la barrera depende del host, del entorno de ejecución y de la configuración.

Un contenedor con una configuración normal puede tener:

• Una vista del sistema de archivos construida a partir de su imagen y su capa de escritura
• Su propio espacio de nombres de procesos
• Un espacio de nombres de red independiente
• Un conjunto configurado de capacidades de Linux
• Controles de CPU y memoria, si se establecen límites

Estos controles reducen por defecto lo que un proceso puede ver y hacer. No equivalen a un ordenador físico independiente, y no todos están activados ni son restrictivos por defecto.

Host or Docker Desktop VM
└── Container boundary
    ├── image and writable layer
    ├── namespaced processes
    ├── container network
    ├── explicitly mounted host paths
    ├── injected secrets and environment variables
    └── configured capabilities and devices

Es en la mitad inferior de esa lista donde fallan muchas suposiciones de seguridad.

Las vías de acceso que importan

Bind mounts y volúmenes

Un bind mount expone una ruta del host al contenedor. Si se monta con permisos de lectura y escritura, el agente puede modificar o borrar archivos de esa ruta. Un montaje de solo lectura reduce el riesgo de escritura, pero sigue exponiendo los datos a cualquier proceso del contenedor.

Monta el directorio más acotado que necesite la tarea. No montes un directorio personal, uno de credenciales ni una carpeta de trabajo amplio solo por comodidad.

services:
  agent:
    volumes:
      - ./task-workspace:/workspace:rw
      - ./reference-data:/reference:ro

Por eso la carpeta de trabajo compartido no es un «buzón» sellado. Es una vía de acceso real, y tienes que revisar su alcance y su modo.

El socket de Docker

Montar /var/run/docker.sock permite a un contenedor controlar el demonio de Docker. En muchas instalaciones, ese control sirve para iniciar contenedores privilegiados o montar rutas del host. Trata el acceso al socket de Docker como un privilegio alto, no como una comunicación normal entre contenedores.

Modo privilegiado, capacidades y dispositivos

--privileged, las capacidades concedidas en exceso, los dispositivos del host y los perfiles de seguridad débiles amplían lo que puede hacer un contenedor. Empieza con los privilegios mínimos, elimina las capacidades que no necesites y vuelve a añadir solo lo que requiera la tarea.

Ejecutar como usuario sin privilegios de root es una buena defensa en profundidad. No convierte en seguro un contenedor privilegiado o con montajes peligrosos.

Acceso a la red

La red predeterminada de los contenedores suele permitir conexiones salientes. Según la plataforma y la red, un contenedor también puede llegar a otros contenedores, a servicios del host o a dispositivos de la red local.

Define a qué debe poder llegar el agente. Separa las cargas de trabajo en redes adecuadas y aplica controles de salida fuera de Docker cuando importe restringir los destinos. Una red de contenedores por sí sola no es un cortafuegos de salida completo.

Secretos y variables de entorno

Parte de que el agente y el código que ejecute pueden usar cualquier secreto disponible dentro del contenedor. Opta por credenciales de corta duración y con alcance limitado. No des por hecho que un contenedor impide la exfiltración si el proceso tiene el secreto y, además, acceso saliente a la red.

Los límites de recursos reducen el impacto, pero no eliminan el riesgo

Los límites de CPU y memoria pueden evitar que una carga de trabajo consuma todos los recursos configurados. Hay que establecerlos: Docker no deduce límites seguros para un agente.

services:
  agent:
    mem_limit: 2g
    cpus: 2

Comprueba la sintaxis y el comportamiento en las versiones de Compose y del entorno de ejecución que uses. Ten en cuenta también los límites de procesos, el crecimiento del almacenamiento, la rotación de registros y los tiempos de espera. Un límite de memoria no impide que se agote el disco ni que se hagan llamadas caras a API externas.

El host puede seguir ralentizándose con mucha carga, sobre todo si varios contenedores comparten la misma máquina virtual de Docker Desktop. Prueba los límites en las máquinas donde se ejecutarán los agentes.

Una base más segura para agentes en contenedores

Úsala como lista de revisión, no como certificación:

1. Usa una imagen dedicada y mínima. Fija las dependencias y reconstruye a partir de fuentes revisadas.
2. Ejecuta como usuario sin privilegios de root. Plantéate usar espacios de nombres de usuario o Docker sin root si son compatibles.
3. Evita el modo privilegiado. Elimina las capacidades innecesarias y no expongas dispositivos del host.
4. No montes nunca el socket de Docker salvo que el control del demonio sea un requisito explícito. Si lo es, aísla esa carga de trabajo del resto.
5. Acota los montajes. Opta por el acceso de solo lectura para el material de referencia y una carpeta de trabajo propio con escritura para los resultados.
6. Establece límites de recursos y de ejecución. Cubre memoria, CPU, procesos, almacenamiento, registros, tiempo real de ejecución y gasto externo.
7. Restringe las vías de red. Permite solo los destinos y los nodos que necesite el flujo de trabajo.
8. Usa credenciales con alcance limitado. Rótalas y evita secretos de larga duración en imágenes o archivos de entorno.
9. Mantén actualizados el host, Docker, las imágenes y las dependencias. Los escapes de contenedor y las vulnerabilidades de la cadena de suministro son una posibilidad real.
10. Registra y revisa las acciones. Conserva los comandos, las llamadas a herramientas, las aprobaciones y los eventos de red relevantes.

Docker frente a máquinas virtuales y sandboxes más robustos

Los contenedores y las máquinas virtuales resuelven problemas distintos.

Usa una máquina virtual o un entorno de ejecución en sandbox si tienes que ejecutar código hostil o imponer una barrera más sólida entre inquilinos. Dentro de esa barrera puedes seguir usando Docker para empaquetar.

Los contenedores y las máquinas virtuales no son barreras de seguridad intercambiables. Hay que valorar el modelo de amenazas, la configuración, la plataforma del host y el entorno de ejecución.

Cómo aborda noHuman Team el aislamiento

Actualmente, noHuman Team ejecuta cada noHuman como un proceso nativo supervisado en macOS o Windows. No promete un aislamiento completo del sistema de archivos respecto a la cuenta del usuario.

Sus controles abordan riesgos distintos:

• En las conexiones de Claude y ChatGPT gestionadas por la pasarela, los noHumans usan credenciales provisionales y la pasarela local añade la autenticación del proveedor
• Cada agente tiene su propio estado de trabajo y sus perfiles de navegador, y todos colaboran en una carpeta de trabajo que elige el usuario
• Los controles de aprobación rigen las acciones sensibles según el nivel de autonomía configurado
• Los presupuestos por agente y los límites de turnos acotan el trabajo desatendido

Los inicios de sesión nativos y las vías alternativas pueden guardar credenciales reales en los archivos de cada noHuman. Un proceso nativo puede seguir accediendo a los datos que permita la cuenta del sistema operativo; las carpetas separadas no son un sandbox del sistema de archivos. Elige con cuidado la carpeta de trabajo, revisa los permisos y usa una máquina virtual u otro sandbox si necesitas una barrera estricta en el sistema de archivos. La guía de cuentas de IA explica cómo se guardan las credenciales y cómo se accede a ellas.

Cómo elegir el nivel de aislamiento adecuado

Pregúntate:

• ¿El agente ejecuta código procedente de internet?
• ¿Qué datos del host debe leer o escribir?
• ¿Qué secretos recibirá?
• ¿Puede llegar a servicios internos o a la red local?
• ¿Qué pasa si su proceso, una dependencia o una instrucción son maliciosos?
• ¿Necesitas protección frente a errores, frente a código hostil o frente a ambos?

Para una compilación de confianza en una carpeta de trabajo acotado, un contenedor reforzado puede ser adecuado. Para código no fiable con datos sensibles del host cerca, usa una barrera más sólida y elimina la conectividad innecesaria.

Puntos clave

• Docker reduce el acceso por defecto, pero el aislamiento real lo determina la configuración
• Los bind mounts exponen datos del host, y los montajes de lectura y escritura permiten cambiar archivos del host
• El acceso al socket de Docker, el modo privilegiado, los dispositivos, las capacidades, las redes y los secretos merecen una revisión específica
• Los límites de recursos deben configurarse y no cubren todas las formas de agotamiento
• noHuman Team es una aplicación nativa para macOS y Windows; si tu modelo de amenazas lo exige, añade aparte un aislamiento más sólido

Preguntas frecuentes

¿Es Docker lo bastante seguro para un agente de IA?

Puede ser adecuado para un modelo de amenazas definido, si está reforzado y monitorizado. No es seguro solo porque el proceso esté dentro de un contenedor. Revisa los montajes, el acceso al demonio, los privilegios, las vías de red, los secretos, los límites y las actualizaciones del host.

¿Puede un contenedor de Docker acceder a los archivos del host?

Sí, cuando se montan rutas del host o cuando otra vía privilegiada da acceso al host. Por defecto, un contenedor normal no puede explorar cualquier ruta del host, pero un bind mount expone exactamente lo que configures, con los permisos de lectura o escritura que indiques.

¿Puede un contenedor llegar a mi red local?

A menudo, sí. El comportamiento depende de la plataforma y de la configuración de red. No confundas el acceso saliente predeterminado con una lista de permitidos restringida. Prueba y aplica la política de red que necesites.

¿Puede escaparse un contenedor de Docker?

Puede ocurrir por vulnerabilidades del entorno de ejecución o del kernel y por configuraciones peligrosas. Mantén actualizada toda la pila, reduce los privilegios y usa una capa de aislamiento más sólida cuando las consecuencias de un escape sean inaceptables.

¿Son los contenedores de Docker tan seguros como las máquinas virtuales?

Por regla general, no. Una máquina virtual tiene un kernel invitado independiente, mientras que un contenedor Linux estándar comparte el kernel con su host o con la máquina virtual de Docker Desktop. Cuál te conviene depende del modelo de amenazas y de las restricciones operativas.

¿Ejecuta noHuman Team los agentes en Docker?

No. La aplicación actual ejecuta procesos nativos supervisados en macOS y Windows. Usa controles de credenciales, aprobaciones, carpeta de trabajo, presupuestos y ejecución, pero no promete un aislamiento del sistema de archivos a nivel de contenedor.

¿Quieres un equipo local nativo con controles de aprobación visibles? Consigue noHuman Team para macOS o Windows. Si tu modelo de amenazas exige la barrera de un contenedor o de una máquina virtual, añádela tú en lugar de dar por hecho que la aplicación nativa ya la ofrece.