The Complete OpenClaw Security Checklist (9 Points)

63% of self-hosted OpenClaw installs have at least one critical misconfiguration. Most of them are the same nine issues, in the same order.

This checklist covers every one of them.

1. API key exposure

The most common issue: API keys stored in plain text in config files that are version-controlled or accessible via the filesystem. Anyone with SSH access to your VPS — or anyone who gets it — has your OpenAI, Anthropic, and tool API keys.

Fix: Store all API keys in environment variables, never in committed config files. Use a .env file locally and inject via your VPS provider's secrets management for production.

2. No network isolation between agents

By default, OpenClaw agents run in the same network namespace and can communicate with each other and the host filesystem directly. A compromised or misbehaving agent can read data from other agents or write to the host.

Fix: Run each agent in its own Docker container with explicit network policies. Agents should communicate only via defined channels, not via shared filesystem access.

3. Unrestricted tool permissions

OpenClaw agents can be granted access to tools — email, calendar, CRM, file system, browser. A common mistake is granting all tools to all agents "to be safe." The COO doesn't need file system access. The CCO doesn't need database write permissions.

Fix: Apply least-privilege per agent. Each agent gets only the tools it explicitly needs. Document every permission grant.

4. No rate limiting on the orchestrator

Without rate limiting, a runaway task loop (or a prompt injection attack) can exhaust your API budget in minutes. We've seen clients arrive with $400+ bills from a single overnight incident.

Fix: Set hard token budgets per agent per hour. Configure the orchestrator to halt and alert via Telegram if any agent exceeds its budget. OpenClaw supports this natively — it needs to be configured explicitly.

5. Telegram bot token exposed

Most OpenClaw deployments use Telegram for briefings and alerts. The bot token is frequently left in a config file or hardcoded in a skill. Anyone with the token can read your agent's messages and send commands.

Fix: Store the bot token as an environment variable. Restrict the bot to your specific chat ID. Consider IP allowlisting on the VPS if your connection is static.

6. No skill validation before installation

ClawHub (the skill marketplace) is community-contributed. Installing an unreviewed skill is the equivalent of running a random script from the internet as root. Malicious skills can exfiltrate data, add persistent backdoors, or silently modify agent behavior.

Fix: Review every skill before installation. Check the source repository, look at recent commits, verify the author. Never install skills from unverified sources.

7. VPS exposed on default ports

A freshly provisioned VPS with OpenClaw running will often have ports 22 (SSH), 3000 (OpenClaw dashboard), and others open to the public internet by default. The dashboard especially should never be public-facing.

Fix: Configure UFW or your provider's firewall to block all ports except 443 (HTTPS) and 22 (SSH, restricted to your IP). Route the dashboard behind a VPN or SSH tunnel. Never expose it to the public internet.

8. No backup of agent memory and configuration

Agent memory, skill configurations, and workflow definitions represent significant setup work. A VPS failure with no backup means starting from scratch.

Fix: Configure daily automated backups of the OpenClaw workspace directory to a separate storage location (S3, Backblaze B2, or similar). Test restoration at least once.

9. No alerting on agent failures

Silent failures are the most dangerous kind. An agent that stops running due to an API error or context overflow won't announce itself — it just stops working. Clients often discover this weeks later.

Fix: Configure the COO agent to run a health check on all sub-agents every 15 minutes and send a Telegram alert if any agent fails to respond. Set up uptime monitoring on your VPS.

All nine of these are handled as standard practice in every Clawesome Labs deployment. They're not add-ons — they're the baseline.