Hermes Agent Sandbox For Automation

A Hermes Agent sandbox means switching Hermes off the default local backend and onto an isolated one, usually Docker, so the agent's shell commands run inside a container or on a separate machine instead of directly on your computer. One setting does it: hermes config set terminal.backend docker.

📺 Watch: NEW Hermes Agent NOW CHANGES HOW AI WORKS!

🔥 Get the Agent OS as a free bonus: AI Profit Boardroom members get the full Agent OS zip, prompt libraries, daily tutorials and weekly live coaching calls. → Get inside

That's the answer. Now let me show you why it matters, which backends you can pick, how to harden Docker, how to keep your API keys out of the sandbox, and exactly how to set it up.

I run Hermes every day inside my Agent OS with a profile per model. The sandbox is the setting I'd tell anyone to look at before they let an agent loose on real work.

Why you'd sandbox Hermes at all

The default backend is local. Commands run directly on your machine with no isolation. The Hermes docs are blunt about it: the agent has the same filesystem access as your user account.

Think about what that means. Everything your user can read, the agent can read. Everything your user can delete, the agent can delete. Local tool subprocesses even keep your real home directory by default, so CLIs like git, ssh and gh find the credentials they already use.

That's handy for personal use. It's also a lot of trust to hand a model.

The docs give you two ways to reduce it: use hermes tools to disable tools you don't want, or switch to Docker for sandboxing. Sandboxing is the bigger lever.

Here's the old way versus the new way. The old way: run the agent on your laptop and hope it behaves. The new way: give it its own box, decide what goes in, and let it work freely inside that boundary.

If you want to learn Hermes setups like this step by step, the AI Profit Boardroom has Hermes courses, daily updates, my Agent OS zip and 4 coaching calls a week, for $69/mo.

Hermes Agent sandbox backends compared

Hermes supports seven terminal backends. The backend decides where the agent's shell commands actually run. Six of them give you some kind of isolation. This table comes straight from the Hermes docs.

For a deeper look at every backend option, read my guide to the Hermes Agent backend.

📺 Watch: Hermes3D Is INSANE: AI Agents Now Have a 3D Office

Docker hardening: what you get out of the box

The Docker backend runs commands with security hardening built in: all capabilities dropped, no privilege escalation and PID limits. You don't have to configure that part.

On top of that, you get knobs to tighten it further:

• Resource limits. container_cpu, container_memory and container_disk cap how much the sandbox can use.
• Air-gap. Set docker_network to false and the container runs with no network at all. That cuts off all network egress from agent commands, the code execution tool and the file tools.
• Mounts you choose. docker_volumes lists exactly which host folders go in, and you can mark them read-only with :ro.
• Secrets kept out of config. docker_forward_env forwards a value from your shell or the Hermes .env file, so the actual secret never sits in your config file. Use that for tokens and docker_env for static settings.

One warning from the docs: docker_extra_args gets appended to the docker run command and can override Hermes defaults. Flags that conflict with the hardening will quietly weaken isolation. Use it sparingly.

Shared container vs per-session isolation

By default, Hermes starts one long-lived container and routes every terminal, file and code call into it. That container is shared across sessions, /new, /reset and subagents. Installed packages, files in /workspace and background processes all carry over.

That's great for getting work done. It's not a security boundary between conversations.

If you want that boundary, set container_persistent to false. Now every chat gets its own fresh sandbox, created on its first terminal or file call and removed when the session closes or sits idle past lifetime_seconds. Nothing carries over between sessions. No files, no mounts, no background processes.

Add docker_mount_cwd_to_workspace set to true and only the workspace attached to that session is mounted at /workspace. A fresh session with no attached folder gets an empty workspace. Subagents still share their parent session's container.

My take: if one person uses the agent, the shared container is fine. If your agent talks to different people, for example through a bot, use per-session isolation. That pairs well with Hermes Agent bot mode.

Not sure which setup fits your business? Book a free AI strategy session and we'll work it out.

📺 Watch: Hermes AI Agents Just Went Portable

The egress credential-injection proxy

Here's the part most people miss. Even in a sandbox, if you pass your real API keys into the container, the agent can see them.

