Hardening OpenClaw in Production: A Security-First Deployment Guide

OpenClaw is the most popular open-source AI agent framework on the planet. It is also, right now, one of the most actively exploited.

In the first three weeks of February 2026 alone, the OpenClaw ecosystem has been hit with over 40 CVEs patched in a single release (v2026.2.12), a critical 1-click RCE vulnerability (CVE-2026-25253, CVSS 8.8) that bypasses local network protections entirely, and the discovery that 11.9% of all skills on ClawHub — 341 out of 2,857 audited by Koi Security — were confirmed malicious, with 335 traced to a single coordinated campaign dubbed ClawHavoc. Since that initial scan, the number has ballooned to over 824 malicious skills across a registry that grew to 10,700+.

If you are running OpenClaw in production today, your attack surface is not theoretical. It is measured, cataloged, and actively being targeted.

This guide documents the exact hardening steps we apply to every OpenClaw deployment at Principium Axis. It is organized into four defense layers: application configuration, host-level network controls, monitoring and detection, and edge protection. Each layer is independent. Each layer is necessary.

Layer 1: OpenClaw Application Hardening

The OpenClaw configuration file (openclaw.json) is the first and most commonly misconfigured attack surface. Most deployments ship with permissive defaults. The default sandbox mode is "none". The default plugin policy is allow-all. The default workspace access is read-write. These defaults exist to make the first-run experience frictionless. They are not production settings.

Plugin Allowlisting

The plugins.allow directive is an exclusive list. When set, only the plugins you explicitly name are loaded. Everything else is rejected at startup.

{
  "plugins": {
    "allow": ["telegram"]
  }
}

This is not optional. The ClawHavoc campaign demonstrated that malicious skills can exfiltrate SSH keys, open reverse shells, and deploy Atomic Stealer (AMOS) binaries — all through the plugin and skill system. If you are not explicitly allowlisting, you are trusting every plugin author on ClawHub with root-equivalent access to your host.

Sandbox Configuration

OpenClaw's agent sandbox controls what tools can do at runtime. The two critical settings are mode and workspaceAccess.

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "workspaceAccess": "ro"
      }
    }
  }
}

mode: "all" sandboxes every tool invocation. workspaceAccess: "ro" restricts the agent's workspace to read-only. An agent that cannot write to its own workspace cannot persist malicious artifacts, cannot modify its own configuration, and cannot stage payloads for later execution.

Gateway Trust Configuration

If you are running OpenClaw behind a reverse proxy (and you should be), the gateway.trustedProxies setting determines which upstream addresses OpenClaw trusts for forwarded headers.

{
  "gateway": {
    "trustedProxies": ["127.0.0.1"]
  }
}

Set this to loopback only. Your reverse proxy should be the only process communicating with the OpenClaw gateway.

Disable Network Discovery

{
  "discovery": {
    "mdns": {
      "mode": "off"
    }
  }
}

mDNS broadcasts your agent's presence to the local network. Turn it off. Service discovery protocols on production hosts are how lateral movement begins.

File Permissions

After editing openclaw.json with tools like jq (which writes to a temp file and moves it back), the file permissions reset to world-readable.

chmod 600 /path/to/openclaw.json

Your configuration file contains gateway settings and potentially API keys. It should be readable only by the service user. Check this after every configuration change.

Verify With the Built-In Audit

openclaw security audit --deep

Your target is zero critical findings and zero warnings. If you cannot reach that target, you have work to do before anything else in this guide matters.

Layer 2: Host-Level Network Controls

Application-level hardening is necessary but insufficient. A misconfigured application behind a properly locked-down network is survivable. A perfectly configured application on an open network is one exploit away from compromise.

Firewall Strategy: Default Deny, Explicit Allow

# Default deny
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH - the only service open to the internet
sudo ufw allow 22/tcp

# HTTPS - restricted to Cloudflare IP ranges only
sudo ufw allow from 173.245.48.0/20 to any port 443 proto tcp
sudo ufw allow from 103.21.244.0/22 to any port 443 proto tcp
sudo ufw allow from 103.22.200.0/22 to any port 443 proto tcp
# ... (all 15 Cloudflare CIDR blocks)

# Monitoring ports - restricted to specific agent IPs
sudo ufw allow from <AGENT_IP>/32 to any port 1514 proto tcp

The key decision: restrict port 443 to Cloudflare's published IP ranges. Direct IP access returns a connection timeout. An attacker who discovers your server's IP through DNS history or certificate transparency logs still cannot reach your application layer.

Reverse Proxy Architecture

Internet → Cloudflare → Your Server:443 → Caddy → localhost:18789 (OpenClaw)

OpenClaw binds to loopback only. Caddy handles TLS. Cloudflare handles DDoS protection and WAF. At no point does the OpenClaw process directly handle an internet-routable connection.

Layer 3: Monitoring and Detection

Hardening prevents compromise. Monitoring detects it when prevention fails. Both are required.

File Integrity Monitoring (FIM)

A SIEM agent should watch the directories that matter: the OpenClaw workspace, config directory, /etc/systemd/system/, /etc/ssh/, and /etc/sudoers.d/.

<!-- Wazuh FIM configuration -->
<syscheck>
  <directories check_all="yes" realtime="yes">/home/deploy/.openclaw/workspace</directories>
  <directories check_all="yes" realtime="yes">/etc/systemd/system</directories>
  <directories check_all="yes" realtime="yes">/etc/ssh</directories>
  <directories check_all="yes" realtime="yes">/etc/sudoers.d</directories>
</syscheck>

The realtime="yes" flag enables inotify-based monitoring — alerts within seconds of a file change, not on the next scheduled scan.

Verify Your Monitoring Actually Works

# Create a test file in a monitored directory
touch /home/deploy/.openclaw/workspace/fim-test-canary

# Check your SIEM for the alert
# If no alert appears within 60 seconds, your FIM is broken

Do this after every configuration change. Monitoring that is not verified is not monitoring.

Layer 4: Edge Protection

The final layer protects administrative interfaces. Cloudflare Access acts as a zero-trust gateway, requiring email OTP verification before allowing access.

Even if an attacker compromises your Cloudflare credentials, they still need access to a specific email inbox. And even if they have that, they still need to get through Layers 1-3.

# Direct IP access should timeout, not return a page
curl -k --connect-timeout 5 https://<YOUR_SERVER_IP>
# Expected: connection timeout

The Audit Checklist

• ☐openclaw security audit --deep returns 0 critical, 0 warnings
• ☐plugins.allow is set and contains only plugins you actively use
• ☐sandbox.mode is "all" and workspaceAccess is "ro"
• ☐gateway.trustedProxies contains only 127.0.0.1
• ☐discovery.mdns.mode is "off"
• ☐openclaw.json permissions are 600
• ☐UFW is active with default deny incoming
• ☐Port 443 restricted to Cloudflare IP ranges
• ☐Monitoring ports restricted to specific agent IPs
• ☐SSH is key-only, no root login, no password auth
• ☐OpenClaw binds to loopback only, behind reverse proxy
• ☐FIM active on workspace, config, systemd, SSH, sudoers
• ☐FIM alerts verified with a canary file test
• ☐Cloudflare Access protects administrative interfaces
• ☐Direct IP access returns connection timeout
• ☐Running v2026.2.12 or later (40+ CVE patch release)
• ☐Gateway auth token rotated after updating past CVE-2026-25253