Proteger tu servidor de agentes IA: sandboxing, firewall y monitorización

14 min de lectura·Matthieu·monitoringlinuxfirewalldockersecurityai-agents|

Los agentes IA ejecutan acciones arbitrarias, consumen recursos impredecibles y procesan entradas no confiables por diseño. Esta guía asocia cada amenaza con un control Linux concreto y comandos probados.

Los agentes IA no son servicios normales. Un servidor web gestiona peticiones HTTP predecibles. Un agente IA ejecuta llamadas a herramientas arbitrarias, lanza subprocesos, hace peticiones HTTP salientes y consume recursos en picos impredecibles. Si una inyección de prompt tiene éxito, el agente se convierte en un atacante con los privilegios que le hayas dado.

Esta guía trata cada agente IA como código no confiable. Cada sección empieza con una amenaza concreta y la asocia con un control Linux que puedes verificar. Los comandos funcionan en cualquier VPS con Debian 12 o Ubuntu 22.04+, con cualquier framework de agentes: OpenClaw, Claude Code, n8n, LangChain, CrewAI o configuraciones personalizadas.

Requisitos previos: Un VPS con acceso root, conocimientos básicos de Linux y SSH (seguridad básica de VPS cubre lo esencial), y al menos un agente IA que quieras proteger. Esta guía asume que ya has completado el hardening inicial del servidor (hardening SSH).

¿Qué hace de los agentes IA una amenaza de seguridad diferente?

Los servicios tradicionales tienen un conjunto acotado de comportamientos. Un proceso Nginx sirve archivos y hace proxy de peticiones. El comportamiento de un agente IA depende de su entrada, que tú no controlas. Tres propiedades hacen que los agentes sean distintos de cualquier otra cosa que ejecutes en un servidor:

  1. Ejecutan acciones arbitrarias. Los agentes con tool-calling ejecutan comandos de shell, escriben archivos y hacen peticiones HTTP basándose en la salida del LLM.
  2. Consumen recursos impredecibles. Un bucle de razonamiento puede disparar la CPU al 100% durante minutos. Un agente descontrolado puede quemar tokens de API en segundos.
  3. Procesan entradas no confiables por diseño. El objetivo de un agente es aceptar lenguaje natural y actuar en consecuencia.
Amenaza Vector de ataque Impacto Control
Ejecución de comandos shell Inyección de prompt vía entrada de usuario o salida de herramienta Compromiso total del sistema Aislamiento de usuario, sandbox en contenedor
Exfiltración de datos El agente envía secretos vía HTTP/DNS a un dominio del atacante Robo de credenciales, fuga de datos Firewall de salida, filtrado DNS
Agotamiento de recursos Bucle de razonamiento infinito o llamadas recursivas a herramientas Caída del servidor, otros servicios afectados Límites de CPU/memoria con cgroup
Filtración de credenciales El agente registra o memoriza claves API del entorno Robo de claves API, movimiento lateral Inyección de secretos, aislamiento de entorno
Movimiento lateral Un agente comprometido pivota a otros servicios Compromiso total de la infraestructura Segmentación de red, mínimo privilegio

¿Cómo aíslo un agente IA con un usuario Linux dedicado?

Crea un usuario de sistema dedicado para cada agente sin shell de login, sin acceso sudo y con un directorio home restringido. Este es el control más simple con mayor impacto. Si un agente es comprometido, el atacante hereda solo los permisos de ese usuario, no root.

sudo useradd --system --create-home --shell /usr/sbin/nologin agent-worker

Restringe el directorio home para que otros usuarios no puedan leer los archivos del agente:

sudo chmod 750 /home/agent-worker

Verifica que el usuario existe y tiene el shell correcto:

getent passwd agent-worker

La salida muestra una salida como esta:

agent-worker:x:998:998::/home/agent-worker:/usr/sbin/nologin

