Sandbox Boundaries
What it is
Execution and filesystem limits that reduce damage from tools or generated commands.
In plain terms
Imagine a chemistry classroom’s fume hood: mixing something risky stays safe only as long as nobody hooks its exhaust duct up to the building’s shared air return. Hermes treats code execution the same way: a script runs in a contained child process with only a thin set of doors to the outside world, and the moment that containment gets bridged back to the host, the fume-hood guarantee stops applying.
Why it matters
Which directories, which processes, which network access — sandbox boundaries are the hard limits placed around what code execution, terminal tools, and generated commands can actually touch, so a mistaken or adversarial command can’t do damage outside its intended scope. This is the technical enforcement layer underneath approval boundaries: approval decides whether an action requires confirmation, sandboxing decides what’s even possible if it goes wrong regardless of that approval. It’s most visible around code execution and terminal tools, the two toolsets with the most direct system-level access.
How it works
The execute_code sandbox (tools/code_execution_tool.py) spawns a script in its own child process whose only way to call Hermes tools is a tiny RPC channel scoped to seven allowed names, web_search, web_extract, read_file, write_file, search_files, patch, terminal, intersected with whatever the current session actually has enabled. Before that process starts, its inherited environment variables are scrubbed of anything containing a secret-shaped substring like KEY, TOKEN, or SECRET, leaving only a narrow allowlist. A script gets a default five-minute timeout and a cap of 50 tool calls. When the terminal backend is a Docker container whose host directories are bind-mounted in (tools/terminal_tool.py), Hermes treats it as no longer meaningfully isolated and routes it back through the full command-approval guard instead of a fast path.
A concrete example
A skill runs execute_code to fetch a webpage and save a summary. Inside the sandboxed script:
- It can call write_file to save the summary, that name is on the allowed list.
- It cannot call a cron-scheduling tool at all, even if the script’s code tries, the RPC surface simply doesn’t expose it.
- Printing os.environ shows PATH and HOME but no ANTHROPIC_API_KEY-shaped variable, because the child process never received it. If the same script instead ran inside a Docker sandbox with the host’s home directory mounted in, Hermes would no longer treat it as isolated.
How it connects
This note belongs to the Operations family. Its closest neighboring concepts are: Approval Boundaries, Secret Handling, Agent Runtime, Personal OS.
Source evidence
vendor/hermes-agent/toolsets.py#<file>— Structural Source Map fallback for toolsets.py. A core source file in the Tool Registry and Toolsets structure within Tools, Toolsets, and MCP.
Workflows
- No first-pass workflow mapping yet; this concept still appears in the vault graph through articles and source evidence.
Related articles
- No article currently mentions this concept by name/alias often enough to qualify (see mention-mining policy).