OpenClaw Architecture: Trusted Gateway vs Single-Process Harnesses

Explains OpenClaw's security model: trusted gateway, untrusted execution, deterministic policy, and versioned state, compared with single-process harnesses. Essential for architects and security engineers evaluating agent frameworks.

Read this when

  • You are evaluating agent harnesses for team or enterprise use
  • You need to explain to a security team how OpenClaw differs from single-process harnesses
  • You want the citable version of the trusted-gateway / untrusted-execution argument
  • You want to know whether OpenClaw's enterprise depth makes it heavyweight for personal use

Every harness now ships the same feature list: channels, tools, memory, skills, scheduling. A feature table alone does not define the security model. The real differentiators are where the trust boundary sits and whether policy is enforced in code or merely requested in the system prompt.

Most harnesses operate as a single trust envelope. One process runs the agent loop, the channel connections, the credentials, and the shell, all as a single OS user on a long-lived machine. Wrapping that process in a VM still keeps every component inside the same boundary. The machine is maintained and patched in place.

OpenClaw separates a trusted Gateway from untrusted, movable execution. Policy is enforced by code that fails closed, and state is versioned and migrated, so a deployment is replaceable. Every claim below carries a source; the comparison with Hermes Agent is based on its source tree. This separation of credentials from execution is spreading: OpenAI's Agents SDK adopted it in 2026 for sandbox orchestration. An SDK supplies components for building an agent; OpenClaw ships this separation as an operated product with channels, identity, and state.

What an enterprise harness has to prove

Six testable properties:

  1. Separated trust boundary. Execution moves into a sandbox, a node, or a throwaway cloud machine; credentials do not move with it.
  2. Policy is code. Denial is structural, not a request the model is asked to honor; approval paths fail closed.
  3. Authenticated access, bounded roles. Inbound access is default-deny and authenticated; people hold bounded roles; the vendor states which boundaries are security and which are convenience.
  4. Secrets have owners. Credentials are referenced, not inlined; one broken secret degrades exactly its owner, not the platform.
  5. Versioned state, guarded upgrades. State is schema-versioned with owned migrations; upgrades are guarded and delivered through release channels.
  6. Recorded provenance. Memory, audit, and delivery answer "where did this come from and what happened to it" with recorded facts and bounded retention.

How OpenClaw answers

The trust boundary

The Gateway owns channel connections, config, credentials, and the control-plane API. It binds to loopback by default and refuses non-loopback binds without a working auth path (architecture, network model).

tools.exec.host resolves to the gateway host, a sandbox, or a paired node. While a sandbox runtime is active, per-call escapes to the host are rejected, and an explicit host=sandbox with no runtime configured fails instead of silently running on the host. Backends: Docker and Podman (default profile: no network, read-only root, all capabilities dropped, non-root user), SSH, OpenShell, and Daytona cloud sandboxes (automatic idle-stop with resume on next use, memory-preserving pause, cold-storage archiving), the latter two installed as plugins, registered through the same backend contract as Docker. If you run OpenShell already, OpenClaw uses its sandboxes; it does not need to be wrapped in one.

Sandbox bind mounts are validated twice, once on the normalized path and again after resolving through the deepest existing ancestor, so symlink-based bypass attempts fail closed. The deny-list of credential and system paths cannot be disabled, the dangerouslyAllowExternalBindSources override relaxes only the allowed-roots check.

This separation also applies across machines. A paired node that hosts sessions receives a sealed worker artifact, content-hash-verified at three points (download, manifest, and on every reuse); the node installs no packages and runs no lifecycle scripts, and can put each hosted session in its own container, enforced by node-local config the Gateway's launch request cannot express. With Cloud workers, a session's coding work runs on a throwaway cloud machine that connects back to the Gateway with a closed, dispatcher-enforced RPC method allowlist, gets per-dispatch minted credentials stored hashed at rest with a ten-minute TTL, and holds no standing model, GitHub, or cloud credential. Inference is proxied through the Gateway. The durable transcript lives only on the Gateway; the worker sees a bounded per-turn context window and keeps no copy.

