Cómo impedir que un agente de IA ejecute comandos peligrosos en Linux: sandbox, permisos mínimos y aprobación humana

Un agente de IA conectado a Linux puede ser una herramienta poderosa para administrar servidores, revisar logs, diagnosticar fallos y automatizar tareas repetitivas. Pero también puede convertirse en un riesgo grave si tiene permiso para ejecutar comandos sin límites, modificar archivos críticos, reiniciar servicios, borrar datos o conectarse por SSH a producción sin aprobación humana.

El problema no es solo técnico. OWASP identifica riesgos específicos en aplicaciones con modelos de lenguaje, como prompt injection y excessive agency, donde un sistema basado en IA puede ser manipulado o tener demasiada capacidad de acción sobre herramientas, datos y servicios externos. En un servidor Linux, esa “agencia excesiva” puede afectar confidencialidad, integridad y disponibilidad.

1. El riesgo: cuando la IA deja de sugerir y empieza a ejecutar

Mientras una IA solo responde preguntas, el riesgo está en la calidad de la respuesta. Pero cuando la IA puede ejecutar herramientas, llamar APIs, administrar servidores o conectarse por SSH, el riesgo cambia por completo. Ya no hablamos solo de una respuesta equivocada, sino de una acción real sobre infraestructura.

OWASP advierte que la agencia excesiva puede ocurrir cuando una aplicación basada en LLM tiene demasiada autonomía, demasiados permisos o herramientas demasiado amplias. También describe escenarios donde una inyección de prompt indirecta puede hacer que el agente realice acciones no deseadas, como extraer información o ejecutar instrucciones contrarias al propósito original.

2. Regla principal: la IA no ejecuta, solicita ejecución

La arquitectura segura debe separar tres roles: el modelo de IA razona y propone; un motor de políticas decide si la acción está permitida; y un ejecutor limitado realiza la acción solo cuando se cumplen las reglas. El modelo nunca debe tener una shell libre.

Usuario humano
   ↓
Agente de IA
   ↓
Motor de políticas
   ↓
Clasificación de acción:
   - lectura permitida
   - cambio requiere aprobación
   - acción bloqueada
   ↓
Sandbox / contenedor / usuario limitado
   ↓
Ejecución controlada
   ↓
Logs, evidencia y auditoría

Este diseño coincide con el enfoque de gestión de riesgos del NIST AI RMF: gobernar, mapear, medir y gestionar riesgos durante el diseño, desarrollo, despliegue y uso de sistemas de IA. En un agente Linux, eso significa definir límites antes de conectarlo a servidores reales.

3. Clasificar comandos: lectura, cambio, peligro y bloqueo

El primer control práctico es clasificar comandos. No todos tienen el mismo riesgo. Ver espacio en disco no equivale a borrar archivos. Consultar el estado de un servicio no equivale a reiniciarlo. Leer logs no equivale a modificar configuración.

4. Crear un usuario Linux exclusivo para el agente

El agente no debe usar la cuenta del administrador, ni root, ni una llave SSH personal. Debe tener un usuario propio, sin permisos generales, sin acceso a secretos innecesarios y con un directorio de trabajo limitado.

sudo adduser --system --group --home /var/lib/ai-agent ai-agent
sudo mkdir -p /var/lib/ai-agent/work /var/log/ai-agent
sudo chown -R ai-agent:ai-agent /var/lib/ai-agent /var/log/ai-agent
sudo chmod 750 /var/lib/ai-agent /var/log/ai-agent

Este usuario debe tener permisos de lectura muy concretos y, cuando sea inevitable ejecutar tareas administrativas, debe hacerlo mediante reglas sudo específicas. El archivo sudoers permite definir qué usuario puede ejecutar qué comando, como qué usuario destino y con qué etiquetas, por lo que es una pieza crítica para aplicar privilegio mínimo.

5. Sudoers: permitir solo comandos exactos

No entregues al agente una regla como ALL=(ALL) NOPASSWD: ALL. Esa es una puerta total. Lo correcto es definir comandos exactos, sin comodines peligrosos, sin shell interactiva y sin permisos para editar archivos críticos directamente.

sudo visudo -f /etc/sudoers.d/ai-agent

# Solo comandos concretos y auditables

Cmnd_Alias AI_READONLY = /usr/bin/systemctl status nginx.service, 
/usr/bin/journalctl -u nginx.service --since *

Cmnd_Alias AI_CONTROLLED = /usr/bin/systemctl reload nginx.service

ai-agent ALL=(root) NOPASSWD: AI_READONLY
ai-agent ALL=(root) PASSWD: AI_CONTROLLED