Fíjate bien: el shell es /usr/sbin/nologin. Esto significa que nadie puede conectarse por SSH como este usuario ni abrir una sesión interactiva. El proceso del agente se ejecuta como este usuario vía systemd, no vía login.

Si tu agente necesita escribir archivos temporales, crea un directorio dedicado:

sudo mkdir -p /home/agent-worker/tmp
sudo chown agent-worker:agent-worker /home/agent-worker/tmp
sudo chmod 700 /home/agent-worker/tmp

Verifica los permisos:

ls -la /home/agent-worker/

Qué consigue esto: Incluso si un atacante logra ejecución de código mediante inyección de prompt, queda confinado a /home/agent-worker sin capacidad para leer archivos de otros usuarios, escalar a root ni modificar binarios del sistema.

¿Cómo ejecuto un agente IA en un sandbox Docker?

Ejecutar tu agente dentro de un contenedor Docker añade una segunda barrera de aislamiento. El contenedor tiene su propio sistema de archivos, namespace de procesos y pila de red. Combinado con flags de seguridad, limita lo que un agente comprometido puede hacer, incluso con ejecución de código.

¿Qué flags de seguridad Docker debo usar para agentes IA?

Usa todas las restricciones que tu agente pueda tolerar. Empieza con todo bloqueado y relaja solo lo que falle. Este es un comando docker run de producción para un agente IA:

docker run -d \
  --name ai-agent \
  --user 1000:1000 \
  --read-only \
  --tmpfs /tmp:size=100M,noexec,nosuid \
  --cap-drop ALL \
  --security-opt no-new-privileges:true \
  --security-opt seccomp=/etc/docker/seccomp-agent.json \
  --memory 2g \
  --memory-swap 2g \
  --cpus 1.5 \
  --pids-limit 100 \
  --network agent-net \
  --restart unless-stopped \
  --env-file /etc/agent/env \
  your-agent-image:latest

Qué hace cada flag:

Flag Propósito Por qué importa para agentes
--user 1000:1000 Ejecutar como no-root dentro del contenedor Evita escapes del contenedor vía exploits de root
--read-only Sistema de archivos raíz en solo lectura Bloquea instalación de malware, manipulación de configuración
--tmpfs /tmp:size=100M,noexec,nosuid Temp escribible sin ejecución El agente puede escribir archivos temporales pero no ejecutar binarios desde /tmp
--cap-drop ALL Eliminar todas las capabilities de Linux Sin CAP_NET_RAW (sniffing de paquetes), sin CAP_SYS_ADMIN (mount), nada
--security-opt no-new-privileges:true Impedir escalación de privilegios vía setuid Bloquea que un agente comprometido obtenga root mediante binarios setuid
--pids-limit 100 Limitar número de procesos Detiene fork bombs de un agente descontrolado
--memory 2g / --memory-swap 2g Techo de memoria fijo, sin swap Evita que el OOM killer mate otros servicios
--cpus 1.5 Límite de CPU El agente no puede privar de recursos a otros servicios

Verifica que el contenedor está ejecutándose con la configuración de seguridad correcta:

docker inspect ai-agent --format '{{.HostConfig.SecurityOpt}}'

Salida esperada:

[no-new-privileges:true seccomp=/etc/docker/seccomp-agent.json]

Comprueba que se ejecuta como no-root:

docker exec ai-agent whoami

Debería devolver el usuario no-root, no root.

Perfil seccomp personalizado para agentes IA