Hermes fixes that with the egress credential-injection proxy. With it on, the sandbox never sees your real API keys. It only gets opaque proxy tokens that work exclusively from behind a local TLS-intercepting daemon. The daemon swaps those tokens for the real credentials at the network boundary.

Your code inside the sandbox still reads the normal variable names, like OPENROUTER_API_KEY. It just gets a proxy token instead of the real secret.

Setup per the docs is: hermes egress setup and then hermes egress start. The setup command is an interactive wizard. There's also hermes egress setup --from-bitwarden if you keep secrets in Bitwarden Secrets Manager, and hermes egress setup --rotate-tokens to mint fresh proxy tokens.

Know the limit: Docker is the only backend wired for this right now. The docs say Modal, SSH, Daytona and Singularity are not wired yet. It's also disabled by default, so you have to turn it on.

How to set it up, step by step

Here's the simple path with Docker.

1. Install Docker. You need Docker Desktop or Docker Engine installed and running. Podman also works if you set HERMES_DOCKER_BINARY to podman.
2. Switch the backend. Run hermes config set terminal.backend docker. For a remote server instead, run hermes config set terminal.backend ssh.
3. Set your limits. In your config, under terminal, set container_cpu, container_memory and container_disk. The docs example uses 1 CPU, 5120 MB of memory and 51200 MB of disk.
4. Pick shared or per-session. Leave container_persistent as true for one shared container, or set it to false for a fresh sandbox per session.
5. Decide on network. Leave docker_network as true, or set it to false to air-gap the container.
6. Turn on the egress proxy. Run hermes egress setup, then hermes egress start. Running hermes setup terminal also points Docker users at it.

A minimal config looks like this:

terminal:
backend: docker
docker_image: "nousresearch/hermes-sandbox:desktop"
container_cpu: 1
container_memory: 5120
container_persistent: false
docker_network: true

Or skip the typing. Ask your Hermes agent: "Switch my terminal backend to Docker with per-session isolation and set up the egress proxy." Let it run the commands and tell you what changed. That's how I'd tell anyone in my community to do it. If you'd rather have someone walk you through it, book a free AI strategy session.

What runs inside the sandbox

This is where it gets good. On Docker, the browser and computer use run inside the sandbox too, not on your desktop.

Per the docs, computer_use, the bot's browser and the screen they act on always run in the same place. With docker, ssh or singularity, the default placement is inside the sandbox. The desktop stack, Chromium and cua-driver run in the container or on the SSH host. The pane streams the sandbox's screen, and nothing of your host desktop is reachable.

With modal, daytona or vercel_sandbox, the screen is refused for now, because those backends can't host a display yet. Hermes tells you so rather than quietly running the screen on your host. You can force the old behaviour with placement set to gateway, but that's an explicit opt-in.

The sandbox needs the desktop stack, and nousresearch/hermes-sandbox:desktop is the default image for the container backends. Use another image and shell work still runs, but the screen then needs placement set to gateway.

Want to know which tools are worth enabling once your sandbox is up? See my list of the best Hermes Agent tools. Before you trust any model in that setup, test it, which is why I built Goldie Bench. And for the full system of profiles, skills and sandboxes working together, read my Agent OS guide.

FAQ

Does Hermes run in a sandbox by default?

No. The default backend is local, which has no isolation, and the agent has the same filesystem access as your user account. You switch to a sandbox by changing terminal.backend to docker, ssh, modal, daytona, vercel_sandbox or singularity.

Which Hermes Agent sandbox backend should I use?

Docker for most people: full isolation with dropped capabilities, no privilege escalation and PID limits, and it's the only backend wired for the egress proxy right now. Use ssh for remote hardware, and modal, daytona or vercel_sandbox for cloud execution.

Can the sandbox see my API keys?

Only if you pass them in. With the egress credential-injection proxy on Docker, the sandbox only gets opaque proxy tokens, and the real keys are swapped in at the network boundary. Run hermes egress setup, then hermes egress start.

How do I stop sessions sharing one container?

Set container_persistent to false on the Docker backend. Each session then gets its own fresh container, removed when the session closes or goes idle past lifetime_seconds.

Want Hermes courses, daily updates and 4 coaching calls a week? Join the AI Profit Boardroom for $69/mo. Or get a plan for your own setup with a free AI strategy session.