How to Harden OpenClaw: A 3-Tier Security Guide for Self-Hosted Deployments

OpenClaw is powerful because it has real access to your system. It can read files, execute commands, call APIs, and interact with external services on your behalf. That's exactly what makes it useful — and exactly why running it with default settings is a bad idea.

This guide covers a progressive, three-tier security hardening system for OpenClaw deployments. It's structured from minimum viable security through defense-in-depth. Most operators should complete Tier 1 and Tier 2. Tier 3 is for those running sensitive workflows or wanting maximum isolation.

Before anything else, a candid disclaimer from security researchers who have studied this tool in depth: prompt injection is inherent to LLMs and cannot be fully mitigated by configuration. A malicious email, document, or webpage can manipulate your OpenClaw agent into executing commands. This guide reduces the blast radius when that happens — it doesn't prevent it entirely.

Shortcut: The Security Hardener skill (free) runs the 12-step checklist and auto-fixes 7 of 12 checks. Or use the Security Checker tool for a quick audit.

Is OpenClaw Safe to Use?

OpenClaw is safe to use when you operate it like personal infrastructure, not like a shared public bot. The honest answer is yes within the intended trust model and no outside it: if one trusted operator controls the gateway, OpenClaw can be run safely enough with the hardening below. If you expect one instance to securely separate mutually untrusted people with broad tool access, the answer is no, because the official docs do not claim that boundary.

OpenClaw is not unsafe because it is self-hosted; it becomes unsafe when trust boundaries and tool authority are handled badly. The practical risk comes from permissive inbound access, powerful tools, browser and exec surfaces, and prompt injection from untrusted external content. Channel access, tool permissions, and blast radius matter more than branding, which is exactly what the three tiers below are designed to control.

What Should You Never Connect to OpenClaw?

OpenClaw should never be connected to primary email, banking, password managers, work accounts, or cryptocurrency wallets regardless of how well you harden the deployment.

Never connect:

• Primary email accounts
• Banking or financial services
• Password managers
• Work accounts (Slack, corporate Google Workspace, internal systems)
• Social media accounts with irreplaceable history
• Cryptocurrency wallets
• Government or healthcare portals
• Your primary GitHub account

Acceptable (with dedicated burner accounts only):

• A Gmail created solely for OpenClaw notifications
• A Telegram bot (not your personal Telegram)
• A calendar dedicated to AI-managed scheduling
• Development-only GitHub for test repositories
• Low-stakes services you could recreate in under an hour

The rule: every account connected to OpenClaw should be one you could lose without significant impact.

Before you implement the checklist: skim the State of OpenClaw Security 2026 for the big-picture risk map, then use the Security Checker to see which gaps matter most on your own deployment.

How Should You Choose Your OpenClaw Isolation Method?

OpenClaw must never run on your primary computer, and Remote OpenClaw recommends a VPS at $4-6/month on Hetzner, DigitalOcean, or Vultr for most operators seeking clean isolation and easy setup.

VPS (Recommended for most): $4-6/month on Hetzner, DigitalOcean, or Vultr. Clean isolation, easy setup, 2-3 hours to configure manually.

Old hardware (spare laptop or Mac Mini): One-time hardware cost, higher specs for the price, but requires maintenance and is affected by power outages.

Automated Ansible deployment: The openclaw-hardened-ansible playbook implements all three tiers automatically in 15-30 minutes. Recommended if you want the full setup without doing every step manually.

