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.
Who This Guide Is For
This checklist is for anyone running OpenClaw in a business or personal-productivity context who wants to move beyond the default "just get it working" setup. Whether you installed OpenClaw on a Mac Mini, a VPS, or through a one-click Docker template, these steps apply.
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. If that machine contains your personal documents, banking credentials, SSH keys, or password manager vaults, a single prompt injection could expose everything.
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
Never run OpenClaw as the root user. 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
By default, OpenClaw's gateway listener binds to 0.0.0.0, meaning it accepts connections from any IP address. This is the single biggest reason 135,000+ instances were found exposed online.
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
The gateway token is the single authentication credential that protects your OpenClaw instance. Treat it like a root password.
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: Configure Firewall Rules
Restrict inbound traffic to only the ports you actually need.
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.
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
In our deployments, we 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 security audit command that checks for common misconfigurations.
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 multiple DM access modes: open, allowlist, pairing, and disabled. The "open" mode lets anyone who knows your bot's number or handle send it commands.
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.
Step 9: Enable Execution Approval for Dangerous Tools
OpenClaw can run shell commands, delete files, push to Git, and perform other irreversible actions. Without approval gates, a hallucination or prompt injection can cause real damage.
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 skill system allows third-party plugins. Some community skills have been found to contain malicious code.
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. These files should not be world-readable.
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
Your OpenClaw bot accumulates personal context — memory files, conversation history, access tokens, and workflow patterns. Sharing it with others or adding it to group chats exposes all of this.
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
Security is not a one-time setup. We recommend:
- Weekly: Run
openclaw security auditto 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
From our last 30+ remote OpenClaw deployments:
| 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.
Book a free 15 minute call 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.*