Skip to content

OpenClaw Architecture

OpenClaw follows a hub-and-spoke architecture centered on a Gateway control plane that mediates between user-facing messaging channels and an AI agent runtime.

High-Level Architecture

graph TB
    subgraph Channels["Messaging Channels"]
        WA[WhatsApp]
        TG[Telegram]
        SL[Slack]
        DC[Discord]
        IM[iMessage]
        WEB[WebChat]
        MORE[24+ more...]
    end

    subgraph Core["OpenClaw Core"]
        GW["Gateway<br>(WebSocket Control Plane)<br>ws://127.0.0.1:18789"]
        PI["Pi Runtime<br>(Minimal Agent Core)"]
        LB["Lobster<br>(Workflow Engine)"]
        MEM["Memory System<br>(MEMORY.md + Daily Notes)"]
        SK["Skills Engine<br>(53 bundled + ClawHub)"]
    end

    subgraph Tools["Agent Capabilities"]
        BASH[Bash/Shell]
        FS[File System]
        BROWSER[Browser Automation]
        CRON[Cron/Scheduling]
        MCP_T[MCP Servers]
        CANVAS[Canvas Rendering]
    end

    subgraph LLMs["LLM Providers"]
        CLAUDE[Claude]
        GPT[GPT]
        DEEP[DeepSeek]
        GEM[Gemini]
        NEM[Nemotron/Local]
    end

    Channels --> GW
    GW <-->|RPC| PI
    PI --> Tools
    PI <--> LLMs
    GW --> LB
    GW --> MEM
    GW --> SK

Gateway — The Control Plane

The Gateway is a WebSocket server that handles:

  • Session management — conversation state, branching, and history
  • Presence — online/offline status across channels
  • Configuration — bot settings, channel bindings, model selection
  • Cron jobs — scheduled task execution
  • Webhooks — external trigger integration
  • Channel routing — dispatching messages to/from 24+ platforms

The Gateway runs locally, bound to ws://127.0.0.1:18789 by default. All messaging platform connectors route through this single control plane.

One Agent, Many Channels

The key architectural insight is that OpenClaw separates the interface layer (where messages arrive) from the assistant runtime (where intelligence lives). One persistent agent is accessible through every messaging app, with state managed centrally on your hardware.

Pi Runtime — The Agent Core

Underneath the Gateway, Pi, a minimal coding agent runtime, does the actual agent work.

Design Philosophy

Pi is deliberately minimal:

  • Shortest system prompt of any major coding agent
  • Ships with only four core tools: Read, Write, Edit, Bash
  • Communicates with the Gateway over RPC with tool streaming and block streaming
  • The philosophy: if you want the agent to do something new, you do not download a plugin — you ask the agent to write code that extends itself

Execution Model

sequenceDiagram
    participant U as User (Channel)
    participant GW as Gateway
    participant Pi as Pi Runtime
    participant LLM as LLM Provider
    participant T as Tools

    U->>GW: Message via WhatsApp/Telegram/etc
    GW->>Pi: RPC dispatch (session context)
    Pi->>Pi: Assemble context (history + memory)
    Pi->>LLM: Inference request
    LLM-->>Pi: Response + tool calls
    Pi->>T: Execute tool calls
    T-->>Pi: Tool results
    Pi->>LLM: Continue with results
    LLM-->>Pi: Final response
    Pi-->>GW: Response + state update
    GW-->>U: Reply via channel

Session Architecture — Trees, Not Logs

One of OpenClaw's most distinctive architectural features: sessions are trees, not flat logs.

You can branch and navigate within a session, which enables workflows impossible in most agent frameworks:

  • Branch for debugging — instead of polluting the main context, the agent branches off to diagnose a broken tool
  • Rewind after fix — once the issue is resolved, the agent rewinds to the main branch and summarizes what happened
  • Clean main context — the main session stays focused while side-quests happen in branches

This is critical for failure recovery — the agent literally recovers in-band.

Lobster — The Workflow Engine

Lobster is a typed, local-first "macro engine" that turns skills and tools into composable pipelines.

Why Lobster Exists

Complex workflows require many back-and-forth tool calls, each costing tokens. Lobster moves orchestration into a typed runtime: one call instead of many.

LLMs do what LLMs are good at: writing code, analyzing code, running tests. Lobster does what code is good at: sequencing, counting, routing, retrying.

Key Properties

