¿Es seguro Hermes Agent? El agente nunca debería tener el token

Un agente siempre activo con una shell es un colega con root: uno que nunca duerme, lee todo lo que le señalas y va a imprimir un secreto en un log sin pensarlo dos veces si nada lo frena. La seguridad de ese colega se reduce casi siempre a dos preguntas: a qué puede llegar y qué puede imprimir. El modelo detrás de él importa mucho menos que cualquiera de las dos.

Corro Hermes Agent en producción en mi propio VPS. Cada incidente de abajo me pasó a mí. Cada control de abajo lo revisé en el código fuente, no en la página de marketing.

¿Es seguro Hermes Agent?

Tiene controles reales, y su propio código es explícito sobre cuáles de ellos no son un límite de seguridad. Los prompts de aprobación bloquean comandos riesgosos en cada superficie de mensajería, un archivo de parada de emergencia puede detener todo trabajo nuevo, y un proxy de egress mantiene las credenciales fuera del sandbox de Docker. Nada de esto hace que Hermes sea seguro por defecto. Hace que Hermes sea seguro de configurar correctamente, que es una afirmación distinta, y la brecha entre ambas es donde pasó cada incidente de abajo.

Trátalo como lo que es: un colega con shell, no un juguete en sandbox. Dale su propia máquina o contenedor, credenciales acotadas y nunca una key que no puedas rotar.

Lo que realmente salió mal cuando lo corrí

Nada de esto es teórico. Cuatro incidentes distintos, cuatro lecciones distintas, corriendo Hermes y Paperclip en producción desde junio.

Incidente, causa, arreglo

Tres de los cuatro son mi responsabilidad de arreglar. La trampa de WebSocket es un comportamiento del navegador que ningún runtime controla.

Qué pasó	Causa raíz	Arreglo
Tokens de API aparecieron en un log de sesión	Un dump de config.yaml dentro de una sesión de Hermes los imprimió directo en el log	Roté los tokens
El dashboard web se quedó colgado al conectar	Chrome no reenvía basic auth en un upgrade de WebSocket. La misma trampa afectó a la propia UI de OpenClaw.	Un segundo router de Traefik con un token, separado del basic auth
Una corrida falló con permission denied en agent.log	Mis propios diagnósticos, corridos como root dentro del contenedor, dejaron archivos propiedad de root en .hermes	chown de vuelta al usuario del servicio
Un token de provider terminó en un servicio que nunca lo usó	Mi tooling de auth propaga tokens a cada servicio administrado, pero cada app decide por su cuenta qué env var lee	Tratar la propagación y el consumo como dos preguntas separadas, no una

El patrón en los cuatro: el agente no filtró nada por ser astuto. Una herramienta imprimió lo que le dijeron que imprimiera, un navegador descartó un header que nunca iba a reenviar, un diagnóstico corrió con el usuario equivocado, y un token llegó a una máquina que no tenía ningún uso para él. La seguridad de un agente casi siempre falla en la plomería, no en que el modelo decida portarse mal.

La lección de segundo orden del arreglo de WebSocket vale la pena pensarla. La ruta de bypass usó un token en el query string de la URL, ?token=, que es a su vez una versión más chica del mismo problema: cualquier cosa en una URL termina en los access logs, el historial del navegador y los headers de referrer. Un arreglo para una filtración puede abrir en silencio una más angosta. Revisa qué registras antes de lanzar el parche, no después.

Controles de seguridad de Hermes Agent, desde el código fuente

Cuatro mecanismos hacen el trabajo real, y el propio código de Hermes es explícito sobre cuál de ellos es cosmético.

Qué se interpone entre el agente y el daño

1. 1

   Aprobación en cada superficie

   Un comando de terminal riesgoso se detiene y pregunta, con el mismo texto en Telegram, la CLI o cualquier otro gateway: 'Hermes quiere correr un comando que necesita tu OK', con la razón por la que se marcó y un timeout después del cual el comando no corre.

   +
2. 2

   ESTOP, un archivo sentinela

   hermes pause escribe un archivo en $HERMES_HOME/ESTOP. Mientras existe, el scheduler de cron, el dispatcher de kanban y los nuevos turnos de gateway se saltan todo trabajo nuevo. El trabajo en curso nunca se mata. hermes resume lo elimina.

   +
