Todo usuario habitual de Hermes Agent conoce ese momento: estás viendo al agente trabajar, todo va bien, y de pronto —pum— aparece una petición de aprobación. ¿De verdad la leíste? Seamos honestos. Tras el quincuagésimo aviso de rm del día, la mayoría solo pulsa «aprobar» sin mirar. Eso es la fatiga de aprobación, y es una brecha de seguridad disfrazada de comodidad: cuantos más avisos sellas de memoria, menos significado tiene cada uno.

Hermes v0.19.0 (la Quicksilver Release) atacó este problema de raíz. Las aprobaciones inteligentes ahora son el valor predeterminado: en lugar de pedirte aprobar cada comando marcado, Hermes hace que un revisor LLM independiente evalúe cada uno, apruebe automáticamente los de bajo riesgo, rechace los realmente peligrosos y solo te consulte los dudosos. Menos interrupciones, mismo control humano — si acaso, más fuerte, porque tu atención se gasta solo donde importa.

Esta publicación es una guía práctica: cómo funciona de verdad el nuevo flujo de aprobación, las claves reales de config.yaml (verificadas contra el código de v0.19, no contra leyendas), y cómo fijar líneas rojas que ni el modo yolo puede cruzar.

El problema: la fatiga de aprobación es un bug de seguridad

La aprobación manual funcionaba cuando los agentes ejecutaban un puñado de comandos por sesión. Los agentes modernos ejecutan decenas o cientos. Cada aviso es un cambio de contexto; cada cambio de contexto agota tu atención; la atención agotada aprueba cosas que no debería. Los investigadores de seguridad tienen un nombre para esto —habituación— y es exactamente así como se cuela el único comando que deberías haber leído con cuidado.

El flujo antiguo tenía además un segundo problema: tú eras el clasificador de riesgo. Hermes marcaba un comando, tú lo juzgabas, fin. La calidad del juicio dependía de lo despierto que estuvieras en ese momento exacto, que es el peor diseño posible para un mecanismo de seguridad.

Las aprobaciones inteligentes arreglan ambas cosas: el clasificador de rutina pasa a ser un modelo que nunca se cansa, y la decisión final sigue siendo tuya.

Cómo funcionan: tres veredictos, un comando cada vez

Cuando Hermes quiere ejecutar un comando que coincide con su lista de patrones peligrosos, el flujo ya no es «pregunta al humano». Es:

1. Un LLM auxiliar evalúa el comando de forma independiente — no el agente principal, sino un modelo revisor separado.
2. El revisor devuelve uno de tres veredictos:
   • Seguro → aprobación automática, sin interrupción.
   • Peligroso → rechazo automático, con el motivo registrado.
   • Dudoso → escalado a ti para aprobar o rechazar manualmente.

El detalle importante está en las notas de la versión: cada veredicto cubre solo ese comando exacto. Un comando posterior que coincida con el mismo patrón recibe su propia revisión nueva. No existe el atajo de «ya aprobamos esta clase antes, aprueba otra vez». El revisor no se acostumbra por patrones, y tú tampoco — porque solo ves los casos genuinamente ambiguos.

Tú: "despliega el servidor de staging y ejecuta la migración"
Hermes: [kubectl apply --dry-run ...]      → revisión: seguro, aprobado
        [kubectl rollout restart ...]      → revisión: seguro, aprobado
        [kubectl delete namespace prod]    → revisión: PELIGROSO, rechazado
        [psql -c "DROP TABLE users;"]      → dudoso → escalado a ti

Ese es el flujo que acaba con el asentir.

La configuración real: approvals.mode, no leyendas

Si has leído posts antiguos sobre las aprobaciones de v0.19, quizá viste claves inventadas como smart_approvals: true o deny_rules: con campos pattern:/reason:. Esas no existen. El esquema real en config.yaml es:

# ~/.hermes/config.yaml
approvals:
  mode: smart        # smart | manual | off  (smart es el valor por defecto)
  timeout: 300       # segundos que espera tu aprobación antes de fallar en cerrado
  cron_mode: deny    # deny | approve — qué hacen los cron jobs con un comando marcado
  deny: []           # tus líneas rojas: patrones glob bloqueados incondicionalmente

Clave	Por defecto	Qué hace
mode	smart	Política de aprobación para comandos shell marcados
timeout	300	Segundos que Hermes espera tu respuesta antes de tratarla como rechazo
cron_mode	deny	Comportamiento sin supervisión: deny bloquea comandos marcados en cron, approve los ejecuta
deny	[]	Patrones glob que bloquean comandos incondicionalmente — incluso con yolo

Verifica tu ajuste actual en cualquier momento:

hermes config | grep -A 4 approvals

Los tres modos en cristiano:

• smart (por defecto) — la revisión LLM filtra los comandos de rutina; los peligrosos se rechazan; los dudosos llegan a ti.
• manual — cada comando marcado te pregunta, igual que antes de v0.19.
• off — sin avisos de aprobación; equivalente a --yolo / HERMES_YOLO_MODE=1. Solo para sandboxes de confianza.

Líneas rojas: approvals.deny le gana a yolo

Esta es la parte que hace seguro relajarse con el modo inteligente. La lista deny es un conjunto de patrones glob que bloquean comandos coincidentes incondicionalmente — antes de cualquier bypass yolo, antes de /yolo, antes de mode: off. Es la contrapartida editable por el usuario de la lista negra rígida integrada en Hermes, y es la línea de defensa más importante que puedes configurar:

approvals:
  mode: smart
  deny:
    - "git push --force*"
    - "rm -rf /"
    - "*curl*|*sh*"
    - "kubectl delete namespace*"

Los patrones son globs fnmatch insensibles a mayúsculas. Ponlos entre comillas en YAML — un * inicial desnudo es un error de parseo. Un comando que coincide se bloquea con motivo registrado, sin discusión. Incluso en modo yolo. Esta es tu lista de «no importa lo seguro que esté el agente, esto nunca pasa», y debe contener esas pocas operaciones cuyos modos de fallo son inaceptables: force-push a ramas compartidas, borrados recursivos, eliminación de namespaces de producción, secretos escritos por CLI.

¿La escapatoria para un uso deliberado y puntual? No hay ninguna en la configuración — y ese es el punto. Si de verdad necesitas hacer un force-push, quitas el patrón, ejecutas el comando y lo vuelves a añadir. La fricción es intencionada y mínima.

/deny <reason>: haz que la negativa enseñe

Las aprobaciones inteligentes no solo reducen avisos — hacen más valiosos los que sí respondes. Cuando el revisor te escala un comando y lo rechazas, ahora puedes decirle al agente por qué:

Hermes quiere ejecutar: docker system prune -a -f

> /deny demasiado agresivo — otros contenedores comparten esa caché de imágenes

El motivo se escribe de vuelta en el contexto, y el agente corrige el rumbo — busca un comando más acotado en lugar de reintentar el mismo esperando que te ablandes. Una negativa con razón es feedback; una negativa seca es un muro. Acostúmbrate a dar una frase de por qué, y el siguiente intento del agente será notablemente mejor.

Relacionado: si el agente va por mal camino del todo, /stop sigue matando la ejecución al instante. El flujo de aprobación y el botón de parar son complementarios — uno filtra comandos, el otro corta la secuencia entera.

Cron jobs: no hay nadie para asentir

Las aprobaciones inteligentes brillan en sesiones interactivas, pero ¿y las que no tienen supervisión? Cuando un cron job programado encuentra un comando marcado, no hay usuario al que escalar. El valor por defecto cron_mode: deny lo maneja de forma conservadora: el comando se bloquea y el agente debe buscar otro camino. Si confías en un trabajo concreto (p. ej., un backup nocturno que limpia archivos viejos legítimamente), puedes cambiar su política:

approvals:
  cron_mode: approve   # aprueba automáticamente comandos marcados en contexto cron

Piénsalo dos veces antes de activar esto. deny no cuesta nada cuando el agente encuentra una ruta alternativa; approve convierte cada aviso de cron en una ejecución silenciosa. Para la mayoría de los trabajos, deny más una lista de excepciones estrecha en approvals.deny es la forma correcta.

¿Qué modo deberías usar?

Situación	Recomendación
Trabajo interactivo diario	smart (por defecto) — conservas el veto, pierdes el ruido
Cirugía de repos / operaciones destructivas	smart + reglas deny — líneas rojas para lo irreversible
Sandbox de total confianza / contenedor CI	off o --yolo, pero mantén deny como red de seguridad
Nostalgia	manual — si de verdad quieres que vuelvan todos los avisos

Para la mayoría, la respuesta es: deja mode: smart, dedica diez minutos a escribir reglas deny y usa /deny <reason> cada vez que rechaces. Esa es toda la actualización.

Más allá de las aprobaciones: defensa en profundidad

Las aprobaciones inteligentes son una capa del modelo de defensa en profundidad de Hermes, no toda la historia. Otras capas que vale la pena conocer: checkpoints toman instantáneas automáticas del sistema de archivos antes de operaciones destructivas (un error es un rollback, no un desastre), el enmascarado de secretos limpia cadenas con forma de API key de la salida de las herramientas antes de que lleguen al contexto o a los logs, y el aislamiento por contenedor (backends Docker/Singularity/Modal) puede encerrar la herramienta de terminal por completo. Las aprobaciones deciden si un comando se ejecuta; los checkpoints deciden qué pasa después. Se componen.

Resumen

Las aprobaciones inteligentes de Hermes v0.19 no significan «el agente ya puede hacer lo que quiera». Son lo contrario: un humano cansado que sellaba cada aviso es sustituido por un revisor incansable que filtra la rutina, bloquea lo peligroso y solo saca a la superficie lo ambiguo. La configuración real son tres claves y un hábito:

• approvals.mode: smart — el valor por defecto que acaba con la fatiga de aprobación.
• approvals.deny: [...] — tus líneas rojas, vigentes incluso en modo yolo.
• approvals.cron_mode: deny — los trabajos sin supervisión siguen siendo conservadores.
• El hábito: /deny <reason> — cada negativa enseña.

Tu agente gana autonomía; tú conservas cada gramo de control. Se acabó asentir.

¿Quieres más guías de seguridad y flujo de trabajo de Hermes? Echa un vistazo al análisis a fondo de la v0.19.0, a la configuración de aprobaciones con tres compuertas, a nuestro explicador del modo yolo y a la guía de manejo de errores y recuperación. ¿Nuevo en Hermes? Empieza con la guía de instalación.