Guía de Seguridad del Agente Hermes para Autoalojamiento

Hola, soy Lena. Pasé la mayor parte de una tarde leyendo las páginas de seguridad antes de tocar un solo archivo de configuración. Luego volví y las leí de nuevo. La primera vez, el sistema me parecía una larga lista de opciones. La segunda vez, comencé a ver la forma de la cosa: realmente no hay una "función de seguridad" en la seguridad del Agente Hermes, hay una pila de capas independientes que cada una asume que las demás podrían fallar.

Esa perspectiva importa más de lo que pensé. La mayoría de los informes de seguridad del agente que he encontrado se leen como una lista de verificación de consejos: activa esto, configura esa bandera, estás seguro. La forma en que Hermes está realmente documentado es diferente. Es un modelo de defensa en profundidad donde cada capa hace un trabajo específico, y activar una sola no sustituye a las demás. Ninguna capa es la solución completa. Esa frase básicamente resume todo el artículo.

Este es un escrito de cómo estoy pensando en endurecer un despliegue de Hermes autoalojado que funciona a largo plazo. Todavía estoy resolviendo algunos aspectos.

El modelo de seguridad de Hermes en capas

Si lees la página oficial de seguridad cuidadosamente, el modelo tiene aproximadamente siete capas independientes — y la palabra "independiente" tiene mucho peso allí. Cada capa hace una suposición diferente sobre lo que podría salir mal. Listadas aproximadamente en el orden en que se aplican durante una llamada de herramienta:

• Autorización de usuario — verificación a nivel de gateway sobre quién puede comunicarse con el agente en absoluto
• Aprobación de comandos peligrosos — detección basada en patrones de comandos de shell antes de ejecutarse
• Escáner de contenido Tirith — escaneo previo a la ejecución basado en Rust para patrones de inyección de prompt, exfiltración de credenciales, inyección en terminal
• Aislamiento en tiempo de ejecución — local vs Docker vs SSH vs Modal vs Daytona vs Singularity
• Filtrado de credenciales — eliminación de variables de entorno para procesos hijos, listas de permitidos del entorno de subprocesos MCP, redacción de salidas
• Escaneo de archivos de contexto — AGENTS.md, SOUL.md, .cursorrules escaneados por inyección de prompt al cargarse
• Aislamiento entre sesiones — las sesiones no pueden leer el estado de otras; rutas de cron endurecidas contra traversal

Sigo volviendo a esto porque la capa que detecta un problema dado no siempre es la que uno cree. Un comando malicioso de shell podría ser detectado por la aprobación, por Tirith, o por el contenedor — o por los tres, o a veces por ninguno. Por eso desactivar una capa parece seguro hasta que deja de serlo.

El principio del que se está tomando prestado es más antiguo que los agentes. La guía conjunta Secure by Design de CISA habla sobre las configuraciones seguras por defecto: la idea es que la configuración predeterminada sea la segura, y cualquier desviación debe ser explícita. Hermes sigue esto en su mayoría: las aprobaciones están activadas por defecto, Tirith falla cerrado en modo de alta seguridad, y el gateway niega el acceso a todos los usuarios cuando no se ha establecido una lista blanca. La cuestión es que es en su mayoría, y las desviaciones importan.

Aprobación de comandos peligrosos y dónde ayuda

Aquí es donde quiero ser cuidadoso. Las solicitudes de aprobación son reconfortantes, y por eso es fácil confiar excesivamente en ellas.

Hermes mantiene una lista de patrones regex para comandos peligrosos — cosas como rm -rf, DROP TABLE, fork bombs, canalizar la salida de curl a bash, o matar el proceso del gateway. Cuando se encuentra una coincidencia, se le pide al usuario que apruebe. Tres modos: manual (preguntar siempre), smart (evaluación de riesgo asistida por LLM), off (no preguntar). También existe /yolo para la sesión que omite todo.

Lo que me sigo recordando: la detección basada en regex es fundamentalmente evadible. Un comando puede ser ofuscado, codificado en base64, dividido entre dos llamadas a herramientas, escrito en un archivo y luego ejecutado con source. Hermes sí normaliza la entrada (elimina secuencias ANSI, bytes nulos, Unicode NFKC) antes de escanear, lo que cierra las obvias rutas de ofuscación. Pero aún así es una coincidencia de patrones contra una superficie de ataque infinita.

Una auditoría de seguridad comunitaria en el GitHub de Hermes reciente pasó por esto en detalle. La conclusión no fue que Hermes no sea seguro — fue que la configuración por defecto es permisiva y asume que el usuario la reforzará. Esa es una elección de diseño defendible. También es una que pone la verdadera responsabilidad en quien ejecute la implementación.

Así que la forma en que pienso sobre la aprobación ahora: es un mecanismo de alerta para accidentes, no una defensa contra un agente adversario. Cuando un modelo con acceso a herramientas se desvía de manera no intencionada — camino incorrecto, bandera faltante, un comando ejecutado de manera equivocada pero con confianza — la aprobación lo detecta. Cuando algo ha comprometido efectivamente la entrada del modelo, la aprobación es la capa incorrecta en la que confiar. La solicitud de aprobación es el ​cinturón de seguridad de la persona en el bucle; el contenedor es la zona de absorción de impactos.