Tier 1: Basic Protection (Do This or Don't Run OpenClaw)

OpenClaw Tier 1 basic protection takes 3-4 hours and covers the minimum viable security every deployment must have before going live.

Step 1: Set Up an Isolated Server

SSH in as root, then:

apt update && apt upgrade -y
apt install ufw fail2ban unattended-upgrades -y
dpkg-reconfigure -plow unattended-upgrades

# Create a non-root user for OpenClaw
useradd -r -m -d /home/openclaw -s /bin/bash openclaw
passwd openclaw

Set up SSH key authentication for the new user and disable root SSH + password auth:

sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

Step 2: Configure the Firewall

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
# DO NOT open 18789 to the internet
ufw enable

Port 18789 (OpenClaw's gateway) should never be accessible publicly. Access it via Tailscale.

Step 3: Install Tailscale

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --ssh
tailscale ip -4 # Note your Tailscale IP

You'll access OpenClaw at http://100.x.x.x:18789 from any device on your Tailnet.

Step 4: Install Node.js 22.12.0+

Node.js versions below 22.12.0 contain a permission model bypass vulnerability (CVE-2026-21636). Verify your version:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
apt install -y nodejs
node --version # Must be 22.12.0 or later

Step 5: Lock Down File Permissions

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.openclaw/gateway.yaml
chmod -R 600 ~/.openclaw/credentials/

Credential files must be readable only by the OpenClaw user.

Step 6: Configure gateway.yaml (Critical Settings)

Edit ~/.openclaw/gateway.yaml:

gateway:
 host: "127.0.0.1" # NEVER 0.0.0.0
 port: 18789
 trustedProxies:
 - "10.0.0.0/8"
 - "172.16.0.0/12"
 - "192.168.0.0/16"
 - "100.64.0.0/10" # Tailscale range — required
 controlUi:
 dangerouslyDisableDeviceAuth: false # Never set true

mdns:
 enabled: false # Disable mDNS broadcasting

The 100.64.0.0/10 Tailscale range in trustedProxies is required — without it, Tailscale access will break.

Step 7: Restrict Filesystem Access

Create ~/.openclaw/tools.yaml:

tools:
 filesystem:
 enabled: true
 allowedPaths:
 - "/home/openclaw/workspace"
 deniedPaths:
 - "/home/openclaw/.ssh"
 - "/home/openclaw/.openclaw/credentials"
 - "/etc"
 - "/root"

Step 8: Only Connect Burner Accounts

Before connecting any account, ask: "Could I lose this account without significant impact?" If no, don't connect it.

Step 9: Set DM Policy to Pairing

In ~/.openclaw/openclaw.json:

{
 "channels": {
 "telegram": {
 "dmPolicy": "pairing"
 }
 }
}

Never use dmPolicy: "open" with allowFrom: ["*"].

Step 10: Run the Security Audit

openclaw security audit --deep

Fix any CRITICAL or WARNING issues before proceeding.

Verify Tier 1

openclaw start
ss -tlnp | grep 18789
# Must show: 127.0.0.1:18789
# Must NOT show: 0.0.0.0:18789

Tier 2: Standard Protection (Recommended for Regular Use)

OpenClaw Tier 2 standard protection adds tool allowlisting, MCP server security, OAuth scope minimisation, and automated weekly monitoring on top of the Tier 1 baseline.

Step 11: Configure Tool Allowlisting

The security principle: denylists fail because attackers find alternatives. Allowlists work because anything not listed can't run.

Edit ~/.openclaw/tools.yaml:

tools:
 shell:
 enabled: true
 allowlist:
 - "ls"
 - "cat"
 - "grep"
 - "head"
 - "tail"
 - "find"
 - "wc"
 - "sort"

If a command isn't in this list, it cannot execute. Start minimal and add only commands you explicitly need.

Step 12: Secure MCP Server Configuration

Edit ~/.openclaw/mcp.json:

{
 "mcpServers": {
 "memory": {
 "version": "0.3.0",
 "autoUpdate": false,
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-memory@0.3.0"]
 }
 }
}

Rules:

• Never use "enableAllProjectMcpServers": true
• Always version-pin ("version": "0.3.0", not "latest")
• Always set "autoUpdate": false
• Never enable filesystem, shell, ssh, or docker MCP servers

Step 13: Minimize OAuth Scopes

Only grant read-only access where possible:

gmail:
 scope: "readonly" # Not "full"

github:
 scope: "public_repo" # Not "repo"

Review OAuth sessions monthly and revoke anything unused.

Step 14: Set Up Automated Weekly Security Monitoring

Create ~/check-openclaw-security.sh:

#!/bin/bash
echo "=== OpenClaw Security Audit $(date) ===" > ~/security-report.txt
openclaw security audit --deep >> ~/security-report.txt 2>&1

# Check for exposed ports
if ss -tlnp | grep -q "0.0.0.0:18789"; then
 echo "CRITICAL: Port 18789 exposed to internet" >> ~/security-report.txt
fi

# Verify device auth is enabled
grep -q "dangerouslyDisableDeviceAuth: true" ~/.openclaw/gateway.yaml && \
 echo "CRITICAL: Device auth disabled" >> ~/security-report.txt

# Check for prompt injection attempts in recent sessions
find ~/.openclaw/agents/*/sessions -name "*.jsonl" -mtime -7 -exec \
 grep -iH "IGNORE PREVIOUS\|SYSTEM:\|DISREGARD\|NEW INSTRUCTIONS" {} \; \
 >> ~/security-report.txt 2>/dev/null

cat ~/security-report.txt

chmod +x ~/check-openclaw-security.sh
crontab -e
# Add: 0 9 * * 0 /home/openclaw/check-openclaw-security.sh

Step 15: Monthly Maintenance Routine

Every first Sunday of the month (30-45 minutes):

# 1. Run security audit
~/check-openclaw-security.sh

# 2. Update everything
sudo apt update && sudo apt upgrade -y
npm update -g openclaw@latest
sudo tailscale update

# 3. Review installed skills and MCP servers
cat ~/.openclaw/mcp.json

# 4. Rotate gateway token
openssl rand -base64 32
# Update in gateway.yaml, restart OpenClaw

# 5. Encrypted backup
BACKUP_DATE=$(date +%Y%m%d)
tar -czf ~/backup-$BACKUP_DATE.tar.gz ~/.openclaw ~/workspace
age --encrypt --armor --recipient $(cat ~/.age-key.txt | grep "public key" | cut -d: -f2) \
 < ~/backup-$BACKUP_DATE.tar.gz > ~/backup-$BACKUP_DATE.tar.gz.age
rm ~/backup-$BACKUP_DATE.tar.gz

Tier 3: Advanced Protection (Defense-in-Depth)

OpenClaw Tier 3 advanced protection adds Docker/Podman sandboxing with LiteLLM credential brokering and Squid proxy domain allowlisting, taking 2-3 hours manually or 30 minutes with the Ansible playbook.

Even Tier 3 does not make OpenClaw safe for accounts on the NEVER list.

Step 16: Docker/Podman Sandbox with LiteLLM

The architecture: OpenClaw runs in a container with no external internet access. LiteLLM runs in a separate container with internet access and acts as a credential broker — it injects your real Anthropic API key into requests so OpenClaw never sees it directly.

Security benefits:

• OpenClaw is network-isolated; it can't exfiltrate data directly
• Rate limiting and cost controls enforced at the LiteLLM layer
• OpenClaw never holds your real API key
• Containers can be destroyed and rebuilt independently

Container runtime recommendation: Use rootless Podman rather than Docker. Docker's daemon runs as root — a container escape gives full root access. Podman's rootless mode means a container escape lands you as an unprivileged user.

# Install Podman (Debian/Ubuntu)
sudo apt install podman podman-compose -y
sudo loginctl enable-linger openclaw

The docker-compose configuration creates two networks:

• openclaw-internal: for communication between OpenClaw and LiteLLM (no internet)
• openclaw-external: for LiteLLM's outbound API calls (internet-accessible)

OpenClaw only connects to openclaw-internal. LiteLLM connects to both.

Step 17: Squid Proxy for Domain Allowlisting

Even with network segmentation, adding a Squid proxy as a second egress filter adds another layer. Squid enforces a domain allowlist for all outbound traffic from the OpenClaw network — anything not on the list is blocked.

The allowlist is strict by default and includes only:

• Core dependencies (npmjs, GitHub)
• Messaging platforms (Telegram, Discord, Slack, WhatsApp)
• Safe external services you explicitly add

The deny-by-default approach means a compromised OpenClaw agent can only communicate with explicitly approved domains.

Step 18: Automated Deployment via Ansible

Rather than implementing Tier 3 manually, the openclaw-hardened-ansible playbook automates the entire setup:

git clone https://github.com/Next-Kick/openclaw-hardened-ansible.git
cd openclaw-hardened-ansible

# Interactive deployment
./deploy.sh

# Non-interactive with Anthropic
./deploy.sh \
 --target <YOUR-VPS-IP> \
 --provider anthropic \
 --model claude-sonnet-4-20250514 \
 --key sk-ant-... \
 --non-interactive

The playbook handles: system updates, Podman installation, Tailscale setup, dedicated user creation, UFW configuration, three-container deployment (OpenClaw + LiteLLM + Squid), and monitoring timers. Manual setup takes 7-9 hours; the playbook takes 15-30 minutes.

Emergency Response

OpenClaw emergency response requires immediately stopping the agent, blocking all outbound traffic with UFW, preserving evidence, and revoking all API credentials from a separate device.

# Stop everything
openclaw stop
sudo ufw deny out to any

# Preserve evidence
cp -r ~/.openclaw ~/incident-$(date +%Y%m%d)

# Revoke credentials immediately (from a different device)
# Anthropic: console.anthropic.com/settings/keys
# Gmail: myaccount.google.com/permissions
# GitHub: github.com/settings/applications

If you suspect compromise: destroy the VPS entirely and rebuild from scratch. Do not attempt to clean a compromised system.

The Realistic Summary

OpenClaw Tier 1-2 hardening protects against exposed dashboards, credential theft, unauthorised bot access, and configuration drift, but cannot prevent prompt injection, zero-day vulnerabilities, or supply chain attacks via ClawHub skills.

What it doesn't protect against: prompt injection (unfixable), zero-day vulnerabilities in OpenClaw, compromised model provider APIs, supply chain attacks via ClawHub skills.

That's not a reason to skip hardening — it's a reason to understand what you're accepting. Run OpenClaw on isolated infrastructure with burner accounts, keep it updated, and monitor it monthly. That's the realistic security posture for a hobbyist deployment.

Links:

• Ansible playbook: github.com/Next-Kick/openclaw-hardened-ansible
• Tailscale setup: tailscale.com
• OpenClaw docs: docs.openclaw.ai