Property Detail
Determinism Pipelines are data — easy to log, diff, replay, review
Resumable state Halted workflows return a resumeToken. Approve and continue without re-running
Safety Timeouts, output caps, sandbox checks, allowlists enforced by runtime
Execution Runs inside the Gateway process — no external subprocess spawned
Grammar Intentionally tiny — a predictable, AI-friendly pipeline spec

Multi-Agent Pipeline Example

graph LR
    subgraph Lobster["Lobster Pipeline"]
        CODE[Programmer Agent] --> REVIEW[Reviewer Agent]
        REVIEW -->|Pass| TEST[Tester Agent]
        REVIEW -->|Fail<br>max 3 iterations| CODE
        TEST -->|Pass| DONE[Done]
        TEST -->|Fail| CODE
    end

A real-world dev pipeline: code → review (max 3 iterations) → test → done, with no human in the loop unless something breaks.

Resilience & State

OpenClaw uses a write-ahead queue for task interruption handling:

  • If an agent fails mid-execution, it resumes from the last saved checkpoint
  • State is preserved for long-running autonomous tasks
  • An email triage workflow that crashes halfway does not restart from scratch

Multi-Agent Patterns

OpenClaw supports three distinct multi-agent patterns:

1. Sub-Agents

Background workers spawned from the main agent. They run in parallel, finish their task, and report back.

Best for: long-running research, batch processing, code review.

2. Multi-Agent Routing

Separate, independent agents on one Gateway, each bound to different channels or users.

Best for: home/work separation, security isolation, different personas.

3. Agent Teams

Community-built orchestration systems (SWAT, OpenMOSS, Mission Control, ClawTeam) that add structured coordination on top of OpenClaw.

Best for: complex pipelines with review loops, 24/7 operations.

NemoClaw Integration (NVIDIA)

graph TB
    subgraph NemoClaw["NemoClaw Stack"]
        OC[OpenClaw Agent]
        OS["OpenShell Runtime<br>(K3s in Docker)"]
        PR["Privacy Router"]
        PE["Policy Engine<br>(YAML declarative)"]
    end

    subgraph Inference["Inference Routing"]
        LOCAL["Local Nemotron<br>(120B on DGX Spark)"]
        CLOUD["Cloud Provider<br>(Claude/GPT)"]
    end

    OC -->|Sandboxed| OS
    OS --> PR
    PR -->|Sensitive| LOCAL
    PR -->|Non-sensitive| CLOUD
    PE -->|Enforces| OS

NemoClaw adds:

  • Out-of-process policy enforcement — policies enforced outside the agent, so even a compromised agent cannot bypass them (similar to browser tab isolation)
  • Privacy Router — routes inference to local or cloud based on configured policy
  • Credential injection — credentials never touch the sandbox filesystem
  • Isolated sandboxes — each agent runs in its own sandbox with declarative YAML policy controlling filesystem, network, process, and inference routing
  • K3s under the hood — all components run as a K3s Kubernetes cluster inside a single Docker container

When to Use NemoClaw

  • Personal, non-confidential → plain OpenClaw is sufficient
  • Confidential data or business use → NemoClaw recommended
  • Corporate adoption → NemoClaw virtually essential
  • Best practice → two instances: one everyday, one confidential via NemoClaw

Sources

Security

OpenClaw's security posture is the single most important consideration for anyone evaluating the platform. A rapid succession of critical CVEs, six-figure counts of exposed instances, and a compromised skill marketplace define a threat landscape that demands defense-in-depth before any production use.

Summary Verdict

OpenClaw accumulated at least 10 public CVEs in its first five months of existence, including a CVSS 9.9 remote code execution chain. By contrast, comparable projects like Hermes Agent reported zero CVEs over the same period. Treat OpenClaw as high-risk infrastructure requiring active hardening.

CVE Timeline

The following table documents OpenClaw's known CVE history. The project was first released in November 2025 (as Clawdbot) and renamed to OpenClaw on January 30, 2026.

