OpenClaw Security for Enterprises: Risks, CVEs and Controls

OpenClaw security is the work of keeping a self-hosted OpenClaw gateway, an agent that can run shell commands, read files and message people on your behalf, inside the boundary its operator intends. The project supports one trusted operator per gateway, so enterprise risk concentrates in network exposure, shared use, third-party skills and slow patching.

OpenClaw started life as Clawdbot, was later called Moltbot, and in under a year became one of the most-starred repositories on GitHub. That reach means it turns up on employee laptops and home servers whether or not IT signed off. Every fact below was checked on 27 September 2026 against the OpenClaw repository, the security documentation and the GitHub Advisory Database. If the category is new to you, start with what an agent harness is.

What the OpenClaw security model assumes

The Gateway is the centre of an OpenClaw install: a long-running process that owns sessions, tools, events and channel connections on one port (18789 by default). Channels link it to WhatsApp, Telegram, Slack, Discord, iMessage, Microsoft Teams and more than twenty other services, and plugins run as code inside the Gateway process.

The project’s trust model page is unusually direct about scope. Five points matter most for a security review:

• One trust boundary per gateway. A gateway serves a single operator or a mutually trusting team. It is explicitly not a boundary between adversarial users, and hosting mixed-trust users means running separate gateways.
• Shared authority. Everyone who can message a tool-enabled agent shares that agent’s delegated tool authority. Session keys route conversations; they do not authorize anyone.
• Host execution without prompts. For the trusted single-operator case, host exec is allowed without approval prompts (security="full", ask="off"). The docs call this intentional UX.
• Wide defaults inside the gateway. Session tools can see every agent’s sessions (tools.sessions.visibility defaults to all), agent-to-agent messaging is on, and agents with message access can post across channel providers.
• Sandboxing is opt-in. Tool sandboxing is off by default, and the Gateway process itself always stays on the host.

Recent releases add team features on top of that model. Named operator roles bind authenticated profiles to scopes and can require sandboxed sessions, though the trust model page calls them collaboration guardrails rather than tenant isolation. Exec approvals can put a person in front of shell commands, and when no approver is reachable the askFallback setting defaults to deny. A metadata-only audit ledger records which agent ran and which tool actions it executed, without prompts or arguments, and queries cover 30 days with a cap of 100,000 records.

The docs order their advice as identity first, scope next, model last. For one person automating their own accounts, the defaults are reasonable. They become enterprise risks when a gateway is reachable from a network, shared across people with different entitlements, or connected to company systems.

What the public record shows

Advisories and CVEs

As of 27 September 2026 the repository lists 722 published security advisories, the first from late January 2026: 14 rated critical, 249 high, 390 medium and 69 low. By our count of advisory titles, roughly four in ten concern authorization inside a gateway, such as owner-only checks, sender allowlists, operator scopes and approval binding. File and path handling, SSRF guards and injection flaws form the next largest groups. The volume partly reflects a practice of publishing an advisory per fix and the scrutiny a project this size attracts; the lesson is that an install is only as safe as its last upgrade.

The critical-rated entries cluster around device pairing and operator scopes, where a lower-privilege token could be escalated to operator.admin and reach remote execution on a paired node. GHSA-4jpw-hj22-2xmc (CVSS 9.9) is a representative example.

Gateways reachable from the internet

Censys counted 21,639 exposed instances by 31 January 2026, found through the Control UI page title, and noted that most still required a token to use. Treat any single count as a snapshot. The durable point is that gateways do get published to the internet, and CVE-2026-25253 showed that a loopback bind is one layer of defence rather than a complete one.

ClawHub and the skill supply chain

ClawHub is OpenClaw’s public skill registry, and operators install from it explicitly with openclaw skills install. In February 2026 Koi Security audited all 2,857 skills then listed and found 341 malicious ones, as reported by The Hacker News. Of those, 335 belonged to one campaign, named ClawHavoc, which dressed up popular-sounding tools with fake “Prerequisites” sections that walked users into installing the Atomic Stealer (AMOS) infostealer on macOS and a keylogging trojan on Windows. ClawHub responded with user reporting and automatic hiding of heavily reported skills.

Scanning improved after that, and attackers adapted. Unit 42’s June 2026 analysis says ClawHub partnered with VirusTotal for proactive screening, yet between February and May 2026 its researchers still found five malicious skills that were not blocked. One received a Pass verdict from ClawHub’s automated audit; another placed its payload ahead of 22 MB of padding to exceed the file-size limits of content scanners.

The skills documentation now gives operators several levers:

• ClawHub pages show VirusTotal, ClawScan and static-analysis status before install, and openclaw skills verify @owner/<slug> checks a skill’s trust envelope.
• security.installPolicy runs an operator-owned command that returns allow, warn or block before any skill or plugin install completes, and it fails closed.
• Secrets configured for a skill are injected into the host process for that turn, not into the sandbox, so a skill with secrets deserves the same review as a plugin.
• Self-learning through Skill Workshop defaults to auto; setting it to propose stages agent-written skills for review before they change behaviour.

