Resumen
Hermes Agent para soporte de TI interno encaja mejor que Hermes para atención al cliente, porque tus usuarios son compañeros a los que puedes poner en una lista de permitidos. Brilla como ayudante personal del administrador de TI: comprobaciones de estado con cron, triaje de alertas de Datadog o Grafana y comandos reales en un servidor por SSH.
El problema aparece cuando lo abres a toda la empresa. El acceso se concede ID de usuario por ID de usuario, la separación entre administrador y usuario solo limita los comandos con barra, y la aprobación de un comando arriesgado vuelve al empleado que preguntó, no a TI. La solución son dos perfiles: un perfil "it-desk" de solo lectura para todos, con el terminal desactivado, y un perfil "ops" al que solo llegan los administradores.
Si prefieres evitar el servidor, eesel responde preguntas de TI de los empleados en Slack desde tu Confluence, actúa como primer respondedor en Jira Service Management y solo deja que tus administradores de TI aprueben acciones.
Por qué probé Hermes para TI interno
Construyo agentes de IA en eesel, y últimamente la pregunta de "¿no podemos usar simplemente Hermes?" me llega más de equipos de TI que de equipos de soporte. Tiene sentido si lo piensas. Un equipo de TI ya gestiona servidores, vive en Slack o Teams y suele haber un ingeniero al que no le molesta un archivo YAML.
Llevo tiempo en el otro lado de esto. eesel ha trabajado como primer respondedor en el servicio de TI interno de InDebted, donde un equipo de TI de 5 a 10 personas atendía solicitudes de más de 250 empleados en cinco mercados. Desvió el 15 % de las incidencias y siguió entrenándose con solicitudes pasadas hacia un objetivo del 55 %. Su Head of IT lo dijo sin rodeos:
"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."
Jason Loyola, Head of IT, InDebted
Ese trabajo me enseñó dónde está realmente el riesgo en TI interno, y no son los desconocidos. Es el compañero servicial que le pide al bot que "simplemente lo reinicie". Así que leí la documentación de Hermes de principio a fin con una pregunta en la cabeza: ¿qué pasa cuando 200 empleados pueden hablar con un agente que tiene un terminal?
Qué aporta Hermes Agent a un equipo de TI
Hermes Agent es el agente de código abierto y autoalojado de Nous Research. Tiene licencia MIT, 251,503 estrellas en GitHub y su última versión es la v0.21.5, publicada el 24 de septiembre de 2026.
Mi reseña de Hermes Agent cubre el producto completo, y mi repaso de agentes de IA de código abierto lo compara con sus pares. Para trabajo de TI importan cuatro piezas.
- Siete backends de terminal. Hermes puede ejecutar comandos en local, en Docker, por SSH o en Modal, Daytona, Vercel Sandbox o Singularity (Configuration). El backend SSH mantiene una shell persistente en un servidor remoto, y la documentación lo llama "Recommended for security" porque el agente no puede modificar su propio código (Tools).
- Un gateway de mensajería. Slack, Microsoft Teams, Google Chat, correo y más de 20 canales adicionales (Messaging Gateway), que es como la mayoría de los equipos ya gestionan el ITSM en Slack.
- Cron y webhooks. Tareas programadas y webhooks entrantes de herramientas como GitHub, GitLab y Jira, con verificación de firma HMAC (Webhooks).
- Servidores MCP. Un catálogo curado de
65servidores revisados, desactivados por defecto (MCP catalog). Si MCP es nuevo para ti, mi explicación del servidor MCP de agentes de IA cubre lo básico.
Así que es un kit real para un equipo de TI. La pregunta abierta es quién puede usarlo.
Dos trabajos, un agente
La mayoría de los planes de "Hermes para TI" que veo mezclan dos trabajos muy distintos.
El trabajo 1 es el de ayudante del administrador de TI. Dos o tres administradores le escriben por mensaje directo al agente, que ejecuta comprobaciones en servidores, hace triaje de alertas e informa de lo que encontró. Quien aprueba un comando arriesgado aquí es un administrador que lo entiende.
El trabajo 2 es la puerta de entrada de los empleados. Todos en la empresa le preguntan en #it-help "¿por qué está caída mi VPN?". Es el trabajo que la gente imagina cuando habla de IA para help desks de TI internos. El agente es el mismo y las herramientas también, pero el riesgo es muy distinto.
Todos los ejemplos de TI de la documentación de Hermes son del trabajo 1. Busqué en todo el volcado de la documentación "helpdesk", "IT support" o "employee" y no obtuve ni un resultado. Lo que muestran los ejemplos es a un operador gestionando sus propias operaciones: triaje de alertas para un canal de guardia, comprobaciones de disponibilidad y alertas de disco.
Trabajo 1: Hermes como ayudante del administrador de TI (esto funciona)
Aquí Hermes se gana su sitio. Algunos de los patrones documentados se trasladan casi sin cambios a un equipo de TI:
- Comprobaciones de estado del servidor programadas. La guía Team Telegram Assistant incluye un prompt que revisa cada 6 horas el uso de disco con
df -h, la memoria confree -hy el estado de los contenedores condocker ps, y lo entrega en un canal del equipo. - Cron solo de script, sin llamada al modelo.
hermes cron create "*/15 * * * *" --no-agent --script disk-alert.sh --deliver telegramejecuta un script simple y envía la salida (Script-only cron). Es barato, y no gastas tokens en una comprobación de disco. - Triaje de alertas desde la monitorización. La página Automation Blueprints tiene un webhook de triaje de alertas que pide una recomendación de escalado de P1 a P4 y termina con "This goes to the on-call channel."
- Fallos silenciosos. "A recurring job that keeps failing with the same error alerts you once, not on every run" (Cron). Si alguna vez has silenciado un canal de alertas ruidoso, sabrás apreciarlo.
En cuanto a herramientas, el catálogo ya incluye el stack de monitorización que usan la mayoría de los equipos de TI: Datadog, Grafana, Sentry, Better Stack y Cloudflare, todos por OAuth. Combínalos con el backend SSH y tendrás un agente que lee una alerta, revisa la máquina y te dice qué cree que falla.
Dos valores de seguridad por defecto también ayudan. Los trabajos de cron deniegan los comandos peligrosos por defecto (cron_mode: deny), así que un trabajo programado no puede hacer systemctl restart de nada a menos que lo cambies (Security). Las comprobaciones de comandos peligrosos también se ejecutan en los backends local y ssh, que es justo donde ocurre el trabajo de TI.
Eso es lo que describen los usuarios de homelab. Un comentarista de Hacker News lo ejecuta exactamente así, con un paso de aprobación y una vía de vuelta atrás:
"I use Hermes at home. [...] it's a sysadmin for my homelab. It has a read-only mcp server to check the k8s status and has it's own ssh access to fix stuff after I approve it per session. It's magical. Each morning I get a small update whether the backup ran, if pods are stuck or behaving weirdly etc... Since the entire homelab is GitOps I can always reverse a change made by the agent."
Fíjate en quién aprueba ahí: la misma persona que es dueña de los servidores. Si eres un equipo de TI pequeño con un ingeniero al que le gusta este tipo de cosas, el trabajo 1 es un buen uso para una herramienta gratuita.
Trabajo 2: Hermes como puerta de entrada de los empleados (donde se complica)
Cuando abres el mismo agente a todos, cuatro cosas de la documentación empiezan a importar. Ninguna es un error, que quede claro. Hermes se diseñó como agente de operador, y estas son las costuras por donde se nota ese diseño.
1. El acceso se concede ID por ID
Cada lista de permitidos de chat es una lista de IDs individuales: IDs de miembro de Slack, IDs de objeto de Azure AD en Teams, direcciones de correo en Google Chat (Environment variables). No encontré un comodín de dominio como *@company.com, ni tampoco un ajuste para todo el tenant o el workspace.
Los únicos interruptores de "todos", como SLACK_ALLOW_ALL_USERS y TEAMS_ALLOW_ALL_USERS, aparecen marcados como "(dev only)" en la referencia. El acceso por grupos existe, pero solo para roles de Discord. La otra vía es el emparejamiento por mensaje directo: cada empleado recibe un código y un administrador lo aprueba a mano con hermes pairing approve. Para 200 personas son 200 aprobaciones, y luego cada nueva incorporación.
El inicio de sesión único existe, pero solo para el panel web, mediante tu propio proveedor de OpenID Connect (Web Dashboard). Tampoco hay SCIM, así que cuando das de baja a alguien en Okta, no se le elimina del bot.
2. El nivel de usuario limita comandos, no herramientas
Hermes tiene una separación entre administrador y usuario, y es tentador suponer que limita lo que pueden hacer los usuarios normales. Lo que limita en realidad son los comandos con barra. Los usuarios normales obtienen los comandos que enumeres en user_allowed_commands, más /help y /whoami (Slash commands).
El chat normal no está restringido en absoluto, lo que significa que cualquier empleado permitido puede pedirle al agente cualquier cosa que sus herramientas permitan, el terminal incluido. Me topé con el mismo muro desde el lado del cliente en mi artículo de Hermes para atención al cliente.
3. Las aprobaciones van a quien preguntó
Si eres responsable de TI, este es el que subrayaría dos veces. Cuando Hermes quiere ejecutar un comando marcado, como systemctl restart, chown -R root o sed -i sobre un archivo en /etc/, pide aprobación en el mismo chat: "the agent sends the dangerous command details to the chat and waits for the user to reply" (Security).
La configuración approvals tiene mode, timeout, cron_mode y alguna opción más, pero ninguna lista de aprobadores ni forma de enviar la tarjeta a un administrador de TI o a un canal aparte. En Teams, la tarjeta tiene cuatro botones: Allow Once, Allow Session, Always Allow, Deny (Teams). Quién puede pulsarlos en un chat de grupo, la documentación no lo dice.
"Always Allow" además persiste. Los comandos aprobados se guardan en config.yaml y se "silently approved in all future sessions" (Security). Así que un clic de un empleado con prisa, y ese comando queda preaprobado para todos.
4. La memoria es compartida y no hay registro de auditoría del chat
La memoria integrada es un MEMORY.md (2.200 caracteres) y un USER.md (1.375 caracteres) por perfil, cargados en cada sesión que ejecuta ese perfil (Memory). En un bot de TI compartido, eso significa que lo que el agente guarde durante el chat de un empleado aparecerá en la sesión del siguiente. La protección que ofrece la documentación es memory.write_approval: true, que deja en espera cada guardado desde mensajería para que un administrador lo revise con /memory pending.
Un desarrollador que probó una configuración multiusuario fue más allá:
"we need a container per user, because, without modifications, if multiple users talk to the same Hermes instance then they can access each other's conversations by asking the agent."
La documentación de Hermes enumera el aislamiento entre sesiones como una de sus ocho capas de seguridad, así que trátalo como la experiencia de un desarrollador, no como un fallo documentado. Sigue siendo lo primero que probaría antes de poner en marcha un canal donde la gente pregunta por restablecimientos de contraseña.
Sobre la auditoría, la página de monitorización del gateway dice que no es "analytics, audit logs, or detailed execution traces" (Gateway monitoring). La lista de comprobación de seguridad te dice que revises "~/.hermes/logs/". Si tu equipo de TI tiene que rendir cuentas ante un auditor de SOC 2, es una brecha que tendrías que cubrir por tu cuenta.
Conectar Hermes a Slack, Teams y Google Chat
Cada app de chat tiene una forma distinta, y esas diferencias acaban decidiendo dónde puedes alojar el gateway.
| Slack | Microsoft Teams | Google Chat | |
|---|---|---|---|
| Conexión | Socket Mode (WebSocket) | Webhook HTTPS público, puerto 3978 | Pull de Cloud Pub/Sub |
| Requiere URL pública | No | Sí, con un certificado TLS real | No |
| Permisos de administrador necesarios | Instalar la app de Slack | Registro de la app con la Teams CLI en tu tenant | Administrador del workspace para publicar la app |
| Lista de permitidos por | ID de miembro de Slack | ID de objeto de Azure AD | Dirección de correo |
| En canales | Responde cuando lo @mencionan, en un hilo | Responde cuando lo @mencionan | Responde en el hilo, una sesión por hilo |
Fuentes: Slack, Teams, Google Chat.
Slack es lo más fácil. Socket Mode "works behind firewalls, on your laptop, or on a private server." Para TI, los dos ajustes que importan son channel_skill_bindings, que carga una skill cuando empieza una sesión en un canal como #it-help (los hilos la heredan), y allowed_channels, que hace que el bot ignore cualquier otro canal incluso si lo @mencionan. Una peculiaridad que conviene saber: los mensajes directos están exentos de allowed_channels.
Teams da más trabajo. "Teams delivers messages by calling a public HTTPS webhook," así que el gateway necesita un endpoint accesible y "Teams rejects self-signed certificates." El registro se hace con @microsoft/teams.cli de Microsoft ("no Azure portal needed"), que te entrega un ID de cliente, un secreto y un ID de tenant. Hay una advertencia en la documentación que tomaría al pie de la letra: sin TEAMS_ALLOWED_USERS, "anyone who can find or install your bot can interact with it."
También hay un listener de Microsoft Graph (msgraph_webhook), pero hoy alimenta sobre todo el flujo de resúmenes de reuniones de Teams (Graph webhook). No da a Hermes acceso al directorio de usuarios ni a la gestión de dispositivos, así que no esperes que restablezca contraseñas ni consulte Intune. Mi guía para automatizar el soporte en Microsoft Teams mira la vía de Teams con más amplitud.
A qué herramientas de TI puede llegar Hermes
El catálogo MCP es donde los equipos de TI suelen llevarse sorpresas. Es sólido en monitorización, pero escaso en identidad y gestión de servicios.
Jira Service Management tiene una brecha oculta. La entrada de Atlassian del catálogo describe "Jira issues and Confluence pages" y se conecta por OAuth. El servidor MCP Rovo de Atlassian sí tiene un grupo de herramientas de JSM, pero esas cuatro herramientas son de alertas de guardia y calendarios, y solo aparecen con autenticación por token de API que debe habilitar un administrador de la organización. Por la vía OAuth del catálogo, Hermes ve una solicitud como un simple work item de Jira. No hay herramienta para tipos de solicitud, colas, SLA ni aprobaciones. Mi artículo de Claude para JSM repasa el mismo servidor en detalle.
ServiceNow no tiene entrada en el catálogo. El propio servidor MCP de ServiceNow está incluido en Now Assist y en los SKU AI Native, y su servidor Quickstart trae cuatro herramientas de lectura y resumen. En el lado de código abierto, la vía es un servidor de la comunidad que configuras tú mismo en mcp_servers. Consulta mi guía de la integración MCP de ServiceNow.
Identidad y dispositivos son de hágalo usted mismo. No hay entradas de Okta, Entra, Intune, Jamf ni administración de Google Workspace. Las skills de la comunidad en skills.sh son pequeñas: la skill de ServiceNow más popular tiene 135 instalaciones, Freshservice 118, Jamf 4. La excepción es la skill persona-it-admin de Google, con 28,951 instalaciones (skills.sh). Ten en cuenta que cualquiera de ellas es código de terceros que Nous no ha revisado.
Si tu stack es Jira, Confluence y Datadog, Hermes cubre mucho. Si es ServiceNow, Okta e Intune, cuenta con tiempo de desarrollo real. Mi repaso de IA para gestión de servicios de TI cubre herramientas pensadas para ese segundo stack.
Cómo configurar Hermes de forma segura para TI interno
El patrón por el que me decantaría es separar los dos trabajos en dos perfiles. En Hermes, un perfil es un agente completamente aparte con su propia configuración, memoria, skills y tokens de bot, y un gateway puede servir a varios (Profiles).
Un desarrollador en Hacker News llegó a la misma idea, aunque por un riesgo distinto:
"My solution to the problem, which I am implementing as a Hermes plugin + custom iOS / macOS app, is simple: an airlock architecture. One Hermes profile runs with local FS access and no internet access, inside an Apple container, and one Hermes profile runs with internet access and no FS access, inside an Apple container."
Así lo construiría yo, paso a paso.
1. Ejecuta el gateway en su propia máquina
La documentación es directa: "For maximum security, run the gateway on a separate machine or VM. Set terminal.backend: ssh" (Security). Y nunca expongas el panel sin autenticación. La documentación de Docker describe "the June 2026 MCP-config persistence campaign", en la que escáneres llegaron a paneles expuestos y "drove the agent into planting an SSH-key backdoor" (Docker).
2. Desactiva el terminal en el perfil de empleados
En el perfil it-desk, añade terminal y code_execution a agent.disabled_toolsets. La documentación dice que un toolset listado ahí se elimina siempre, "even if a platform's saved config still lists it" (Configuration). Sin terminal, el problema de que "la aprobación va al solicitante" desaparece en gran parte, porque ya no queda nada peligroso que aprobar.
Eso deja trabajo de leer y derivar: responder desde tu base de conocimiento interna en Confluence o Notion, consultar un issue de Jira, abrir un ticket. Eso cubre la mayor parte del volumen de "¿cómo configuro la VPN?", y derivar el resto es simple triaje de tickets.
3. Fíjalo a un canal y a una skill
Configura allowed_channels con #it-help y vincula ese canal a una skill de TI con channel_skill_bindings. Usa también strict_mention, para que en un hilo largo el bot guarde silencio hasta que alguien le vuelva a mencionar. La documentación nombra justo este caso: "a long tech-support thread where the bot helped at the start and you'd rather it stay silent unless explicitly pinged again" (Slack).
4. Deja en espera las escrituras de memoria
Configura memory.write_approval: true en el perfil it-desk para que el chat de un empleado no pueda reescribir en silencio lo que el agente le dice después a todos los demás.
5. Blinda el perfil ops
El perfil ops recibe el backend SSH, approvals.mode: manual y una lista de permitidos con solo tus administradores de TI. Además, añade una lista approvals.deny con los comandos que nunca quieres que se ejecuten desde el chat, y evita "Always Allow" para todo lo que toque /etc/ o un servicio. La lista de bloqueo estricta rechaza rm -rf /, las fork bombs y las escrituras directas a disco sin importar nada, así que eso ya está cubierto.
6. Prueba antes de que lo vean los empleados
Hermes no ayuda con este paso. No hay forma integrada de reproducir los tickets de TI del mes pasado con el agente y ver qué habría respondido. Lo que necesitarás es un canal de pruebas, una lista de preguntas reales del pasado y a alguien que lea cada respuesta antes de que #it-help salga en vivo.
Cuánto cuesta Hermes a un equipo de TI
La licencia no cuesta nada. Ejecutarlo es otra historia.
| Partida de coste | Lo que pagas | Fuente |
|---|---|---|
| Software Hermes Agent | $0, licencia MIT | FAQ |
| Tokens del modelo vía Nous Portal | Nivel gratuito (solo modelos gratuitos), Plus $20/mo por $22 de crédito, Super $100/mo por $110, Ultra $200/mo por $220 | Nous Portal |
| Herramientas alojadas (búsqueda, navegador, voz) | Por uso, del mismo saldo | Nous Portal |
| Servidor o VM del gateway | Tu factura de nube; Teams además necesita un dominio público y TLS | Teams |
| Atlassian Rovo MCP | Gratis en todos los planes de Atlassian Cloud | Atlassian |
| Tiempo de ingeniería | Listas de permitidos, perfiles, skills, conexión MCP, revisiones | Tu equipo |
Nous Portal también te permite conectar un plan elegible de ChatGPT para la inferencia, con herramientas y alojamiento facturados aparte. Mi artículo de alternativas a Hermes desglosa las capas con más detalle.
La última línea es la que nunca aparece en una factura. Alguien tiene que ser responsable de la lista de permitidos, aprobar códigos de emparejamiento para las nuevas incorporaciones, revisar la memoria en espera y mantener el gateway parcheado. Para el trabajo 1 está bien, porque el administrador es el usuario. Para el trabajo 2 se convierte en un pequeño producto interno que ahora tienes que mantener. Un cliente que decidió no construir el suyo expresó bien el equilibrio:
"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."
an engineering lead at a crypto-hardware company, on why they bought instead of building
Hermes vs eesel para soporte de TI interno
Así se comparan en lo que un responsable de TI suele preguntar primero.
| Hermes Agent | eesel | |
|---|---|---|
| Qué es | Agente autoalojado de propósito general | Compañero de help desk con IA listo para usar |
| Dónde preguntan los empleados | Slack, Teams, Google Chat, correo, 20+ más | Slack, Google Chat, Microsoft Teams (bajo petición) |
| Quién puede aprobar acciones arriesgadas | Quien esté chateando | Solo Owners y Editors del workspace, identificados por el correo de Slack |
| Configuración de acceso | Listas de permitidos por ID de usuario o códigos de emparejamiento | Instalar la app; pregunta antes de unirse a canales |
| Fuentes de conocimiento | Servidores MCP y skills que conectas tú | Confluence, Notion, Google Drive, archivos |
| Ticketing | Jira vía Atlassian MCP; ServiceNow por tu cuenta | Primer respondedor de Jira Service Management |
| Ejecuta comandos en servidores | Sí, vía SSH | No; llama a APIs REST mediante Network Access |
| Pruebas con tickets pasados | No integradas | Simulación con tickets pasados |
| Precio | Software gratuito más tokens, alojamiento y tiempo de desarrollo | 100 créditos gratis; desde $299/mo por 500 créditos |
Fuentes: documentación de Internal Operations de eesel, aprobaciones de eesel, precios de eesel.
Para ser sincero con los límites de eesel: no ejecuta comandos de shell en tus servidores, y es a propósito. Es un compañero de service desk, no un sysadmin. Si quieres un agente que entre por SSH a una máquina y reinicie nginx, ese es el trabajo 1 de Hermes, no aquello para lo que sirve eesel. Además, eesel hoy no tiene integración con ServiceNow ni Freshservice (mi repaso de IA para Freshservice cubre ese stack), y Teams se activa bajo petición en lugar de por autoservicio.
¿Deberías ejecutar Hermes para TI interno?
Sí, para el trabajo 1. Si tienes un equipo pequeño de TI u operaciones y un ingeniero al que le gusta esto, Hermes como ayudante solo para administradores es una buena herramienta, y gratuita. Ejecútalo con el backend SSH y aprobaciones manuales, Datadog o Grafana por MCP y cron solo de script para las comprobaciones aburridas.
Con cuidado, para un it-desk de solo lectura. Si tu conocimiento vive en Confluence y tus tickets en Jira, un perfil sin terminal fijado a #it-help puede responder las preguntas de "cómo hago". Solo presupuesta el mantenimiento de la lista de permitidos y las pruebas que nadie quiere hacer.
No, para una puerta de entrada de empleados con terminal. Hasta que Hermes pueda enviar las aprobaciones a un administrador, no dejaría que 200 empleados chateen con un agente que puede ejecutar systemctl. No es una crítica a Hermes. Se construyó para el operador, y la documentación lo dice.
Si aún estás sopesando opciones, mis listas de herramientas de IA para soporte de TI y chatbots de soporte interno cubren herramientas hechas para la puerta de entrada, y mi lista de sistemas de tickets en Slack cubre el lado del ticketing.
eesel para soporte de TI interno
Si lo que realmente quieres es el trabajo 2, un help desk de TI al que los empleados puedan preguntar en Slack sin que nadie gestione un servidor, eso es lo que hace el compañero de help desk de eesel. Responde desde tu Confluence, Notion y Google Drive con la fuente enlazada, y cuando no encuentra algo, lo dice.
Lo más importante para este artículo son las aprobaciones. Cada acción se configura como Auto, Requiere aprobación o Desactivada, y cuando una ejecución empezó en Slack, la tarjeta de aprobación aterriza en ese hilo. Solo los Owners y Editors del workspace pueden aprobar, identificados por el correo de su perfil de Slack (documentación de aprobaciones). El empleado que preguntó no puede aprobar su propia solicitud.
Para TI con tickets, eesel trabaja dentro de Jira Service Management: recoge las nuevas solicitudes, responde a quien las reportó o deja una nota interna, y asigna, etiqueta y mueve issues. Y antes de tocar siquiera una solicitud real, puedes ejecutarlo contra tickets pasados y leer cada respuesta que habría dado.
Y si a tu equipo le gusta el terminal tanto como a los usuarios de Hermes, la CLI de eesel ejecuta el mismo compañero desde una shell. eesel approvals lista las acciones pendientes, eesel chat "how do I reset a password?" prueba una respuesta y cada comando imprime JSON, de modo que Claude Code o Codex pueden manejar tu configuración. ¿Necesitas que llegue a una base de datos interna de activos? Network Access le permite llamar a una API REST mientras las credenciales quedan fuera de la vista de la IA.
Puedes probar eesel gratis con 100 créditos, sin tarjeta. Conecta Slack y Confluence, hazle tus diez preguntas de TI más comunes y mira qué responde.