A "cloud backend" in a single-envelope harness is a remote place where the terminal tool runs, while the process holding every credential stays on the original machine. An OpenClaw cloud session moves the execution and retains authority at the Gateway. Of these two approaches, only the OpenClaw cloud session changes what a compromised sandbox can reach.

Sandboxing is off by default. Out of the box, OpenClaw is a personal assistant for one trusted operator, and exec runs on the gateway host without prompts. The enterprise posture requires explicit configuration, verifiable with two commands: openclaw sandbox explain prints the effective execution posture, and openclaw security audit flags drift with stable check IDs you can alarm on.

Policy as code

Deterministic enforcement is not unique to OpenClaw, Claude Code, Codex, and Goose all gate approvals in code. Structural tool gating in a multi-channel assistant, rather than a terminal, is rarer: permission modes shape which tools exist at all. A read-only session never has the file-mutation tools registered, edit, write, and apply_patch are not offered to the model, and its exec tool resolves to a deny policy that refuses at the call boundary. full requires operator.admin, and scopes are derived from request parameters before dispatch (operator scopes), so a method with a privileged parameter still needs the privileged scope.

Three controls govern separate decisions (sandbox vs. tool policy vs. elevated). The sandbox decides where tools run. Tool policy decides which tools exist; deny always wins, and a blocked call's audit entry names the deny rule that fired. tools.elevated is an exec-only escape hatch that cannot override a deny.

Exec approvals bind an approved run to its canonical command, cwd, environment hash, and content-hashed file operands, and deny on any drift after approval. Where OpenClaw cannot bind precisely, shell pipelines, commands after a cd, interpreters with no identifiable single file operand, it refuses to mint the approval rather than approve an imprecise binding. When no approval UI is reachable, the answer is deny by default, and strict cases (inline eval, heredocs) cannot be softened by any fallback setting.

Tool policy filters by name, not side effects: allowing exec while denying write does not make shell commands read-only. As documented, restricting side effects is the sandbox's responsibility.

Identity and roles

Control-plane clients present signed device identities and go through pairing. Reconnecting with broader scopes creates a new approval request; there is no silent escalation of privilege. Unknown DM senders get a pairing code, not the agent. Identity-aware front doors (Tailscale, trusted proxy, Cloudflare Access) map verified identities to scopes.

Eight operator scopes, read, write, admin, plus narrower ones for pairing, approvals, questions, and talk, are derived per request from the actual parameters before dispatch, and methods with no scope classification are denied rather than allowed. A read-scoped connection cannot mutate anything, and admin-only parameters stay admin-only however the request arrives. gateway.roles assigns named person-level roles: visibility into other people's sessions, an agent allow-list, and a scope ceiling that is intersected with whatever connection auth granted, never added to it. A profile with no assignment, or an assignment naming an unknown role, resolves to deny-all. Multi-user sessions record an immutable creator, an assignable owner, and a bounded participant history, and verified GitHub identity can flow through to Co-authored-by trailers and PR-linked session transcripts (user model).

Our security documentation lays out the boundary clearly: a single gateway represents a single trust domain. Roles facilitate collaboration among individuals who already have mutual trust. For multi-tenant setups, deploy one gateway per tenant; openclaw fleet handles this automatically by spinning up one hardened container cell per tenant, each with its own state, credentials, and network (currently experimental). The multi-tenant guide details the isolation hierarchy beyond that, moving from gVisor and Kata up to dedicated machines.

Secrets

All supported credential fields accept a SecretRef: env, file, exec (this is how 1Password, Vault, Bitwarden, and sops integrate), or the shared store. If a secret cannot be resolved during startup, the Gateway enters a degraded state instead of shutting down. The specific owner (one provider, one channel account, one plugin route) gets flagged as unavailable, requests to it fail with a typed error, no fallback to a different credential occurs, and doctor along with status identify every degraded owner with a redacted explanation. A faulty secret triggers an operational alert, not a service disruption.