3. 3

   Un proxy de egress para el backend de Docker

   El propio código de Hermes lo llama un 'firewall de credenciales del lado del host'. Construye los argumentos de mount, env y host que enrutan un sandbox a través de él, y protege exactamente las superficies de config (env reenviado, args extra) que de otro modo podrían debilitarlo o saltárselo.

   +
4. 4

   Redacción de salida

   Un módulo dedicado elimina strings sensibles de lo que el agente imprime, tanto en el prompt de aprobación, la herramienta de terminal y la entrega a un gateway. Reduce el radio de impacto de una filtración. No evita que ocurra.

Cada guard acá es defensa en profundidad, NO un límite de seguridad: la herramienta de terminal corre como el mismo usuario del sistema operativo y puede leer/escribir cualquier cosa.

Esa línea es de agent/file_safety.py en el código de Hermes, no de un blog post sobre Hermes. Es la frase más honesta de toda la codebase. Un guard de archivos detiene a un modelo que respeta un error de herramienta. No hace nada contra un modelo que recurre a bash en su lugar, porque la herramienta de terminal es el mismo usuario del sistema operativo de cualquier forma.

Dos controles estructurales más importan acá. Los perfiles de Hermes te dan “múltiples instancias aisladas de Hermes”, cada una con su propio HERMES_HOME, config y base de datos de estado, que es la forma de evitar que un agente comprometido lea la memoria o las credenciales de otro agente en la misma máquina. Y el backend de ejecución que elijas (local por defecto, o Docker, SSH, Singularity, Modal, Daytona o Vercel Sandbox) es el control real de radio de impacto: un agente que corre sus comandos en un sandbox descartable pierde mucho menos que uno que los corre en la misma máquina donde vive.

Credenciales detrás de un proxy, nunca en manos del agente

El agente nunca debería tener un token que pueda imprimir. El patrón que funciona es un proxy que guarda la credencial y una config que solo apunta al agente hacia el proxy.

Mi propio mcp-pooler hace exactamente esto para el tráfico de MCP. Guarda un token bearer upstream, configurado una sola vez como variable de entorno en el propio pooler, y cada agente de vida corta aguas abajo habla con el endpoint propio del pooler, que no pide ninguna credencial. El agente no puede filtrar el token upstream porque nunca lo recibe. El tradeoff es explícito en el propio README del pooler: ese endpoint aguas abajo no tiene auth propia y está pensado para correr en una red privada, no expuesto a internet. Un proxy que esconde una credencial no es motivo para saltarte el aislamiento a nivel de red.

La misma lógica aplica a cada fuente que lee un agente, no solo al gateway que está frente a ellas. Acota las fuentes MCP de Slack y Google Workspace a solo lectura donde la lista de herramientas lo permita, y trata el cliente OAuth o el bot token detrás de cada una como algo que emitiste tú y puedes revocar, nunca algo prestado de otro sistema. Una fuente de Git es la misma pregunta otra vez: un token acotado a un repo filtra mucho menos que uno acotado a toda tu cuenta.

¿Es seguro OpenClaw? Misma pregunta, defaults distintos

OpenClaw y Hermes parten del mismo default: los comandos corren en el host. Hermes viene con el backend local seleccionado, y OpenClaw corre las herramientas en el host a menos que actives el sandboxing. La propia documentación de OpenClaw señala esa elección directamente, ofreciendo Docker, Podman, SSH, OpenShell o Crabbox como sandboxes opt-in, y dice sin vueltas que incluso el sandbox “no es un límite de seguridad perfecto”. Su heartbeat despierta al agente solo cada 30 minutos por defecto, que es una feature para un asistente personal y una ventana de ataque más amplia para cualquier cosa que no querías darle.

La seguridad de OpenClaw, igual que la de Hermes Agent, es una decisión de configuración, no una propiedad que ninguno de los dos proyectos te entregue de fábrica. Las aprobaciones de exec existen en ambos. Ninguno hace sandboxing por defecto; los dos te dejan elegir un sandbox al configurarlo. Ninguno de esos dos hechos te dice si un deploy específico es seguro. Las preguntas de la checklist de abajo sí.