El perfil seccomp por defecto de Docker bloquea unas 44 syscalls peligrosas. Para agentes IA, puedes restringirlo más. Crea /etc/docker/seccomp-agent.json:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 1,
  "archMap": [
    {
      "architecture": "SCMP_ARCH_X86_64",
      "subArchitectures": ["SCMP_ARCH_X86", "SCMP_ARCH_X32"]
    }
  ],
  "syscalls": [
    {
      "names": [
        "read", "write", "close", "fstat", "lseek", "mmap", "mprotect",
        "munmap", "brk", "rt_sigaction", "rt_sigprocmask", "ioctl",
        "access", "pipe", "select", "sched_yield", "mremap", "msync",
        "mincore", "madvise", "dup", "dup2", "nanosleep", "getpid",
        "socket", "connect", "sendto", "recvfrom", "sendmsg", "recvmsg",
        "bind", "listen", "accept", "getsockname", "getpeername",
        "setsockopt", "getsockopt", "clone", "execve", "exit",
        "wait4", "kill", "uname", "fcntl", "flock", "fsync",
        "fdatasync", "truncate", "ftruncate", "getdents", "getcwd",
        "chdir", "openat", "newfstatat", "readlinkat", "fchmodat",
        "set_tid_address", "exit_group", "epoll_wait", "epoll_ctl",
        "tgkill", "futex", "set_robust_list", "get_robust_list",
        "epoll_create1", "pipe2", "clock_gettime", "clock_nanosleep",
        "prlimit64", "getrandom", "memfd_create", "statx",
        "rseq", "close_range", "poll", "getuid", "getgid",
        "geteuid", "getegid", "arch_prctl", "sigaltstack",
        "rt_sigreturn", "accept4", "pread64", "pwrite64",
        "writev", "readv", "sched_getaffinity"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Este perfil permite solo las syscalls necesarias para un proceso de agente típico en Python/Node.js. Todo lo demás, incluyendo mount, ptrace, reboot, kexec_load e init_module, devuelve un error de permisos.

Establece los permisos correctos en el perfil:

sudo chmod 644 /etc/docker/seccomp-agent.json
sudo chown root:root /etc/docker/seccomp-agent.json

Prueba que el contenedor arranca con el perfil personalizado:

docker run --rm --security-opt seccomp=/etc/docker/seccomp-agent.json alpine echo "seccomp works"

Si ves seccomp works, el perfil es válido.

Para un hardening de Docker más profundo incluyendo modo rootless, consulta Docker security hardening. Para el problema de interacción Docker/UFW, consulta Docker UFW fix.

¿Cómo bloqueo a un agente IA el acceso a internet?

Amenaza: Un agente comprometido exfiltra secretos haciendo peticiones HTTP salientes a un servidor controlado por el atacante, o codifica datos en consultas DNS. Por defecto, UFW permite todo el tráfico saliente.

Establece una política de denegación por defecto para el tráfico saliente y luego permite solo los endpoints que tu agente necesita:

sudo ufw default deny outgoing
sudo ufw default deny incoming

Permite el tráfico saliente esencial:

# DNS resolution (required for all outbound)
sudo ufw allow out 53/udp

# Allow outbound HTTPS to reach AI provider APIs
sudo ufw allow out 443/tcp

# Allow outbound HTTP for package updates only
sudo ufw allow out 80/tcp

Permite SSH entrante (para no quedarte fuera):

sudo ufw allow in 22/tcp

Activa el firewall:

sudo ufw enable

Verifica las reglas:

sudo ufw status verbose

La salida muestra Default: deny (incoming), deny (outgoing) en la parte superior, seguido de tus reglas de permitir.

¿Cómo limito el tráfico saliente solo a los endpoints API que necesita mi agente?

Las reglas anteriores todavía permiten HTTPS saliente a cualquier destino. Para un control más estricto, restringe el tráfico saliente a rangos IP específicos. Esto requiere iptables porque UFW no soporta filtrado por destino basado en dominio.

Primero, resuelve el endpoint API de tu proveedor de IA:

dig +short api.anthropic.com
dig +short api.openai.com

Luego crea reglas iptables para esas IPs. Crea /etc/iptables/agent-egress.rules:

#!/bin/bash
# Agent egress whitelist - update IPs when providers change

# Anthropic API (check current IPs with: dig +short api.anthropic.com)
ANTHROPIC_IPS="104.18.0.0/16"

# Drop all outbound from agent user except whitelisted destinations
iptables -A OUTPUT -m owner --uid-owner agent-worker -d $ANTHROPIC_IPS -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner agent-worker -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner agent-worker -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner agent-worker -j DROP

sudo chmod 700 /etc/iptables/agent-egress.rules
sudo bash /etc/iptables/agent-egress.rules

Verifica que el usuario del agente no puede alcanzar hosts arbitrarios:

sudo -u agent-worker curl -s --max-time 5 https://example.com && echo "FAIL: egress not blocked" || echo "OK: egress blocked"

La salida esperada es OK: egress blocked.

Nota sobre exfiltración DNS: Las reglas anteriores permiten DNS en el puerto 53. Un atacante sofisticado puede codificar datos en consultas DNS, enviando secretos como subdominios (por ejemplo, sk-ant-api-key.attacker.com). Para cerrar esta brecha, apunta el DNS del agente a un resolver local como unbound configurado con una zona de política de respuesta (RPZ) que bloquee consultas a dominios no permitidos.

Instala y configura un resolver local:

sudo apt install -y unbound

Edita /etc/unbound/unbound.conf.d/agent-dns.conf:

server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow

    # Only allow resolution of specific domains
    local-zone: "." deny
    local-zone: "anthropic.com." transparent
    local-zone: "openai.com." transparent
    local-zone: "ubuntu.com." transparent
    local-zone: "debian.org." transparent

sudo systemctl enable --now unbound
sudo systemctl status unbound

Luego configura el contenedor o servicio systemd de tu agente para usar 127.0.0.1 como resolver DNS en lugar del predeterminado del sistema. En Docker, añade --dns 127.0.0.1 a tu comando docker run.

¿Cómo aplico rate limiting a los endpoints API de un agente IA?

Amenaza: Un endpoint API de agente expuesto es bombardeado por bots o abusado mediante intentos automatizados de inyección de prompt. Sin rate limiting, cada petición desencadena llamadas costosas a APIs de LLM.

Si expones tu agente a través de Nginx, añade rate limiting en la capa de reverse proxy. Añade a tu configuración de Nginx:

http {
    # 10 requests per second per IP for agent endpoints
    limit_req_zone $binary_remote_addr zone=agent_api:10m rate=10r/s;

    # Stricter limit for prompt submission endpoints
    limit_req_zone $binary_remote_addr zone=agent_prompt:10m rate=2r/s;

    server {
        listen 443 ssl;
        server_name agent.example.com;

        location /api/agent/ {
            limit_req zone=agent_api burst=20 nodelay;
            limit_req_status 429;
            proxy_pass http://127.0.0.1:8080;
        }

        location /api/agent/prompt {
            limit_req zone=agent_prompt burst=5 nodelay;
            limit_req_status 429;
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

Prueba la configuración:

sudo nginx -t && sudo systemctl reload nginx

Verifica que el rate limiting está activo enviando peticiones rápidas:

for i in $(seq 1 30); do curl -s -o /dev/null -w "%{http_code}\n" https://agent.example.com/api/agent/; done

La salida muestra respuestas 200 seguidas de respuestas 429 cuando se alcance el límite.

¿Cómo limito el uso de CPU y memoria de un agente IA?

Amenaza: Un bucle de razonamiento o una llamada recursiva a herramientas dispara la CPU al 100% durante minutos. Sin límites, el agente priva de recursos a SSH, monitorización y otros servicios. En un VPS compartido, esto puede provocar throttling del proveedor o suspensión automática.

Límites de recursos en Docker

Si tu agente se ejecuta en Docker, los flags --memory y --cpus de la sección de contenedores ya gestionan esto. Verifica que los límites se aplican:

docker stats ai-agent --no-stream

Comprueba que MEM USAGE se mantiene por debajo de MEM LIMIT y que CPU % no supera los cores asignados.

Límites cgroup con systemd para agentes sin contenedor

Si tu agente se ejecuta directamente en el host (no en Docker), usa systemd para aplicar límites cgroup v2. Crea un servicio systemd con controles de recursos:

sudo systemctl edit --force --full ai-agent.service

[Unit]
Description=AI Agent Service
After=network.target

[Service]
Type=simple
User=agent-worker
Group=agent-worker
WorkingDirectory=/home/agent-worker
ExecStart=/home/agent-worker/run-agent.sh
Restart=on-failure
RestartSec=10

# Resource limits
MemoryMax=2G
MemoryHigh=1536M
CPUQuota=150%
TasksMax=100

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=tmpfs
PrivateTmp=true
ReadWritePaths=/home/agent-worker/data

# Secrets
EnvironmentFile=/etc/agent/env

[Install]
WantedBy=multi-user.target

MemoryMax=2G es un techo fijo. El OOM killer termina el agente si lo supera. MemoryHigh=1536M es un límite blando. El kernel reclama memoria de forma agresiva por encima de este umbral, ralentizando al agente antes de llegar al límite fijo. CPUQuota=150% permite 1,5 cores de CPU. TasksMax=100 previene fork bombs.

Activa e inicia el servicio:

sudo systemctl enable --now ai-agent.service

enable hace que sobreviva a reinicios. --now lo inicia de inmediato.

Verifica que el servicio está corriendo y los límites están aplicados:

sudo systemctl status ai-agent.service

Comprueba los límites cgroup:

systemctl show ai-agent.service | grep -E "(MemoryMax|CPUQuota|TasksMax)"

Salida esperada:

MemoryMax=2147483648
CPUQuota=150%
TasksMax=100

¿Cómo gestiono los secretos de agentes IA sin que se filtren?

Amenaza: Un agente registra sus variables de entorno (muchos frameworks lo hacen en modo debug), incluye claves API en el contexto del LLM o escribe credenciales en un archivo temporal. Un atacante con acceso de lectura a la memoria o los logs del agente obtiene todos los secretos.

Nunca pongas secretos en el archivo de configuración del agente, en el Dockerfile o en los argumentos de línea de comandos. Usa un archivo de entorno con permisos restringidos.

Crea el archivo de secretos:

sudo mkdir -p /etc/agent
sudo touch /etc/agent/env
sudo chmod 600 /etc/agent/env
sudo chown root:root /etc/agent/env

Añade tus secretos:

sudo tee /etc/agent/env > /dev/null << 'EOF'
ANTHROPIC_API_KEY=sk-ant-your-key-here
AGENT_DB_PASSWORD=replace-with-generated-password
EOF

Genera contraseñas fuertes en lugar de inventarlas:

openssl rand -base64 32

El servicio systemd referencia este archivo con EnvironmentFile=/etc/agent/env. El proceso del agente recibe las variables pero no puede leer el archivo en sí (propiedad de root, modo 600). Systemd lee el archivo y pasa las variables al proceso.

Verifica los permisos del archivo:

ls -la /etc/agent/env

Esperado: -rw------- 1 root root. Solo root puede leerlo.

Rotación: Cuando rotas un secreto, actualiza /etc/agent/env y reinicia el servicio:

sudo systemctl restart ai-agent.service

El agente recoge los nuevos valores sin cambios en ningún archivo de configuración.

¿Cómo monitorizo la actividad de agentes IA en un servidor Linux?

Amenaza: Un agente comprometido o defectuoso funciona en silencio. Sin monitorización, descubres el problema cuando llega la factura de la API o tu servidor es señalado por abuso.

Monitorización de recursos en tiempo real

Observa el uso de recursos en directo:

journalctl -u ai-agent.service -f

Esto transmite stdout/stderr del agente en tiempo real. Pulsa Ctrl+C para parar.

Para contenedores Docker:

docker logs -f ai-agent

Monitoriza CPU y memoria en tiempo real:

docker stats ai-agent

¿Qué reglas de auditd debo configurar para procesos de agentes IA?

Instala auditd:

sudo apt update && sudo apt install -y auditd

Crea reglas de auditoría específicas para agentes. Añade a /etc/audit/rules.d/agent.rules:

# Monitor all commands executed by the agent user
-a exit,always -F arch=b64 -S execve -F uid=998 -k agent-exec

# Monitor file access in sensitive directories
-a exit,always -F arch=b64 -S openat -F dir=/etc -F uid=998 -k agent-etc-access

# Monitor network connections by agent user
-a exit,always -F arch=b64 -S connect -F uid=998 -k agent-network

# Monitor file permission changes by agent user
-a exit,always -F arch=b64 -S chmod,fchmod,fchmodat -F uid=998 -k agent-chmod

Sustituye uid=998 por el UID real de tu usuario agente. Encuéntralo con:

id -u agent-worker

Carga las nuevas reglas:

sudo augenrules --load
sudo systemctl enable --now auditd

Verifica que las reglas están activas:

sudo auditctl -l | grep agent

La salida muestra tus cuatro reglas listadas.

Busca eventos de ejecución del agente:

sudo ausearch -k agent-exec --start recent

Alertas automatizadas

Para producción, configura un watchdog simple que alerte sobre uso alto de recursos. Crea /usr/local/bin/agent-watchdog.sh:

#!/bin/bash
# Alert if agent container exceeds 90% memory
USAGE=$(docker stats ai-agent --no-stream --format "{{.MemPerc}}" | tr -d '%')
THRESHOLD=90

if (( $(echo "$USAGE > $THRESHOLD" | bc -l) )); then
    logger -t agent-watchdog "ALERT: ai-agent memory at ${USAGE}%"
fi

sudo chmod 755 /usr/local/bin/agent-watchdog.sh

Ejecútalo cada minuto vía cron o un timer de systemd. Las alertas aparecen en syslog, que puedes reenviar a tu stack de monitorización.

¿Cómo mantengo actualizado el software de agentes IA de forma segura?

Amenaza: El software de agente sin parchear contiene vulnerabilidades conocidas. Pero actualizar a mitad de sesión puede corromper el estado o romper flujos de trabajo en ejecución.

Para agentes basados en Docker, el proceso de actualización es atómico:

# Pull the new image
docker pull your-agent-image:latest

# Stop the old container
docker stop ai-agent

# Remove the old container
docker rm ai-agent

# Start with the same flags (use the docker run command from above)
docker run -d \
  --name ai-agent \
  # ... same flags as before ...
  your-agent-image:latest

Para agentes sin contenedor:

# Check for updates to the agent
sudo systemctl stop ai-agent.service

# Update the agent (varies by framework)
# pip install --upgrade agent-framework
# npm update -g agent-tool

# Restart
sudo systemctl start ai-agent.service

# Verify it is running
sudo systemctl status ai-agent.service

Consejo de producción: Ejecuta dos instancias del agente detrás de un balanceador de carga. Actualiza una a la vez. Si la instancia actualizada falla los health checks, revierte a la versión anterior.

Mantén el sistema operativo del host parcheado por separado:

sudo apt update && sudo apt upgrade -y

Activa las actualizaciones de seguridad automáticas:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Antes y después: lo que ve un atacante

En un servidor sin proteger donde el agente se ejecuta como root sin contenedor y sin firewall:

  • Acceso total al sistema de archivos: leer /etc/shadow, claves SSH, datos de otros usuarios
  • Salida sin restricciones: exfiltrar datos a cualquier destino
  • Todas las syscalls disponibles: montar sistemas de archivos, cargar módulos del kernel, esnifar tráfico de red
  • Recursos ilimitados: tumbar el servidor con un fork bomb o una fuga de memoria
  • Acceso persistente: instalar un backdoor, añadir claves SSH, crear nuevos usuarios

Después de aplicar todos los controles de esta guía:

  • Confinado a /home/agent-worker sin acceso a archivos del sistema
  • HTTPS saliente restringido solo a endpoints API permitidos
  • ~80 syscalls disponibles (frente a las 300+), sin mount/ptrace/reboot
  • Techo fijo de 2 GB de RAM y 1,5 cores de CPU, límite de 100 procesos
  • Sistema de archivos en solo lectura, sin posibilidad de instalar software ni persistir cambios
  • Cada comando registrado por auditd con traza de auditoría consultable

El agente sigue funcionando. Puede llamar a APIs de LLM, procesar entradas y devolver salidas. Pero un agente comprometido no puede escapar de su caja.

¿Algo salió mal?

Síntoma Causa probable Solución
El contenedor se cierra inmediatamente Perfil seccomp demasiado restrictivo Ejecuta con --security-opt seccomp=unconfined temporalmente, comprueba dmesg para syscalls bloqueadas, añádelas a tu perfil
El agente no llega a la API Firewall de salida bloqueando el tráfico Comprueba sudo ufw status, verifica que la IP de destino está permitida
El agente es matado por OOM Límite de memoria demasiado bajo Aumenta MemoryMax o --memory, comprueba el uso pico real del agente con docker stats
auditd no registra Reglas no cargadas o UID incorrecto Ejecuta sudo auditctl -l para verificar, comprueba que el UID coincide con el usuario agente
Errores 429 desde Nginx Rate limit demasiado estricto Aumenta el valor de burst, comprueba si se esperan picos de tráfico legítimo
El agente no puede escribir archivos temporales --read-only sin --tmpfs Añade --tmpfs /tmp:size=100M a tu comando Docker run

Comprueba los logs del agente primero:

# Systemd service
journalctl -u ai-agent.service -n 50 --no-pager

# Docker container
docker logs --tail 50 ai-agent

Comprueba los logs de auditoría para acciones bloqueadas:

sudo ausearch -k agent-exec --start today -i

FAQ

¿Puedo ejecutar agentes IA como root de forma segura?

No. Ejecutar agentes como root significa que cualquier inyección de prompt da al atacante control total del sistema. No existe ningún control compensatorio que haga aceptable ejecutar como root. Usa siempre un usuario dedicado sin privilegios de root.

¿Necesito Docker para proteger un agente IA?

No. El aislamiento de usuarios Linux, las directivas de seguridad de systemd (ProtectSystem, NoNewPrivileges, PrivateTmp) y los límites cgroup proporcionan un aislamiento sólido sin Docker. Docker añade una barrera de contenedor, que es valiosa como defensa en profundidad. Úsalo si puedes, pero el aislamiento de usuarios por sí solo detiene la mayoría de ataques de inyección-de-prompt-a-shell-root.

¿Cuánta CPU debo asignar a un agente IA?

Empieza con 1-2 cores de CPU (CPUQuota=150% en systemd o --cpus 1.5 en Docker) y 2 GB de RAM en un VPS de 8 GB. Monitoriza el uso real con docker stats o systemctl status durante una semana y luego ajusta. Los agentes son impredecibles en su consumo: están inactivos entre peticiones y se disparan durante el razonamiento. Los límites evitan que los picos afecten a otros servicios.

¿Cómo protejo varios agentes en el mismo servidor?

Crea un usuario Linux y un contenedor separados para cada agente. Cada uno con sus propios límites cgroup, reglas de salida y traza de auditoría. Usa redes Docker para aislar el tráfico entre agentes. Nunca compartas secretos entre agentes.

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.

¿Listo para probarlo?

Ejecuta agentes de IA de forma segura en tu VPS.

Ver planes VPS
Proteger servidor de agentes IA: sandbox y firewall