HomeLab Monitor 0.38 añade un agente de IA con permisos acotados

El problema no es preguntar, sino ejecutar

Consultar el estado de un homelab con lenguaje natural es útil, pero la parte delicada empieza cuando el asistente puede tocar máquinas. Reiniciar un contenedor, limpiar imágenes o reducir logs son tareas corrientes, aunque también pueden dejar un servicio fuera de juego si se automatizan sin contexto. Lo que me interesa de HomeLab Monitor 0.38 no es que añada IA, sino que intenta poner límites técnicos antes de darle capacidad de actuar. (github.com)

La versión incorpora un agente opcional integrado en el panel de HomeLab Monitor. Puede responder preguntas sobre la infraestructura usando las mismas herramientas de lectura que expone el servidor MCP del proyecto, en lugar de limitarse a contestar a partir de una descripción genérica. También puede usar modelos locales detectados en la red, entre ellos Ollama, vLLM y llama.cpp, además de otros servidores compatibles. (sikamikanikobg.github.io)

Un agente que no recibe una shell

Aquí está la decisión importante: el agente no tiene una shell libre para ejecutar lo que se le ocurra. Las operaciones disponibles pertenecen a un catálogo cerrado, con acciones como iniciar o reiniciar contenedores, limpiar imágenes colgantes, reducir la caché de compilación, descargar modelos de Ollama o comprobar el uso de disco. Eso no elimina el riesgo, pero evita convertir una petición escrita en lenguaje natural en una orden arbitraria enviada por SSH. (sikamikanikobg.github.io)

Cada host puede estar en modo Off, Passive o Active. Un host nuevo empieza en Passive, que permite únicamente lecturas, mientras que Active habilita acciones dentro de la política configurada. Además, cada acción se decide por host con los estados Deny, Ask o Allow, y el valor inicial es Deny. (sikamikanikobg.github.io)

La comprobación tampoco queda en manos del modelo. El servidor valida la política cuando el agente propone una operación y la vuelve a validar justo antes de ejecutarla, incluso después de una aprobación manual. Los contenedores protegidos incluyen el propio monitor y el servicio que entrega el modelo en uso, una protección razonable para no permitir que el agente se desconecte a sí mismo. (sikamikanikobg.github.io)

Activar menos es una buena configuración inicial

Yo empezaría dejando el agente desactivado mientras se revisan los hosts, el acceso SSH y las alertas. La documentación indica que AGENT_ENABLED=0 oculta el agente y deja las rutas /api/agent/* sin responder, mientras que ENABLE_HOST_RUN=0 mantiene apagada la ruta antigua para ejecutar comandos arbitrarios en un host. El agente no utiliza esa ruta de ejecución libre, pero conviene asegurarse de que siga cerrada. (sikamikanikobg.github.io)

environment:
  AGENT_ENABLED: "0"
  ENABLE_HOST_RUN: "0"

Cuando se decida activarlo, HomeLab Monitor exige configurar una contraseña para el panel y completar el proceso de puesta en marcha. El sistema prueba si el modelo es capaz de hacer llamadas a herramientas, porque un modelo que solo genere texto no sirve para consultar datos reales del homelab. Para automatizaciones, también recomienda comprobar que el modelo puede encadenar una llamada, leer el resultado y decidir el siguiente paso. (sikamikanikobg.github.io)

Automatizar sin perder la revisión humana

Las automatizaciones pueden partir de plantillas para tareas como limpieza de Docker, vigilancia de espacio en disco, salud de contenedores, mantenimiento del sistema o seguimiento de copias de seguridad. Se pueden programar y ejecutar en tres modos: solo informe, propuesta pendiente de aprobación o actuación dentro de la política. Esa separación es útil porque permite probar una rutina durante semanas en modo de informe antes de permitir que haga cambios. (sikamikanikobg.github.io)

Las acciones no atendidas tienen más restricciones que las ejecutadas manualmente. Las operaciones de bajo riesgo permitidas pueden realizarse solas, pero hay límites por destino y las acciones de riesgo medio, alto o que requieren privilegios esperan aprobación salvo excepciones explícitas. En concreto, reiniciar servicios con privilegios o reducir el journal no se ejecuta sin confirmación automática del usuario. (sikamikanikobg.github.io)

También hay trazabilidad. La vista de actividad registra las llamadas a herramientas, las decisiones de política, las aprobaciones y el resultado de cada ejecución, con exportación en JSON o CSV. Las acciones quedan además reflejadas en la salida del contenedor, algo práctico si quiero conservar una copia de auditoría fuera de la base de datos de la aplicación. (sikamikanikobg.github.io)

La letra pequeña importa más que el chat

Esto no convierte al agente en un administrador universal, y me parece bien. La documentación deja fuera el reinicio de máquinas, la eliminación de volúmenes y el borrado de archivos; tampoco tener una política permisiva sustituye una copia de seguridad verificada. Si una tarea exige una secuencia compleja, entiende mal el estado de una aplicación o depende de conocimiento que no está en las métricas, seguirá siendo mejor hacerla con procedimientos normales y revisión humana. (sikamikanikobg.github.io)

Usar un modelo local reduce la salida de información fuera de la red, pero no arregla por sí solo una configuración insegura del homelab. Si se elige un proveedor en la nube, se le envían la pregunta y los resultados de las herramientas que el agente ha leído, incluidos nombres de hosts, contenedores, métricas o fragmentos de logs. Antes de usar esa opción conviene revisar qué datos puede recoger el agente y qué proveedor recibirá ese contexto. (sikamikanikobg.github.io)

Tampoco asumiría que un modelo pequeño va a resolver bien tareas de varios pasos. HomeLab Monitor prueba las llamadas a herramientas y diferencia entre modelos que funcionan para el agente y modelos que no, pero la calidad de la decisión sigue dependiendo del modelo y de los datos disponibles. Para mí, el enfoque correcto es usarlo primero como capa de consulta y reporte, y habilitar solo las acciones repetibles cuyo impacto ya conozco. (sikamikanikobg.github.io)

HomeLab Monitor 0.38 no vende un piloto automático total, sino una forma de introducir automatización con frenos. Esa es la parte que merece atención: permisos por host, acciones limitadas, confirmaciones, presupuestos y registro de actividad. En un homelab, donde casi siempre hay servicios personales y configuraciones acumuladas durante años, prefiero ese tipo de agente a uno que tenga acceso ilimitado por defecto. (github.com)

Fuente: notas de la versión v0.38.0. Documentación oficial: agente de IA de HomeLab Monitor.