Hermes Agent vs OpenClaw: Which Runs Air-Gapped?

A defense contractor's compliance officer does not care whether an agent framework is clever. They care whether it can run inside a boundary with no route to the internet, whether every credential it touches is masked and auditable, and whether a prompt-injected tool call can be scoped down before it does damage. Hermes Agent v0.21.1 (Nous Research, tagged September 7, 2026) and OpenClaw 2.0 (v2026.8.1, released August 31, 2026) are the two leading open-source frameworks for always-on AI agents; our prior comparison covered their features broadly. This post answers the narrower, harder question: which one actually air-gaps?

The short answer: OpenClaw documents an offline path with explicit config keys; Hermes Agent's own maintainers list offline installation as unbuilt. Neither is disqualifying — both run local models and neither phones home with prompt content — but the operational lift differs. See our air-gapped AI solution page for the broader architecture either framework sits on top of.

What does each framework phone home for by default?

OpenClaw 2.0 sends a daily update check by default, carrying the OpenClaw version, OS, Node version, and CPU architecture — disable it with update.checkOnStart: false. Optional anonymous feature statistics are off by default and carry no identifier; per OpenClaw's own FAQ, no prompts, messages, model names, keys, paths, or machine identifiers are ever sent to the OpenClaw Foundation (docs.openclaw.ai/help/faq). Separately, OpenClaw makes startup calls to fetch model pricing data and discover available models unless models.pricing.enabled: false is set. For a fully offline posture, OpenClaw documents cloud_fallback: false and network.mode: "offline" so no prompts, responses, or telemetry leave the machine.

