Sandbox para agentes de IA: Docker y máquinas virtuales

Lo que cubre este artículo

• Por qué los agentes de IA deben estar aislados
• Qué significa una sandbox en el contexto de agentes
• Cómo funciona Docker como sandbox ligera
• Cuándo tiene sentido una máquina virtual
• Cómo funcionan el aislamiento del sistema de archivos y de red

Introducción

Los agentes de IA son interesantes porque realizan tareas de forma autónoma. Acceden a herramientas, leen archivos, ejecutan comandos e interactúan con otras APIs. Pero precisamente esa libertad es la que los hace peligrosos. Un agente que accede sin control al sistema operativo puede causar daños graves.

Una sandbox es un área limitada donde el agente trabaja. Lo que sucede dentro de la sandbox permanece allí. Los archivos, procesos y conexiones de red quedan aislados del resto del sistema. En este artículo te mostramos cómo construir este tipo de entorno usando Docker y máquinas virtuales.

Si te interesa profundizar en los conceptos fundamentales de agentes de IA, vale la pena revisar Tool Calling y la introducción a la operación segura.

Por qué la sandbox es importante para agentes de IA

Los agentes tienen frecuentemente posibilidades ilimitadas si no los restringimos. Un pequeño error en el prompt o una instrucción mal interpretada puede llevar a que el agente elimine archivos, lea contraseñas o envíe contactos a internet.

Una sandbox evita que un fallo en el agente afecte al sistema completo. Ofrece:

• Restricción del acceso al sistema de archivos
• Limitación de capacidades de red
• Control sobre los procesos y recursos permitidos
• Recuperación simple mediante el reinicio de la sandbox
• Separación entre el agente y datos sensibles del usuario

Las sandboxes no son un sustituto de las aprobaciones humanas o los guardrails, pero constituyen un fundamento técnico importante. Siempre deben considerarse en conjunto.

Qué es una sandbox, explicado brevemente

Una sandbox es como un patio de juegos cerrado. El agente puede trabajar dentro, pero no puede simplemente atravesar la puerta e ir al resto de la casa. Técnicamente se logra usando características del sistema operativo como namespaces, cgroups, capabilities y redes virtuales.

Los namespaces aíslan los procesos. Los cgroups limitan CPU, RAM y disco. Los capabilities restringen qué derechos root tiene un proceso. Una red virtual permite filtrar el tráfico de datos.

Docker utiliza todas estas características del kernel de Linux para construir contenedores. Una máquina virtual va un paso más allá e inicia un sistema operativo propio. Ambos enfoques tienen su justificación según el nivel de amenaza y el aislamiento requerido.

Para quién es este artículo

El artículo está dirigido a personas que comienzan con agentes de IA en local o en un servidor. Debes sentirte cómodo trabajando con la terminal. Experiencia con Docker es útil, pero no obligatoria.

Este texto es para ti si:

• Quieres ejecutar un agente de IA con herramientas como Bash o Python
• Deseas evitar que un agente modifique archivos involuntariamente
• Planeas usar Docker o máquinas virtuales para el aislamiento
• Quieres entender qué nivel de aislamiento se ajusta a tu escenario

Términos importantes

Término	Explicación
Sandbox	Un entorno aislado donde se ejecuta un proceso con restricciones.
Contenedor	Un entorno de aislamiento ligero basado en el mismo kernel.
Docker	Una plataforma para construir y ejecutar contenedores.
VM	Máquina virtual. Un sistema operativo independiente sobre hardware simulado.
Namespace	Una característica del kernel que separa procesos entre sí.
Cgroup	Una característica del kernel que limita recursos como RAM y CPU.
Capabilities	Derechos root específicos que puede poseer un proceso.
Volume	Una carpeta montada en el contenedor que comparte datos con el host.
Image	Una plantilla de solo lectura para un contenedor.
Layer	Un nivel del sistema de archivos de una imagen de contenedor.

Docker como sandbox