El uso de PASSWD en acciones sensibles fuerza una barrera adicional. En entornos empresariales, incluso ese mecanismo puede no ser suficiente: conviene que el agente genere una solicitud de cambio y que una persona ejecute o apruebe la operación desde una herramienta formal.

6. SSH: nada de shell libre para el agente

Si el agente se conecta por SSH, la llave debe estar restringida. OpenSSH permite opciones en authorized_keys, como command=, restrict, no-pty y restricciones de reenvío, útiles para obligar a que una llave solo ejecute un comando o wrapper específico.

# /var/lib/ai-agent/.ssh/authorized_keys

restrict,no-pty,no-port-forwarding,no-X11-forwarding,command="/usr/local/bin/ai-agent-wrapper" ssh-ed25519 AAAA...

Con este patrón, aunque la llave sea robada o el modelo intente abrir una terminal interactiva, el servidor fuerza la ejecución del wrapper autorizado. El agente no obtiene una shell general: solo puede pedir acciones al controlador.

7. Wrapper de comandos: el candado principal

El wrapper es el programa que recibe solicitudes del agente y decide qué se puede ejecutar. Debe aceptar únicamente comandos declarados, normalizar argumentos, rechazar shell metacharacters peligrosos y registrar cada intento.

#!/usr/bin/env python3
import json
import shlex
import subprocess
import sys
from datetime import datetime, timezone
from pathlib import Path

LOG = Path("/var/log/ai-agent/commands.jsonl")

ALLOWLIST = {
"uptime": ["/usr/bin/uptime"],
"disk": ["/usr/bin/df", "-h"],
"memory": ["/usr/bin/free", "-m"],
"nginx_status": ["/usr/bin/systemctl", "status", "nginx.service", "--no-pager"],
"nginx_logs_30m": ["/usr/bin/journalctl", "-u", "nginx.service", "--since", "30 minutes ago", "--no-pager"]
}

def log_event(event):
LOG.parent.mkdir(parents=True, exist_ok=True)
event["ts"] = datetime.now(timezone.utc).isoformat()
with LOG.open("a", encoding="utf-8") as f:
f.write(json.dumps(event, ensure_ascii=False) + "\n")

def main():
if len(sys.argv) != 2:
print("Uso: ai-agent-wrapper ", file=sys.stderr)
sys.exit(2)

```
action = sys.argv[1]

if action not in ALLOWLIST:
    log_event({"action": action, "allowed": False, "reason": "not_in_allowlist"})
    print("Acción no permitida", file=sys.stderr)
    sys.exit(1)

cmd = ALLOWLIST[action]
result = subprocess.run(
    cmd,
    text=True,
    capture_output=True,
    timeout=20,
    check=False
)

log_event({
    "action": action,
    "allowed": True,
    "cmd": cmd,
    "returncode": result.returncode
})

print(result.stdout)
if result.stderr:
    print(result.stderr, file=sys.stderr)

sys.exit(result.returncode)
```

if **name** == "**main**":
main()

El punto crítico del ejemplo es que el agente no envía comandos arbitrarios. Envía nombres de acciones: disk, memory, nginx_status. El servidor traduce esas acciones en comandos exactos. Así se evita que el modelo invente argumentos peligrosos o encadene instrucciones no previstas.

8. Aprobación humana para cambios sensibles

Las acciones de cambio deben requerir aprobación humana. MCP, por ejemplo, establece que los hosts deben obtener consentimiento explícito del usuario antes de invocar herramientas, porque el protocolo permite integrar aplicaciones LLM con datos y herramientas externas.

La aprobación no debe ser un botón genérico de “aceptar”. Debe mostrar qué se va a ejecutar, en qué servidor, con qué usuario, cuál es el impacto, si existe rollback, qué evidencia se generará y cuánto tiempo se espera de indisponibilidad.

9. MCP seguro: herramientas pequeñas, claras y con permisos separados

Si el agente usa MCP para ejecutar herramientas, cada herramienta debe ser estrecha y explícita. No conviene publicar una herramienta llamada run_shell o execute_command. Es mejor publicar herramientas concretas como get_disk_usage, get_service_status, read_nginx_errors o request_service_reload.

La documentación de seguridad de MCP señala que las salvaguardas y permisos adecuados son responsabilidad de quien despliega el servidor, y que cuando las aplicaciones de IA usan MCP, el modelo determina qué herramientas invocar según las solicitudes del usuario y las descripciones disponibles. Por eso, confiar solo en la descripción de la herramienta no es una barrera suficiente.

