Remote harness execution and sandbox trust boundaries

Short answer

Remote harness execution is the descriptive label this guide uses when the agent control loop, terminal/sandbox, or child harness process runs across a host boundary rather than entirely inside one local process/filesystem. It is not a UHP, ACP, MCP or A2A protocol term.

The important architectural change is that execution now crosses several independently meaningful trust boundaries:

Client / product
      │
      │ UHP (optional external contract)
      ▼
Harness / gateway host
      │
      ├── profile + session ownership
      ├── credential / environment policy
      │
      │ SSH / remote runtime / child-harness transport
      ▼
Remote execution environment
      │
      ├── command execution
      ├── working files
      └── produced artifacts
             │
             │ validated egress / fetch
             ▼
        host-side delivery

A system can get the protocol request right and still get the remote-execution boundary wrong. Environment variables can be missing or leak across profiles, an artifact path can resolve to a credential store, a symlink can cross an intended boundary, or a shared process cache can silently select the wrong terminal backend.

Why this deserves a separate architecture layer

A local harness often has one process environment, one filesystem namespace and one obvious session owner. Remote execution breaks that assumption. The control host must decide what state may cross outward, while artifact delivery must separately decide what bytes may cross back.

That produces five recurring concerns:

Boundary	Question
Execution ownership	Which profile/session owns this remote environment?
Environment transport	Which variable names and values may cross to the remote process?
Secret isolation	Which provider or platform credentials must never cross?
Artifact egress	Which remote files may be copied back and delivered?
Canonicalization/lifetime	Which resolved path, active sandbox and current session are authoritative?

These concerns are orthogonal to whether the outer client speaks UHP. UHP 2026-08-11 standardizes the client/server/harness task contract; it does not prescribe SSH SendEnv, remote filesystem extraction, ControlMaster behavior, process-global environment caching or a specific sandbox implementation.

Hermes current main: remote execution became an explicit trust boundary on 5 September

Note

Maturity boundary: the behavior below is verified in upstream Hermes current main at 2e24e06e on 5 September 2026. The latest tagged Hermes release remains v2026.8.31 / Agent v0.21.0. These commits are therefore post-release current-main implementation evidence, not a new stable release.

SSH environment forwarding: names and values have different transport surfaces

Commit 7456081d fixes a gap where a skill could declare required_environment_variables, or an operator could configure terminal.env_passthrough, and the variables worked locally/Docker but were absent on the SSH host. Hermes now forwards allowed variable names with SSH SendEnv; the values ride in the SSH client’s own environment rather than being embedded in the remote bash -c command text.

The implementation keeps Hermes provider credentials behind the same passthrough blocklist, can fill an unset allowed value from the Hermes .env, and unsets profile-scoped names that are absent from the active profile. The remote SSH daemon must also be configured to AcceptEnv the forwarded names.

A subtle transport detail matters: an SSH ControlMaster only relays the SendEnv names it was started with. Hermes therefore uses a control socket keyed by the active forwarded-name set instead of assuming one multiplexed connection can safely carry every later environment shape. Upstream records a live SSH-daemon verification of that behavior.

The general invariant is: an allowlist is not enough unless the transport actually carries the allowed state, keeps secret values off weaker command-line surfaces, and preserves profile ownership under connection reuse.

Remote artifacts: egress is a separate validation step

Commit 70a64db5 adds a host-side recovery path for MEDIA:/path when the artifact exists inside a remote terminal environment rather than on the gateway filesystem. BaseEnvironment.fetch_file copies a regular file through the existing execution channel using marker-fenced base64. The read is bounded inside the remote environment before bytes are transferred; the current implementation caps this delivery path at 50 MiB, preventing an unbounded source such as /dev/zero from flooding host memory.

The remote path is checked before transfer, resolved inside the sandbox, copied into the host document cache and then passed through the normal host delivery validator. This preserves the existing MEDIA: interface instead of adding a second file-delivery tool.

Follow-up commit b499ab11 tightens that path:

• an unresolvable readlink -f now fails closed instead of falling back to the unresolved name;
• strict media-delivery mode does not perform the remote fetch, preserving its existing recency gate;
• the active sandbox lookup uses the current HERMES_SESSION_ID rather than a looser session-key assumption; and
• path normalization is aligned with the host-side MEDIA: parser.

