Security and approval modes

Hermes security should not be treated as one toggle. The current source material frames it as a layered operating surface: who is allowed to talk to the agent, which dangerous commands require approval, what happens when YOLO is enabled, how permanent allowlists widen the execution surface, and how backend/container choices change isolation and persistence expectations.

Choose approval mode deliberately

• manual
• smart
• off

The practical rollout default is to start with manual or smart, not off.

Treat YOLO as a real risk escalation

• hermes --yolo
• hermes chat --yolo
• /yolo
• HERMES_YOLO_MODE=1

Do not assume YOLO removes every guardrail

Hermes still documents an unrecoverable blocklist. Some command classes are refused even with YOLO, approvals.mode: off, or headless approval contexts.

Review backend and container isolation on purpose

• docker_forward_env: [] is an explicit secret-minimizing posture
• container_persistent: true changes persistence expectations, not only isolation style

Practical failure checks

• assuming off is fine everywhere because the environment feels internal
• treating /yolo as if it bypasses every guardrail
• widening command_allowlist without reviewing the new risk surface
• assuming containerization alone solves security

Related pages

• Debugging and recovery
• Validation and observability
• Messaging rollout differences