Model-provider credentials are held as sentinels in memory. Configuration, logs, SDK objects, and error paths all carry the sentinel; the actual value gets substituted at the egress boundary, and any sentinel-shaped value that is not recognized is rejected rather than passed along. Operators can provide a credential without exposing it to the agent: a secret entered under Settings → Secrets in the Control UI is write-only from the moment it is saved, list output never displays it, no agent-facing surface can retrieve it (one admin-scoped resolve exists for operators), and credential-shaped names default to protected. The agent's context contains only the sentinel, which is AES-256-GCM ciphertext keyed to the Gateway process, and the opt-in egress proxy swaps in the real value at the network boundary for exact allow-listed destination hosts. Even a fully compromised agent context holds nothing worth stealing. The agent can also ask for a credential it does not possess: an agent-requested secret prompt goes to the operator, the value lands in the protected store, and the model still never sees it. Hermes has no counterpart: its dashboard uses "write-only" masking, but an /api/env/reveal endpoint returns the plaintext (hermes_cli/web_server.py:8752), entered values end up in .env and the process environment, and iron-proxy's token swap covers eleven model-provider keys inside Docker sandboxes while the real credentials stay in the agent process. openclaw secrets audit locates plaintext at rest; secrets configure --apply shifts it behind refs. Workspace .env files cannot override provider keys or OPENCLAW_* runtime controls.