The follow-up source identifies SSH, Daytona and Vercel as known-remote-home cases. Backends without a known remote home keep a conservative home-relative denylist rather than being treated as equivalent automatically. That distinction matters: remote artifact support should not be generalized beyond the runtime identity and path information the implementation can actually verify.

Conversation and credential stores are never ordinary artifacts

Commit 4139695c closes a separate exfiltration hole in media delivery. Before the fix, MEDIA:~/.hermes/state.db could pass the default delivery policy even though the database contains cross-session conversation history and can contain secrets pasted into chats. Its SQLite WAL/SHM sidecars are especially dangerous under recency-based trust because normal writes keep them fresh.

Hermes now denies delivery of the relevant SQLite stores and sidecars, legacy sessions/ transcripts, the copied browser-profile/ login/cookie store and named-board kanban.db stores, while deliberately leaving ordinary skills, logs, memories and agent-created artifacts deliverable.

This illustrates another invariant: artifact allowlisting must be evaluated against data sensitivity, not merely path reachability or file freshness. A file produced or reachable inside a harness home is not automatically a safe user-facing artifact.

Multiplexed profiles must not share terminal identity accidentally

Current Hermes main ends this verification window at commit 2e24e06e, which fixes a cross-profile terminal-backend leak in a multiplex dashboard process. A request scoped to a secondary profile could cause that profile’s terminal.backend to be re-bridged into shared os.environ. In the documented failure shape, a launch profile configured for SSH retained its SSH host variables but acquired TERMINAL_ENV=local from a sibling profile, so commands silently executed locally.

The fix resolves the true process-level Hermes home with an override-immune helper before re-bridging terminal configuration. Per-request profile overrides can still scope request-local work, but they can no longer redefine the shared process’s launch profile while that shared environment is being refreshed.

The architectural lesson is broader than Hermes: context-local identity and process-global state must not be treated as the same ownership domain. Any shared cache or environment bridge that controls execution location needs an explicit fence against request/profile overrides.

GitHub Agentic Workflows current main: specialized sandboxing consolidates on Cloud Hypervisor

GitHub Agentic Workflows documented a material sandbox-runtime transition on 5 September 2026. Current upstream main deprecates the specialized gvisor and docker-sbx runtime options and makes preview cloud-hypervisor the supported direction when a workflow needs a hardware-virtualized microVM boundary. The ordinary docker runtime remains available with its network-isolation and proxy-enforcement model.

This is a current-main maturity boundary, not a stable-release claim: the latest GitHub Agentic Workflows release observed is v0.88.2, published 3 September 2026, while the consolidation documentation and workflow migration landed after that release. The 5 September documentation says Cloud Hypervisor currently requires a GitHub-hosted Ubuntu x86_64 runner with /dev/kvm; the compiler performs host checks and provisions digest-pinned runtime assets.

The migration is useful evidence for a broader harness-design principle: sandbox policy and sandbox mechanism are separate layers. A product may keep the same workflow-level execution contract while retiring one isolation substrate, retaining a lower-cost/default container profile, and directing higher-isolation workloads toward a hardware-virtualized runtime. UHP does not standardize that substrate choice, so a UHP-compatible server could make an equivalent migration without changing its external protocol contract.

The same current-main line also exposes why microVM adoption needs explicit filesystem policy rather than only a stronger isolation primitive. Follow-up commit 36ab2fbe grants the repository-memory directory /tmp/gh-aw/repo-memory/<id> write access under the Cloud Hypervisor sandbox after agents otherwise hit a read-only-filesystem failure. That is not a weakening of the protocol boundary; it is evidence that writable state has to be deliberately projected into the sandbox when the runtime’s default filesystem policy becomes stricter.

Caution

GitHub Agentic Workflows is not UHP and this does not establish a UHP binding. It is upstream implementation evidence for agent-workflow sandbox selection and policy. No source reviewed here shows GitHub Agentic Workflows adopting UHP, HarnessRouter using its Cloud Hypervisor runtime, or UHP defining gvisor, docker-sbx, Cloud Hypervisor, KVM or GitHub Actions runner semantics.

Pi v0.85.1: remote harness support is explicitly source-only

Pi v0.85.1 turns the earlier current-main distribution boundary into a released product fact. Its coding-agent changelog says SDK import failures in v0.85.0 were caused by unintentionally publishing internal experimental code and dependencies. The fix keeps the experimental client and experimental/plugin subpaths and the server/client commands source-only through pi-test.sh; the supported local SDK and stdio RPC API remain unchanged.