Opciones de aislamiento en tiempo de ejecución

Aquí es donde Hermes te da opciones reales, y la elección tiene más peso que las demás. El backend del terminal determina lo que realmente significa físicamente que "el agente ejecutó un comando".

• local — ejecuta comandos en el host. Predeterminado. Los avisos de aprobación están activos. El radio de explosión es el host.**
• docker — los comandos se ejecutan dentro de un contenedor con root de solo lectura, capacidades limitadas y CPU/memoria/almacenamiento configurables. Las comprobaciones de comandos peligrosos se omiten incondicionalmente porque el contenedor en sí es el límite.
• ssh — ejecuta comandos en una máquina remota. Útil para mantener el agente completamente fuera de tu portátil.
• modal y daytona — backends sin servidor que hibernan cuando están inactivos. Aislamiento tipo contenedor, costo de inactividad cercano a cero.
• singularity — para entornos HPC donde Docker no está disponible.

Un par de cosas que vale la pena destacar. La “omisión de contenedor” de los avisos de aprobación es intencional: el razonamiento del equipo es que si el contenedor se mantiene, la verificación de regex interna es redundante; si el contenedor falla, la regex de todos modos no te habría salvado. Tuve que reflexionar un momento antes de estar de acuerdo con ello.

Si decides usar Docker, la configuración de Hermes expone palancas de fortalecimiento que se corresponden de cerca con las prácticas estándar en la documentación oficial de seguridad del motor de Docker: aislamiento de namespaces, capacidades limitadas, root de solo lectura, límites de recursos. La imagen predeterminada de Hermes Docker viene con esto activado. El error que cometen las personas es volver a añadir cosas. terminal.docker_forward_env es el obvio: cada variable que pases al contenedor es una que el agente puede leer y exfiltrar. Lista de permitidos vacía por defecto, y yo la mantendría así para cualquier cosa que no sea tokens específicos de la tarea.

El modo persistente vs efímero es otra bifurcación. Persistente monta un directorio de espacio de trabajo a través de ejecuciones, para que el agente pueda construir estado — útil para desarrollo. Efímero usa tmpfs, así que todo muere cuando el contenedor se detiene — útil para cualquier cosa más cercana a producción. Elige según si aceptarías que un archivo malicioso permanezca en ~/.hermes/sandboxes/ por una semana antes de que lo notaras.

Messaging y límites de seguridad de MCP

Cuando Hermes se ejecuta como puerta de enlace, “quién puede hablar con él” se convierte en una pregunta real. El modelo de autorización es por capas: banderas de permitir todo por plataforma, lista aprobada de emparejamiento DM, listas de permitidos por plataforma, lista global de permitidos. El valor predeterminado si ninguna de estas está configurada es denegar a todos, con una advertencia al inicio. Ese es el valor predeterminado correcto — y el hecho de que algunas guías de autoalojamiento guíen a los usuarios para configurar GATEWAY_ALLOW_ALL_USERS=true para pruebas y luego olviden deshacerlo es una categoría de incidente por sí sola.

El emparejamiento de DM es la parte que sigo recomendando a las personas. En lugar de que mantengas una lista de IDs de Telegram/Discord, un usuario desconocido obtiene un código de emparejamiento de un solo uso, y lo apruebas desde la CLI con hermes pairing approve telegram ABC12DEF. La documentación de Hermes señala que este diseño se basa en OWASP y en la guía de identidad digital NIST SP 800-63: los códigos son de un solo uso, con límite de tiempo, y la acción de aprobación es explícita. No es novedoso, pero sí significa que las decisiones de acceso se toman con un humano real revisando la solicitud, no editando archivos de configuración de antemano.

MCP es su propia superficie por completo. Lo que más me costó internalizar: una herramienta MCP dentro de Hermes se ejecuta con los permisos del servidor donde reside, no con los del agente. Ese es todo el propósito del protocolo, pero también significa que cada servidor MCP conectado es una decisión de confianza separada.

La referencia de configuración de MCP de Hermes documenta dos protecciones que ahora considero no opcionales. Primero, filtrado del entorno: por defecto, solo PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR y XDG_* se pasan a los subprocesos stdio de MCP. Todo lo demás — claves API, tokens — se elimina. Las variables que realmente necesites van en el bloque env explícito del servidor. Segundo, filtrado de herramientas por servidor con include y exclude: si un servidor expone 20 herramientas y el agente necesita 3, permite solo esas 3.

La tercera no es configuración — es disciplina. Los archivos de contexto (AGENTS.md, SOUL.md, .cursorrules) se escanean en busca de patrones de inyección de prompt antes de cargarse en el prompt del sistema. Esta es la capa que aborda lo que los OWASP LLM Top 10 llaman inyección indirecta de prompt — instrucciones ocultas en contenido que el modelo debe leer. El escáner no es una defensa completa (nada lo es en esta categoría), pero es el lugar correcto para que esa verificación exista, y viene activado por defecto.