Checklist de seguridad para agentes de IA: antes de darle una shell a un agente

El GenAI Security Project de OWASP nombra el patrón directamente: LLM06:2025, Excessive Agency, el riesgo de que a un agente se le otorgue más permiso, más herramientas o más autonomía de la que la tarea que tiene enfrente necesita. Cada incidente de este artículo es una variante de ese mismo riesgo, no una falla exclusiva de un runtime.

Antes de darle una shell a un agente

• ✓Obligatorio:
  Corre como su propio usuario, en su propio sandbox o contenedor.Los guards de escritura de archivos no son un límite de seguridad. El usuario del sistema operativo con el que corre la herramienta es el límite real.
• ✓Obligatorio:
  Cada credencial que toca está detrás de un proxy o de un token acotado que emitiste tú mismo.El agente nunca debería tener un secreto que pueda imprimir. Si tiene que tenerlo, que sea el más pequeño que funcione.
• ✓Obligatorio:
  Las acciones riesgosas se detienen y preguntan, en la superficie que realmente lees.Un prompt de aprobación que nadie ve no es un gate de aprobación. Haz que la superficie coincida con dónde estás.
• ✓Obligatorio:
  Tienes un kill switch que detiene trabajo nuevo sin matar el trabajo en curso.El archivo ESTOP de Hermes es una forma de esto. Conoce el tuyo antes de necesitarlo.
• ✓Obligatorio:
  Publicar, enviar y borrar pasan por un humano, por diseño, no por accidente.Mis propios agentes nunca tuvieron acceso de escritura a los canales donde publico. Ellos producen. Yo publico.
• ✓Obligatorio:
  Sabes qué registra, y has leído un archivo de log, no solo el relato del propio agente de lo que pasó.Un dump de config, un query string de una URL, un stack trace: todos son lugares donde un secreto se esconde a la vista de todos.

Seguridad de Hermes Agent, respuestas rápidas

¿Es seguro Hermes Agent?+

Viene con controles reales: prompts de aprobación en cada superficie de mensajería, un archivo ESTOP que detiene trabajo nuevo, y un proxy de egress que mantiene las credenciales fuera del sandbox de Docker. Su propio código dice que los guards de escritura de archivos son defensa en profundidad, no un límite de seguridad.

Que un deploy específico sea seguro depende del backend de ejecución, de las credenciales a las que puede llegar, y de si las acciones riesgosas requieren un humano. Son decisiones de configuración, no defaults.

¿Contra qué protege realmente la seguridad de Hermes Agent?+

Sobre todo fallas de plomería, no un modelo que decide portarse mal: una herramienta que imprime un secreto porque se le dijo que lo imprimiera, un diagnóstico corrido con el usuario del sistema equivocado, un token que llega a un servicio que nunca lo necesitó. Cada incidente que tuve en producción fue uno de estos, no el modelo saliéndose de control.

¿Es seguro OpenClaw?+

Igual que Hermes, OpenClaw corre comandos en el host por defecto y hace que el sandboxing sea opt-in, con Docker, Podman, SSH, OpenShell o Crabbox. Su propia documentación dice que el sandbox no es un límite de seguridad perfecto. Es un default honesto que vale la pena conocer, no un veredicto sobre ningún setup en particular.

¿Cómo mantiene Hermes Agent las credenciales lejos del agente?+

A través de un patrón de proxy: un componente como mcp-pooler guarda el token bearer upstream y el agente solo habla con el endpoint propio del proxy, que no lleva ninguna credencial. Combina eso con scopes de solo lectura en fuentes como Slack y Google Workspace donde la lista de herramientas lo permita.

¿Qué es la seguridad de agentes de IA, en la práctica?+

Dos preguntas, repetidas para cada herramienta y cada credencial: a qué puede llegar este agente, y qué puede imprimir. El GenAI Security Project de OWASP llama a ese modo de falla general Excessive Agency. Todo lo demás, desde el sandboxing hasta los prompts de aprobación y la redacción, es una respuesta específica a una de esas dos preguntas.