Problem or Use Case

When Hermes is accessed via the messaging gateway (Telegram, Discord, Slack, WhatsApp, Signal), the terminal backend is whatever is configured globally. If terminal.backend: local, commands from messaging users execute directly on the host machine.

The gateway's authorization layer (DM pairing, allowlists) controls who can talk to the agent, but not what damage an authorized session can do. Once a user is authorized, the agent executes LLM-generated commands with the host user's full privileges. Combined with:

• Critical: Sandbox code execution bypasses dangerous command approval via terminal tool #4146 — execute_code sandbox bypasses dangerous command approval entirely
• [Security] No network egress filtering — terminal commands have unrestricted internet access #4170 — no network egress filtering on local backend
• Security: Path traversal in credential_files and skills_hub quarantine_bundle #3967 — skill path traversal can read ~/.ssh/id_rsa

This means a prompt injection via a Telegram message (or a confused deputy from web content the agent fetches) can result in arbitrary host command execution with no approval gate and no containment.

The existing dangerous command approval system explicitly skips checks for container backends because "the container itself is the security boundary." For gateway sessions on the local backend, neither the approval system nor container isolation protects the host.

Proposed Solution

1. Warn on unsafe gateway configuration

When hermes gateway start is invoked with terminal.backend: local, emit a visible warning:

⚠ Gateway is running with local terminal backend.
  Commands from messaging platforms will execute on this machine.
  Consider using a sandboxed backend: docker, daytona, or modal.
  See: https://hermes-agent.nousresearch.com/docs/user-guide/security#gateway

2. Per-session sandbox creation

Optionally (or by default for gateway), create an ephemeral sandbox per messaging session:

gateway:
  terminal_backend: daytona  # override global backend for gateway sessions
  sandbox_lifetime: 3600     # auto-cleanup after 1 hour of inactivity

The gateway already manages sessions. Each session gets its own sandbox via the existing terminal backend abstraction. Any container backend works here.

3. Document recommended production configuration

The production deployment checklist already recommends container backends but doesn't enforce or warn. For users running Hermes as an always-on Telegram bot on a VPS (a primary use case per the README), this is the most exposed attack surface.

Risk Context

• Critical: Sandbox code execution bypasses dangerous command approval via terminal tool #4146 shows that execute_code → terminal() RPC bypasses all approval
• [Security] No network egress filtering — terminal commands have unrestricted internet access #4170 shows unrestricted network egress from terminal
• Security: Docker container runs as root with excessive capabilities #3969 shows even the Docker backend has capability issues

Interaction with Existing Issues

• Address outbound threats #129 — outbound threat mitigation umbrella
• feat(secrets): Phase 2 — Environment Scoping + Terminal Integration #3628 — environment scoping (should apply per-session for gateway)

Alternatives Considered

• Rely on application-level command approval only — already bypassed by Critical: Sandbox code execution bypasses dangerous command approval via terminal tool #4146. Not sufficient as the sole layer.
• Require Docker for gateway — works but lacks persistence across bot restarts and serverless hibernation that other backends offer.

Feature Type

Performance / reliability

Scope

Large (new module or significant refactor)