Hermes LoopHermes Loop
Hermes runtime · isolation

Runtime isolationWhat protects you today, and what doesn't yet.

← Runtime
What this is
Where terminal_exec / python_rpc actually run, and what the boundary is.
What to do
Read what the current local backend gives you, and what real isolation (Docker / Modal / SSH) would add.
What happens next
When a backend is wired, this page will switch its status. Until then, treat the policy as an accident-prevention layer, not a sandbox.
Active backend

Local Node process

RUNTIME_BACKEND env: local

ACTIVE
  • Workspace-locked working directory (path traversal blocked).
  • Hard timeout (30s default, 120s cap) with SIGTERM → SIGKILL.
  • 8 KB stdout/stderr cap with truncation flag.
  • Secrets stripped from child env (HERMES_API_KEY, OPENROUTER_*, DATABASE_URL).
  • Three-bucket policy: ALLOW / RISKY / BLOCK (policy →).
  • Risky and Python calls require an approval before running.
  • Every call logged as a ToolCall row + audit event.
terminal_execbackend: local
requested local
python_rpcbackend: local
requested local

What this is NOT: there is no per-mission container, no namespace isolation, no kernel-level filtering. The host Node process runs the spawned shell. Treat the policy as defense-in-depth against accidents and obvious abuse, not as an adversarial boundary.

Roadmap backends

Real isolation is still on the parity board

Docker
ROADMAP

Per-mission container with hardening, namespace isolation, capability dropping. Volume-mount workspace read-only.

Modal
ROADMAP

Serverless GPU/CPU sandbox. Handles Python RPC + heavy missions without provisioning your own host.

SSH
ROADMAP

Run terminal_exec on a remote host (e.g. a target box you're auditing). Per-host policy.

Set RUNTIME_BACKEND in .env.local to one of local | docker | modal | ssh. Until the backend is implemented, the runtime warns and continues with local.