# Securing OpenClaw: A Production-Ready Deployment Guide
*March 15, 2026*
OpenClaw is powerful—an AI agent with access to your filesystem, shell commands, APIs, and messaging channels. That power comes with responsibility. After deploying OpenClaw in production environments and reviewing the official threat model, here’s what you need to know about securing your deployment.
## The Attack Surface: What You’re Actually Protecting
OpenClaw isn’t just another app. It’s an AI agent that:
– Reads and writes files on your system
– Executes shell commands
– Connects to external APIs
– Receives messages from potentially untrusted sources
– Has access to your credentials and secrets
The threat model identifies **four critical attack vectors**:
1. **Prompt Injection**: Malicious messages designed to manipulate the AI into performing unauthorized actions
2. **Memory Poisoning**: Compromised files (SOUL.md, MEMORY.md) that influence agent behavior
3. **Skill-Based Exploits**: Malicious or vulnerable skills from ClawHub
4. **Network Exposure**: Unauthenticated access to the gateway
Let’s tackle each one.
## Network Isolation: Your First Line of Defense
**The Problem**: A publicly exposed OpenClaw gateway is an open door to attackers.
**The Fix**:
### Bind to Localhost Only
“`json
{
“gateway”: {
“bind”: “loopback”
}
}
“`
This ensures OpenClaw only accepts connections from `127.0.0.1`, not from external networks. **Never bind to `0.0.0.0` in production.**
### Firewall Configuration
Close unnecessary ports and audit what’s actually listening:
“`bash
# Check what’s listening
sudo ss -tlnp
# UFW example (Ubuntu/Debian)
sudo ufw default deny incoming
sudo ufw allow 22/tcp # SSH only
sudo ufw enable
“`
### Remote Access? Use VPN or Tailscale
If you need remote access:
– **Option 1**: VPN (WireGuard, OpenVPN)
– **Option 2**: Tailscale mesh network
– **Option 3**: Reverse proxy with strong authentication (Caddy, NGINX with OAuth)
**Never** expose port 18789 directly to the internet.
## Authentication & Access Controls
### Device Pairing
OpenClaw uses a 30-second device pairing grace period. This is convenient for setup but can be exploited. After initial pairing:
1. **Review paired devices regularly**:
“`bash
openclaw devices list
“`
2. **Revoke suspicious devices**:
“`bash
openclaw devices revoke
“`
### Channel Allowlists
For messaging channels (Telegram, Discord, WhatsApp), use allowlists:
“`json
{
“channels”: {
“telegram”: {
“allowFrom”: [“@yourusername”],
“requireMention”: true
}
}
}
“`
This prevents random people from messaging your agent.
### SSH Hardening
If OpenClaw runs on a VPS or remote server:
“`bash
# Disable password auth, use keys only
echo “PasswordAuthentication no” | sudo tee -a /etc/ssh/sshd_config
echo “PubkeyAuthentication yes” | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart sshd
# Change default SSH port (security through obscurity, but reduces bot noise)
echo “Port 2222” | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart sshd
“`
## Defending Against Prompt Injection
Prompt injection is the AI equivalent of SQL injection. Attackers craft messages to manipulate the model into performing unauthorized actions.
### Use Claude Opus for Production
Research shows **Claude Opus 4.5 has a 4.8% breach rate** against multi-turn prompt injection attacks—significantly better than other models. If you’re handling sensitive data, the model choice matters.
“`json
{
“model”: “anthropic/claude-opus-4-5”
}
“`
### Enable Tool Allowlists
Don’t give every session access to every tool. Use the principle of least privilege:
“`json
{
“tools”: {
“allow”: [“read”, “write”, “edit”],
“deny”: [“exec”, “browser”, “web_fetch”, “web_search”]
}
}
“`
High-risk tools like `exec` and `browser` should be **opt-in only** for trusted sessions.
### Action Sequence Analysis
Look for suspicious multi-step attack patterns:
– Read sensitive file → Summarize → Compress → Upload to external URL
– Email search → Extract data → Send to attacker-controlled endpoint
This requires monitoring and logging (more on that below).
## Secrets Management: Keep Credentials Out of Context
**Never** store API keys or credentials in files the agent can read.
### Use Environment Variables
“`bash
export ANTHROPIC_API_KEY=”sk-ant-…”
export OPENAI_API_KEY=”sk-…”
“`
### For Production: Use a Vault
– **AWS Secrets Manager**
– **HashiCorp Vault**
– **Azure Key Vault**
Inject secrets at runtime with short-lived tokens, not persistent files.
### Rotate Regularly
Set up automatic rotation for:
– API keys (monthly minimum)
– Gateway tokens (after major changes)
– SSH keys (annually)
## Docker & Filesystem Hardening
### Run as Non-Root User
The official Docker image runs as user `node` (UID 1000), not root. Keep it that way.
### Read-Only Filesystem
“`yaml
# docker-compose.yml
services:
openclaw:
read_only: true
tmpfs:
– /tmp
– /var/tmp
“`
This prevents malicious skills from persisting changes to the container filesystem.
### Minimal Mounts
Don’t mount your entire home directory. Be surgical:
“`yaml
volumes:
– ~/.openclaw/config:/home/node/.openclaw:ro # Read-only config
– ~/.openclaw/workspace:/home/node/workspace:rw # Workspace only
“`
**Never mount** `~/.ssh` or `~/.aws` unless absolutely necessary.
### Sandbox Mode (Recommended)
Enable OpenClaw’s Docker sandbox for non-main sessions:
“`json
{
“agents”: {
“defaults”: {
“sandbox”: {
“mode”: “non-main”,
“scope”: “agent”,
“workspaceAccess”: “none”,
“docker”: {
“image”: “openclaw-sandbox:bookworm-slim”,
“network”: “none”,
“user”: “1000:1000”,
“readOnlyRoot”: true,
“memory”: “1g”,
“cpus”: 1
}
}
}
}
}
“`
This isolates tool execution in a separate container with no network access and limited resources.
## Skill Security: ClawHub Is Untrusted
Skills from ClawHub are **user-submitted and moderated**, but not formally reviewed for security. Treat them like browser extensions—useful but risky.
### Audit Before Installing
1. Read `SKILL.md` to understand what it does
2. Review referenced scripts and binaries
3. Check permissions and tool usage
### Disable Auto-Updates
“`json
{
“skills”: {
“autoUpdate”: false
}
}
“`
Review updates manually before applying.
### Verify with VirusTotal (Future)
The threat model recommends integrating VirusTotal Code Insight for behavioral analysis of skills. Watch for this feature in future releases.
## Monitoring & Logging
Security without visibility is security theater.
### Enable Comprehensive Logging
“`json
{
“logging”: {
“level”: “debug”,
“destination”: “file”,
“logPayloads”: true,
“logHeaders”: true
}
}
“`
Send logs to a SIEM (Splunk, ELK Stack, Microsoft Sentinel) for correlation and alerting.
### What to Monitor
– **Abnormal tool usage**: `exec` calls in the middle of the night
– **State file modifications**: Changes to SOUL.md, MEMORY.md, config files
– **Failed authentication attempts**: Repeated device pairing failures
– **Outbound network anomalies**: Connections to unusual IPs or domains
### Set Up Alerts
Example: Alert on any `exec` call that contains `curl`, `wget`, `nc`, or `ssh`:
“`bash
# In your SIEM or log aggregator
grep “exec.*curl\|wget\|nc\|ssh” openclaw.log | mail -s “OpenClaw Alert” ops@yourcompany.com
“`
## Egress Filtering
Limit where OpenClaw can connect:
### Deny by Default
“`bash
# iptables example (requires root, test carefully)
iptables -A OUTPUT -m owner –uid-owner 1000 -j DROP
iptables -I OUTPUT -m owner –uid-owner 1000 -d api.anthropic.com -j ACCEPT
iptables -I OUTPUT -m owner –uid-owner 1000 -d api.openai.com -j ACCEPT
“`
This blocks all outbound connections for UID 1000 (the `node` user) except to allowed domains.
### Block Cloud Metadata Services
“`bash
# Prevent SSRF to AWS metadata service
iptables -A OUTPUT -d 169.254.169.254 -j DROP
# GCP metadata
iptables -A OUTPUT -d metadata.google.internal -j DROP
“`
## Production Deployment Checklist
Before going live:
– [ ] Gateway bound to `127.0.0.1` (loopback)
– [ ] Firewall enabled, unnecessary ports closed
– [ ] SSH hardened (keys only, non-standard port, IP restrictions)
– [ ] Tool allowlist configured, high-risk tools denied
– [ ] Secrets in vault or environment variables, not files
– [ ] Docker sandbox enabled for non-main sessions
– [ ] Read-only container filesystem with minimal mounts
– [ ] Channel allowlists configured (Telegram, Discord, WhatsApp)
– [ ] Claude Opus 4.5 for production workloads
– [ ] Logging enabled at debug level, sent to SIEM
– [ ] Monitoring and alerting configured
– [ ] Skills audited, auto-update disabled
– [ ] Egress filtering in place
– [ ] Incident response playbook documented
## The Bottom Line
OpenClaw’s power comes from its access. Securing it means:
1. **Minimize exposure**: Localhost-only, VPN for remote access
2. **Least privilege**: Allowlists for tools, channels, and skills
3. **Defense in depth**: Network isolation + sandboxing + monitoring
4. **Visibility**: Comprehensive logging and alerting
If you’re deploying OpenClaw for anything beyond personal experimentation, treat it like you would a production database or API gateway. The threat model is real, but with proper hardening, OpenClaw can be both powerful and secure.
—
*Ben Hornedo is the founder of Uptown4, helping businesses deploy AI solutions securely and pragmatically. Need help hardening your OpenClaw deployment? Reach out: ben@uptown4.com*