OpenClaw Security Hardening Checklist: 12 Steps to a...

Originally published on Remote OpenClaw.

Over 135,000 OpenClaw instances were recently found exposed to the public internet with no authentication. This checklist covers the exact 12-step security hardening process we follow when deploying OpenClaw (formerly ClawdBot / MoltBot) for founders and executive teams. In our last 30+ remote deployments, zero clients have experienced a security incident using this process.

OpenClaw is powerful — it can access your files, run shell commands, browse the web, and send messages on your behalf. That power requires deliberate security boundaries. The official docs say it best: "There is no perfectly secure setup." But there is a responsible one.

This guide is based on real production deployments, not theoretical advice. Every step comes from our hands-on experience deploying OpenClaw remotely for teams worldwide.

Marketplace

Free skills and AI personas for OpenClaw — browse the marketplace.

Browse the Marketplace →

Join the Community

Join 1k+ OpenClaw operators sharing deployment guides, security configs, and workflow automations.

Join the Community →

Who Is This OpenClaw Hardening Guide For?

Remote OpenClaw's security hardening checklist applies to anyone running OpenClaw in a business or personal-productivity context on a Mac Mini, VPS, or one-click Docker template who wants production-grade security.

If you previously used ClawdBot or MoltBot (the earlier names for this project), the same security principles apply — OpenClaw is the same codebase, renamed.

Step 1: Never Run OpenClaw on Your Primary Device

OpenClaw has full filesystem and shell access on whatever machine it runs on, meaning a single prompt injection on your personal device could expose banking credentials, SSH keys, and password manager vaults.

What to do: Install OpenClaw on a dedicated device — a Mac Mini, a Raspberry Pi, or a cloud VPS. In our deployments, roughly 60% of clients use a cloud VPS (DigitalOcean, Hetzner, or Hostinger), 30% use a dedicated Mac Mini, and 10% use an existing server they already manage.

