Security Guide: Hardening Your OpenClaw Instance

TL;DR: Your OpenClaw instance is an AI with access to tools, files, and API keys. Treat it like a server with root access — because it functionally is one. Lock down the gateway, secure your tokens, restrict file access, and never expose it to the public internet without auth.

Estimated time: 20-30 minutes
Difficulty: Intermediate

Why This Matters

Your OpenClaw instance can:

• Read and write files on the server
• Execute shell commands
• Access your API keys (worth real money)
• Send messages on your behalf
• Browse the web
• Interact with external services

If someone gains unauthorized access, they can do all of the above. They can drain your API credits, read your files, or use your assistant as a stepping stone to attack other systems.

This isn't theoretical. Automated bots scan every public IP on the internet, probing for open ports and misconfigured services. An unprotected OpenClaw gateway will be found.

Default Security Posture

Out of the box, OpenClaw has some security built in — but it assumes you'll do your part too.

What's Secure by Default

• Gateway binds to localhost: The gateway listens on 127.0.0.1:3000 by default, meaning only processes on the same machine can reach it
• Pairing required for new chats: New users/groups must be approved before the AI responds
• Session isolation: Different chats get separate sessions — one user can't see another's conversation
• No remote shell by default: The gateway doesn't expose a terminal to the network

What You Need to Configure

• Firewall rules (the server itself may have all ports open)
• Gateway auth token (for any non-localhost access)
• File system boundaries
• API key storage
• SSH hardening (not OpenClaw-specific, but critical)

1. Firewall Rules

Your server should only expose the ports it absolutely needs.

What OpenClaw Needs

That's it. OpenClaw communicates with Telegram, WhatsApp, and Discord via outbound connections — it doesn't need any inbound ports for messaging to work.

UFW Setup (Ubuntu/Debian)

# Reset to defaults
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (consider restricting to your IP)
sudo ufw allow ssh

# If using a reverse proxy for the dashboard
# sudo ufw allow 443/tcp

# Enable
sudo ufw enable

# Verify
sudo ufw status verbose

Restrict SSH to Your IP

If you have a static IP:

sudo ufw delete allow ssh
sudo ufw allow from YOUR.IP.ADDRESS to any port 22

iptables (if not using UFW)

# Default deny incoming
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Save
iptables-save > /etc/iptables/rules.v4

2. Gateway Auth Token

If you need to access the gateway from outside localhost (for node pairing, remote management, or reverse proxy), always set an auth token.

config.json

{
  "gateway": {
    "port": 3000,
    "authToken": "your-long-random-secret-token-here"
  }
}

Generate a Strong Token

# Generate a random 64-character token
openssl rand -hex 32

Output: a3f8b2c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1

Use this as your authToken. Don't use "password123" or your birthday.

How It Works

With an auth token configured, all API requests to the gateway must include the token:

# This fails (no token)
curl http://localhost:3000/api/status
# → 401 Unauthorized

# This works
curl -H "Authorization: Bearer your-token-here" http://localhost:3000/api/status
# → 200 OK

Messaging channels (Telegram, WhatsApp, Discord) don't need the gateway token — they connect outbound. The token protects the gateway's HTTP API.

3. Pairing and DM Approval

The pairing system is your first line of defense against unauthorized chat access.

How Pairing Works

1. Someone messages your bot for the first time
2. OpenClaw holds the message and generates a pairing code
3. You see the pairing request in your admin interface
4. You approve or reject it
5. Approved chats can now interact with the AI freely

Managing Pairings

# List pending pairing requests
clawdbot pairing list

# Approve a specific request
clawdbot pairing approve <code>

# Reject a request
clawdbot pairing reject <code>

# List approved pairings
clawdbot pairing approved

# Revoke access
clawdbot pairing revoke <chatId>

Group Chat Pairing

When your bot joins a group, the group itself needs to be paired. This prevents random people from adding your bot to their groups and using your API credits.

Auto-Approval

If you want your bot to respond to everyone without pairing (not recommended for most setups):

{
  "pairing": {
    "autoApprove": true
  }
}

Only use this if you understand the cost and security implications. Anyone who finds your bot can chat with it, consuming your API credits.

4. Token and Key Security

Your OpenClaw instance holds several sensitive secrets:

Best Practices

Use environment variables, not config files, for secrets:

# In ~/.bashrc or /etc/environment or a .env file
export ANTHROPIC_API_KEY="sk-ant-xxxxx"
export TELEGRAM_BOT_TOKEN="7123456789:xxxxx"
export GATEWAY_AUTH_TOKEN="xxxxx"

{
  "providers": {
    "anthropic": {
      "type": "anthropic",
      "apiKey": "${ANTHROPIC_API_KEY}"
    }
  }
}

