Sandboxing para agentes de IA
Qué cubre este artículo sobre sandboxing para agentes de IA
- Cómo ejecutar agentes de IA en entornos sandbox.
- Tecnologías de sandbox disponibles: Docker, Firejail, gVisor, nsjail.
- Cómo aislar la ejecución de código, acceso al sistema de archivos y red.
- Ejemplos prácticos para agentes de código, agentes de archivos y agentes web.
- Buenas prácticas en seguridad, rendimiento y mantenimiento.
Introducción: Sandboxing para agentes de IA explicado claramente
Los agentes de IA que ejecutan código, modifican archivos o envían solicitudes de red son peligrosos. Un agente manipulado (inyección de prompt) puede ejecutar código malicioso, eliminar archivos o extraer datos. El sandboxing es aislar el agente en un entorno sin acceso al sistema host. Si el agente hace algo dañino, solo afecta la sandbox, no el servidor.
Este artículo está dirigido a desarrolladores que construyen agentes de IA con ejecución de código o acceso al sistema. Deberías entender qué son los agentes de IA y cómo funciona Docker. Encontrarás los fundamentos de programación en Python en IRC-Coding.de.
¿Por qué necesito sandboxing?
Imagina que construyes un agente de código que escribe y ejecuta código Python. El agente recibe una tarea, escribe código y lo ejecuta. ¿Qué sucede si el agente (mediante inyección de prompt) escribe código malicioso? os.system("rm -rf /") eliminaría todo tu sistema. En una sandbox, nada sucede: el código se ejecuta aislado y el sistema host está seguro.
Sandboxing para agentes de IA brevemente explicado
El sandboxing es aislar el agente en un entorno con acceso restringido. El agente puede ejecutar código, pero solo dentro de la sandbox. El sistema de archivos, la red y los procesos están aislados. Si el agente hace algo dañino, solo afecta la sandbox.
La idea central es: el agente puede hacer cualquier cosa en la sandbox, pero nada fuera de ella.
Para quién está pensado este artículo
- Desarrolladores que construyen agentes de código.
- Responsables de seguridad que aseguran agentes.
- Administradores de sistemas que mantienen agentes en producción.
- Equipos que introducen agentes con acceso al sistema.
Se requieren conocimientos previos en Docker, agentes de IA y seguridad.
Términos importantes
- Sandbox - Entorno de ejecución aislado. Cuándo es útil: para ejecución segura de código.
- Docker - Plataforma de contenedores. Cuándo es útil: sandbox más popular.
- Firejail - Herramienta de sandbox para Linux. Cuándo es útil: aislamiento ligero.
- gVisor - Sandbox de Google para contenedores. Cuándo es útil: capa de seguridad adicional.
- nsjail - Herramienta de sandbox de Google. Cuándo es útil: aislamiento basado en procesos.
- Aislamiento - Separación entre agente y host. Cuándo es útil: el principio de seguridad.
- Agentes de IA - Lo que se aísla. Cuándo es útil: el objeto de estudio.
- Inyección de prompt - Manipulación del agente. Cuándo es útil: por qué el sandboxing es necesario.
- Permisos de herramientas - Gestión de derechos. Cuándo es útil: complementa el sandboxing.
Comparación de tecnologías de sandbox
| Tecnología | Aislamiento | Rendimiento | Complejidad | Caso de uso |
|---|---|---|---|---|
| Docker | Contenedor | Bueno | Medio | Sandbox estándar |
| Firejail | Proceso | Muy bueno | Bajo | Aislamiento ligero |
| gVisor | Kernel | Medio | Alto | Alta seguridad |
| nsjail | Proceso | Muy bueno | Medio | Basado en procesos |
| VM | Completo | Pobre | Alto | Aislamiento máximo |
Docker como sandbox
Docker es la sandbox más popular para agentes de IA. Creas una imagen con Python y dependencias, luego ejecutas el código del agente dentro del contenedor.
Dockerfile para agente de código
FROM python:3.12-slim
# Dependencias de Python
RUN pip install --no-cache-dir ollama requests
# Directorio de trabajo
WORKDIR /workspace
# Sin usuario root
RUN useradd -m agent
USER agent
# Copiar código
COPY --chown=agent:agent agent.py .
# Sin red (opcional)
# CMD ["python", "agent.py"]
Ejecutar agente en Docker
# Construir imagen
docker build -t code-agent .
# Iniciar contenedor con permisos restringidos
docker run --rm \
--network none \ # Sin red
--memory 512m \ # Límite de memoria
--cpus 1 \ # Límite de CPU
--read-only \ # Sistema de archivos de solo lectura
--tmpfs /tmp:size=100m \ # Directorio temporal
--cap-drop ALL \ # Eliminar todas las capacidades
--security-opt no-new-privileges \ # Sin escalada de privilegios
-v ./workspace:/workspace:ro \ # Montar workspace de solo lectura
code-agent
Ejecutar código Python en Docker
import subprocess
import tempfile
def execute_in_docker(code, timeout=30):
# Guardar código en archivo temporal
with tempfile.NamedTemporaryFile(mode="w", suffix=".py", delete=False) as f:
f.write(code)
code_file = f.name
# Ejecutar en Docker
result = subprocess.run([
"docker", "run", "--rm",
"--network", "none",
"--memory", "512m",
"--cpus", "1",
"--read-only",
"--tmpfs", "/tmp:size=100m",
"--cap-drop", "ALL",
"--security-opt", "no-new-privileges",
"-v", f"{code_file}:/code.py:ro",
"python:3.12-slim",
"python", "/code.py"
], capture_output=True, text=True, timeout=timeout)
return {
"stdout": result.stdout,
"stderr": result.stderr,
"returncode": result.returncode
}
Firejail como sandbox
Firejail es una sandbox ligera para Linux que aísla procesos.
Instalación
sudo apt install firejail
Ejecutar agente con Firejail
# Ejecutar agente aislado
firejail --noprofile --private-tmp --nosound --no3d \
--net=none \
--private=/tmp/agent-workspace \
--rlimit-fsize=10485760 \ # Límite de archivo de 10MB
--rlimit-nproc=10 \ # Máximo 10 procesos
python agent.py
Ejecutar código Python con Firejail
import subprocess
import tempfile
def execute_in_firejail(code, timeout=30):
with tempfile.NamedTemporaryFile(mode="w", suffix=".py", delete=False) as f:
f.write(code)
code_file = f.name
result = subprocess.run([
"firejail", "--noprofile",
"--private-tmp",
"--net=none",
"--rlimit-fsize=10485760",
"--rlimit-nproc=10",
"python", code_file
], capture_output=True, text=True, timeout=timeout)
return {
"stdout": result.stdout,
"stderr": result.stderr,
"returncode": result.returncode
}
gVisor como seguridad adicional
gVisor es una sandbox de Google que implementa filtrado de llamadas al sistema. Proporciona una capa de seguridad adicional sobre Docker.
Instalación
# Instalar gVisor
sudo apt install runsc
# Configurar Docker para gVisor
sudo tee /etc/docker/daemon.json <<EOF
{
"runtimes": {
"runsc": {
"path": "/usr/bin/runsc"
}
}
}
EOF
sudo systemctl restart docker
Ejecutar agentes con gVisor
docker run --rm \
--runtime=runsc \
--network none \
--memory 512m \
code-agent
Caso práctico 1: agente de código con Docker
class DockerCodeAgent:
def __init__(self, model="llama3.1"):
self.model = model
def execute_code(self, code, timeout=30):
# Ejecutar código en Docker
result = execute_in_docker(code, timeout)
return result
def run(self, task):
# Pedir al modelo que escriba código
code = call_ollama([
{"role": "system", "content": "Escribe código Python para la tarea."},
{"role": "user", "content": task}
])
# Ejecutar código en sandbox
result = self.execute_code(code)
# Devolver resultado al modelo
if result["returncode"] == 0:
return result["stdout"]
else:
return f"Error: {result['stderr']}"
Caso práctico 2: agente de archivos con acceso restringido al sistema de archivos
# Agente con acceso de solo lectura a /data
docker run --rm \
--network none \
-v /data:/data:ro \ # Read-only
--tmpfs /tmp:size=100m \ # Escritura solo en /tmp
file-agent
Caso práctico 3: agente web con acceso limitado a la red
# Agente solo puede acceder a Ollama, no a Internet
docker run --rm \
--network agent-network \ # Red propia
--network-alias agent \
web-agent
# Configurar red para que solo Ollama sea accesible
docker network create --internal agent-network
# Ollama en la misma red
docker run --network agent-network -d ollama
Recomendaciones de seguridad
- Sin root: nunca ejecutes el agente como root. Crea un usuario propio.
- Aislar red: proporciona acceso de red solo si es necesario. Usa
--network noneo redes internas. - Límites de recursos: establece límites de memoria y CPU para evitar consumo excesivo.
- Sistema de archivos de solo lectura: usa
--read-onlypara que el agente no pueda modificar archivos. - Eliminar capacidades: usa
--cap-drop ALLpara desactivar todas las capacidades Linux. - Sin nuevos privilegios: usa
--security-opt no-new-privilegespara prevenir escalada de privilegios. - Tiempos de espera: establece timeouts para evitar bucles infinitos.
- Auditoría: registra todas las llamadas a la sandbox. Ver Auditoría.
- Ver también: Entornos sandbox, Permisos de herramientas.
Errores comunes
- Sin sandbox: ejecutar código directamente en el host. Alto riesgo.
- Usuario root: agente ejecutado como root. Puede hacer cualquier cosa.
- Sin límite de red: agente puede enviar datos hacia afuera.
- Sin límites de recursos: agente puede sobrecargar el host.
- Sin timeout: bucles infinitos bloquean la sandbox.
- Sandbox no probada: sandbox puede tener vulnerabilidades. Prueba con código malicioso.
Enlaces relacionados
- Fundamentos de agentes de IA - Qué son los agentes de IA.
- Fundamentos de Docker - Entender Docker.
- Seguridad en Docker - Asegurar Docker.
- Aislamiento de red en Docker - Aislar redes.
- Límites de recursos en Docker - Establecer límites.
- Permisos de herramientas - Gestionar permisos.
- Entornos sandbox - Seguridad.
- Protección contra inyección de prompts - Por qué es necesaria la sandbox.
Puntos clave:
- Sandboxing aísla los agentes del sistema host.
- Docker es la sandbox más popular, Firejail es más ligero, gVisor proporciona seguridad adicional.
- Fundamental: sin root, aislar red, límites de recursos, solo lectura, timeouts.
- Los agentes de código siempre deben ejecutarse en sandbox.
- La sandbox por sí sola no es suficiente: combínala con permisos de herramientas, protección contra inyección de prompts y auditoría.
Preguntas frecuentes
¿Qué es sandboxing para agentes de IA?
¿Por qué necesito sandboxing?
¿Qué tecnología de sandbox debo usar?
¿Cómo uso Docker como sandbox?
¿Qué es Firejail?
¿Qué es gVisor?
¿Cómo evito el acceso a la red?
¿Cómo limito los recursos?
¿Cómo construyo un agente de código con sandbox?
¿Es suficiente sandboxing por sí solo?
Fuentes y lecturas adicionales
- Docker Sicherheit - Seguridad en Docker.
- Firejail - Sandbox de Linux.
- gVisor - Sandbox de Google.
- nsjail - Sandbox de procesos.


