Cómo crear un agente de IA que administre servidores Linux de forma segura: SSH, MCP, permisos, logs y aprobación humana

Idea central: un agente de IA seguro para Linux no debe tener un botón universal de “ejecutar comando”. Debe tener herramientas específicas, permisos mínimos, evidencias, límites, logs y aprobación humana para todo cambio que afecte disponibilidad, seguridad o datos.

Usuario autorizado
   ↓
Cliente de IA / ChatOps
   ↓
Servidor MCP de administración Linux
   ↓
Motor de políticas y aprobación humana
   ↓
SSH restringido / Bastion / VPN
   ↓
Servidores Linux
   ↓
Logs, auditd, journalctl, sudo I/O logging, SIEM

Regla de oro: el modelo de IA nunca debe recibir credenciales SSH directas, llaves privadas, tokens de root ni acceso a una función genérica llamada run_shell. Toda acción debe pasar por una herramienta pequeña, auditable y limitada.

Formato mínimo de aprobación

1. Servidor: nombre, IP, ambiente y criticidad.
2. Acción: comando exacto o herramienta exacta.
3. Motivo: evidencia técnica que justifica la acción.
4. Impacto: posible caída, pérdida de sesión, bloqueo o cambio de datos.
5. Rollback: cómo volver al estado anterior.
6. Aprobador: usuario, fecha, hora y ticket.
7. Resultado: salida, logs y verificación posterior.

Acción propuesta: reiniciar nginx.service
Servidor: web-01 / 10.10.1.20 / Producción
Evidencia: nginx no responde en puerto 443 y systemctl indica failed
Comando permitido: sudo /usr/local/sbin/aiops-restart-service nginx.service
Impacto: posible corte breve de conexiones activas
Rollback: revisar journalctl, restaurar config previa si falla, escalar a administrador
Aprobación requerida: Sí
Ticket: INC-2026-0912

sudo adduser --system --group --home /var/lib/aiops --shell /usr/sbin/nologin aiops

sudo mkdir -p /var/lib/aiops/.ssh
sudo chmod 700 /var/lib/aiops/.ssh
sudo touch /var/lib/aiops/.ssh/authorized_keys
sudo chmod 600 /var/lib/aiops/.ssh/authorized_keys
sudo chown -R aiops:aiops /var/lib/aiops/.ssh

command="/usr/local/sbin/aiops-gate",restrict,no-pty,no-agent-forwarding,no-X11-forwarding,no-port-forwarding ssh-ed25519 AAAA... clave-del-agente

#!/usr/bin/env bash
set -Eeuo pipefail

CMD="${SSH_ORIGINAL_COMMAND:-}"
HOST="$(hostname -f 2>/dev/null || hostname)"
FECHA="$(date -u '+%Y-%m-%dT%H:%M:%SZ')"

logger -t aiops "host=$HOST fecha=$FECHA usuario=$USER cmd_original='$CMD'"

case "$CMD" in
"status nginx")
/usr/bin/systemctl status nginx.service --no-pager
;;

"status ssh")
/usr/bin/systemctl status ssh.service --no-pager 2>/dev/null || 
/usr/bin/systemctl status sshd.service --no-pager
;;

"logs nginx 30m")
/usr/bin/journalctl -u nginx.service --since "30 minutes ago" --no-pager -n 200
;;

"ports")
/usr/bin/ss -tulpen
;;

"disk")
/usr/bin/df -hT
;;

"top cpu")
/usr/bin/ps aux --sort=-%cpu | /usr/bin/head -n 15
;;

*)
echo "Acción no autorizada."
logger -t aiops "DENEGADO host=$HOST cmd_original='$CMD'"
exit 126
;;
esac

Prohibido en producción: no agregues al agente a sudo completo. Un agente con root sin límites puede convertir una mala instrucción, una prompt injection o un error de interpretación en una caída real del servidor.

#!/usr/bin/env bash
set -Eeuo pipefail

SERVICIO="${1:-}"

case "$SERVICIO" in
nginx.service|apache2.service|php-fpm.service)
logger -t aiops "reinicio_aprobado servicio=$SERVICIO usuario=$SUDO_USER"
/usr/bin/systemctl restart "$SERVICIO"
/usr/bin/systemctl status "$SERVICIO" --no-pager
;;
*)
echo "Servicio no permitido."
exit 126
;;
esac