CVE Date CVSS Category Description
CVE-2026-25253 January 2026 TBD — not publicly scored at time of writing RCE Remote code execution via crafted WebSocket message to Gateway. Allowed unauthenticated attackers to execute arbitrary shell commands through Pi Runtime.
CVE-2026-3xxxx (batch 1) March 4, 2026 9.9 RCE Chain Multi-step RCE through skill deserialization combined with Pi's Bash tool. The highest-severity vulnerability disclosed against OpenClaw.
CVE-2026-3xxxx (batch 2) March 4, 2026 TBD Auth Bypass Gateway authentication bypass allowing session hijacking across channels.
CVE-2026-3xxxx (batch 3) March 5, 2026 TBD SSRF Server-side request forgery via browser automation tool. This enables internal network scanning from exposed instances.
CVE-2026-3xxxx (batch 4) March 5, 2026 TBD Path Traversal Arbitrary file read through Pi's Read tool when skill input is unsanitized.
CVE-2026-3xxxx (batch 5–9) March 6–7, 2026 TBD Various Five additional CVEs covering prompt injection escalation, memory file poisoning, Lobster pipeline escape, channel token leakage, and ClawHub skill signature bypass.

CVE ID Precision

The exact CVE identifiers for the March 2026 batch are documented as "9 CVEs in 4 days" in security research. The specific CVE-2026-3xxxx numbers in the CVE Timeline table are placeholders — refer to the NVD database for authoritative IDs as they are published. The CVSS 9.9 score for the highest-severity issue is confirmed in multiple independent reports.

Threat Model

OpenClaw's attack surface is unusually broad for a self-hosted tool because it combines a network-accessible control plane, arbitrary code execution, a third-party skill marketplace, and LLM-mediated input processing.

graph TB
    subgraph External["External Attack Surface"]
        INET["Public Internet<br>135,000+ exposed instances"]
        CHAN["Channel APIs<br>(WhatsApp, Telegram, etc.)"]
        HUB["ClawHub Marketplace<br>341–900 malicious skills"]
        PROMPT["Prompt Injection<br>via user messages"]
    end

    subgraph Gateway["Gateway (ws://127.0.0.1:18789)"]
        AUTH["Authentication"]
        SESS["Session Manager"]
        ROUTE["Channel Router"]
        CRON["Cron Scheduler"]
        WEBHOOK["Webhook Handler"]
    end

    subgraph Runtime["Pi Runtime"]
        BASH["Bash Tool<br>(arbitrary shell)"]
        FS["Read/Write/Edit<br>(filesystem access)"]
        BROWSER["Browser Automation"]
        MCP["MCP Servers"]
    end

    subgraph Data["Sensitive Data"]
        MEM["MEMORY.md<br>(long-term memory)"]
        DAILY["Daily Notes"]
        KEYS["API Keys & Tokens"]
        FILES["User Files"]
    end

    INET -->|Unfiltered access| Gateway
    CHAN -->|Message injection| ROUTE
    HUB -->|Supply chain| Runtime
    PROMPT -->|Via any channel| SESS

    AUTH -->|Bypass: CVE batch| SESS
    SESS --> Runtime
    CRON -->|Scheduled execution| Runtime
    WEBHOOK -->|External triggers| Runtime

    BASH -->|Code execution| Data
    FS -->|File access| Data
    BROWSER -->|SSRF vector| INET
    MCP -->|Tool expansion| Data

    style INET fill:#d32f2f,color:#fff
    style HUB fill:#d32f2f,color:#fff
    style PROMPT fill:#e65100,color:#fff
    style BASH fill:#d32f2f,color:#fff

Threat 1 — Gateway Exposure (135,000+ Instances)

As of early 2026, security researchers identified over 135,000 OpenClaw Gateway instances directly reachable from the public internet, spread across 82 countries. The Gateway binds to ws://127.0.0.1:18789 by default, but many users either:

  • Change the bind address to 0.0.0.0 for remote access without a reverse proxy
  • Run in Docker with -p 18789:18789 mapping to all interfaces
  • Deploy on cloud VMs with no firewall rules on the Gateway port

Each exposed instance is a potential RCE target given the CVE history. The Gateway was not designed as an internet-facing service — it lacks rate limiting, TLS termination, and thorough authentication when accessed directly.

Threat 2 — Pi Runtime Code Execution

Pi's four core tools (Read, Write, Edit, Bash) provide the agent with essentially root-equivalent access to the host system (or container). The Bash tool executes arbitrary shell commands, and the filesystem tools have no built-in sandboxing.

Attack chains:

  • Malicious skill triggers Bash to exfiltrate data or install persistence
  • Prompt injection causes the agent to execute attacker-controlled commands
  • Session hijack (via auth bypass CVE) grants full Pi Runtime control
  • Path traversal through Read accesses files outside intended scope

