Docker or SSH Isolation

6.5. Docker or SSH Isolation — The Real Isolation Boundary

Core principle: the container is the security boundary

This is the most important thing to understand: when terminal.backend is set to docker, singularity, modal, or daytona, the dangerous-command checks in 6.3 are skipped entirely — because the container itself is the replacement safety boundary. This is a deliberate trade-off: allow unlimited execution inside a disposable box, instead of controlling every command.

TERMINAL_ENV=docker

When container isolation is mandatory

For untrusted repositories or unfamiliar unverified code, use Docker or Daytona as the terminal backend — running the default local backend in front of untrusted content means operating outside the officially supported security model of Hermes.

Isolation at the operating system level (supplement, not replacement)

Even without a container backend, restricting the write permissions of the operating user (covered in 1.2) remains a separate layer: the result is that even if the agent “decides” to run rm -rf /, the kernel still refuses, because that user only has write rights inside its own data directory.

Notes

• If the agent must process content from uncontrolled sources (open web, incoming email, multi-user chat channels, unverified MCP servers), switching fully to a container backend is mandatory, not optional — running a local backend in this situation is outside the official security model.
• Do not confuse “a container that isolates the agent” with “a container that isolates the Hermes process itself” — the official Hermes Docker image (2.3) is about compact/safe deployment of the Hermes process itself; terminal.backend: docker is about isolating the command execution environment that the agent produces. Two separate layers, usable at the same time.
• Make sure the container image used for the terminal backend is also locked down properly — isolation only works if the image itself does not come with holes or excessive privileges.