OpenClaw Security: Must-Have Fixes Before You Go Live

Running OpenClaw on a VPS or local machine is powerful. But the default setup gets you functional, not secure. Most people connect their API key, set up a Discord channel, and call it done.

That's the wrong call.

An AI agent with unconfigured access controls, exposed credentials, and no rate limits is a real risk — not a theoretical one. Here's what to fix before you go live.

---

1. Never Store API Keys in Plain Text

The most common mistake. API keys sitting in .env files, shell profiles, or chat history are a credential leak waiting to happen.

What to do instead:

• Use a secrets manager or templated credential storage — OpenClaw supports config files with restricted permissions
• Set file permissions on any credential file: chmod 600 ~/.openclaw/config.json
• Never paste API keys into Discord, Telegram, or any channel the agent monitors — the agent reads those channels
• Rotate keys immediately if you suspect exposure

# Lock down your config file
chmod 600 ~/.openclaw/config.json
chown $USER:$USER ~/.openclaw/config.json

---

2. VNC Must Not Be Exposed to the Internet

If you set up OpenClaw with a GUI and VNC (required for the browser relay), a common mistake is leaving VNC bound to 0.0.0.0 — meaning anyone on the internet can attempt to connect.

VNC has no brute force protection by default. Weak passwords get cracked fast.

Fix: bind VNC to localhost only, tunnel over SSH

# In your VNC server config (e.g., ~/.vnc/xstartup or systemd unit)
# Bind to localhost only
vncserver -localhost yes

# Then access via SSH tunnel from your machine
ssh -L 5901:127.0.0.1:5901 user@your-server-ip
# Connect your VNC client to localhost:5901

Or better — use Cloudflare Tunnel to expose VNC access through an authenticated tunnel instead of raw port exposure.

---

3. Use Cloudflare Tunnel Instead of Open Ports

If you need to access your OpenClaw server remotely — VNC, a web UI, or any management interface — do not open ports directly.

Use Cloudflare Tunnel (cloudflared) instead:

# Install cloudflared
curl -L https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg > /dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared focal main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install cloudflared

# Authenticate and create a tunnel
cloudflared tunnel login
cloudflared tunnel create openclaw-tunnel

This gives you a stable, authenticated HTTPS endpoint without a single open port. No exposed attack surface.

---

4. Lock Down Channel Access

OpenClaw responds to messages in whichever channels you configure. If you don't restrict who can trigger it, anyone in that Discord server (or anyone who gets your Telegram bot token) can send commands to your agent.

Minimum controls to configure:

• Set an explicit authorized senders allowlist in your OpenClaw config — only those user IDs can issue commands
• Never use a public channel as your primary agent channel
• Prefer a private Discord channel with restricted role access
• For Telegram, use a private bot with allowed_users set

---

5. Rate Limit Agent Actions

An agent without rate limits can run up significant API costs in minutes if it gets stuck in a loop, receives a flood of messages, or hits a runaway workflow.

What to configure:

• Set maxTokensPerSession and maxConcurrentSessions in your OpenClaw config
• Configure your AI provider's hard spend limits independently (Anthropic, OpenAI both support this)
• Set up billing alerts at your provider — these fire before limits are hit

This is both a security control and a cost control. A compromised or looping agent can drain hundreds of dollars of API credits in an afternoon.

---

6. Isolate Each Agent's Workspace

If you run multiple agents — different projects, different clients, different personas — don't let them share a workspace, memory files, or credentials.

Proper isolation means:

• Separate workspace directories per agent
• Separate config files with only the credentials that agent needs
• Separate channel assignments — agents shouldn't read each other's channels
• Separate SOUL.md and MEMORY.md per project so context doesn't bleed between agents

# Example structure
~/.openclaw/
  agents/
    quinji-website/
      config.json   (chmod 600)
      SOUL.md
      MEMORY.md
    client-project/
      config.json   (chmod 600)
      SOUL.md
      MEMORY.md

---

7. SSH Hardening on the Host Server

OpenClaw runs on a server. If that server's SSH is weak, the agent security doesn't matter — the whole machine is compromised.

Minimum SSH hardening:

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers youruser
Port 2222   # change default port
MaxAuthTries 3

# Restart SSH after changes
sudo systemctl restart sshd

# Verify you can still connect before closing your current session

Also: set up fail2ban to block repeated failed SSH attempts.

---

8. What Gets Logged — and What Doesn't

By default, your agent processes messages, takes actions, and potentially handles sensitive information. Know what's being logged:

• OpenClaw session logs — check where these are stored and who can read them
• AI provider logs — Anthropic and OpenAI log requests (with varying retention). Review their data handling policies for your use case
• Channel message history — Discord and Telegram retain messages. Don't put secrets in agent channels
• MEMORY.md — this file accumulates context over time. Review it periodically for sensitive data that shouldn't persist

---

Quick Checklist

Before you call your OpenClaw setup production-ready:

• chmod 600 on all config and credential files
• VNC bound to localhost only — no direct port exposure
• Cloudflare Tunnel set up for remote access
• Authorized senders allowlist configured
• API spend limits set at the provider level
• Separate workspace per agent
• SSH hardened on the host (no root, no passwords, fail2ban active)
• MEMORY.md reviewed for sensitive data

---

Security is not what you add after setup. It's what you build into the setup from the start. If any of these are missing on your current deployment, fix them before the next time the agent handles something sensitive.

Need a done-for-you secure OpenClaw setup? See the setup packages or book a call.