Threat 3 — ClawHub Supply Chain

The ClawHub marketplace hosts 13,700+ community-contributed skills, of which 341 to 900 are identified as malicious. This range reflects the difficulty of exact classification — some skills exhibit suspicious behavior that can be intentional or accidental.

Known malicious skill categories:

Category Behavior
Data exfiltration Reads MEMORY.md or daily notes and sends contents to external endpoints
Credential theft Harvests API keys from environment variables or config files
Persistence Installs cron jobs or modifies system prompt to maintain access
Crypto mining Uses Bash tool to download and run mining software
Prompt injection relay Injects instructions into the context of the agent to override user intent

No Mandatory Code Review

ClawHub does not require skills to pass security review before publication. The marketplace relies on community flagging and optional static analysis. There is no sandboxed execution environment for skill testing. TBD — whether the OpenClaw foundation announced plans for mandatory vetting.

Threat 4 — Prompt Injection

OpenClaw is susceptible to prompt injection attacks through any of its 24+ messaging channels. Because the agent processes user messages as natural language instructions, an attacker who can inject text into a conversation can potentially:

  • Override the system prompt to change agent behavior
  • Exfiltrate memory contents by instructing the agent to read and relay them
  • Trigger Bash commands disguised as legitimate instructions
  • Bypass Lobster pipeline safety controls through instruction manipulation

Prompt injection is particularly dangerous in OpenClaw because the same agent instance can serve multiple channels. A compromised message in one channel can affect the behavior of the agent in subsequent interactions across all channels.

Threat 5 — Channel Authentication Weaknesses

Each messaging platform connector has its own authentication model. This creates an inconsistent security boundary:

  • WhatsApp/Telegram/Signal — rely on platform-level sender identity. OpenClaw trusts the channel API's reported sender
  • WebChat — minimal authentication by default. Anyone with the URL can interact
  • IRC — no native authentication. Nicknames are trivially spoofable
  • Webhooks — shared secret validation varies by connector. Some connectors accept unsigned payloads

There is no unified identity layer across channels. User isolation depends on channel bindings configured per-agent, not on a centralized IAM system.

Threat 6 — Memory and Session Data Exposure

OpenClaw's three-tier memory system (MEMORY.md, daily notes, session context) stores sensitive user data in plaintext on the local filesystem:

  • MEMORY.md — permanent facts, preferences, potentially PII
  • memory/YYYY-MM-DD.md — daily interaction logs
  • Session trees — full conversation history including tool outputs

If the host is compromised (via any of the threats in this threat model), all memory data is immediately accessible. There is no at-rest encryption for memory files in the default deployment.

Access Control Model

Gateway Authentication

The Gateway supports the following authentication mechanisms:

Mechanism Scope Notes
API key header WebSocket connections Single shared key. No per-user granularity
Channel binding Per-platform Maps specific channel accounts to agent instances
Admin UI token Web dashboard Separate token for configuration interface
No auth (default) Local access Localhost binding relies on network isolation only

No RBAC

OpenClaw has no role-based access control. Any authenticated client has full access to all agent capabilities. There is no read-only mode, no permission tiers, and no audit trail for who issued which command.

Channel Bindings

Channel bindings associate a messaging platform identity (phone number, username, bot token) with an OpenClaw agent instance. This is the primary isolation mechanism for multi-user or multi-agent deployments:

  • One agent can be bound to multiple channels
  • Multiple agents on one Gateway can be bound to different channels
  • Cross-agent communication is possible through Lobster pipelines

User Isolation

In multi-user scenarios, isolation depends entirely on configuration:

  • Single-user (typical) — one agent, all channels, no isolation needed
  • Multi-agent routing — separate agents per user/context, each with own memory and session state
  • No built-in tenant isolation — the Gateway does not enforce per-user boundaries within a single agent

Network Security

Port 18789 Binding

The Gateway defaults to ws://127.0.0.1:18789, which is safe for single-machine deployments. The critical failure mode is binding to 0.0.0.0:18789 without additional protection.

Required network architecture for remote access:

graph LR
    CLIENT["Remote Client"] -->|HTTPS/WSS| RP["Reverse Proxy<br>(nginx/Caddy/Traefik)"]
    RP -->|ws://127.0.0.1:18789| GW["Gateway"]

    subgraph Firewall["Firewall Rules"]
        ALLOW["Allow: 443/tcp inbound"]
        DENY["Deny: 18789/tcp inbound"]
    end

    RP -.->|Protected by| Firewall
    GW -.->|Protected by| Firewall

    style DENY fill:#d32f2f,color:#fff
    style ALLOW fill:#2e7d32,color:#fff

