A sandbox backend in 📝Hermes Agent is the execution environment for terminal commands and code — local process, Docker container, remote SSH host, or a third-party managed runtime — chosen per agent or per task.
The sandbox backend is the layer between the agent's reasoning and the physical execution of a command. When Hermes decides to run a shell line or execute generated code, that work runs inside whichever backend is configured for the current task. Hermes ships six backends out of the box: a local backend that uses the host machine directly, Docker for containerized isolation, SSH for execution on a remote host, and three third-party platforms — Daytona, Singularity, and Modal — for managed cloud sandboxes.
The choice of backend is a security and reproducibility decision more than a performance one. The local backend is fastest but offers the least isolation; running an agent against arbitrary tasks with the local backend gives the agent the full permissions of the user running it. Docker, SSH, and the third-party backends each provide a different combination of namespace isolation, network reachability, and persistent state. Hermes layers a pre-execution scanner on top of every backend to inspect commands before they run, but the backend itself determines what "running" can affect.
Backends are configured per agent and overridable per task; a single Hermes install can route different tasks to different backends without relaunching. The container-hardening defaults — read-only root filesystems, dropped capabilities, namespace isolation — apply to backends that support them; SSH and local backends inherit the host's posture instead. Choosing the right backend is operational hygiene: tighten the sandbox for tasks that touch untrusted input, loosen it for tasks that need the host's tools and state.