Running an autonomous AI agent with system access demands serious security. This guide provides production-ready Docker configs, permission lockdown templates, VPS hardening scripts, and a 12-point security checklist. Because the question isn't whether you'll encounter a malicious skill — it's whether you'll be prepared when you do.
In early 2026, multiple malicious OpenClaw skills were discovered in the community registry. These skills exfiltrated environment variables (including API keys, database credentials, and cloud provider tokens) to external servers. The damage was significant for affected users. This wasn't a flaw in OpenClaw's core — it was a consequence of the trust model. OpenClaw's SKILL.md manifest declares permissions, but the runtime doesn't enforce them. A skill that says 'read-only file access' can still write files, make network requests, and execute system commands. The good news: OpenClaw is still safe for production use — if you implement proper security measures. This guide covers everything you need. The alternative: If enforced sandboxing is a hard requirement, NanoClaw provides Docker-based isolation for every skill with enforced permission boundaries. See our comparison for details.
The single most important security measure: never run OpenClaw directly on your host machine in production. Run OpenClaw inside a Docker container with restricted capabilities: Essential Docker flags: - `--network=none` (default) or `--network=openclaw-net` (restricted egress) - `--read-only` for the root filesystem - `--tmpfs /tmp:rw,noexec,nosuid` for temporary files - `--cap-drop ALL` to remove all Linux capabilities - `--security-opt no-new-privileges:true` to prevent privilege escalation - `-v /host/data:/data:ro` for read-only data mounts - `-v /host/output:/output:rw` for controlled write access Network isolation: Create a custom Docker network that only allows outbound connections to LLM API endpoints (api.openai.com, api.anthropic.com, etc.). Block all other egress. This prevents data exfiltration even if a skill is compromised. Volume mounts: Never mount your home directory, SSH keys, cloud credentials, or environment files. Mount only the specific directories OpenClaw needs, with the minimum required permissions. For container-focused deployment, the Docker Captain skill can help generate and validate your configuration.
Before installing any skill, run through this checklist: 1. Check verification status: Our skills directory shows three statuses: - ✅ Verified — Passed security audit, reviewed by the ClawSkills team - 🔵 Community — Basic automated scanning passed - ⚠️ Unreviewed — Use at your own risk 2. Read the SKILL.md: Does the skill request more permissions than it needs? A Markdown formatter shouldn't need network access. A search skill shouldn't need filesystem write access. 3. Check the source code: Use the Code Reviewer skill to scan the skill's source. Look for: - Outbound HTTP calls to unexpected domains - Environment variable reads (`process.env`) - Dynamic code execution (`eval`, `Function`, child_process) - Obfuscated code or minified modules 4. Check the author: Who published this skill? Do they have other skills with good reviews? Are they active in the community? 5. Check the update history: When was the skill last updated? Abandoned skills may have unpatched vulnerabilities. 6. Test in isolation: Install the skill in a sandboxed OpenClaw instance first. Monitor network traffic and file system changes before using it with real data.
If you're running OpenClaw on a VPS, the VPS itself needs hardening: SSH Security: - Disable password authentication; use key-based auth only - Change the default SSH port - Use fail2ban to block brute-force attempts - Consider SSH key rotation on a 90-day schedule Firewall Configuration: - Allow inbound: SSH (your IP only), HTTPS (if serving a web interface) - Allow outbound: LLM API endpoints, package registries (npm, pip) - Block everything else - Use UFW or iptables with default-deny policies OS Hardening: - Run OpenClaw as a non-root user with minimal permissions - Enable automatic security updates - Use AppArmor or SELinux profiles - Mount /tmp and /var/tmp with noexec Monitoring: - Set up auditd for filesystem monitoring - Monitor network connections with netstat/ss - Alert on unexpected outbound connections - Log all OpenClaw skill installations and executions Backup & Recovery: - Daily encrypted backups of OpenClaw configuration and memory - Tested recovery procedure - Separate backup credentials from production credentials For automated VPS setup, use the Cloud Deployer skill with our security templates.
Never expose sensitive environment variables to OpenClaw directly. Instead: Use a secrets manager: Store API keys, database credentials, and tokens in a secrets manager (Vault, AWS Secrets Manager, Doppler). OpenClaw should read secrets at runtime from the manager, not from `.env` files. Scope API keys: Create dedicated API keys for OpenClaw with the minimum permissions needed. Don't reuse your personal or admin API keys. Rotate regularly: Set up automatic rotation for all keys used by OpenClaw. If a key is compromised, the window of exposure is limited. Monitor usage: Set up spending alerts and anomaly detection on all API keys. A compromised skill that starts making unexpected API calls should trigger an alert before significant damage occurs. Environment isolation: Use separate OpenClaw instances for different sensitivity levels. Don't use the same instance for casual experimentation and production workloads that access sensitive data. For evaluating skills' permission requirements before installation, browse our skills directory where each skill's permission requirements are documented.
Use this checklist before deploying OpenClaw to production: Infrastructure: 1. ☐ OpenClaw runs inside Docker with `--cap-drop ALL` and `--read-only` 2. ☐ Network egress limited to LLM API endpoints 3. ☐ No home directory, SSH keys, or cloud credentials mounted 4. ☐ VPS firewall configured with default-deny 5. ☐ SSH is key-only, non-default port, with fail2ban Skills: 6. ☐ Only verified skills installed for production workloads 7. ☐ Every skill's SKILL.md reviewed for excessive permissions 8. ☐ Source code scanned with Code Reviewer 9. ☐ Skills tested in sandbox before production deployment Secrets & Monitoring: 10. ☐ API keys scoped to minimum permissions and rotated quarterly 11. ☐ No sensitive env vars exposed directly to OpenClaw 12. ☐ Network monitoring active; alerts on unexpected outbound connections Score: - 12/12: Production-ready - 9-11: Acceptable for internal tools - 6-8: Needs improvement before handling sensitive data - Below 6: Do not use for anything beyond local experimentation For the most secure alternative, consider migrating production workloads to NanoClaw, which enforces these boundaries at the container level.
Is OpenClaw safe to use? Yes, with proper security measures. The malicious skills discovered in early 2026 affected users who installed unreviewed community skills without Docker isolation. Users following security best practices were not affected. Are verified skills guaranteed safe? Verified skills have passed our security review, which includes static analysis, dynamic testing, and manual code review. No review process is 100% foolproof, but verified skills represent the lowest risk. Check our directory for verification status. Should I run OpenClaw as root? Never. Create a dedicated non-root user with only the permissions OpenClaw needs. Running as root means a compromised skill has full system access. Can a skill access my API keys? If your API keys are in environment variables accessible to the OpenClaw process, yes. That's why secrets management is critical — use a dedicated secrets manager instead of .env files. Is NanoClaw more secure than OpenClaw? For skill isolation, yes. NanoClaw's Docker-per-skill model enforces permission boundaries that OpenClaw's shared-process model cannot. See our detailed comparison. For overall deployment security, both require proper VPS hardening and secrets management. What about MCP security? MCP servers run as separate processes, providing natural process-level isolation. However, MCP doesn't enforce permission boundaries — a malicious MCP server can still exfiltrate data. The same vetting process applies. See our MCP guide.