How to Secure Moltbot: Hardening Guide

Hey friends — if you're running Moltbot (now called OpenClaw, formerly Clawdbot — yeah, the naming is confusing), you've probably already felt that moment of "wait, this thing has full system access?"

I got there too. Not docs-confused. Real "I just gave an AI agent shell access to my VPS" confused.

So I spent the last few weeks stress-testing security configs inside a real setup — WhatsApp gateway on a DigitalOcean droplet, running 24/7, handling actual tasks. The goal wasn't to build a fortress. It was to find the minimum viable hardening that doesn't kill the agent's usefulness.

This is what survived.

Security Basics

Let's be real about what we're dealing with here.

Moltbot is powerful because it has deep system access — file I/O, shell commands, browser control, your credentials. That's the whole point. But that same access means one bad prompt injection, one misconfigured channel, or one exposed port can turn your helpful agent into a security nightmare.

I'm not exaggerating. The official docs literally call this out: "Treat the agent as hostile by default." Third-party security researchers have flagged it as a potential "AI crisis" scenario. Palo Alto Networks even wrote about it in the context of OWASP's Top 10 for Agentic Apps.

The core risks I actually encountered:

Prompt injection — This isn't theoretical. I tested it. Send a crafted message through WhatsApp with hidden instructions, and the agent can execute them. Web search results, attachments, even memory from previous conversations can carry injection payloads.

Excessive privileges — By default, Moltbot runs with whatever permissions your user has. That means rm -rf, credential access, network requests — everything. No gates, no approvals.

Unauthenticated gateway exposure — The default setup binds to loopback only (good), but if you expose it to 0.0.0.0 for remote access without proper auth, anyone who hits that port gets full control. I tested this in a sandbox. It's scary.

Credential handling — Credentials can be stored in plaintext in ~/.openclaw/credentials/ if you're not careful. Logs and memory can leak API keys. I found my Anthropic key in session logs twice before I hardened the config.

Memory poisoning — The persistent memory system stores everything. That includes untrusted data. An attacker can plant a payload in one conversation that triggers days later when the agent recalls it.

Here's what I did first, before anything else:

# Lock down the workspace
chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.openclaw/credentials/*
# Run the built-in audit
openclaw security audit --deep

The audit caught three misconfigurations I didn't even know about. One was a world-readable credential file. Another was an exposed tool that didn't need to be enabled.

The fundamental principle I followed: least privilege, default-deny. If a tool isn't essential for my use case, I removed it from the allowlist. If a channel doesn't need group access, I disabled it. If an action is destructive, I gated it with human approval.

I also stopped running as root. Created a dedicated low-privilege user for OpenClaw:

adduser openclaw
usermod -aG sudo openclaw  # only if you need elevated tasks
su - openclaw

This limits the blast radius. If the agent goes rogue, it can't touch system files or other users' data.

Authentication Setup

Authentication was where I made my first real mistake.

I initially skipped token auth because "it's just running locally, right?" Wrong. The moment I wanted remote access via the Control UI, I realized I'd left the gateway wide open. No password, no token, just a WebSocket sitting there.

Token Auth

Here's the right way to set it up from the start.

OpenClaw uses a gateway token for both WebSocket connections and the Control UI. You can generate one during onboarding, or manually with:

openclaw doctor --generate-gateway-token

Then add it to ~/.openclaw/openclaw.json:

{
  "gateway": {
    "auth": {
      "mode": "token",
      "token": "your-super-long-random-string-here"
    }
  }
}

I use a 64-character random string. Anything less feels flimsy for something with shell access.

For channel-specific auth (Telegram bots, WhatsApp), use environment variables instead of hardcoding tokens in the config:

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

Then export them in your shell or systemd service file. This keeps secrets out of version control and backups.

One thing that caught me: rotate tokens immediately if you suspect compromise. I tested this by intentionally leaking a token in a public repo (in a sandbox). Within hours, I saw unauthorized connection attempts in the logs. OpenClaw doesn't have automatic rotation, so you have to stay on top of it.

IP Allowlists

OpenClaw doesn't have a built-in IP allowlist for gateway connections. Instead, you control access through:

Bind address — Keep it on loopback (127.0.0.1) unless you absolutely need LAN/public access.
Firewall rules — Use UFW or iptables to allow only specific source IPs.
Channel allowlists — For WhatsApp/Telegram, restrict who can message the bot.

Here's my WhatsApp config:

{
  "channels": {
    "whatsapp": {
      "dmPolicy": "allowlist",
      "allowFrom": ["+1234567890"],
      "groupPolicy": "disabled"
    }
  }
}

This blocks everyone except my number. No exceptions. Groups are completely disabled because I don't want the bot in shared conversations where it could leak context or respond to someone else's prompt injection.

For the gateway itself, I added firewall rules on my VPS:

sudo ufw allow from 203.0.113.5 to any port 18789
sudo ufw enable

Replace 203.0.113.5 with your actual IP. This creates a hard network boundary. Even if someone gets the token, they can't connect from an unauthorized IP.

SSH Tunnels

The official docs recommend SSH tunnels or Tailscale for remote access instead of exposing the gateway directly. I went with SSH tunnels because it's simpler and I already have SSH set up.

From my local machine:

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

This forwards the remote gateway to my local port 18789. The gateway stays bound to loopback on the VPS, never exposed to the public internet. I can access the Control UI at http://localhost:18789 on my laptop, fully authenticated and encrypted through SSH.

The first time I set this up, I forgot to restart the gateway after changing the bind address. Spent 20 minutes debugging "connection refused" errors before I realized. Classic.

For teams or more complex setups, Tailscale is probably better. It gives you identity-based auth and works across NATs without port forwarding. But for a single-user VPS, SSH tunnels are dead simple and secure enough.

Sandboxing

This is where things got real.

Sandboxing means running the agent inside an isolated environment — usually Docker — so it can't touch your actual filesystem, credentials, or network without explicit permission. OpenClaw has built-in support for per-session or per-agent sandboxes.

I enabled sandboxing for all non-main sessions (groups, public channels):

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "non-main",
        "scope": "session",
        "workspaceAccess": "ro",
        "docker": {
          "network": "none",
          "readOnlyRoot": true,
          "capDrop": ["ALL"]
        }
      }
    }
  }
}

What this does:

mode: "non-main" — Sandbox everything except my personal DM sessions.
scope: "session" — Each conversation gets its own isolated container.
workspaceAccess: "ro" — Read-only access to the workspace. No writes, no deletions.
network: "none" — The sandbox can't make outbound network requests.

I tested this by sending a malicious prompt through a test WhatsApp number: "Delete all files in the current directory." The agent responded with an error because the sandbox blocked the rm command. Perfect.

The tradeoff: sandboxed sessions are slower. Tool calls that would normally take 1-2 seconds now take 3-4 because of container startup overhead. For public-facing use, that's acceptable. For my personal workflow, I kept the main session unsandboxed because I need full access.

I also created a read-only "summarizer" agent for web content. It can fetch and analyze pages, but it can't execute shell commands or write files. This lives in a separate gateway instance:

openclaw gateway start --config ~/.openclaw/summarizer-config.json

Multiple gateways = strong isolation. The summarizer has zero access to my credentials or personal workspace.

One thing I wish I'd known earlier: sandboxing doesn't protect against memory poisoning. If the agent stores a malicious payload in memory during a sandboxed session, it can still trigger later in an unsandboxed session. I handle this by periodically resetting memory for public-facing agents.

Monitoring

You can't secure what you don't watch.

OpenClaw has built-in logging, but the defaults aren't aggressive enough for my taste. I cranked up the detail and added sensitive data redaction:

{
  "logging": {
    "level": "info",
    "redactSensitive": "tools",
    "redactPatterns": ["sk-[a-zA-Z0-9]+", "Bearer .+", "password"]
  }
}

This redacts API keys, bearer tokens, and passwords from logs. I learned this the hard way when I found my Anthropic key in plaintext in a session log. Not fun.

Session logs live in ~/.openclaw/agents/<id>/sessions/*.jsonl. I lock down permissions:

chmod 600 ~/.openclaw/agents/*/sessions/*.jsonl

For real-time monitoring, the Control UI is invaluable. It shows:

Active sessions
Tool execution in progress
Memory access patterns
Recent errors

I keep it open in a browser tab when I'm testing new configs. It's saved me multiple times by showing unexpected tool calls that I could kill before they executed.

I also set up a simple alert system using OpenClaw's webhook support:

{
  "hooks": {
    "/alerts": {
      "token": "webhook-secret",
      "events": ["tool_error", "auth_failure", "config_change"]
    }
  }
}

This posts to a Slack channel whenever something suspicious happens. It's not sophisticated, but it's enough to catch anomalies.

The audit command is my weekly ritual:

openclaw security audit --deep

It checks for:

Exposed credentials
Overly permissive file permissions
Disabled auth mechanisms
Outdated dependencies

I run it every Sunday. Takes 30 seconds, has caught issues three times.

Here's what I'm running now after all this testing:

Dedicated low-privilege user
Token auth with 64-char random string
SSH tunnel for remote access, gateway bound to loopback
Sandboxing for all non-main sessions, read-only workspace
Aggressive logging with sensitive data redaction
Weekly audits, real-time monitoring via Control UI

Is it perfect? No. Could an advanced attacker still find a way in? Probably. But this setup survived my own red-teaming, blocks common prompt injections, and doesn't break the agent's core functionality.

The goal was never to make this bulletproof. It was to find the minimum hardening that lets me sleep at night while still getting real work done.

If you're running OpenClaw in production or connecting it to messaging apps, start here. Test it with your actual workflows. Break it intentionally. Then adjust.

For more comprehensive security guidance, I recommend reviewing Tenable's research on mitigating OpenClaw vulnerabilities and Hostinger's hardening tutorial. There's also an academic paper on agentic AI security that provides deeper theoretical context.

And if you find a config that works better, I'd genuinely love to hear about it. This is still an evolving system, and I'm learning as I go.

—

Security hardening is complex, but starting with Macaron isn't. We’ve already applied these battle-tested configs to our infrastructure, so you can deploy confidently without touching a single SSH tunnel. Start your free trial today.