10. Sandbox con systemd: limitar el proceso del agente

systemd ofrece opciones de sandboxing para servicios, como NoNewPrivileges, ProtectSystem, ProtectHome, PrivateTmp, RestrictAddressFamilies, CapabilityBoundingSet y otras opciones compartidas por unidades de servicio. Estas opciones ayudan a reducir lo que el proceso puede ver, modificar o usar.

[Unit]
Description=Agente IA Linux controlado
After=network-online.target

[Service]
User=ai-agent
Group=ai-agent
WorkingDirectory=/var/lib/ai-agent/work
ExecStart=/opt/ai-agent/venv/bin/python /opt/ai-agent/server.py

NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/ai-agent /var/log/ai-agent
CapabilityBoundingSet=
AmbientCapabilities=
RestrictSUIDSGID=true
LockPersonality=true
MemoryDenyWriteExecute=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
SystemCallArchitectures=native

[Install]
WantedBy=multi-user.target

El bit no_new_privs del kernel Linux impide que un proceso gane nuevos privilegios a través de execve, por ejemplo mediante bits setuid o capacidades de archivo; además, es una base importante para filtros seccomp persistentes.

11. Contenedores: ejecutar herramientas en una jaula controlada

Otra estrategia es ejecutar las herramientas del agente dentro de un contenedor sin privilegios. Docker permite opciones como --read-only, --cap-drop, --security-opt no-new-privileges y perfiles seccomp. Docker documenta seccomp como una herramienta importante para ejecutar contenedores con privilegio mínimo.

docker run --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt no-new-privileges \
  --pids-limit=128 \
  --memory=512m \
  --network=none \
  --tmpfs /tmp:rw,noexec,nosuid,nodev,size=64m \
  ai-agent-tools:latest \
  python /app/checks.py disk

Podman también es atractivo para este escenario porque muchos comandos pueden ejecutarse como usuario regular, y en modo rootless el contenedor no puede tener más privilegios que la cuenta que lo lanzó.

12. SELinux y AppArmor: contener aunque algo falle

SELinux y AppArmor permiten añadir una capa de control adicional. SELinux implementa control de acceso obligatorio y puede limitar interacciones no autorizadas entre procesos, archivos y dispositivos. Red Hat explica que, si un proceso confinado es comprometido, el daño posible queda limitado según la política aplicada.

AppArmor, por su parte, restringe capacidades y permisos mediante perfiles por programa. Ubuntu lo describe como una implementación LSM orientada a confinar aplicaciones con reglas por ruta, acceso a archivos, red y capacidades.

# SELinux
getenforce
sestatus

# AppArmor

sudo aa-status

# Logs recientes de denegaciones

sudo journalctl --since "1 hour ago" | grep -Ei "apparmor|avc|selinux"

13. No permitir comandos compuestos ni shell interactiva

Un error común es validar el primer comando y dejar pasar el resto. En Linux, una instrucción puede encadenar acciones con tuberías, redirecciones, sustituciones, variables, operadores lógicos o subcomandos. Por eso, el wrapper no debe ejecutar cadenas de shell completas.

La validación debe trabajar con argumentos estructurados, no con texto libre. El agente pide una acción; el servidor decide el comando exacto. Esa separación reduce el riesgo de prompt injection y evita que el modelo se convierta en intérprete de shell.

14. Logs completos: cada acción debe dejar huella

Sin logs, no hay control real. Debes registrar quién pidió la acción, qué recomendó el agente, qué comando se ejecutó, en qué servidor, con qué usuario, desde qué IP, cuál fue el resultado, quién aprobó y qué salida produjo.

auditd es el demonio de auditoría de Linux y escribe registros en disco; sus eventos pueden consultarse con herramientas como ausearch y resumirse con aureport. journalctl permite filtrar registros de systemd por unidad, rangos de tiempo y otros campos, lo que ayuda a revisar la actividad del servicio del agente.

# Revisar logs del servicio
journalctl -u ai-agent.service --since "24 hours ago" --no-pager

# Vigilar cambios en carpetas del agente

sudo auditctl -w /opt/ai-agent -p wa -k ai_agent_code
sudo auditctl -w /etc/sudoers.d/ai-agent -p wa -k ai_agent_sudoers
sudo auditctl -w /var/lib/ai-agent -p wa -k ai_agent_state

# Consultar eventos

sudo ausearch -k ai_agent_code
sudo ausearch -k ai_agent_sudoers
sudo aureport -f --summary

15. Política de ejecución en JSON

