OpenClaw Security Hardening: Best Practices for Self-Hosted AI Assistants

Self-hosting an AI assistant gives you control over your data, but it also makes you responsible for security. OpenClaw is designed with security defaults, but there are additional steps you should take, especially if you're exposing it remotely or running it on a VPS. This guide covers both OpenClaw-specific hardening and host-level security.

The Security Model

OpenClaw operates on a single-user, personal assistant model. It is not designed for multi-tenant deployments or public-facing services. The security assumptions:

You trust your own messages — the main session (direct chats with you) runs with elevated privileges by default

Group chats and channels are untrusted — non-main sessions can be sandboxed

Inbound DMs require pairing — unknown senders cannot message you without approval

The Gateway is local-only by default — it binds to 127.0.0.1 unless you explicitly configure remote access

This model works well for personal use, but breaks down if you try to run OpenClaw as a shared service. Don't do that.

OpenClaw Security Audit

Before doing anything else, run the built-in security audit:

openclaw security audit --deep

This checks:

• DM policies — are unknown senders blocked?
• Channel allowlists — who can message you?
• Group settings — are mentions required?
• File permissions — are credentials readable by other users?
• Gateway binding — is the Gateway exposed to the internet?
• Browser control — is it enabled, and is 2FA required on important accounts?

Example output:

✅ DM policy: pairing (secure)
✅ Telegram allowlist: restricted to 1 user
⚠️  Browser control enabled — ensure 2FA on important accounts
✅ Gateway bind: 127.0.0.1 (local-only)
✅ Credentials file: mode 0600 (secure)

Auto-Fix Safe Issues

To apply OpenClaw's safe defaults:

openclaw security audit --fix

This tightens file permissions and updates OpenClaw config settings. It does not change host firewall, SSH, or OS update policies.

DM Pairing: The First Line of Defense

By default, OpenClaw uses DM pairing for channels like Telegram, WhatsApp, and Discord. When an unknown sender messages you:

OpenClaw generates a short pairing code

The sender receives the code and a message explaining they need approval

OpenClaw does not process their message

You approve or reject via openclaw pairing approve or openclaw pairing reject

Once approved, the sender is added to an allowlist and can message you freely.

Verify DM Policy

Check your Telegram config:

{
  "channels": {
    "telegram": {
      "dmPolicy": "pairing",
      "allowFrom": ["1303993020"]
    }
  }
}

Never set dmPolicy: "open" unless you understand the risk. Open DM policies mean anyone can message your assistant and potentially extract information or trigger tool calls.

Approve Pending Requests

List pending pairing requests:

openclaw pairing list

Approve a specific request:

openclaw pairing approve <code>

Reject all:

openclaw pairing reject --all

Channel Allowlists

Even with DM pairing enabled, you should explicitly allowlist who can contact you:

{
  "channels": {
    "telegram": {
      "allowFrom": ["@your_username", "1234567890"]
    },
    "whatsapp": {
      "allowFrom": ["+15555550123"]
    },
    "discord": {
      "allowFrom": ["123456789012345678"]
    }
  }
}

Pro tip: Run openclaw status --deep to see your user ID for each channel, then add it to the allowlist.

Group Chat Security

If you're using OpenClaw in group chats (Telegram groups, Discord servers, Slack channels), require mentions:

{
  "channels": {
    "telegram": {
      "groups": {
        "*": {
          "requireMention": true
        }
      }
    }
  },
  "messages": {
    "groupChat": {
      "mentionPatterns": ["@openclaw", "hey openclaw"]
    }
  }
}

Now the assistant only responds when explicitly mentioned, preventing it from reacting to every message in busy groups.

Sandbox Group Sessions

By default, the main session (your direct chats) runs with full tool access on the host. Group chats should run sandboxed:

{
  "tools": {
    "sandbox": {
      "mode": "non-main",
      "tools": {
        "allow": ["read", "write", "edit", "web_search", "web_fetch"],
        "deny": ["browser", "exec", "nodes", "cron"]
      }
    }
  }
}

This runs non-main sessions (groups, channels) in isolated Docker containers where they can read/write files but cannot execute arbitrary commands or control your browser.

Prerequisite: Docker must be installed. OpenClaw uses per-session containers.

Gateway Binding and Firewall

The Gateway should never be exposed directly to the public internet. By default, it binds to 127.0.0.1 (local-only):

{
  "gateway": {
    "port": 18789,
    "bind": "127.0.0.1"
  }
}

Verify with:

ss -ltnp | grep 18789

You should see:

LISTEN 0 511 127.0.0.1:18789 0.0.0.0:*

If you see 0.0.0.0:18789, the Gateway is exposed to all interfaces. Fix it:

{
  "gateway": {
    "bind": "127.0.0.1"
  }
}

Restart the Gateway:

openclaw gateway restart

Remote Access: Use Tailscale

If you need remote access to the Control UI or WebChat, use Tailscale Serve/Funnel:

{
  "gateway": {
    "tailscale": {
      "mode": "serve"
    }
  }
}

Serve mode exposes the Gateway to your tailnet (private VPN) only. Funnel mode makes it public but requires password authentication.

