HostAgentics Docs

HostAgentics Sandboxing

Last updated: 2026-08-06

This document describes the isolation and sandbox posture applied to every runtime on the HostAgentics platform. The principles: runtimes are isolated from each other, from the host, and from the control plane; agent workloads run in a restrictive safe mode by default; and browser automation cannot be abused to reach internal services. Customer-facing security claims must be limited to what this document actually supports (see also `docs/security.md`).

1. Per-runtime isolation

  • **One container per runtime.** Every n8n, OpenClaw, and Hermes runtime is its own service with its own persistent volume, its own environment variables, its own credentials, and its own domain. Runtimes never share volumes, credentials, or memory stores.
  • **No shared agent memory.** Agent runtimes each have an isolated memory store; there is no cross-runtime memory sharing, and the platform does not read agent memory.
  • **Provider-level isolation.** Services are provisioned as separate workloads in the infrastructure layer; a failing or malicious runtime cannot reach another runtime's storage or environment.

    • 2. Safe mode (default)

    Agent runtimes (OpenClaw, Hermes Agent) start in **safe mode** — a runtime-level capability that restricts tool use and outbound actions:

  • **No host shell.** Neither the control plane nor any runtime exposes host shell access. There is no Docker socket anywhere in the runtime plane: the provider abstraction has no socket concept, and no runtime receives host-level container control.
  • **No cloud metadata access.** Runtime workloads cannot reach provider-internal metadata endpoints, the control-plane network, or provider-internal address spaces. Outbound destinations are subject to the runtime's egress policy; link-local and provider-internal ranges are not routable from runtime workloads.
  • **Restricted filesystem.** Agent file access is bounded by the runtime's write-safe root and persistent volume; writes stay inside the runtime's own storage (Hermes: `/opt/data` via `HERMES_WRITE_SAFE_ROOT`; OpenClaw: its state volume).
  • **Caps enforced regardless of mode.** The plan's concurrency limits (agent tasks, browser sessions) and resource hard limits are enforced by the platform whether or not safe mode is relaxed.

    • Safe mode is configurable per runtime by the customer; relaxing it widens what the agent may do but does not change the platform-level isolation, resource caps, or egress policy.

    3. SSRF protection for browser automation

    Agent runtimes can drive a managed browser (browser sessions are a plan entitlement). A compromised or prompt-injected agent could otherwise abuse the browser to reach internal services (SSRF):

  • Browser automation runs inside the runtime's own network scope, **not** on the control-plane network; it cannot reach control-plane metadata endpoints or internal services.
  • Outbound destinations are subject to the runtime's egress policy; provider-internal and link-local address spaces are not routable from runtime workloads.
  • Browser sessions are counted and capped per plan (`maxBrowserSessions`); exceeding the cap blocks new sessions rather than silently allowing more.

    • 4. Control-plane boundary

  • The control plane is **not in the runtime data path** for customer workloads: customers reach their runtimes directly over HTTPS at their branded domains.
  • Runtimes communicate with the control plane only through narrow, authenticated channels (Relay callbacks with HMAC signatures and scoped tokens — `docs/relay.md`; status/health reports). There is no shared database credential, and the control plane never mounts into runtime containers.
  • Secrets injected into runtimes are per-runtime and scoped; the platform's own credentials (Stripe keys, management keys, workspace token) never enter runtime environments.

    • 5. What sandboxing does not do (limitations)

  • Sandboxing reduces the blast radius of a compromised or prompt-injected agent; it does not eliminate prompt injection (see `docs/security.md` §9).
  • It protects the platform and other tenants, not the customer's own data exfiltration to third parties the customer's workflows legitimately call.
  • No sandbox posture is a security guarantee; this document describes engineering controls, not an audited attestation.

    • 6. Related documents

  • `docs/security.md` — threat model and controls
  • `docs/openclaw-deployment.md`, `docs/hermes-deployment.md` — sandboxing in the provisioning flows
  • `docs/resource-limits.md` — caps enforced regardless of mode