En la comunidad de Hermes circula una frase: más de la mitad de los usuarios ha activado YOLO al menos una vez. Pero YOLO no es toda la historia, solo es un punto extremo en el espectro de seguridad de Hermes. Quienes realmente sacan provecho de Hermes alternan entre siete modos comunes, en lugar de recurrir a /yolo cada vez que algo se ralentiza.

Hermes Agent se basa en una premisa por defecto: si le permites ejecutar un comando, debe hacerse responsable de las consecuencias. Por eso, antes de ejecutar algo que pueda dañar tu sistema, se detiene y pregunta. Esto se llama Aprobación de Comandos Peligrosos (Dangerous Command Approval), y YOLO es solo una forma de omitirla.

Este artículo explica los siete modos de seguridad y autonomía de Hermes. Al terminar, sabrás decirle a tu agente:

• “El modo smart es suficiente para el desarrollo normal.”
• “Ejecuto este script a menudo, apruébalo para la sesión.”
• “Voy a hacer una refactorización masiva, activa YOLO, pero nunca permitas git push --force.”
• “Ejecuta esto en Docker, así no hacen falta aprobaciones y el host queda seguro.”

---

1. Modo smart: deja que la IA evalúe el riesgo (recomendado por defecto)

approvals:
  mode: smart

smart es el modo predeterminado de Hermes. Cuando un comando coincide con un patrón peligroso, Hermes pide a un modelo auxiliar que evalúe el riesgo real.

• Los comandos obviamente seguros (por ejemplo, python -c "print('hello')") se aprueban automáticamente.
• Los comandos obviamente peligrosos (por ejemplo, rm -rf /) se rechazan automáticamente.
• Los casos dudosos se elevan a ti.

Esto reduce drásticamente la “fatiga de aprobación”. No tienes que confirmar cada bash -c, pero las acciones realmente destructivas siguen siendo detectadas.

Ideal para: desarrollo diario, tareas exploratorias y entornos en los que ya confías en el agente.

---

2. Modo manual: cada comando peligroso pasa por ti

approvals:
  mode: manual

Si prefieres no delegar la evaluación de riesgos a un modelo auxiliar, usa el modo manual. Cada comando que coincida con un patrón peligroso se pausa y espera tu aprobación.

En la CLI, el mensaje suele verse así:

⚠️  DANGEROUS COMMAND: recursive delete
    rm -rf /tmp/old-project

    [o]nce  |  [s]ession  |  [a]lways  |  [d]eny

    Choice [o/s/a/D]:

Cuatro opciones:

• once: permite solo esta ejecución.
• session: permite este patrón durante el resto de la sesión.
• always: añade el patrón a tu lista de permisos permanente en ~/.hermes/config.yaml.
• deny (por defecto): bloquea el comando.

Ideal para: trabajo de alta seguridad, principiantes o cuando ejecutas comandos desconocidos.

---

3. Modo YOLO: omite todas las solicitudes de aprobación

El modo YOLO evita todas las aprobaciones de comandos peligrosos. Puedes activarlo de tres formas:

# Al iniciar
hermes --yolo
hermes chat --yolo

# Durante una sesión
/yolo

# Variable de entorno
HERMES_YOLO_MODE=1

Una vez activo, Hermes muestra un banner rojo y un indicador en la barra de estado para que no olvides que la red de seguridad está desactivada.

> /yolo
  ⚡ YOLO mode ON — all commands auto-approved. Use with caution.

YOLO encaja en escenarios donde estás seguro de que los comandos son seguros, como:

• Scripts de automatización repetidos;
• Trabajo dentro de contenedores o entornos desechables;
• Tareas en las que estás atento y puedes pulsar Ctrl+C en cualquier momento.

Pero recuerda: YOLO no es 100% ilimitado, la lista negra hardline que verás a continuación sigue aplicando.

---

4. Lista negra hardline: el límite que ni YOLO puede cruzar

Incluso con approvals.mode: off o /yolo activado, Hermes sigue rechazando ciertos comandos irreversibles y catastróficos. Esta es la lista negra hardline.

Algunos ejemplos:

Comando	Por qué está bloqueado
rm -rf /	Borra el sistema de archivos raíz
:(){ :|:& };:	Bomba fork de bash
mkfs.* contra un dispositivo raíz montado	Formatea el sistema en ejecución
dd if=/dev/zero of=/dev/sd*	Llena de ceros un disco físico
Canalizar URLs no confiables a sh	Superficie de ataque de ejecución remota de código demasiado grande

Estos patrones residen en tools/approval.py::UNRECOVERABLE_BLOCKLIST y no se pueden anular con ninguna bandera.

Filosofía de diseño: YOLO significa “confío en que la IA no se equivoque”, mientras que la lista hardline significa “incluso si la IA —o el usuario— se equivoca, la máquina no puede quedar destruida”.

---

5. Reglas deny personalizadas: YOLO con excepciones

Si YOLO te parece demasiado permisivo y manual demasiado ruidoso, usa approvals.deny para trazar tus propias líneas rojas:

approvals:
  mode: off           # efectivamente YOLO
  deny:
    - "git push --force*"
    - "*curl*|*sh*"
    - "dd if=* of=/dev/*"

Las reglas son comodines fnmatch insensibles a mayúsculas, que se comparan con el texto completo normalizado del comando. Incluso bajo YOLO, un comando coincidente se bloquea de forma estricta.

Es perfecto para escenarios del tipo “confío en la mayoría de las operaciones, pero algunas acciones nunca están permitidas”:

• Deja que el agente edite código y ejecute pruebas libremente, pero prohíbe git push --force;
• Permite que descargue dependencias, pero bloquea curl ... | sh;
• Permite que opere Docker, pero nunca escriba directamente en dispositivos de bloque.

---

6. Modo write approval: controla los escritos en memoria y skills

Más allá de los comandos de terminal, Hermes escribe cosas por sí mismo: guarda hechos importantes en memory y flujos aprendidos como skills. Si te preocupa que “aprenda cosas incorrectas”, activa write approval.

memory:
  write_approval: true

skills:
  write_approval: true

Cuando está activado, cada escritura de memory o skill se pone en cola bajo ~/.hermes/pending/ hasta que la revises y apruebes:

# Revisar escritos de skills pendientes
/skills pending
/skills diff <id>
/skills approve <id>
/skills reject <id>

# Lo mismo para memory
/memory pending
/memory approve <id>
/memory reject <id>

Ideal para:

• Evitar que el agente recuerde automáticamente datos sensibles o incorrectos;
• Instancias compartidas de Hermes donde las skills aprendidas necesitan revisión humana;
• Depurar el ciclo de aprendizaje antes de permitir que persista nada.

---

7. Modo de aislamiento por contenedores: reemplaza aprobaciones por fronteras

El último modo no se trata de cómo aprobar, sino de hacer que las aprobaciones sean innecesarias. Hermes soporta varios backends de terminal:

Backend	Aislamiento	¿Verifica comandos peligrosos?
local	Ninguno, corre en el host	✅ Sí
ssh	Máquina remota	✅ Sí
docker	Contenedor	❌ No (el contenedor es el límite)
singularity	Contenedor	❌ No
modal	Sandbox en la nube	❌ No
daytona	Sandbox en la nube	❌ No

Cuando ejecutas en Docker, Modal o Daytona, las comprobaciones de comandos peligrosos se omiten porque, aunque el contenedor se destruya, el host permanece intacto. Los gateways de producción de Hermes suelen configurarse así.

Los contenedores Docker también se ejecutan con un conjunto de flags de seguridad endurecidos por defecto:

_BASE_SECURITY_ARGS = [
    "--cap-drop", "ALL",
    "--security-opt", "no-new-privileges",
    "--pids-limit", "256",
    "--tmpfs", "/tmp:rw,nosuid,size=512m",
]

Ideal para: despliegues en producción, CI/CD, entornos multitenancy y cualquier sandbox donde la destrucción sea aceptable.

---

Tabla rápida para elegir el modo adecuado

Modo	Aprobación de comandos	Aprobación de escritos	Cuándo usarlo
smart	IA pre-revisa + revisión humana en casos dudosos	Opcional	Predeterminado para el desarrollo diario
manual	Todos los comandos peligrosos requieren aprobación humana	Opcional	Tareas de alto riesgo o principiantes
YOLO	Se omiten todos los comandos peligrosos	Opcional	Automatización temporal, scripts de confianza
hardline	Comandos catastróficos bloqueados permanentemente	No aplica	Límite de seguridad siempre activo
deny rules	Patrones de bloqueo personalizados	No aplica	YOLO con excepciones
write approval	Opcional	Requerida para escritos de memory/skill	Evitar que el agente aprenda mal
container isolation	No se verifica	Limitada por el contenedor	Producción o sandbox

---

Recomendaciones prácticas

1. Quédate con el valor predeterminado: el modo smart cubre la mayoría del trabajo diario sin interrumpir constantemente.
2. Usa aprobación por sesión para tareas en lote: más seguro que YOLO, pero evita confirmar cada comando.
3. Combina YOLO con reglas deny: si vas a YOLO, al menos conserva algunas líneas rojas personalizadas.
4. Ejecuta producción en Docker: el aislamiento es más fiable que las aprobaciones y elimina la fatiga de aprobación por completo.
5. Audita tu lista de permisos: command_allowlist crece con el tiempo. Límpiala periódicamente con hermes config edit.
6. Activa write approval en Hermes compartido: especialmente importante cuando ejecutas un gateway de larga duración en equipo.

---

Conclusión

El sistema de aprobación de Hermes no está para ralentizarte. Está para equilibrar delegación con confianza y frenada a tiempo. YOLO es divertido, pero es solo uno de siete modos. Los usuarios avanzados saben cuándo quedarse en smart, cuándo pasar a manual, cuándo desactivar YOLO y cuándo dejar que Docker haga el trabajo de seguridad por ellos.

La próxima vez que vayas a escribir /yolo, pregúntate: ¿realmente necesito omitir toda aprobación, o sería suficiente una aprobación por sesión más una regla deny?