1. Create a harmless two-folder task
In your own terminal on the Agent host, create an input folder and a separate output folder:
HERMES_LAB="$(mktemp -d)"
mkdir "$HERMES_LAB/input" "$HERMES_LAB/output"
printf 'Apples: 3\nPears: 4\n' > "$HERMES_LAB/input/counts.txt"
printf '%s\n' "$HERMES_LAB"Keep the printed absolute path. The only task will be to read the two counts and write a total of 7. Do not use your home, source checkout, browser profile, SSH directory or real customer files for this experiment.
2. Configure the disposable profile’s terminal
In that profile’s config.yaml, merge these settings into the existing terminal: block. Replace both example host paths with the absolute path printed above; do not add a second terminal: key.
terminal:
backend: docker
docker_image: "nousresearch/hermes-sandbox:desktop"
docker_mount_cwd_to_workspace: false
docker_forward_env: []
docker_volumes:
- "/absolute/hermes-lab/input:/work/input:ro"
- "/absolute/hermes-lab/output:/work/output:rw"
docker_network: false
container_persistent: falseStart a fresh Agent process and session for this disposable profile. The first run may need to pull the sandbox image. Do not enable host networking, mount the Docker socket, or add your whole home to make a failed test work.
Important boundary: this config limits the terminal and Hermes file tools that use this container. It does not sandbox the whole Hermes process, browser, MCP tools, plugins or model connection. Hermes may also mount its skills, caches and credential-related files automatically; an empty docker_forward_env is not proof that the container contains no secrets. Inspect the actual container mounts before progressing beyond this synthetic profile.
3. Run one explicit terminal-tool task
Ask the agent:
Use the terminal tool for this synthetic test.
Read /work/input/counts.txt.
Write only the total, 7, to /work/output/total.txt.
Do not use other tools or change other files.In your own host terminal, check:
cat "$HERMES_LAB/output/total.txt"
cat "$HERMES_LAB/input/counts.txt"Expected: the output contains 7; the input still contains Apples: 3 and Pears: 4. Inspect the tool activity: Hermes file tools also run in this container. Check that no browser, MCP or plugin tool touched the files.
4. Test the refusal, not just the happy path
In this disposable task only, ask the terminal tool to run:
printf 'changed\n' >> /work/input/counts.txtExpected: the write fails with a read-only filesystem error. On the host, check that the original file is unchanged. If the write succeeds, stop: inspect the actual backend, mount modes and profile configuration before giving it real files. A model declining the request is useful behavior, but it does not prove that the filesystem enforced the boundary; the attempted write and host check do.
With docker_network: false, this terminal container has no network route. The model API still runs outside that container; use the data-flow test to examine that separate route.
5. Retire the test and choose the real boundary
Stop the test process, inspect its actual disposable containers and remove only those you created. Delete the two-folder lab after checking the path, and discard the test profile when finished. For a real job, expose only the specific input and output directories it needs, then repeat the positive and negative tests.
If the requirement is “this agent cannot read my personal files or credentials,” use a separate OS user or VM with only the required files and credentials. A prompt, a tool-name choice, or the terminal backend alone does not provide that whole-process boundary. Keep untrusted plugins and browser sessions inside the same deliberate isolation plan.