Hermes Agent does not collect telemetry, usage data, or analytics, and its documentation states API calls go only to the LLM provider you configure — no calls to Nous Research or other services during normal operation (hermes-agent.nousresearch.com). That is a cleaner starting position than OpenClaw's default telemetry. The gap is installation and the service mesh around a running agent: Hermes's own GitHub tracker carries an open issue, "Support offline/air-gapped installation and local LLM configuration" (NousResearch/hermes-agent#17696), stating that offline deployment is not currently supported out of the box. A genuinely offline Hermes build requires manually removing or pre-configuring every network-dependent service — web browsing, the in-app browser, MCP client connections, memory sync, speech, model fallback, update checks, and gateway channels — and pre-downloading the model and dependencies before isolating the host.

Both frameworks pull from package and skill registries that assume connectivity unless mirrored. OpenClaw's ClawHub is the versioned public registry for skills (agent instructions, lower risk) and plugins (Node modules running in the gateway process, higher risk); installing via openclaw skills install @owner/slug resolves against the registry over the network by design. Hermes Agent's skill ecosystem and MCP server connections carry the same assumption — an air-gapped build must pre-fetch and vendor anything it needs from either registry before the network goes away, the same sneakernet discipline our air-gapped LLM deployment guide lays out for the model layer.

Hermes Agent vs OpenClaw for a regulated, air-gapped deployment

Criterion	Hermes Agent v0.21.1	OpenClaw 2.0 (v2026.8.1)	What a regulated deployment needs
Telemetry by default	None documented; docs state no telemetry, usage data, or analytics collected	Daily update-check call (version, OS, Node version, CPU arch) on by default; disable with update.checkOnStart: false. Optional anonymous feature stats, off by default	Zero outbound calls, or every call explicit, documented, and independently disable-able
Documented offline/air-gap mode	Not documented; open GitHub feature request (#17696) for offline/air-gapped install	Documented: network.mode: "offline", cloud_fallback: false, models.pricing.enabled: false	A named config path, not a workaround assembled from forum threads
Install script	Piped shell script (curl | bash); assumes internet reachability during setup	Piped shell script (curl | bash); assumes internet reachability during setup	Installer and Node runtime mirrored inside the boundary — never pipe a remote script into a production shell either way
Local-model support	Per-bot pinned model; "your own endpoint" (vLLM, llama.cpp, SGLang, OpenAI-compatible) is a first-class provider alongside Nous Portal, OpenRouter, OpenAI	In-process GGUF inference, managed llama-server, improved Ollama/LM Studio integration; installer detects local models on first run	A supported, documented path to a fully local, OpenAI-compatible backend — both qualify
Secrets handling	OAuth credentials cached per server under the active Hermes profile; each MCP server takes its own scoped credentials	Optional 1Password broker: curated secret references, service-account auth, per-secret approval, SQLite audit history; secret value never enters model context or transcript; masked credential prompts elsewhere in onboarding	Secrets never touch prompts, transcripts, or plaintext config; every access is scoped, approved, and logged
Sandboxing	Not a first-class sandbox feature; isolation is whatever the host process provides	Docker/Podman sandbox backends (off by default), plus SSH and OpenShell backends; workspace-restricted filesystem; browser sandboxing requires Docker (unsupported under Podman)	Tool execution isolated from the host filesystem and network by default, not opt-in
MCP tool permission gating	Per-server config block with its own credentials and tool filter; allowlist/blocklist individual tools per server; least-privilege, read-only credentials recommended	Per-operation automation permissions, inspectable and revocable; plugin provenance display	Default-deny tool access, explicit allowlists, and a way to revoke a grant without redeploying
Self-modification controls	v0.21 requires write approval for edits to AGENTS.md, skills, and memory stores — staged writes reviewed via /skills approve / /skills reject	Per-operation permissions cover automation actions broadly; no specific "edit its own instructions" gate documented separately	An agent should never rewrite its own standing instructions without a human approval step — Hermes documents this explicitly for v0.21
Audit logging	Not a named, dedicated audit-log feature in the docs surfaced; MCP tool calls are filtered but logging depth is unconfirmed	Documented recommendation to enable complete operation logging so every agent action is traceable; 1Password broker keeps its own SQLite audit history	Append-only logs of every tool call, model call, and permission grant, shipped to a SIEM you control — confirm this independently for either framework before compliance sign-off
License	MIT	Open source under Foundation governance since July 2026 — verify the license file before procurement	Confirmed permissive terms in writing before a compliance review, not a press description

Air-gap checklist for either framework

Whichever framework you choose, these controls are non-negotiable before an auditor sees the build:

1. Mirror the installer and runtime. Never pipe curl | bash into a production host. Download the install script and Node.js runtime once on a connected staging system, verify checksums, and serve both from an internal mirror.
2. Force offline mode and verify it. For OpenClaw, set network.mode: "offline", cloud_fallback: false, update.checkOnStart: false, and models.pricing.enabled: false, then confirm with egress monitoring — a documented setting is not evidence, a flat traffic graph is. For Hermes, disable or remove web, browser, MCP-remote, memory-sync, speech, fallback, and update services one by one, and confirm the same way.
3. Mirror the skill/plugin registry. Pre-fetch every ClawHub skill or plugin, and every Hermes MCP server and skill package, the deployment will use. Treat the mirror as the only update path afterward, with checksum verification and a transfer log — the same sneakernet cadence as model weights, per our air-gapped LLM deployment guide.
4. Broker credentials, never paste them. Use OpenClaw's 1Password broker or Hermes's per-server scoped credentials; either way, no API key or service password belongs in a config file or a transcript.
5. Sandbox every tool call. Turn on OpenClaw's Docker/Podman sandbox and workspace-restricted filesystem for every automation. In Hermes, scope each bot's MCP tool filter to the minimum it needs, and prefer read-only credentials.
6. Require approval before self-modification. Hermes's v0.21 write-approval gate on AGENTS.md, skills, and memory is the right default; if you build the equivalent for OpenClaw's automation permissions, apply it to anything the agent can use to change its own behavior later.
7. Log everything, and ship it off-host. Append-only logs of tool calls, model calls, and permission grants, replicated into a SIEM inside the same boundary — never rely on a framework's own local store as the audit trail of record.
8. Pin the model behind an OpenAI-compatible local endpoint. Both frameworks support this; point either at a vLLM or SGLang server running GLM-5.3-Flash, Qwen3.8-Flash-Next, or another open-weight model entirely inside the enclave. Our frontier and routing practice designs the hybrid layer where a frontier model still exists for lower-sensitivity work outside the boundary.
9. Stage every upgrade. Back up ~/.openclaw or ~/.hermes state before any update. OpenClaw's move to SQLite storage in 2.0 is a one-way migration — a verified backup is not optional.

Which one fits your deployment?

Defense contractors under CMMC Level 2 or handling ITAR technical data should default to OpenClaw 2.0. Its offline config keys are named in the documentation, its 1Password broker produces the per-secret audit history an assessor wants to see, and Docker/Podman sandboxing maps cleanly onto NIST SP 800-171's boundary-protection controls. Our defense industry page and the OpenClaw sovereign agent workstations case study describe that pattern in a live CMMC-adjacent environment.

Law firms working under privilege and confidentiality obligations can run either framework, since neither collects telemetry once configured correctly, but the operational reality favors whichever framework the firm's IT team can harden without incident. A firm with in-house engineering comfortable building the offline services list from scratch gets MIT licensing and per-matter bot pinning from Hermes Agent; a firm that wants the documented path gets there faster with OpenClaw.

Hospitals and health systems handling PHI should weight the sandboxing and MCP tool-filter story heavily, since clinical integrations mean far more third-party tool calls than a typical enterprise deployment. OpenClaw's per-operation permission model, inspectable and revocable without a redeploy, is the more mature control surface where a badly scoped tool call has real patient-safety stakes.

Construction and engineering firms protecting bid data and proprietary designs are usually the least latency-sensitive of the four and can afford to build the Hermes offline configuration properly, if per-project bot profiles and MIT terms matter more than a documented offline flag. Either framework pinned to a local vLLM endpoint keeps CAD notes, tolerances, and bid math inside the firm's own walls; see our hybrid-routing case study for what that looks like with Hermes Agent's bot roster.

In every case, a framework's marketing claim of "air-gapped" is a starting hypothesis, not a finding. Verify it at the network boundary — egress monitoring proving the gap is real, not a vendor FAQ page or a config key set once and never checked again.

Our private AI hosting and maintenance practice runs the model layer, the agent framework, and the upgrade cadence on hardware inside your boundary, so the offline configuration stays correct release after release instead of drifting the first time someone reaches for the default install script.