Docker es la forma más rápida de aislar un agente de IA. Un contenedor se inicia en cuestión de segundos y requiere poco overhead. Defines cuáles archivos, redes y derechos recibe el contenedor.

Un comando típico para una sandbox robusta se ve así:

docker run -d \
  --name kisandbox \
  --read-only \
  --tmpfs /tmp \
  --cap-drop all \
  --cap-add chown \
  --network none \
  mein-agent-image

Este comando realiza varias cosas:

• --read-only hace que el sistema de archivos raíz sea de solo lectura.
• --tmpfs /tmp permite operaciones de escritura temporales solo en RAM.
• --cap-drop all elimina todos los derechos especiales.
• --cap-add chown agrega selectivamente un único derecho.
• --network none desactiva el acceso a la red.

Para archivos que el agente debe procesar, utilizas volumes. Asegúrate de exponer solo carpetas específicas y no montes rutas sensibles como /etc o /home. Encontrarás más conceptos fundamentales sobre Docker en nuestro artículo sobre Docker Basics.

Máquinas virtuales

Una máquina virtual es el tipo de sandbox más potente. Emula hardware completo e inicia un sistema operativo propio. Incluso si un atacante o agente defectuoso compromete la VM, el sistema host está mucho mejor protegido que con un contenedor.

Las VMs son especialmente adecuadas cuando:

• Deseas probar tareas de alto riesgo
• Necesitas sistemas operativos diferentes
• Quieres una frontera clara entre el host y el agente
• Planeas hacer snapshots antes y después de las ejecuciones

La desventaja: las VMs requieren más recursos. Cada VM ejecuta su propio sistema operativo. En servidores domésticos con RAM limitada esto se vuelve restrictivo rápidamente. Herramientas como Proxmox, virt-manager o VirtualBox simplifican la gestión.

Si quieres configurar tu propio servidor, encontrarás ayuda en nuestro artículo sobre Ubuntu.

Aislamiento del sistema de archivos

El aislamiento del sistema de archivos es especialmente importante para agentes de IA que acceden a archivos mediante herramientas. Por defecto, un contenedor puede acceder a archivos dentro de su propio sistema de archivos. Cuando montas volumes, abres deliberadamente accesos.

La mejor práctica es usar volumes de solo lectura donde solo se permite la lectura:

docker run -d \
  -v /home/benutzer/daten:/data:ro \
  mein-agent-image

El :ro significa solo lectura. El agente puede leer los archivos pero no modificarlos. Para salidas defines un directorio de escritura separado que el agente puede escribir pero no releer en caso de que sea necesario.

También es recomendable que el contenedor se ejecute como un usuario que no sea root. Agrega un usuario propio en tu Dockerfile:

RUN useradd -m agent
USER agent

De esta forma, un proceso que atraviesa los límites del contenedor no puede actuar directamente como root en el host.

Aislamiento de red

El aislamiento de red protege contra que un agente envíe datos a internet o consulte servicios internos que no están permitidos. Docker ofrece varios modos de red:

• bridge: Estándar. El contenedor tiene acceso de red limitado.
• none: Sin red.
• host: El contenedor comparte el stack de red del host. Evita este modo.
• container:NAME: El contenedor comparte la red de otro contenedor.

Para agentes que no necesitan estar en línea, none es frecuentemente la mejor opción. Si se requiere acceso a un endpoint de API local, creas una red bridge y permites selectivamente puertos individuales:

docker network create agent-net
docker run -d --network agent-net --name ollama ollama/ollama
docker run -d --network agent-net -e OLLAMA_HOST=http://ollama:11434 mein-agent-image

De esta forma, el agente solo se comunica con Ollama, no con el resto de la red ni con internet.

Errores comunes a evitar

