Skip to content
BotServBotServ
SandboxingDockerAislamientoSeguridadEjecución de código

Sandboxing para Agentes IA

Sandboxing para agentes IA. Docker, Firejail, gVisor, aislamiento, ejecución segura de código y ejemplos prácticos.

S

schutzgeist

8 min read
Sandboxing para Agentes IA

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íaAislamientoRendimientoComplejidadCaso de uso
DockerContenedorBuenoMedioSandbox estándar
FirejailProcesoMuy buenoBajoAislamiento ligero
gVisorKernelMedioAltoAlta seguridad
nsjailProcesoMuy buenoMedioBasado en procesos
VMCompletoPobreAltoAislamiento 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 none o 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-only para que el agente no pueda modificar archivos.
  • Eliminar capacidades: usa --cap-drop ALL para desactivar todas las capacidades Linux.
  • Sin nuevos privilegios: usa --security-opt no-new-privileges para 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

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?

Sandboxing es el aislamiento del 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.

¿Por qué necesito sandboxing?

Los agentes de IA que ejecutan código son peligrosos. Un agente manipulado (inyección de prompts) puede ejecutar código malicioso. En una sandbox no hay problema, porque el agente no tiene acceso al sistema host.

¿Qué tecnología de sandbox debo usar?

Docker es el estándar. Firejail es más ligero. gVisor ofrece seguridad adicional. Para aislamiento máximo usa VMs. La elección depende de los requisitos de seguridad y rendimiento.

¿Cómo uso Docker como sandbox?

Crea una imagen Docker con Python y dependencias. Ejecuta el contenedor con —network none, —memory, —cpus, —read-only, —cap-drop ALL y —security-opt no-new-privileges.

¿Qué es Firejail?

Firejail es una sandbox ligera para Linux. Aísla procesos sin el overhead de Docker. Útil para ejecutar código simple.

¿Qué es gVisor?

gVisor es una sandbox de Google que actúa como una capa de seguridad adicional sobre Docker. Filtra las llamadas al sistema y proporciona un aislamiento más fuerte que los contenedores puros.

¿Cómo evito el acceso a la red?

Con Docker usa —network none. Si el agente necesita alcanzar Ollama, crea una red Docker interna que contenga solo Ollama y el agente, pero sin conexión a Internet.

¿Cómo limito los recursos?

Usa —memory para memoria, —cpus para CPU y —rlimit-fsize para tamaño de archivos. Establece también timeouts para evitar bucles infinitos.

¿Cómo construyo un agente de código con sandbox?

El modelo escribe código, lo ejecutas en Docker (con todos los flags de seguridad), devuelves el resultado al modelo. El agente puede probar código sin riesgo.

¿Es suficiente sandboxing por sí solo?

No. Combina sandboxing con permisos de herramientas (qué herramientas puede usar el agente), protección contra inyección de prompts (prevenir manipulación) y auditoría (trazabilidad).

Fuentes y lecturas adicionales

Volver al blog
Share:

Entradas relacionadas