Teams deciding between Meta Muse Secure VM and a self-hosted OpenClaw or Hermes agent are choosing who holds the security boundary. Muse is a managed personal-agent boundary. OpenClaw and Hermes Agent are runtimes you install and operate.
Meta's September 8, 2026 research post describes Muse as a dedicated cloud Linux VM per user, with the agent inside a restricted cell and permission decisions outside that cell. OpenClaw and Hermes leave the host, the model provider, the tools, and the trust boundary with you. The self-hosted side of this compare reuses only the operating picture in OpenClaw vs Hermes Agent, the OpenClaw business setup guide, and the Hermes Agent business setup guide. Those guides cite the OpenClaw docs and the Hermes docs as of mid-September 2026. Recheck both docs before you deploy. The projects move quickly.
Short answer
Choose Muse Secure VM when you want Meta's per-user cloud VM, with Sentinel as the permission authority for built-in connector actions and all network egress, and you can live with the launch access model: Meta may still access the VM as necessary under its operational policy.
Choose OpenClaw or Hermes when the agent has to run on infrastructure you administer, you want messaging channels, tool policy, and schedules in config you can read, and your team will own patching, credentials, and the trust split. Start from the self-hosted AI agent deployment checklist and trust boundaries for self-hosted agents. The short OpenClaw versus Hermes split is below.
Launch-state Muse and the planned Confidential VM are different designs. Launch still allows Meta access as necessary under operational policy. A Confidential VM that would cryptographically and verifiably prevent provider access is planned for later in 2026. That design is not what launch provides.
Execution model
Muse gives each user a dedicated cloud Linux VM. The runtime is a systemd-nspawn cell mapped to an unprivileged host user. Outside the cell sit hatch-safety, privsep connector workers, hatch-authd, Sentinel, and application state. Connector actions and network egress are decided beside the cell, not by the cell acting as its own authority.
OpenClaw is a Gateway you run. It connects model providers, sessions, tools, messaging channels, the Control UI, and optional device nodes. Team use is configuration of that same Gateway, documented under teams, not a separate edition. Sandboxing is off by default. When you turn it on, the Gateway stays on the host and tool execution can move to Docker, Podman, SSH, OpenShell, or Crabbox. `tools.elevated` can run exec outside the sandbox, so treat it as an escape hatch.
Hermes Agent is a process you run from a CLI, a messaging Gateway, an API server, or a supported editor integration. Tools are grouped into toolsets. Profiles separate configuration and state for different roles. Terminal execution can use `local`, `docker`, `ssh`, `daytona`, `singularity`, `modal`, or `vercel_sandbox`. The local backend runs as the host user. Production Gateways should use a container backend and should not run as root. An in-process tool or plugin can still sit outside a terminal-only sandbox.
Permission authority
Sentinel is the sole permission authority for built-in connector actions and for all network egress. It evaluates connector, method, action class, scope, and context, then allows, denies, or asks. For egress it evaluates hostname, final IP, port, protocol, HTTP method, path, and the decoded request. A built-in connector call or a network send has to pass that check outside the cell.
OpenClaw and Hermes record permission in the deployment you operate. OpenClaw uses channel pairing and allowlists, session scope, restrictive tool policy, optional sandboxing, and `openclaw security audit` after configuration changes. Hermes uses selectable toolsets, user allowlists and pairing, dangerous-command approvals, and a hardline blocklist that stays on as a floor. A narrow MCP server can shrink what either runtime is able to call. That policy still lives in your Gateway or process and on your host.
Credential handling
Muse stores credentials in authd (hatch-authd, outside the cell). The runtime sees surrogate tokens. After approval, Sentinel swaps in the real credentials at the network boundary. Built-in connector workers carry explicit credential allowlists. The cell is not the place the long-lived secret lives.
OpenClaw leaves custody with you. Separate credentials by integration, give each the narrowest vendor scope that can do the job, and keep secrets out of prompts, logs, chat output, screenshots, and backups.
Hermes puts secrets in `~/.hermes/.env` and non-secrets in `config.yaml`. Optional `hermes egress setup` can inject credentials through a proxy so a Docker sandbox never sees the raw API keys. MCP environment filtering strips secrets from subprocesses except for variables you explicitly require. File-write guards and `HERMES_WRITE_SAFE_ROOT` are defense in depth: a host terminal running as the same OS user can still reach paths those guards block.
Browser boundary
Muse brokers browser CDP outside the runtime. The browser subagent sees accessibility snapshots. It cannot run page JavaScript or DevTools. The browser pauses during user takeover or a secure credential fill.
OpenClaw and Hermes expose the browser as a tool you can leave off. The OpenClaw setup guide says to deny shell, browser, and filesystem tools where the pilot does not need them. Hermes can run browser automation, and web, browser, image, and voice tools can go through the optional Nous Tool Gateway or through providers you configure directly. A CDP broker outside the runtime, limited to accessibility snapshots, is a Muse mechanism. Installing OpenClaw or Hermes does not add it.
Trust boundary and data
Muse launch puts each user on a cloud Linux VM Meta operates. Launch still allows Meta access as necessary under operational policy. The Confidential VM section below is the one that covers a later design meant to prevent that access.
OpenClaw's security model, as covered in the setup and comparison posts, uses one trust boundary per Gateway. A single operator, or teammates who already share credentials and delegated authority, can share a Gateway when you configure it that way. Mutually untrusted customers or departments need separate Gateways and, where isolation matters, separate OS users or hosts. Hermes uses the same personal-agent shape: one process is one trust boundary. Separate business units or clients should at least use separate profiles and, where isolation matters, separate processes, credentials, OS users, or hosts. Container backends and a non-root Gateway reduce blast radius. They do not turn one shared process into hostile multi-tenant isolation.
On either self-hosted system, write down the data path before launch. Channel providers process the messages they deliver. Hosted models receive prompts and selected context. Search, browser, speech, image, and MCP providers receive task data when you enable them. A local model and local-only tools shorten that path only when you configure them that way. Trust boundaries for self-hosted AI agents is the guide for when one Gateway or process is enough and when to split.
Approvals
Muse asks a human through the Muse client, outside the conversation. A grant can be one-time, session-scoped, task-scoped, time-bounded, or perpetual. Purchases always require a human, and the approval shows the exact details. When a wallet flow is used, payment credentials are single-use.
OpenClaw, in the business setup guide, expects you to decide which actions require a human. Pairing and allowlists decide who can invoke the agent. Tool policy decides what that person can cause. The OpenClaw versus Hermes comparison notes that a human step which works in interactive chat may not behave the same way on a headless schedule. Test that before you automate it.
Hermes configures dangerous-command approvals with `approvals.mode` set to `smart`, `manual`, or `off`. Operators can add `approvals.deny` globs. `cron_mode`, `single_query_mode`, and `unattended_mode` default to deny when nobody is there to answer. A hardline blocklist remains an always-on floor under a looser mode. For a business deployment, leave the unattended and cron paths on deny.
For tools you build, bind approval to an exact payload, amount, and expiry. See permissions and human approval and typed action budgets. Those patterns apply to systems you run. They do not describe Muse grants.
Scheduling and background work
Meta's September 8, 2026 research post does not describe a Muse scheduler, cron system, or background job runner. This compare does not assign Muse one. If unattended recurring work is a requirement, confirm it in current Muse documentation before you plan on the VM firing jobs on a clock.
OpenClaw schedules with `openclaw automations` (`openclaw cron` is an alias). Jobs run in the Gateway scheduler and persist their definitions. The setup guide says to start scheduled runs in draft or report-only mode, set the timezone explicitly, and review run history.
Hermes cron starts each job in a fresh agent session, so the prompt has to stand on its own or attach the skills it needs. The scheduler can preflight-validate config before it spends tokens. `no_agent` jobs run a script with no model call when the work is deterministic. `hermes cron doctor` checks fleet health. Keep dangerous unattended handling on deny unless the job sits in a tight, isolated boundary.
Where OpenClaw and Hermes differ
Next to Muse, both are self-hosted: you own the host and the trust boundary, and Sentinel is not in the path. They are different operating models. The full comparison is OpenClaw vs Hermes Agent.
Choose OpenClaw for a Gateway-centered assistant across chats, sessions, tools, and optional device nodes, for one operator or a configured team inside one trust boundary. Choose Hermes for a CLI- and profile-oriented runtime, explicit toolsets, several terminal backends, skills, and MCP, with chat as one interface among several.
Keep either runtime off the sole path for a deterministic transaction or for isolation between mutually hostile users. Workflow automation fits when the steps are fixed. The agent can draft, classify, or take actions a human still approves.
Launch state versus the planned Confidential VM
Launch, the design in the September 8, 2026 research post:
- a dedicated cloud Linux VM per user
- the runtime in a systemd-nspawn cell mapped to an unprivileged host user
- hatch-safety, privsep connector workers, hatch-authd, Sentinel, and application state outside the cell
- Meta access still allowed as necessary under operational policy
Planned, and not the launch state:
- Confidential VM later in 2026
- a design meant to cryptographically and verifiably prevent provider access
"The provider cannot access this machine" describes that later Confidential VM plan. Launch still includes Meta access as necessary under operational policy. OpenClaw or Hermes puts the machine on a host you administer, and model and tool providers still receive the data you send them.
Decision checklist
| Question | Muse Secure VM fits better when | OpenClaw or Hermes fits better when |
|---|---|---|
| Who administers the host? | A Meta-operated cloud VM per user is acceptable | Your team must patch, back up, and recover the host |
| Where does allow or deny live? | Sentinel, outside the cell, for built-in connector actions and all network egress | Gateway or agent config you can read, change, and audit |
| Where do long-lived secrets live? | authd; the runtime sees surrogate tokens; Sentinel swaps real credentials at the network boundary after approval | On your host, scoped per integration. Hermes can proxy them so a Docker sandbox does not see raw API keys |
| What browser limit do you need? | CDP brokered outside the runtime, accessibility snapshots, no page JavaScript or DevTools, pause on user takeover or secure credential fill | A browser tool you can leave off, or a provider path you document (including optional Nous Tool Gateway on Hermes) |
| Can the VM operator read the machine? | Launch: yes, as necessary under Meta's operational policy. Confidential VM is a later 2026 plan, not launch | You run the host. Providers still see what you send them |
| Do you need scheduled jobs now? | Not described in the September 8, 2026 research post. Confirm in current Muse docs before you depend on it | `openclaw automations`, or Hermes cron with fresh sessions, preflight, and `no_agent` script jobs |
| Who may share the agent? | The documented unit is a VM per user | One trusted operator group per Gateway or process. Split hosts when trust is mixed |
| How are purchases approved? | Always a human, with the exact details. Single-use payment credentials when the wallet flow is used | Your own gate, with the payload, amount, and expiry enforced outside the model |
When the boundary questions point at Muse and the operating questions point at OpenClaw or Hermes, split the system. Keep fixed side effects in ordinary integrations. Use the agent for judgment, with a human or a hard policy on anything that spends money, sends a message, or changes a record.
How this fits implementation work
OrchestriAI does not operate Muse, OpenClaw, or Hermes. AI agent systems define the job, the tool list, and the human gate. MCP development gives a self-hosted agent a narrow tool instead of a broad API token. Systems integration keeps credentials, queues, and side effects on the identity that matches the boundary you chose.
Independence and limitations
OrchestriAI is an independent implementation provider. Names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Meta, OpenClaw, or Nous Research / Hermes. This is an architectural comparison drawn from Meta's September 8, 2026 research post and from our existing OpenClaw and Hermes guides. It is not a security certification, a compliance conclusion, or a guarantee that current builds still match these pages. Confirm Muse in Meta's research post, and confirm OpenClaw and Hermes in the OpenClaw docs and Hermes docs, before you adopt any of them.