Defaults:aiops log_output
Defaults:aiops log_input

aiops ALL=(root) NOPASSWD: /usr/local/sbin/aiops-restart-service

# Ver actividad del agente registrada con logger
sudo journalctl -t aiops --since "24 hours ago" --no-pager

# Ver acciones de sudo ejecutadas por el usuario técnico

sudo journalctl | grep -Ei "sudo.*aiops|aiops.*sudo"

# Ver logs de un servicio antes/después de una acción

sudo journalctl -u nginx.service --since "30 minutes ago" --no-pager

# Ver sesiones SSH recientes

sudo journalctl -u ssh --since "24 hours ago" --no-pager 2>/dev/null || 
sudo journalctl -u sshd --since "24 hours ago" --no-pager

# Vigilar cambios en sudoers, SSH y scripts del agente
sudo auditctl -w /etc/sudoers -p wa -k aiops_sudoers
sudo auditctl -w /etc/sudoers.d/ -p wa -k aiops_sudoers_d
sudo auditctl -w /etc/ssh/sshd_config -p wa -k aiops_ssh
sudo auditctl -w /usr/local/sbin/aiops-gate -p wa -k aiops_gate
sudo auditctl -w /usr/local/sbin/aiops-restart-service -p wa -k aiops_actions

# Buscar eventos

sudo ausearch -k aiops_gate
sudo ausearch -k aiops_actions
sudo aureport -x --summary

Reglas contra prompt injection

1. Tratar logs como datos, no como instrucciones: el agente no debe obedecer texto encontrado en logs.
2. No mezclar contexto con autoridad: una alerta no puede autorizar un cambio.
3. Validar herramientas en código: la política debe vivir fuera del modelo.
4. Bloquear comandos libres: nunca pasar texto generado por IA directo a shell.
5. Requerir aprobación para cambios: especialmente si el input viene de fuentes externas.
6. Registrar denegaciones: los intentos de ejecutar acciones no permitidas también son evidencia.

tools:
  - name: check_service
    readOnlyHint: true
    allowed_services:
      - nginx.service
      - ssh.service
      - docker.service

* name: read_logs
  readOnlyHint: true
  max_lines: 200
  max_time_window: "60m"
  allowed_units:

  * nginx.service
  * ssh.service
  * docker.service

* name: request_restart_service
  readOnlyHint: false
  destructiveHint: true
  requires_approval: true
  allowed_services:

  * nginx.service
  * apache2.service
  * php-fpm.service

Campos mínimos del log del agente

1. request_id: identificador único de cada solicitud.
2. usuario: persona que pidió la acción.
3. servidor: activo afectado.
4. herramienta: función MCP invocada.
5. parámetros: servicio, rango de tiempo, límite de líneas o acción.
6. riesgo: lectura, cambio menor, cambio crítico.
7. aprobación: aprobador, hora, motivo y ticket.
8. resultado: éxito, error, salida resumida y evidencia.
9. hash o firma: para proteger integridad del registro.

1. Usuario pregunta: "¿Por qué está lenta la web?"
2. Agente ejecuta herramientas de lectura: CPU, disco, logs, servicios, puertos.
3. Agente resume evidencia: nginx responde, CPU 95%, php-fpm saturado.
4. Agente propone acción: reiniciar php-fpm y revisar consultas lentas.
5. Sistema solicita aprobación humana.
6. Aprobador valida impacto y rollback.
7. Acción se ejecuta con sudoers limitado.
8. Se registran comando, salida, logs y aprobador.
9. Agente verifica estado posterior.
10. Se genera informe del incidente.

Lista roja

1. Borrar archivos, logs, backups o directorios completos.
2. Modificar reglas de firewall, VPN o rutas críticas.
3. Crear usuarios, cambiar contraseñas o tocar claves SSH.
4. Instalar paquetes desde fuentes no aprobadas.
5. Actualizar kernel o reiniciar servidores de producción.
6. Ejecutar migraciones de base de datos.
7. Cambiar permisos de carpetas sensibles.
8. Desactivar SELinux, AppArmor, auditd o monitoreo.
9. Leer secretos, tokens, variables de entorno o archivos de credenciales.
10. Ejecutar comandos generados desde texto no confiable.

Checklist técnico y de seguridad