TLS Requirements

The Gateway does not natively terminate TLS. All production deployments must use a reverse proxy for:

  • TLS termination (Let's Encrypt or managed certificates)
  • WebSocket upgrade handling (wss:// to ws://)
  • Request rate limiting
  • IP allowlisting

Firewall Configuration

Minimum firewall rules for a production OpenClaw instance:

# Allow HTTPS (reverse proxy)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Block direct Gateway access from external networks
iptables -A INPUT -p tcp --dport 18789 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 18789 -j DROP

# Block outbound from agent container (if using Docker)
# Allow only necessary API endpoints
iptables -A OUTPUT -p tcp --dport 443 -d api.anthropic.com -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -d api.openai.com -j ACCEPT

Sandboxing Approaches

NemoClaw is the primary sandboxing solution. It provides out-of-process security enforcement that the agent itself cannot bypass. See ai-agents/openclaw/explanation#NemoClaw Integration (NVIDIA) for the full architecture diagram.

Security features:

Feature How It Works
Out-of-process policy enforcement Policies are enforced by the OpenShell runtime outside the process of the agent. Even a fully compromised agent cannot modify or disable policies — analogous to browser tab sandboxing.
Privacy Router Routes LLM inference to local models (Nemotron) for sensitive data, cloud providers for non-sensitive. Prevents confidential data from leaving the network.
Credential injection API keys and tokens are injected into the agent environment at runtime and never written to the sandbox filesystem. Credentials are not accessible via Read or Bash file operations.
Declarative YAML policies Filesystem access, network egress, process execution, and inference routing controlled via human-readable YAML.
K3s isolation Each agent sandbox runs as an isolated Kubernetes pod within a K3s cluster inside Docker.

Example NemoClaw policy (declarative YAML):

# TBD — exact policy schema not publicly documented at time of writing
# Conceptual structure based on NemoClaw documentation references
sandbox:
  filesystem:
    read:
      - /app/data/memory/**
      - /app/data/skills/**
    write:
      - /app/data/memory/**
    deny:
      - /etc/shadow
      - /root/.ssh/**
  network:
    egress:
      allow:
        - api.anthropic.com:443
        - api.openai.com:443
      deny: ["*"]
  process:
    allow:
      - node
      - python3
    deny:
      - curl    # prevent data exfiltration
      - wget
  inference:
    sensitive_keywords: ["password", "ssn", "credit card"]
    sensitive_route: local    # Nemotron
    default_route: cloud      # Claude/GPT

Docker Isolation

For deployments without NVIDIA hardware, Docker provides the primary isolation layer:

  • Run OpenClaw in a container with minimal filesystem mounts
  • Use read-only root filesystem where possible
  • Drop all Linux capabilities except those required
  • Apply seccomp and AppArmor profiles
  • Network namespace isolation limits lateral movement
docker run -d \
  --name openclaw \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  --security-opt seccomp=openclaw-seccomp.json \
  --security-opt apparmor=openclaw-profile \
  -v ~/.openclaw/data:/app/data:rw \
  -p 127.0.0.1:18789:18789 \
  openclaw/openclaw:latest

Bind to Localhost Only

Note the -p 127.0.0.1:18789:18789 binding. Using -p 18789:18789 (without the 127.0.0.1 prefix) exposes the port on all interfaces, which is the root cause of the 135,000 exposed instances.

Lobster Pipeline Safety Controls

Lobster enforces several runtime safety constraints on workflow execution:

Control Purpose
Execution timeouts Prevents runaway pipelines from consuming resources indefinitely
Output caps Limits the size of data produced by each pipeline step
Tool allowlists Restricts which Pi tools a pipeline step can invoke
Resume tokens Halted pipelines require explicit approval to continue. This prevents autonomous escalation
Sandbox checks Validates environment constraints before executing each step

These controls mitigate the risk of a compromised skill using Lobster as an escalation path, though they are not a substitute for proper host-level sandboxing.

Secrets Management

Default (Insecure)

In a standard OpenClaw deployment, secrets are stored in:

  • Environment variables (for example, ANTHROPIC_API_KEY)
  • Configuration files on the local filesystem
  • Accessible to the agent via Bash (env, cat) and Read tools

This means any successful prompt injection or malicious skill can trivially exfiltrate API keys.

NemoClaw Credential Injection

NemoClaw solves this by injecting credentials at the runtime level:

  • Credentials are stored outside the agent sandbox
  • Injected into the process environment only when needed
  • Never written to any file the agent can access
  • Revocable without restarting the agent

Best Practices

  • Never store API keys in MEMORY.md or daily notes
  • Use NemoClaw credential injection for all sensitive keys
  • Rotate keys regularly. The CVE history suggests compromise windows are short
  • Monitor API provider dashboards for unusual usage patterns
  • Use separate API keys for OpenClaw vs. other applications to limit blast radius

ClawHub Skill Vetting

Current State

Aspect Status
Pre-publication security review Not required
Automated static analysis Optional. Run by some skill authors
Sandboxed testing environment Does not exist
Community flagging Available. Response time varies
Signature verification Bypass vulnerability disclosed in March 2026 CVE batch
Skill permissions model TBD — no public documentation of granular skill permissions

What Auditing Exists

  • Community reports — users can flag skills on ClawHub
  • Star/download metrics — popularity as a weak proxy for trust
  • Source inspection — skills are human-readable (not compiled). This allows manual review
  • Third-party scanners — community-built tools like claw-audit do basic static analysis

What Does Not Exist

  • Mandatory code review before marketplace listing
  • Sandboxed execution for skill testing
  • Behavioral monitoring of installed skills
  • Automated detection of data exfiltration patterns
  • Signed skill packages with chain-of-trust verification (signature bypass CVE undermines this)

Recommendation

Never install ClawHub skills without reading the source code. Prefer the 53 official bundled skills. For community skills, review every line before installation and monitor agent behavior after enabling.

Audit Logging

Built-in Capabilities

OpenClaw logs agent activity to the local filesystem:

  • Session logs — full conversation trees including tool calls and outputs
  • Cron execution logs — timestamped records of scheduled task runs
  • Webhook invocation logs — inbound trigger events

Limitations

  • No structured security audit log (SIEM-compatible format)
  • No tamper-proof log storage — the agent can modify its own logs via Write or Bash
  • No real-time alerting on suspicious activity
  • No separation between operational logs and security events
  • TBD — whether the OpenClaw foundation plans to add structured audit logging

For production deployments, supplement built-in logging with:

  • Host-level auditd/osquery for process and file monitoring
  • Docker logging driver sending to external collector (Loki, Elasticsearch)
  • Network traffic monitoring on the Gateway port
  • API provider usage monitoring for anomalous token consumption

Hardening Checklist

Production Deployment Hardening

Follow every item before exposing OpenClaw to users or sensitive data.

  • Network isolation — Gateway bound to 127.0.0.1:18789 only. Never 0.0.0.0
  • Reverse proxy — nginx/Caddy/Traefik in front with TLS termination and rate limiting
  • Firewall rules — port 18789 blocked from external networks
  • Docker deployment — read-only root filesystem, dropped capabilities, seccomp profile
  • NemoClaw — deployed for any use case involving confidential or business data
  • Credential injection — all API keys via NemoClaw, never in environment variables or config files
  • ClawHub skills audit — every community skill source-reviewed before installation. Prefer bundled skills
  • Memory hygiene — review MEMORY.md periodically. Remove PII that is no longer needed
  • Separate instances — one for everyday use, one (via NemoClaw) for confidential workloads
  • Update cadence — apply OpenClaw updates within 24 hours. The CVE disclosure rate demands urgency
  • External logging — Docker log driver to external SIEM. Host-level auditd or osquery
  • Network egress filtering — whitelist only required API endpoints for outbound traffic
  • Channel authentication — disable WebChat and IRC connectors unless specifically needed. Prefer platforms with strong sender identity (WhatsApp, Signal)
  • Backup and recovery — regular snapshots of memory and configuration. Test restore procedures

Comparison Note — Hermes Agent

For context, Hermes Agent — a comparable open-source AI agent framework — reported zero CVEs as of April 2026. While Hermes has a smaller feature surface (no multi-channel gateway, no skill marketplace), the contrast highlights how OpenClaw's architectural breadth directly expands its attack surface. The multi-channel gateway, arbitrary code execution, and third-party marketplace are features that carry proportional security risk.

Sources