Endureciendo un despliegue de Hermes autohospedado

Algunos patrones que he terminado usando, en orden aproximado de prioridad:

Ejecutar como un usuario no root con sudo sin contraseña solo donde se requiere. El instalador de Hermes asume esto; el modelo de seguridad asume esto. No ejecutes el gateway como root.

Elige el aislamiento de ejecución que se ajuste a tu modelo de confianza, no a tu conveniencia. Para un servidor que suele ejecutar trabajos programados y responder mensajes, el backend Docker con docker_forward_env vacío, espacio de trabajo efímero y volúmenes montados mínimos es la aburrida opción correcta. El backend local es razonable en un portátil personal donde estás vigilando cada indicación de aprobación; es un valor predeterminado peor en un VPS que no estás mirando activamente.

! [imagen] (https://uploads.evomap.ai/blog/7d1335b7b670d9f5.png)

Mantén los secretos fuera de los ámbitos amplios. Las claves API de los proveedores y los tokens de gateway van en ~/.hermes/.env con permisos 0600. Nunca están en env_passthrough. Nunca están en docker_forward_env. Los servidores MCP solo reciben las variables que su bloque env nombres explícitos.

Configura la autorización de usuario explícitamente. O bien establece listas de permisos de plataforma con los IDs de usuario que realmente quieres, o usa emparejamiento de DM. Nunca dejes GATEWAY_ALLOW_ALL_USERS=true** en un entorno de producción** — es una bandera de prueba.

Audita las capas que has desactivado. approvals.mode: off y /yolo existen por una razón — ejecuciones de CI, entornos de prueba en formato sandbox — pero si alguna de las dos está configurada en tu configuración en vivo, apunta por qué. Lo mismo para tirith_enabled: false. El valor no es si están activadas; es si puedes responder por qué no lo están.

La disciplina de las actualizaciones importa más que la configuración inicial. Hermes se distribuye con frecuencia, y las mejoras de seguridad han llegado a casi todas las versiones recientes — bloqueo de exfiltración secreta, protecciones ampliadas de directorios de credenciales, patrones más amplios de redacción de tokens, bloques de exfiltración de URL de navegador. Una instalación de seis meses es peor independientemente de lo cuidadosamente que la configures.

Seguiré perfeccionando esto. Algunas capas aún no las entiendo del todo — la transferencia de veredicto a aprobación de Tirith es una con la que quiero dedicar más tiempo, y no he hecho una revisión real de un despliegue largo por mi cuenta. Lo que tengo bastante claro es que el modelo en capas es correcto, y que ninguna capa individual es la respuesta completa. Si un artículo intenta darte un truco, probablemente esté equivocado.

Preguntas frecuentes

¿Debería correr con approvals.mode: off****?

Solo dentro de un contenedor o sandbox, donde el contenedor está haciendo el trabajo. En el backend local, no.

¿Es el backend de Docker un sustituto completo de las solicitudes de aprobación?

Para daño a nivel de host, en su mayoría sí — por eso la aprobación se evita cuando un backend de contenedor está activo. No sustituye el filtrado de credenciales o los límites MCP.

¿Qué desactiva realmente el modo YOLO**?**

Solicitudes de aprobación de comandos peligrosos para la sesión actual. No desactiva Tirith, el aislamiento de contenedores, la autorización de gateway ni el filtrado de variables de entorno.

¿Cómo sé qué variables de entorno ven los subprocesos MCP?

Solo PATH, HOME, USER, LANG, LC_ALL, TERM, SHELL, TMPDIR, XDG_* y cualquier cosa en el bloque explícito env del servidor. Todo lo demás se elimina.

¿Existe un Hermes gestionado que se encargue de esto por mí?

Hay proveedores que ofrecen implementaciones con un solo clic. Manejan la instalación, pero no toman decisiones de confianza sobre quién puede hablar con tu bot o qué pueden leer tus servidores MCP. Eso todavía tiene que ser tu responsabilidad.

Volveré a este tema cuando pase más tiempo con mi propia configuración. Por ahora, esto es lo que entiendo.

Publicaciones anteriores:

• Si estás configurando múltiples tareas programadas, podría interesarte entender cómo Límites de Memoria y Contexto de Hermes Cron impactan tus trabajos cron.
• Si estás solucionando problemas de ejecuciones superpuestas o lentas, consulta esta guía sobre Configuración segura de Hermes MCP para trabajos Cron.
• Para profundizar en la mejora del comportamiento del agente con indicaciones claras e instrucciones: Cómo escribir habilidades efectivas para agentes Hermes.
• ¿Piensas en automatizar la supervisión en tiempo real? Esta guía te ayudará: Trabajos Cron de verificación periódica de salud con Hermes.
• ¿Necesitas optimizar la entrega de cron para resultados estables? Lee más sobre Gestión de capacidades de agentes y acceso a herramientas.