The docs sum it up: treat third-party skills as untrusted code. For how skill ecosystems differ, see our Hermes Agent and OpenClaw comparison.

A hardening baseline from the official docs

The project publishes a hardened baseline that keeps the gateway local, paired and tool-restricted. Its core looks like this (JSON5, from the docs):

{
  gateway: { mode: "local", bind: "loopback", auth: { mode: "token", token: "long-random-token" } },
  session: { dmScope: "per-channel-peer" },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
    sessions: { visibility: "agent" },
    agentToAgent: { enabled: false },
  },
  channels: { whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } } },
}

Around that config, a workable enterprise checklist drawn from the same docs:

1. Stay on loopback. For remote access, prefer Tailscale Serve or a reverse proxy with trusted-proxy auth. Never expose an unauthenticated gateway on 0.0.0.0, and with Docker, filter published ports in the DOCKER-USER chain.
2. Patch on a schedule. Pin container images to version tags from ghcr.io/openclaw/openclaw and track the advisory feed.
3. Gate who can talk. Use dmPolicy: "pairing" or an allowlist, keep group access allowlisted with mention gating, and give the bot its own phone number on number-based channels.
4. Sandbox tool execution. Set agents.defaults.sandbox.mode to non-main or all, keep scope at agent or session, and start workspaceAccess at none.
5. Keep approvals fail-closed. Where an agent keeps exec, use approval mode and leave askFallback at its default of deny, so a request with no reachable approver is blocked.
6. Close cross-context paths. Set tools.message.crossContext.allowAcrossProviders to false where messages must not jump channels.
7. Allowlist plugins and review skills. Use plugins.allow, pinned versions and an install policy.
8. Audit after every change. Run openclaw security audit --deep; --fix applies narrow remediations and --json suits CI.
9. Lock down files and discovery. Keep state and credential files at 600/700, and set mDNS discovery to minimal or off.

For a model on your own hardware, the local model setup guide covers providers and Docker isolation.

What NemoClaw and OpenShell add, and what they leave open

NVIDIA announced NemoClaw on 16 March 2026 as a one-command stack that installs Nemotron models and the OpenShell runtime, aimed at RTX PCs, workstations, DGX Station and DGX Spark. The Apache 2.0 repository now also supports Hermes and LangChain Deep Agents Code.

What it adds, per the OpenShell README:

• Kernel-level enforcement on each agent’s file access, system calls and network connections, with every outbound connection checked against policy.
• Credential injection only for approved endpoints, so the agent never holds the real secret.
• Formal verification of policy changes that flags newly granted access for human review.
• A default NemoClaw policy written as “deny by default, allow only what’s needed”, plus a privacy router for reaching cloud models.

What it leaves open:

• Maturity. The NemoClaw README calls it an alpha project with best-effort maintainer response. Its default policy file sets Landlock filesystem enforcement to best_effort.
• Integration bugs. The sandbox bridge is code too: several of the OpenClaw advisories above, including CVE-2026-44112 and CVE-2026-44113, concern the OpenShell filesystem bridge.
• The trust model. Anyone who can message the agent still shares its delegated authority inside the sandbox. OpenShell narrows the blast radius; it does not split one gateway into separate trust domains.
• Identity, roles and audit. NemoClaw adds no layer of its own here. Operator roles, exec approvals and the 30-day metadata ledger come from the OpenClaw gateway, and each owner still applies security fixes to each install.
• Telemetry. OpenShell collects anonymous operational telemetry unless you set OPENSHELL_TELEMETRY_ENABLED=false.

Personal harness or governed platform: a decision guide

OpenClaw’s multi-tenant hosting guide answers the shared-use question itself: one isolated gateway cell per tenant, managed by an experimental openclaw fleet command, with outbound egress unrestricted by default. That is a hosting pattern: each cell keeps its own roles, approvals and ledger, and any organization-wide view across cells is yours to build.

The dividing line is whether five controls must hold across many users and agents at once: identity tied to your directory, role-scoped access to tools and data, approvals for consequential actions, an audit trail kept as long as your regulators expect, and enforced egress control. Our agent governance and security handbook sets out how to evaluate each one, and egress-controlled AI goes deeper on the network side.

How VDF AI fits

VDF AI is a governed enterprise agent platform that deploys on-premises, in a private cloud, air-gapped, or in VDF’s managed cloud. It is an alternative for the workloads in the lower rows of that table; it does not run, host, wrap or manage OpenClaw.

Tool access runs through the MCP gateway, where grants attach to roles in an admin-governed registry and each tool call is logged against the calling agent. In VDF AI Networks, a Human Approval node holds a workflow until the accountable owner accepts the recommendation, and workspace admins set the allowed model list and the external services a network may use. The AI gateway’s air-gap mode disables external APIs and keeps routing on local models. SSO is included on the Enterprise Cloud plan, and on-premise deployments sign in with Microsoft Entra ID. The AI governance platform overview explains how those records become evidence for reviewers.

For a side-by-side view of scope and trade-offs, see VDF AI compared with OpenClaw.