OpenClaw enforces that bind stays 127.0.0.1 when Tailscale is enabled, preventing accidental exposure.

SSH Tunnels (Alternative)

If you don't use Tailscale, SSH tunnels work:

ssh -L 18789:127.0.0.1:18789 user@your-vps

Now access the Control UI locally at http://127.0.0.1:18789.

Host-Level Hardening

OpenClaw doesn't manage host firewalls, SSH, or OS updates. You need to handle these separately.

Firewall Rules (Linux)

If you're running OpenClaw on a VPS, enable UFW:

sudo ufw allow ssh
sudo ufw allow from any to any port 443 proto tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

This blocks all inbound traffic except SSH and HTTPS (for Tailscale or reverse proxies).

Do not open port 18789 to the internet. Ever.

SSH Hardening

Edit /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Restart SSH:

sudo systemctl restart sshd

Automatic Security Updates (Debian/Ubuntu)

Install unattended-upgrades:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Verify it's running:

systemctl status unattended-upgrades

Disk Encryption

OpenClaw stores credentials in ~/.openclaw/credentials. If your disk isn't encrypted, anyone with physical access can read them.

Enable disk encryption:

• macOS: FileVault (System Settings → Privacy & Security → FileVault)
• Linux: LUKS (set up during OS installation)
• Windows: BitLocker

Browser Control and 2FA

If you enable browser control:

{
  "browser": {
    "enabled": true
  }
}

Your assistant can log into websites, fill forms, and extract data. This is powerful but risky. Always enable 2FA on important accounts:

• Email (Gmail, Outlook, etc.)
• Banking and financial services
• Social media
• Cloud providers (AWS, GCP, Azure)

Prefer hardware keys (YubiKey, Titan) over SMS-based 2FA.

Credential Hygiene

OpenClaw stores API keys and tokens in:

• ~/.openclaw/credentials — encrypted at rest (if disk encryption is enabled)
• ~/.openclaw/openclaw.json — some tokens may be inline (avoid this)

Move Secrets to Environment Variables

Instead of storing tokens in openclaw.json:

{
  "channels": {
    "telegram": {
      "botToken": "TELEGRAM_BOT_TOKEN"
    }
  }
}

Set the environment variable:

export TELEGRAM_BOT_TOKEN="123456:ABC-DEF..."

OpenClaw reads env vars automatically.

File Permissions

Verify credentials are not world-readable:

ls -l ~/.openclaw/credentials

Should show:

-rw------- 1 user user 1234 Mar 4 12:00 credentials

If not, fix it:

chmod 600 ~/.openclaw/credentials

Periodic Audits

Schedule regular security audits using OpenClaw's cron system:

openclaw cron add \
  --name "security-audit" \
  --schedule "0 2 * * 0" \
  --message "Run: openclaw security audit --deep. Report findings."

This runs every Sunday at 2:00 AM and messages you with the results.

What Not to Do

Don't run OpenClaw as root — use a regular user account

Don't expose port 18789 publicly — use Tailscale or SSH tunnels

Don't set dmPolicy: "open" unless you're testing

Don't commit credentials to Git — use .gitignore for ~/.openclaw/credentials

Don't skip OS updates — security patches matter

Don't use the same API key across multiple machines — rotate keys regularly

Emergency: Suspected Compromise

If you suspect your OpenClaw instance was compromised:

Stop the Gateway immediately:

openclaw gateway stop

Rotate all API keys:

- Anthropic: https://console.anthropic.com
- OpenAI: https://platform.openai.com/api-keys
- Any other providers

Revoke channel tokens:

- Telegram: message @BotFather, /revoke
- WhatsApp: unlink the device
- Discord: regenerate bot token

Check for unauthorized messages:

Review Gateway logs:

openclaw logs --tail 1000 | grep -i "unauthorized\|failed"

Reinstall from scratch:

openclaw uninstall
   rm -rf ~/.openclaw
   npm install -g openclaw@latest
   openclaw onboard --install-daemon

Checklist: Production-Ready Security

Use this checklist before deploying OpenClaw to a VPS:

• [ ] DM pairing enabled (dmPolicy: "pairing")
• [ ] Channel allowlists configured
• [ ] Group chats require mentions
• [ ] Non-main sessions sandboxed (sandbox.mode: "non-main")
• [ ] Gateway binds to 127.0.0.1
• [ ] Firewall blocks inbound traffic except SSH/HTTPS
• [ ] SSH hardened (no root, key-only auth)
• [ ] Automatic security updates enabled
• [ ] Disk encryption enabled
• [ ] 2FA enabled on important accounts (if browser control is used)
• [ ] Credentials file permissions: 0600
• [ ] Periodic audits scheduled
• [ ] Backup strategy in place

Run:

openclaw doctor

This validates your config and catches common mistakes.

Conclusion

Self-hosting an AI assistant is about control, not just convenience. OpenClaw gives you the tools to run securely, but you need to use them. Start with the built-in audit, enable DM pairing, sandbox non-main sessions, and never expose the Gateway port publicly. Layer in host-level hardening (firewall, SSH, updates, encryption), and schedule regular audits.

Security is not a one-time setup. It's an ongoing practice. 🦞