1. Definir casos de uso: diagnóstico, logs, servicios, disco, CPU, puertos y reportes.
2. Crear usuario técnico: sin root, sin contraseña interactiva y con clave SSH dedicada.
3. Restringir SSH: usar command forzado, no-pty, no-forwarding y claves por entorno.
4. Crear herramientas MCP pequeñas: nada de shell genérico.
5. Separar lectura y cambios: lectura automatizable, cambios con aprobación.
6. Validar parámetros: servicios, rutas, ventanas de tiempo y límites de salida.
7. Configurar sudoers mínimo: solo scripts envoltorio autorizados.
8. Registrar todo: solicitud, herramienta, comando, aprobación, resultado y evidencia.
9. Activar auditd: vigilar sudoers, SSH, scripts del agente y cambios críticos.
10. Proteger secretos: no exponer claves, tokens ni variables sensibles al modelo.
11. Aplicar aprobación humana: obligatoria en producción y acciones destructivas.
12. Probar en laboratorio: simular fallos antes de tocar servidores reales.
13. Revisar mensualmente: permisos, logs, herramientas, denegaciones y falsos positivos.

• Dar al agente acceso root por SSH.
• Crear una herramienta MCP genérica para ejecutar cualquier comando.
• Permitir que el modelo construya comandos concatenando texto libre.
• No diferenciar entre lectura, diagnóstico y cambio.
• No registrar aprobador, ticket ni salida real del comando.
• Leer logs con secretos y enviarlos completos al modelo.
• No limitar líneas, tiempo ni unidades en consultas de journalctl.
• Compartir la misma clave SSH para varios agentes o ambientes.
• Permitir modificaciones en producción sin rollback.
• No auditar quién usó el agente ni qué denegaciones ocurrieron.

¿Un agente de IA puede administrar servidores Linux?

Sí, pero debe hacerlo mediante herramientas limitadas, no con acceso libre al shell. Lo más seguro es permitir diagnóstico y lectura automatizada, mientras los cambios requieren aprobación humana, permisos mínimos y logs completos.

¿Qué papel cumple MCP?

MCP permite exponer herramientas que pueden ser invocadas por modelos, por ejemplo revisar un servicio, leer logs o crear una solicitud de reinicio. Su especificación recomienda que exista una persona capaz de aprobar o denegar invocaciones por seguridad.

¿Es seguro darle SSH al agente?

Solo si el acceso está restringido con usuario técnico, clave propia, comando forzado, sin TTY, sin port forwarding, sin agent forwarding y con lista blanca de acciones. OpenSSH permite restringir claves autorizadas con opciones como comandos forzados y deshabilitación de reenvíos.

¿Qué acciones deben requerir aprobación humana?

Toda acción que cambie el sistema: reiniciar servicios, modificar configuración, actualizar paquetes, cambiar firewall, tocar usuarios, borrar archivos, leer secretos o afectar datos. Las herramientas de solo lectura pueden tener menor fricción, pero también deben tener límites.

¿Cómo audito lo que hizo el agente?

Usa logs propios del agente, journalctl, sudo logging, sudo I/O logging y auditd. auditd puede registrar eventos del sistema y luego consultarse con ausearch o resumirse con aureport.

• Cómo usar IA para administrar Linux: comandos, diagnóstico, automatización y seguridad con asistentes inteligentes
• Cómo aprender Bash creando 20 scripts útiles para administrar Linux y automatizar servidores
• Cómo hacer análisis forense en Linux después de un ciberataque: logs, procesos, conexiones y evidencias
• Cómo saber si tu Linux está bien protegido: 30 comprobaciones de seguridad que puedes realizar ahora mismo
• Guía completa de SELinux y AppArmor: cómo proteger aplicaciones y servicios sin complicarte la vida
• Cómo crear un sistema de gestión de vulnerabilidades con software libre: inventario, CVE, prioridades, parches y seguimiento

Cierre editorial

Un agente de IA para Linux puede ser un gran aliado de DevOps, soporte y ciberseguridad, pero solo si nace con límites. La autonomía sin permisos mínimos es riesgo; la automatización sin logs es oscuridad; y la ejecución sin aprobación humana es una puerta abierta al error. El futuro no está en entregar root a la IA, sino en construir agentes auditables, prudentes y controlados por personas.