Restrict file permissions on env files:

# Only the owner can read
chmod 600 ~/.env
chmod 600 /path/to/openclaw/.env

Never commit secrets to git:

echo ".env" >> .gitignore
echo "*.key" >> .gitignore

Rotate keys periodically:

If you suspect a key has been compromised — or just for good hygiene — rotate your API keys every few months. Update the env var, restart the gateway.

Set billing alerts and limits:

• Anthropic: console.anthropic.com → Billing → Set monthly limit
• OpenAI: platform.openai.com → Billing → Set usage limit

Even if your key is compromised, a spending limit caps the damage.

5. File System Sandboxing

OpenClaw has file system access — it can read, write, and execute files. This is powerful and potentially dangerous.

Workspace Boundaries

By default, OpenClaw operates within its workspace directory. You can enforce this:

{
  "security": {
    "workspace": "/home/openclaw/workspace",
    "allowedPaths": [
      "/home/openclaw/workspace",
      "/home/openclaw/data"
    ],
    "deniedPaths": [
      "/etc",
      "/root",
      "/home/openclaw/.ssh"
    ]
  }
}

Run as a Dedicated User

Never run OpenClaw as root. Create a dedicated user with limited permissions:

# Create user
sudo useradd -m -s /bin/bash openclaw

# Give it only what it needs
sudo chown -R openclaw:openclaw /home/openclaw/

# Run the gateway as this user
sudo -u openclaw clawdbot gateway start

What the AI Can Access

Be aware that your AI can access anything the OpenClaw process user can access. This includes:

• All files readable by that user
• Environment variables (including API keys)
• Network access (outbound)
• Any programs installed on the system

If this concerns you, Docker adds another layer of isolation — see our Docker guide.

6. What to NEVER Do

These are the mistakes that actually get people in trouble:

❌ NEVER: Expose the gateway to the internet without auth

# DON'T do this
ports:
  - "0.0.0.0:3000:3000"   # Open to the world, no auth

This lets anyone on the internet access your gateway, send commands to your AI, and potentially access your system.

If you need external access: Use a reverse proxy with authentication, VPN, or SSH tunnel.

❌ NEVER: Run as root

# DON'T do this
sudo node src/index.js

If the AI (or a bug) runs a destructive command, it has full system access.

❌ NEVER: Put API keys in public repos

Even "just for testing." Bots scan GitHub for API keys in near real-time. Your key will be stolen within minutes.

❌ NEVER: Disable pairing with auto-approve on a public bot

Unless you're comfortable with strangers using your API credits and potentially telling your AI to do things you wouldn't approve of.

❌ NEVER: Share your gateway auth token

The token gives full API access to your OpenClaw instance. Treat it like a root password.

❌ NEVER: Skip system updates

# DO this regularly
sudo apt update && sudo apt upgrade -y

Unpatched servers get compromised. This isn't OpenClaw-specific — it's server security 101.

7. SSH Hardening (Server Basics)

This isn't OpenClaw-specific, but if you're self-hosting, your server's SSH config matters:

# /etc/ssh/sshd_config — recommended settings

# Disable root login
PermitRootLogin no

# Use key-based auth only
PasswordAuthentication no
PubkeyAuthentication yes

# Disable empty passwords
PermitEmptyPasswords no

# Limit login attempts
MaxAuthTries 3

# Disable X11 forwarding (you don't need it)
X11Forwarding no

After editing:

sudo systemctl restart sshd

Also install fail2ban:

sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

This automatically bans IPs that fail too many login attempts.

The Managed Alternative

If you don't want to handle security hardening yourself, lobsterfarm provides managed OpenClaw hosting where the server infrastructure — deployment, updates, and maintenance — is handled for you.

Security Checklist

Before considering your instance "production ready," verify:

• [ ] Firewall configured (only SSH + necessary ports open)
• [ ] Gateway bound to localhost (or behind auth)
• [ ] Gateway auth token set (strong, random)
• [ ] Pairing enabled (auto-approve off)
• [ ] Running as non-root user
• [ ] API keys in environment variables, not config files
• [ ] .env file permissions restricted (chmod 600)
• [ ] No secrets in git repos
• [ ] SSH key-based auth only (password auth disabled)
• [ ] fail2ban installed and running
• [ ] Unattended security updates enabled
• [ ] Billing alerts set on API providers
• [ ] Monthly spending limits configured

The Easy Way

Security hardening is important work, but it's also the kind of work most people don't want to do — or don't do thoroughly enough. One missed checkbox and you're exposed.

Don't want to manage server security yourself? lobsterfarm provides managed OpenClaw hosting — deployment, updates, and support handled for you.

Get started with lobsterfarm →