Una política sencilla puede separar acciones de lectura, acciones con aprobación y acciones bloqueadas. La política debe vivir fuera del prompt del modelo. El prompt no es una frontera de seguridad; el control debe estar en código, permisos y sistema operativo.

{
  "read_only_actions": {
    "disk": ["/usr/bin/df", "-h"],
    "memory": ["/usr/bin/free", "-m"],
    "uptime": ["/usr/bin/uptime"],
    "nginx_status": ["/usr/bin/systemctl", "status", "nginx.service", "--no-pager"]
  },
  "approval_required_actions": {
    "nginx_reload": ["/usr/bin/systemctl", "reload", "nginx.service"],
    "nginx_restart": ["/usr/bin/systemctl", "restart", "nginx.service"]
  },
  "blocked_categories": [
    "borrado_masivo",
    "formateo",
    "sobrescritura_de_disco",
    "descarga_y_ejecucion_remota",
    "creacion_de_usuarios",
    "modificacion_de_ssh",
    "cambio_de_firewall_sin_ticket",
    "edicion_directa_de_sudoers"
  ]
}

Este archivo debe ser propiedad de root, con permisos restrictivos. El agente puede leer la política si necesita explicar límites, pero no debe poder modificarla.

16. Separar diagnóstico de remediación

Un agente seguro puede tener bastante libertad para diagnosticar, pero muy poca para remediar. Diagnosticar implica leer métricas y logs. Remediar implica cambiar el sistema. Esa diferencia debe reflejarse en permisos.

17. Usar dry-run antes de todo cambio

Cuando una acción implique cambio, el agente debe generar primero un plan y, cuando la herramienta lo soporte, ejecutar una simulación. En Linux esto puede incluir validar configuración antes de recargar, ejecutar una actualización con modo de simulación o generar un diff antes de modificar archivos.

1. Diagnóstico de solo lectura.
2. Explicación del problema.
3. Propuesta de acción.
4. Validación previa o dry-run.
5. Presentación del impacto.
6. Aprobación humana.
7. Ejecución controlada.
8. Verificación posterior.
9. Registro completo.

Un agente maduro no debe decir “ejecuté esto porque parecía correcto”. Debe poder decir: “detecté esta evidencia, propuse este cambio, fue aprobado por esta persona, ejecuté esta acción exacta y verifiqué este resultado”.

18. Proteger secretos: la IA no debe ver todo

Un agente que lee logs, variables de entorno, archivos de configuración o repositorios puede encontrarse con contraseñas, tokens, claves API, credenciales de base de datos y llaves privadas. Por eso, el agente debe trabajar con salidas filtradas.

La seguridad de MCP también advierte sobre el manejo de permisos, consentimiento y autorización, incluyendo riesgos relacionados con tokens y scopes insuficientemente controlados.

19. Controles de red: el agente no debe poder salir a cualquier parte

Un agente comprometido puede intentar descargar herramientas, enviar datos a un servidor externo o conectarse a redes internas no autorizadas. Por eso, limita salida de red. En contenedores, una opción es ejecutar tareas de diagnóstico sin red cuando no sea necesaria. En systemd, se puede restringir familias de direcciones o combinar firewall con reglas por usuario.

Para tareas locales:
  --network=none

Para agentes internos:
permitir solo API del modelo
permitir solo servidor de logs
permitir solo repositorios oficiales necesarios

Para producción:
bloquear salida genérica
registrar conexiones
usar proxy con allowlist
prohibir descargas y ejecución directa

20. Política de cambios: nada crítico sin ticket

La aprobación humana debe integrarse con la gestión de cambios. Un reinicio de servicio crítico, una modificación de firewall, una actualización de kernel o una edición de SSH no deberían aprobarse en una ventana improvisada desde el chat. Deben quedar en un ticket o registro formal.

21. Checklist de seguridad para un agente de IA en Linux

22. Errores comunes

23. Preguntas clave

Recomendamos

En resumen

Impedir que un agente de IA ejecute comandos peligrosos en Linux exige diseñar seguridad fuera del modelo. El prompt ayuda, pero no basta. La protección real está en el sistema operativo, el wrapper de comandos, sudoers, SSH restringido, sandbox, contenedores sin privilegios, SELinux/AppArmor, logs y aprobación humana.

La mejor arquitectura es simple: el agente diagnostica, propone y explica; el motor de políticas valida; el humano aprueba cambios sensibles; y el ejecutor corre únicamente acciones autorizadas. Así se aprovecha la IA para administrar Linux sin convertirla en una shell peligrosa conectada a producción.