The underlying current-main change, commit 1382777e, excludes those remote-harness paths from published npm packages and standalone binaries, keeps the remote-harness packages as development dependencies, and adds packed-consumer checks. The stable release therefore confirms the key maturity distinction: remote-harness source code exists, but it is not a supported packaged runtime surface in v0.85.1.

Practical invariants for remote agent execution

The current implementation evidence supports a reusable checklist:

1. Bind every remote environment to an explicit session/profile owner. Do not infer owner identity from a mutable process-global default.
2. Separate variable-name policy from secret-value transport. Allowlisted names, blocked provider credentials and transport mechanics are distinct controls.
3. Assume connection reuse has policy state. Multiplexed SSH or pooled transports can cache capability/environment choices that must be keyed or invalidated.
4. Validate artifact egress independently from command execution. A harness being allowed to read a file does not mean the gateway should deliver that file to a user.
5. Canonicalize remotely and fail closed. Symlink/realpath resolution must happen in the filesystem that actually owns the path; unresolved targets must not become a bypass.
6. Bound transfer at the source. Size checks after a remote stream reaches host memory are too late for unbounded or hostile sources.
7. Keep sensitive runtime stores explicitly non-exportable. Session databases, browser profiles, credentials and sidecars need deny rules even when they are recent or adjacent to normal artifacts.
8. Publish maturity separately from source presence. Experimental remote-server/client code should not be described as a stable packaged capability until its distribution boundary says so.
9. Treat sandbox substrate and sandbox policy as different controls. A stronger microVM boundary still needs explicit writable-state, network and credential projections; protocol compatibility alone does not define them.

Relationship to UHP, ACP, MCP and A2A

UHP can sit outside these remote-execution choices. A UHP server may run its selected harness locally, inside a container, over SSH, through a remote execution service, or behind another internal process boundary. The current UHP specification does not require one of those deployment models.

Likewise, ACP or another agent protocol can be used as an internal child/runtime transport in a composed harness, but that does not standardize SSH environment forwarding or artifact extraction. MCP standardizes model/tool context integration rather than the host↔sandbox execution boundary described here, and A2A standardizes agent-to-agent interaction rather than a terminal backend’s filesystem/credential policy.

Passing UHP conformance therefore should not be read as a sandbox-security certification. The protocol and the execution substrate answer different questions.

For adjacent context, see UHP security and trust boundaries, harness composition and subagent delegation, UHP and Hermes and UHP and Pi.

Current boundary

As verified on 5 September 2026:

• UHP remains 2026-08-11.
• HarnessRouter’s latest stable release remains v0.13.3; no new backend or conformance denominator is implied here.
• Hermes latest stable remains v2026.8.31 / Agent v0.21.0; the remote-execution fixes above are post-release current-main behavior through 2e24e06e.
• GitHub Agentic Workflows latest stable remains v0.88.2; the Cloud Hypervisor consolidation is post-release current-main behavior documented on 5 September, with gvisor and docker-sbx deprecated while default Docker remains available.
• Pi latest stable is v0.85.1; its experimental remote harness is explicitly source-only in that release’s supported distribution boundary.
• No native UHP adoption by upstream Hermes, GitHub Agentic Workflows or Pi is established by these changes.
• No standardized UHP↔remote-terminal, UHP↔microVM or UHP↔remote-harness binding is inferred.

Primary sources

• GitHub Agentic Workflows: Cloud Hypervisor runtime consolidation
• GitHub Agentic Workflows consolidation documentation — 19f7c074
• GitHub Agentic Workflows migration — d893c7da
• Cloud Hypervisor repo-memory write projection — 36ab2fbe
• GitHub Agentic Workflows stable v0.88.2
• Hermes current main cutoff — 2e24e06e
• Hermes SSH passthrough via SendEnv — 7456081d
• Hermes remote MEDIA: extraction — 70a64db5
• Hermes remote-media fail-closed hardening — b499ab11
• Hermes media denylist for state/session/browser/Kanban stores — 4139695c
• Hermes stable v2026.8.31 / Agent v0.21.0
• Pi v0.85.1 release
• Pi v0.85.1 coding-agent changelog
• Pi remote-harness distribution boundary — 1382777e
• UHP architecture specification
• UHP security specification