Operations

Sandbox Boundaries

Backend-specific execution and filesystem limits that reduce damage without treating a plain child process as an OS sandbox.

Concept-specific field plateSandbox Boundarieshx-graph-context-concept-sandbox-boundariesLoading visual preview…
View full-size visual

Sandbox Boundaries

What it is

Backend-specific execution and filesystem limits that reduce damage without treating a plain child process as an OS sandbox.

In plain terms

A child process is a separate workbench, not a locked laboratory. Hermes can limit which built-in tools sit on that bench, how long the work runs, and how much output returns, but the operating system still decides what the underlying Python process itself can reach unless a stronger backend supplies real isolation.

Why it matters

Execution safety comes from layered, backend-specific controls rather than a universal workspace wall. Tool allowlists, approvals, redaction, timeouts, containers, and host permissions each cover a different path. A local child process must not be described as unable to touch files such as /etc/hosts merely because the Hermes RPC file tools are workspace-aware; direct Python or terminal access follows the actual OS/backend permissions.

How it works

execute_code (tools/code_execution_tool.py) starts a controlled child process and exposes only seven Hermes tool names over its RPC channel: web_search, web_extract, read_file, write_file, search_files, patch, and terminal, intersected with the session’s enabled tools. It also scrubs secret-shaped environment variables, applies the normal approval policy to nested terminal calls, and enforces five-minute, 50-call, and 50KB-output limits. Those controls do not create an operating-system filesystem or network sandbox: plain Python in a local child process can still reach resources permitted to that OS account. Stronger isolation depends on the selected backend, such as a correctly configured container, and bind-mounting host paths weakens that boundary.

A concrete example

A skill runs execute_code to fetch a webpage and save a summary. Inside the controlled child process:

  1. It can call write_file because that name is on the seven-tool RPC allowlist.
  2. It cannot call a cron-scheduling tool through that RPC surface because the name is not exposed.
  3. Secret-shaped environment variables are removed and the run stops at the configured time, tool-call, or output limit. Those controls do not claim that direct Python filesystem or network calls are blocked; that stronger guarantee requires an isolated backend configured without unsafe host mounts.

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.
  • No article currently mentions this concept by name/alias often enough to qualify (see mention-mining policy).