Overview

OpenClaw is designed as a personal assistant — one trusted operator boundary per gateway. This guide covers hardening your deployment within that model.

Security Model

OpenClaw assumes the host and config boundary are trusted. If someone can modify ~/.openclaw/openclaw.json, they're a trusted operator.

• One user per gateway — recommended baseline
• sessionKey is not authorization — it's routing, not auth
• Operators have full access — by design
• Node pairing is operator-level — treat paired devices as trusted

Quick Security Audit

Run the built-in security audit to catch common issues:

# Basic audit
openclaw security audit

# Deep scan (includes live Gateway probe)
openclaw security audit --deep

# Auto-fix issues
openclaw security audit --fix

# JSON output for automation
openclaw security audit --json

Run this regularly, especially after changing config or exposing network surfaces.

Hardened Baseline Config

This baseline keeps the Gateway local-only, isolates DMs, and disables control-plane/runtime tools by default:

{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "auth": {
      "mode": "token",
      "token": "replace-with-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
    }
  },
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "groups": {
        "*": { "requireMention": true }
      }
    }
  }
}

Authentication Options

OpenClaw supports three authentication modes:

• Token auth — Set a long random token in gateway.auth.token. Best for most cases.
• Password auth — Set gateway.auth.mode: "password". Simple but less secure.
• Device auth — Pairs devices via QR code. No persistent token needed.

openssl rand -base64 32

Key Security Settings

Essential settings for a hardened gateway:

{
  "gateway": {
    "bind": "loopback",
    "auth": {
      "token": "your-secure-token-here"
    }
  },
  "channels": {
    "whatsapp": {
      "allowFrom": ["+15555550123"]
    },
    "telegram": {
      "allowFrom": ["123456789"]
    }
  }
}

• bind: "loopback" — never bind to LAN/public by default
• gateway.auth.token — always set a token
• allowFrom — restrict who can message your bot
• dmScope: "per-channel-peer" — isolate DMs per user

Network Exposure

Keep the gateway loopback-only. Use SSH tunnels or Tailscale for remote access.

# SSH tunnel for remote access
ssh -N -L 18789:127.0.0.1:18789 user@vps

Tool Policy Best Practices

Start with minimal tools and enable them as needed:

• Run openclaw security audit --fix for a hardened baseline
• Avoid elevated mode unless necessary
• Review tool allowlists regularly
• Treat browser control as operator-level access
• Use tools.fs.workspaceOnly: true to limit file access

What the Audit Checks

The security audit checks for these common issues:

• Inbound access — DM policies, group policies, allowlists
• Tool blast radius — elevated tools + open rooms
• Network exposure — Gateway bind/auth, Tailscale Funnel
• Browser control exposure — remote nodes, relay ports
• File permissions — state/config not world-readable
• Plugins — extensions loaded without explicit allowlist
• Sandbox mismatch — exec.host="sandbox" but sandbox disabled

Multi-User Considerations

If multiple users need access, the safest approach:

• Separate gateways per trust boundary
• Ideally, separate OS users/hosts per user
• Don't share one gateway between adversarial users
• Use dmScope: "per-channel-peer" for shared inboxes