Why it matters: The "find ~" incident (documented in OpenClaw's own security page) showed how a simple command could traverse an entire home directory. On a dedicated device, the blast radius is limited to OpenClaw data only.

Step 2: Create a Dedicated Non-Root User

OpenClaw should never run as root because root access means a compromised bot can modify system files, install packages, and escalate privileges without restriction.

What to do:

sudo adduser openclaw
sudo usermod -aG sudo openclaw
su - openclaw

Then install and run OpenClaw under this user account. In our deployments, we also remove sudo access from the openclaw user after initial setup is complete, leaving it with standard user permissions only.

Step 3: Bind the Gateway to Localhost

OpenClaw's default gateway binding to 0.0.0.0 is the single biggest reason 135,000+ instances were found exposed online, because it accepts connections from any IP address on the internet.

What to do: In your openclaw.json configuration, change the gateway bind address:

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

If you need remote access, use Tailscale or an SSH tunnel — never expose the gateway port directly to the internet.

Step 4: Set a Strong Gateway Token

OpenClaw's gateway token is the single authentication credential protecting your entire instance, and Remote OpenClaw recommends generating a 64-character random hex string using openssl.

What to do: Generate a strong, random token:

openssl rand -hex 32

Set this as your OPENCLAW_GATEWAY_TOKEN environment variable. Never use the auto-generated default in production without verifying its strength.

Step 5: How Should You Configure OpenClaw Firewall Rules?

OpenClaw firewall configuration should deny all incoming traffic by default and only allow SSH on port 22, never exposing the gateway port 18789 to the public internet.

What to do:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw limit 22/tcp
sudo ufw enable

Do not open port 18789 (the default gateway port) to the public internet. If you need remote access to the dashboard, use an SSH tunnel:

ssh -N -L 18789:127.0.0.1:18789 user@your-server-ip

Then access the dashboard at http://127.0.0.1:18789 on your local machine.

Step 6: Use Dedicated Credentials for All Connected Services

OpenClaw should never have access to your primary email, calendar, or cloud storage accounts directly, and Remote OpenClaw sets up a dedicated Google Workspace account with minimal OAuth scopes for every client.

What to do: Create a dedicated Gmail (or other email) account specifically for your OpenClaw instance. Share only the specific calendars, documents, and spreadsheets it needs — with the minimum permission level required.

For example:

• Calendar: Share with "view only" access
• Google Docs: Share individual documents with edit access (not entire Drive)
• Google Sheets: Share specific sheets, not folders

Best practice: set up a dedicated Google Workspace account for the bot and configure OAuth scopes that limit access to only the APIs needed.

Step 7: Run the Built-In Security Audit

OpenClaw ships with a built-in security audit command that checks for exposed gateway ports, overly permissive DM policies, missing authentication, and file permission issues.

What to do:

openclaw security audit --deep

This checks for exposed gateway ports, overly permissive DM policies, missing authentication, and file permission issues. For automated fixes:

openclaw security audit --fix

The --fix flag tightens group policies to allowlist mode, re-enables sensitive log redaction, and locks down file permissions on the .openclaw directory.

We run this audit on every deployment, and again 48 hours after the client has configured their workflows, to catch any settings that were loosened during setup.

Step 8: Set DM Policy to Pairing Mode

OpenClaw supports four DM access modes (open, allowlist, pairing, disabled), and Remote OpenClaw recommends pairing mode because it requires explicit approval before any new contact can interact with your bot.

What to do: Set DM policy to "pairing" (the recommended default):

{
 "dm": {
 "policy": "pairing"
 }
}

Pairing mode requires you to explicitly approve each new contact before they can interact with your bot. This prevents unauthorized users from sending commands, even if they discover your bot's WhatsApp number or Telegram handle.

Marketplace

Free skills and AI personas for OpenClaw — browse the marketplace.

Browse the Marketplace →

Key numbers to know

Step 9: Enable Execution Approval for Dangerous Tools

OpenClaw execution approval gates force the agent to ask for your confirmation before running shell commands, deleting files, or pushing to Git, adding roughly 3-5 seconds per action but preventing catastrophic mistakes.

What to do: Enable the exec_approval flag for high-risk tools:

{
 "tools": {
 "terminal": { "exec_approval": true },
 "filesystem_delete": { "exec_approval": true },
 "git_push": { "exec_approval": true }
 }
}

This forces OpenClaw to ask for your confirmation before executing these commands. In our experience, this adds roughly 3-5 seconds per action but prevents catastrophic mistakes.

Step 10: Vet All Community Skills Before Installing

OpenClaw's community skill system allows third-party plugins, and security audits have confirmed that some contain malicious code designed to exfiltrate data or create backdoors.

What to do: Before installing any community skill, scan it:

# Use Cisco's open-source skill scanner
npx @cisco-ai-defense/skill-scanner scan ./skill-folder

We maintain an internal list of vetted skills for our clients. For any skill not on that list, we review the source code manually before installation. If a skill requires network access, filesystem writes, or shell execution, treat it with extra scrutiny.

Step 11: Lock Down File Permissions

OpenClaw stores configuration, credentials, and session data in the ~/.openclaw directory, which must be restricted to chmod 700 with config and credential files set to chmod 600.

What to do:

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/config/*.json
chmod 600 ~/.openclaw/credentials/*.json

This ensures only the OpenClaw user can read configuration and credential files.

Step 12: Never Share Your Bot or Add It to Group Chats

OpenClaw bots accumulate personal context including memory files, conversation history, access tokens, and workflow patterns, all of which become exposed when the bot is shared or added to group chats.

What to do: Keep your bot as a 1:1 private conversation. If your team needs multiple people to interact with OpenClaw, set up separate agent instances with individual access profiles using OpenClaw's multi-agent configuration.

There have been documented cases of shared bots leaking confidential information to unintended recipients. One well-known incident involved a vibe-coded app called MoBebook that started exposing private data after being added to a public context.

Post-Deployment Security Maintenance

OpenClaw security is not a one-time setup, and Remote OpenClaw recommends weekly audits, monthly key rotations, post-update re-audits, and quarterly access reviews.

• Weekly: Run openclaw security audit to catch configuration drift
• Monthly: Review and rotate API keys for connected services
• After every update: Re-run the security audit, as updates can reset configuration defaults
• Quarterly: Review which files and services your bot has access to and revoke anything no longer needed

Our Deployment Stats

Remote OpenClaw has completed 30+ production deployments with zero post-deployment security incidents, averaging 45 minutes per setup with WhatsApp as the most common channel at 70%.

Metric

Value

Average setup + hardening time

45 minutes

Security incidents post-deployment

0

Clients using VPS

~60%

Clients using Mac Mini

~30%

Most common channel

WhatsApp (70%)

Most common LLM

Claude Opus (55%)

Average monthly API cost per client

$15-40

FAQ

Is OpenClaw safe to use in 2026?

OpenClaw is safe when configured correctly. The 135,000 exposed instances were caused by users leaving default settings unchanged — not by a flaw in OpenClaw itself. Following this 12-step hardening checklist brings your deployment to production-grade security.

What is the difference between OpenClaw, ClawdBot, and MoltBot?

They are the same project. It was originally called ClawdBot (November 2025), renamed to MoltBot (January 27, 2026) after a trademark complaint from Anthropic, and renamed again to OpenClaw (January 30, 2026). The codebase and functionality are identical.

Should I run OpenClaw on a Mac Mini or a VPS?

Both work well. A Mac Mini gives you native Apple integrations (iMessage, Notes, Reminders) and runs 24/7 with low power consumption. A VPS is cheaper ($5-20/month), easier to isolate, and accessible from anywhere. For most business use cases, we recommend a VPS.

How much does it cost to run OpenClaw?

The software is free and open-source. Your costs come from the LLM API usage (typically $15-40/month for moderate use with Claude or GPT) and hosting ($5-20/month for a VPS, or the one-time cost of a Mac Mini).

Can I use OpenClaw with a team?

Yes. OpenClaw supports multi-agent configurations where each team member gets their own agent instance with separate access profiles and permissions. This is more secure than sharing a single bot.

Need Help Hardening Your OpenClaw Deployment?

We handle the full security hardening process remotely — from initial setup through firewall configuration, credential isolation, and the complete 12-step checklist above. Most teams are live and hardened within a single session.

Browse the Marketplace to discuss your setup →

*Last updated: February 2026. This guide follows the OpenClaw production security blueprint and is maintained by the Remote OpenClaw team at remoteopenclaw.com.*