1. Ejecutar el contenedor como root: El proceso dentro del contenedor debe ser un usuario no root separado. Root en el contenedor no es un verdadero root, pero sigue siendo arriesgado.
2. Demasiadas capabilities: --privileged o capabilities ALL otorgan al agente muchos más permisos de los necesarios. Elimina todo y añade solo lo que realmente precises.
3. Usar la red del host: --network host elimina la aislación. Evita este modo con agentes.
4. Montar directorios críticos: Montar /, /etc o /home concede acceso directo a archivos sensibles del host.
5. Sin límites de recursos: Sin límites de cgroup, un agente defectuoso puede consumir toda la RAM o CPU.
6. Descargar imágenes débiles de internet: No todas las imágenes son seguras. Usa solo fuentes confiables y escanea imágenes buscando vulnerabilidades.
7. Olvidar snapshots: Con una VM, crea un snapshot antes de ejecuciones importantes. Así podrás revertir rápidamente si algo falla.

Hardware, costos y seguridad

Los contenedores Docker funcionan en casi cualquier hardware que soporte Linux. Un servidor doméstico simple o un VPS son suficientes para la mayoría de agentes. Las VMs requieren más RAM y espacio en disco porque cada sistema invitado funciona de forma independiente.

Los costos provienen principalmente del hardware, no del software. Docker y herramientas de virtualización como Proxmox o virt-manager son gratuitos. Las VMs en la nube se facturan según los recursos utilizados.

En cuanto a seguridad, un aislamiento más profundo ofrece protección mejor pero consume más recursos. Los contenedores son suficientes para la mayoría de configuraciones domésticas. Las VMs tienen sentido cuando ejecutas código muy sensible o potencialmente peligroso. Combina siempre las sandboxes con aprobaciones humanas y guardrails para evitar errores humanos.

Enlaces relacionados

• Operación segura
• Seguridad de agentes en perspectiva
• Aprobación humana
• Configurar guardrails
• Tool Calling
• Fundamentos de Docker
• Configuración de Ubuntu Server

Preguntas frecuentes

¿Qué es una sandbox?

Una sandbox es un entorno de ejecución limitado donde un proceso solo puede acceder a recursos definidos.

¿Cuál es la diferencia entre Docker y una VM?

Docker comparte el kernel del host y es ligero. Una VM ejecuta su propio sistema operativo y ofrece mayor aislación, pero consume más recursos.

¿Debo iniciar un agente como root?

No. Un proceso de agente siempre debe ejecutarse como un usuario no root separado, tanto en contenedores como en VMs.

¿Qué son las capabilities?

Las capabilities son permisos especiales granulares en Linux. Definen qué acciones puede realizar un proceso, incluso si es root.

¿Qué es un volumen de solo lectura?

Un volumen de solo lectura permite a un contenedor leer datos del host pero no escribir en ellos.

¿Mi agente necesita red?

Solo si necesita alcanzar APIs externas o modelos remotos. Para tareas puramente locales puedes desactivar la red.

¿Qué significa --network none?

Esta opción de Docker desactiva completamente el acceso a la red del contenedor.

¿Son los contenedores lo suficientemente seguros para agentes de IA?

Para la mayoría de entornos domésticos y de desarrollo, sí. Para código muy sensible o potencialmente peligroso, considera una VM.

¿Qué es un snapshot?

Un snapshot es una copia del estado en un momento específico al que puedes volver después. Las VMs suelen ofrecer esta funcionalidad.

¿Puedo ejecutar múltiples agentes en un contenedor?

Sí, pero es recomendable aislar cada agente en su propio contenedor para evitar interferencias.

¿Qué es un Dockerfile?

Un Dockerfile es un archivo de texto con instrucciones a partir de las cuales Docker construye una imagen.

¿Qué tan importantes son los límites de recursos?

Muy importantes. Sin límites, un agente defectuoso puede paralizar el host. Los cgroups y las banderas de Docker ayudan.

Referencias

1. Docker Documentation - https://docs.docker.com/
2. Docker Security Cheat Sheet - https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html
3. Linux Capabilities - https://man7.org/linux/man-pages/man7/capabilities.7.html
4. NixOS Wiki: Namespaces y Cgroups - https://wiki.nixos.org/wiki/Namespaces