Browser agents handled the sign-in scenario: 1Password for Claude and ChatGPT's takeover mode keep a password away from the model while a human logs in, one fill at a time, with no durable artifact. As far as we can tell, OpenClaw is the only agent harness where the agent can request an arbitrary credential mid-task and receive back only a durable, reusable handle. The MCP specification prohibits the in-band version of this flow because a client cannot keep an elicited value out of model context; the Gateway can, because it controls both the question channel and the store. Hermes's tracker requested this feature (NousResearch/hermes-agent#410) and closed it by shipping operator-side vault resolvers instead.

The store itself is 0600-permission SQLite, not an HSM, and the docs direct operators with stronger custody requirements to external vaults. A SecretRef reduces what is on disk; it does not prevent a host-exec agent from reading files. Restricting file access falls to the sandbox.

Versioned state, guarded upgrades

Runtime state is database-first: one global SQLite store, one per agent, with a written contract that runtime code never reads or writes JSON sidecars as active state. The contract is machine-checked in CI (database schemas). Schemas carry a two-place version contract; a build refuses to open a database newer than itself; openclaw update refuses a target older than your on-disk schemas; openclaw doctor --fix is the sole owner of file-to-SQLite migrations and records a receipt for each one. Backups go through SQLite's online-backup API and are integrity- and hash-verified; restore never happens in place. Restart recovery resumes interrupted turns under a bounded attempt budget, and a crash-loop breaker keeps the control plane reachable while suppressing channel autostart.

Releases come through four channels (stable, extended-stable, beta, dev) on calendar versions with immutable npm publishes (development channels, release process). Extended-stable is the conservative track and it fails closed: the updater re-fetches and verifies the exact selected package, and missing or inconsistent registry data is an error, never a fallback to latest. Behind every release sits Full Release Validation, which seals an immutable execution-plan artifact covering cross-OS installs and upgrades, package acceptance, live channel lanes, and performance gates. Publishing is serialized and provenance-verified (Sigstore attestations, npm provenance) under the OpenClaw Foundation identity.

Per-surface readiness is published. The maturity scorecard grades 50 surfaces across 280 capability areas from deterministic QA evidence plus reviewed quality scores, with long-term-support status on every row. Extended-stable answers how long a surface is supported; the scorecard answers how proven it is.

Provenance

OpenClaw memory is Markdown plus a SQLite index; there is no hidden state (memory architecture). Each indexed chunk carries an origin class (owner, agent, untrusted, system) stored outside the prose, so recalled text cannot promote its own trust level, and classification never defaults to owner. Graph memory layers like Zep's Graphiti also trace facts to their sources; what OpenClaw adds is a gate that consumes the provenance: the dreaming consolidation pass drops untrusted and system candidates before the consolidation prompt is even built, and cron, heartbeat, and subagent sessions never produce durable memory candidates at all. Taint follows content within a turn, too: after a network-sourced tool result, every later assistant message in that turn is marked tainted and classifies untrusted for memory, whoever was speaking. Cross-conversation recall has a fixed boundary: groups and channels are neither source nor destination (active memory).

Retrieval scoring follows the pattern Generative Agents laid down, weighing relevance, recency, and importance at write time, then applying MMR diversity across a hybrid of BM25 and vector results. Consolidation, or dreaming, happens offline as a background job, with its cost measured through sleep-time compute. Because long-horizon evaluations reveal that the content itself drives outcomes more than the indexing strategy does (LongMemEval), curation effort is spent mainly on the write path.

Where the literature flags problems without offering solutions, OpenClaw applies structural remedies. Memory poisoning (OWASP ASI06, MINJA) gets provenance-gated promotion instead of content inspection. Prospective-memory decay (TriggerBench), meanwhile, is handled by turning standing intents into deterministic triggers outside the model. And tombstoned deletion addresses what Ghost Vectors shows about soft-deleted embeddings staying recoverable.

Each memory record carries its origin sessions through consolidation: merges union the origins, supersedes re-key them, and the model itself never holds provenance. An admission policy can exclude designated sessions from the dreaming pipeline, with those exclusions recorded and reversible. openclaw memory forget removes the tracked artifacts of chosen sessions, including entries, diary quotes, index rows, vectors, and embedding caches, scrubs rewrite backups, and lays down durable tombstones that ingestion, backfill, and later sweeps all honor. A participant selector picks that participant's sessions; archives, exports, and external copies demand separate review. Commands like "purge everything that came from email" and "remove what a departed employee contributed" are supported.

Other systems offer pieces of this: Zep records episode provenance and advertises right-to-be-forgotten deletion. But among every agent memory system we surveyed, SaaS or open source, none documents tombstoned non-resurrection, meaning a purge that the system's own consolidation, backfill, and indexing can never silently reverse. Elsewhere, sleep-time consolidators can re-derive deleted content, and extractors can recreate it a week later. Compliance research holds that genuine erasure needs a provenance map from source records to every derived memory artifact; OpenClaw implements exactly that map.

The audit ledger records identity, ordering, action, and outcome codes. It never stores prompts, bodies, arguments, or filenames. Retention is a hard 30 days with row caps. Decision receipts rely on a closed vocabulary where enforced marks decisions from a gate that actually governed the action; a bare success is never upgraded into authorization proof. The docs publish their own non-claims, including "absence of a row proves nothing" and the pseudonymization being correlation rather than anonymization; for a lossless compliance archive, feed OpenTelemetry to your SIEM.

Failed inbound events land in an inspectable, resubmittable dead-letter queue instead of vanishing, and outbound messages carry staged terminal states. The invariant: every action ends in a visible outcome or a recorded, intentional non-outcome.

Independent verification exists at three levels: a community threat model mapped to MITRE ATLAS, TLA+ models of the riskiest authorization and isolation paths (models of the design, checked in bounded state spaces; they do not establish that "the TypeScript is verified", as the docs state), and a public maturity scorecard that grades our coverage.

The vendor's harness, as a plugin

Agent harnesses are becoming model-specific: labs train and evaluate their models inside their own loops. OpenClaw treats those harnesses as first-class runtimes rather than API endpoints (agent runtimes). The Codex plugin drives Codex's own app-server loop, including native thread resume, compaction, approvals, mid-turn steering, OpenClaw tools bridged into Codex turns, and computer use. The Copilot plugin runs the GitHub Copilot SDK's session loop, and the Anthropic plugin runs the Claude Agent SDK, while OpenClaw keeps ownership of channels, sessions, policy, and state. A model family runs in the loop it was built for, and the choice stays with the operator: every model also works through OpenClaw's own loop. Gateways that integrate these vendors at the API layer keep their own executor in charge; the vendor harness is at most an optional backend.

This embedding pattern comes from the vendors. OpenAI built the Codex app-server so partners could "embed the same harness in their own products" (Unlocking the Codex harness) and open-sourced the full harness in August 2026; Anthropic ships the Claude Agent SDK as the same harness that powers Claude Code. Third-party analysis states that models are post-trained against their harness, and pulling a model out of its harness costs performance you cannot get back.

Like other OpenClaw features, harnesses ship as plugins against a core that stays deliberately small. Channels, model providers, memory, voice, the Codex harness, all plugins behind documented capability registration points, with the boundary enforced by CI import guards, not convention. You can remove what you do not want (strip channels, disable memory, run a minimal surface, pin the allowed set with plugins.allow), and third parties can add what we did not build through the same SDK contracts, including whole message channels, which is how community plugins cover networks the core never touches. Every plugin's manifest is validated before any of its code runs.

The public plugin SDK publishes about 150 entrypoints with more than 4,300 exported symbols, held under shrink-only surface budgets so growth is a conscious decision; Hermes's plugin surface is a hook list, a platform-registration call, and seven consent capability IDs. ClawHub is OpenClaw's registry, with publishing, moderation, security audits, and per-release trust verdicts wired directly into the install gate, where Hermes distributes through skills-hub tap repositories and an in-repo MCP catalog approved by pull-request review. A marketplace at ClawHub's scale attracts malicious uploads; the audits, moderation, and install-gate verdicts address those uploads. Skills are also checked: every ClawHub skill is scanned before install (VirusTotal, ClawScan, static analysis, with the scan state shown on the skill page), and openclaw skills verify checks an installed skill against its trust envelope afterward, so tampering is detectable.

Open standards

OpenClaw adopts the protocols the ecosystem is converging on. It is an MCP client (Streamable HTTP, SSE, and stdio transports, with OAuth) and an MCP server, and plugins can ship their own MCP servers and apps. Other agents reach it through the Linux Foundation A2A 1.0 protocol, with Agent Card discovery, authenticated JSON-RPC tasks, and outbound peer messaging, and editors connect over the Agent Client Protocol, which OpenClaw also uses to host external harnesses. Agents render live A2UI widgets on session dashboards.

Skills are built against the AgentSkills spec, plugin installation performs automatic detection of Agent Plugins, Codex, Claude, and Cursor bundle layouts, and the Gateway can expose an OpenAI-compatible API (/v1/chat/completions with a documented function-tool subset, /v1/responses, /v1/models, /v1/embeddings; turned off by default, /v1/responses separately enabled) so OpenAI clients can point directly at the Gateway. Observability data goes out through OpenTelemetry and Prometheus; gateways make themselves known via Bonjour and DNS-SD; channels come with native Matrix, IRC, and Nostr protocol implementations; and distributions include npm provenance and verifiable artifact attestations.

Working together

Most agent-assisted work currently unfolds between a single person and a single terminal; everyone else sees only the finished commits. A shared OpenClaw gateway turns the work itself into something observable. Sessions carry an immutable creator, an assignable owner, and the people who actually prompted; the Control UI displays who is viewing and typing live (drafts stay ephemeral and never reach the model or the transcript), and the sidebar filters by owner or by "involving me" (multi-user). A conversation that starts in a channel can continue as a session the whole team can open, steer, and take over.

With verified GitHub identity, commits from a shared session carry Co-authored-by trailers for the authenticated people who steered them, ordered by actual contribution, and when the Gateway has a shareable session URL, generated pull requests end with a link back to the team session, so a reviewer with access reads the conversation that produced the diff, not just the diff (user model). Local coding sessions can be mirrored near-live to a team gateway with Beam, and cloud workers put execution on disposable machines while the transcript stays in one shared place. Portals proxy an agent's development server into the operator's browser through the Gateway, and Cloud Worker Desktop streams a live VNC view of the worker, an authenticated loopback-only RFB server, reached through a single-use broker ticket over the worker's own outbound connection, never public ingress, with view-only filtering and single-controller arbitration. Hermes has neither; its sandbox observation is terminal output. OpenClaw is developed this way, in shared sessions on the maintainers' own team gateway; the roles, attribution, and audit surfaces above exist because that workflow requires them.

Governance

The entire OpenClaw product is MIT-licensed, with no enterprise edition under a different license, and it is governed by the OpenClaw Foundation, an independent 501(c)(3) non-profit with sponsors rather than owners, including OpenAI, NVIDIA, Microsoft, Atlassian, GitHub, and Tencent among many others, and a full-time team. The Foundation's stated ambition is to be neutral ground across model providers, and the architecture reflects it: providers are plugins, and no lab's model is privileged. Releases are signed and published under the Foundation identity.

Hermes is built by Nous Research, a venture-funded company whose Series A was led by the crypto investor Paradigm at a token-based valuation, with a later round reported at a $1.5B valuation. This is a difference in governance and funding, not a judgment of the engineering. A neutral non-profit with published governance can serve as enterprise infrastructure.

Third parties invest in the architecture: NVIDIA's NemoClaw distribution hardens OpenClaw with OpenShell kernel-level sandboxing, infrastructure vendors publish production-hardening guides for it, and academic security case studies credit the decoupled architecture while cataloging threats.

OpenClaw publishes its security advisories on the repository, hundreds of them, batch-published alongside fixes, including OpenClaw's own worst stretch: the March 2026 CVE batch that third-party write-ups still cite exists in public because OpenClaw disclosed it, with a written trust model, an incident response plan, and security maintainers from NVIDIA and Tencent. Hermes's repository has published zero advisories as of this writing: its CVE record was filed through third-party CNAs, and the advisory IDs cited in its own issue tracker resolve nowhere public. OpenClaw's large advisory count records bugs it found and disclosed; Hermes's third-party CVE record has no corresponding public repository advisories.

What we do not claim

  • Sandboxing and exec approvals are off by default. Default OpenClaw is a trusted single-operator assistant. Hardening is deliberate configuration, and openclaw security audit will tell you when you have drifted from it.
  • One gateway is one trust domain. Roles and session ownership are collaboration guardrails. Tenancy means one gateway cell per tenant, and fleet is still experimental.
  • Native plugins run in-process and are not sandboxed. Mitigations are allow-lists, an install-policy hook, pinned versions, dependency locking, and CI-enforced SDK boundaries. This is true of every harness in this class today; we would rather say it than have you find it.
  • Egress allowlisting covers cooperating traffic only. The secret egress proxy gained an opt-in traffic allowlist for Gateway-hosted exec (August 2026) on top of its bypass-surviving sentinels, sandboxed execution defaults to kernel-enforced network: "none" or runs under the OpenShell backend's default-deny policy allowlists, but raw sockets from unsandboxed host exec answer to an operator-supplied proxy or host policy, not to OpenClaw. Allowlist proxies elsewhere have had published bypasses; the sentinel design assumes bypass instead of trying to prevent it.
  • Memory retention is a time-bound gap, not a control gap. Provenance is recorded per entry, an admission policy keeps designated sessions out of memory formation, and openclaw memory forget purges by session, hook source, or participant (August 2026). What still does not exist is a time-based retention bound for promoted memories. Turn taint covers network-sourced tool output; text arriving through non-network tools does not taint the turn.
  • gateway.roles shipped in August 2026. Check your installed version before depending on it.

OpenClaw and Hermes Agent

Hermes Agent (Nous Research, MIT) is the strongest harness in the single-envelope generation. Every claim below was verified against their source at commit f751a8c546 (2026-08-25); their tree moves fast, so treat the pins as a snapshot.

Source findings. Hermes's own SECURITY.md states the architecture plainly: "The only security boundary against an adversarial LLM is the operating system" (§2.2), and "Within the authorized set, all callers are equally trusted" (§2.6), so an allow-listed sender has the shell. Its Codex app-server runtime tracks OpenClaw's: "Mirrors openclaw" appears seven times in agent/transports/codex_app_server_session.py. An independent audit of the default configuration found 4 Critical and 9 High issues (their tracker, #7826), multiple CVE records state the vendor "was contacted early about this disclosure but did not respond in any way," and their tracker records hermes update corrupting checkouts (#32384) and a gateway leak reaching tens of GB before OOM kills (#25315). A deleted memory can be re-saved by the next per-turn review pass, the resurrection failure OpenClaw's tombstones prevent. Hermes also provides TOCTOU-safe 0600 credential writes, import-frozen redaction, env-scrubbing that fixed a real passthrough leak, and excellent transcript provenance in their SQLite store.

For model providers, OpenClaw has 54 bundled provider plugins to Hermes's roughly 31 distinct providers, with local models as dedicated plugins; on channels, 30 documented networks to roughly 27, with exclusives on both sides, OpenClaw alone covers Twitch, Zalo (three connection paths), Nextcloud Talk, Urbit, and generic Nostr (Hermes speaks Nostr only to Block's Buzz community relays).

Where Hermes pulls ahead. A side-by-side look at both codebases shows Hermes winning in one respect: a handful of first-party niche adapters. SimpleX, ntfy, and a conversational email channel (IMAP polling, threaded SMTP replies) ship in-tree with Hermes; its A2A adapter has an equivalent in OpenClaw's A2A v1.0 plugin. OpenClaw takes a different route for these integrations: SimpleX relies on a community plugin that's actively maintained (@dangoldbj/openclaw-simplex on npm), ntfy notifications flow through webhook delivery alongside ClawHub send skills (our tracker shows zero recorded demand for that channel), and email is treated as automation rather than a chat channel. The bundled IMAP trigger takes each authenticated inbound message from any provider and routes it into a separate, tool-restricted reader session (Gmail push does the same for Gmail), while sending happens through skills. Hermes's email channel gives an authorized sender the complete tool surface inside a single collapsed per-sender session; OpenClaw's isolation exists specifically to prevent that kind of access. Home Assistant comes with a first-party MCP connector and a ClawHub skill, though their adapter also streams state-change events inbound. Third-party channel plugins are supported by both projects; what differs is who maintains the niche adapters. For a single trusted operator on their own hardware, Hermes remains a solid option.

PropertyOpenClawHermes Agent (f751a8c546)
Trust boundaryTrusted gateway; execution movable to sandbox, node, or cloud worker; OpenShell-native backendSingle process; backends move terminal+file tools only; containment delegated to an OS wrapper
Policy gateDeterministic, fail-closed; denied tools structurally absent; LLM review as a layer behind deny floorsLLM judge (smart) by default over a 111-pattern deny-list; unmatched commands run unprompted; non-interactive paths fail open
Vendor harnessesCodex app-server, Copilot SDK, Claude Agent SDK as native runtimesCodex runtime opt-in, text-only, no thread resume or tool bridging; Copilot flattened to a chat-completions shim
Code executionTypeScript in an isolated QuickJS VM, per-call policy intactPython in a child process that RPCs into the trusted parent
Roles and multi-userPerson-level role ceilings, scopes, session attribution; per-tenant fleet cells (experimental)All authorized callers equally trusted; slash-command gating only; instance per person
SecretsSecretRef with per-owner fail-closed degradation; egress sentinelsPlaintext files into os.environ; vaults resolve into env; DB transcripts unredacted
EmailIMAP trigger routes inbound mail to isolated, tool-restricted reader sessions; send via skillsIMAP/SMTP chat channel; authorized sender reaches the full tool surface in one per-sender session
UpgradesFour channels, immutable versions, schema-guarded updates, sealed release validationgit pull origin main; no channels; tags are rollback anchors; Docker :latest tracks main
Memory provenancePer-entry origin provenance; structural taint gate; admission policy; provenance-linked purge with tombstonesNone in the built-in store; purge-by-source inexpressible; autonomous writes on by default
AuditMetadata-only ledger, closed vocabularies, 30-day bound, published non-claimsRich session attribution; artifacts scattered, no retention policy; trace export via opt-in Langfuse only
Worker observabilityTerminal for local and cloud sessions, portals proxying dev servers, brokered loopback-VNC desktopTerminal output only
PluginsIn-process, unsandboxed (stated); manifest validated without executing code; CI-enforced SDK boundaryIn-process, unsandboxed (stated); declaration-hash consent; install-time scan only
Security recordHundreds of self-published advisories, batch-disclosed with fixesDefault-config audit: 4 Critical, 9 High (#7826); CVEs filed by third-party CNAs; documented vendor non-response
GovernanceOpenClaw Foundation (non-profit), MIT, signed releases, published advisories, public maturity scorecardVenture-funded company (Nous Research; Paradigm-led Series A at a token valuation), MIT, candid security policy, no published repo advisories

The hardened setup

Each enterprise configuration item points to its own reference:

Then treat it as replaceable infrastructure: pin a channel, let doctor own migrations, restore backups by verification, and redeploy instead of repairing deployments in place.

Corrections to any claim on this page, about OpenClaw or about others, are welcome as issues or pull requests.

5,129 words · updated Aug 28, 2026