OpenClaw Security Hardening: The Complete Guide for 2026

The default OpenClaw configuration is designed for ease of use, not security. This guide covers every layer you need to harden, whether you do it yourself or let ClawTrust handle it.

OpenClaw is a powerful AI agent framework. It connects to every major messaging platform, browses the web, executes code, and handles multi-step workflows that would take a human hours. Over 150,000 GitHub stars. Tens of thousands of active deployments. It is the engine behind a new generation of AI employees.

It is also, by default, wide open.

The Problem: 42,665 Exposed Instances

Security researchers scanning the internet found 42,665 publicly accessible OpenClaw instances running with default configurations. The breakdown is alarming:

• 93.4% had authentication bypasses. Gateway auth set to "none" or misconfigured token validation. Anyone with the IP address could send commands to the agent.
• The gateway was bound to all network interfaces. Meaning the OpenClaw API was reachable from the public internet, not just the local machine.
• No encryption at rest. Agent state, conversation logs, and cached credentials sitting on unencrypted disks.
• No firewall rules. Port 18789 open to all inbound traffic.

Then came the CVEs.

CVE-2026-25253 (CVSS 8.8) enabled one-click remote code execution through a malicious WebSocket link. A user clicking a single crafted URL could give an attacker full control of the OpenClaw instance. It was patched in v2026.1.29, but self-hosted instances don't auto-update. Thousands remained vulnerable for weeks.

On top of that, Snyk researchers uncovered the ClawHavoc campaign: 341 malicious skills published to ClawHub, 335 from a single coordinated attacker. A separate study found that 7.1% of all skills on ClawHub leak credentials including API keys, passwords, and credit card numbers in plaintext.

The open-source project is actively improving security. VirusTotal now scans published skills. The community responds quickly to CVE disclosures. But the core issue remains: the default configuration prioritizes convenience over security, and most operators never change the defaults.

This guide walks through seven hardening layers that address every major attack surface. Each layer includes the default behavior, the risk, and the fix.

OpenClaw Security Hardening Best Practices 2026

Security researchers found 42,665 publicly accessible OpenClaw instances in early 2026. The common thread: all of them were running default configurations. OpenClaw is not insecure by design, but its defaults prioritize ease of setup over security. Every hardening best practice in this guide is a deliberate choice you make after the initial install.

The most important best practices, in order of impact:

1. Bind the gateway to loopback only (gateway.bind: "loopback" in config) - this single change blocks the majority of attacks
2. Enable token authentication with a cryptographically random token
3. Configure a firewall to deny all inbound traffic by default
4. Harden Docker containers with resource limits and dropped capabilities
5. Encrypt the disk with LUKS2 so stolen hardware cannot expose agent state
6. Move credentials off the agent server entirely
7. Set up monitoring and a patching schedule

How to Harden OpenClaw: Step-by-Step Checklist

Use this checklist to verify your OpenClaw instance against each hardening layer. Each item is either complete or not - there is no partial credit for security configuration.

• [ ] Gateway bind address set to "loopback" (not "0.0.0.0")
• [ ] Authentication mode set to "token" (not "none")
• [ ] Token is at least 32 characters of random hex (generated with openssl rand -hex 32)
• [ ] UFW or iptables configured to deny all inbound by default
• [ ] Only SSH (port 22) and any required outbound tunnels allowed inbound
• [ ] Docker Compose includes memory limits, CPU limits, and --read-only filesystem
• [ ] Docker socket not mounted inside the container
• [ ] LUKS2 disk encryption configured and tested
• [ ] OAuth tokens and API keys stored off the VPS (Composio, HashiCorp Vault, or similar)
• [ ] Health check endpoint monitored externally
• [ ] Automatic security updates configured or patch schedule documented
• [ ] mDNS broadcasting disabled in config

The 7 Hardening Layers

Layer 1: Gateway Binding

Default behavior: OpenClaw's gateway binds to all network interfaces. This means the API is accessible from every IP address assigned to the server, including the public one.

The risk: Anyone on the internet can reach your OpenClaw instance directly. Port scanners like Shodan index it within hours. This is how 42,665 instances were found.

The fix: Bind the gateway to the loopback interface only.

# openclaw config
gateway:
  bind: "loopback"

With this setting, the gateway only accepts connections from the local machine. Remote access requires a secure tunnel or reverse proxy in front of it.

What ClawTrust does: The gateway is always bound to the loopback interface. External access is routed through an outbound-only encrypted tunnel. There is no public port to scan or exploit.

Layer 2: Authentication

Default behavior: OpenClaw allows setting the gateway authentication mode to "none". Some deployment guides even recommend it for local testing, then never mention changing it for production.

The risk: Without authentication, anyone who can reach the gateway can send commands, read conversation history, access agent memory, and trigger tool calls. Combined with a public-facing gateway (Layer 1), this means full unauthenticated access to your AI agent from the internet.

The fix: Enable token-based authentication and use a strong, randomly generated token.

# openclaw config
gateway:
  auth:
    mode: "token"
    # Use a cryptographically random token, minimum 32 characters
    # Generate with: openssl rand -hex 32

Store the token securely. Do not commit it to version control or include it in Docker images.

What ClawTrust does: Token authentication is always enabled. Tokens are generated with a cryptographically secure random generator, stored separately from the agent server, and rotated on a regular schedule. There is no option to disable authentication.

Layer 3: Firewall and Network Isolation

Default behavior: Most 1-click deployments leave all ports open. Port 18789 (the OpenClaw gateway) is directly accessible from the internet. SSH on port 22 is also open with password authentication enabled.

The risk: Open ports are the first thing attackers scan for. Once the gateway port is found, the attacker can probe for authentication weaknesses, attempt brute-force attacks, or exploit known CVEs. SSH with password auth is similarly vulnerable.

The fix: Configure your firewall to deny all inbound traffic by default, then allow only what you need.

# Basic UFW configuration
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh          # Or restrict to your IP
sudo ufw enable

# Block the OpenClaw port from external access
# (only needed if gateway is NOT bound to loopback)
sudo ufw deny 18789

For production deployments, use a reverse proxy with TLS termination (nginx or Caddy) and restrict SSH to key-based authentication only. Disable password login entirely.

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

What ClawTrust does: Every agent server has zero inbound ports. The firewall denies all incoming connections by default. The server establishes an outbound-only encrypted tunnel. There is nothing to scan, nothing to fingerprint, and nothing to brute-force.

Layer 4: Container Isolation

Default behavior: OpenClaw runs in Docker with default settings. The container has full Linux capabilities, can escalate privileges, and shares the host network in some configurations.

The risk: A container escape vulnerability or a compromised skill could give an attacker access to the host system. Default Docker settings provide minimal isolation for a security-sensitive application.

The fix: Harden the Docker container with resource limits, privilege restrictions, and filesystem controls.

# docker-compose.yml (security-relevant settings)
services:
  openclaw:
    security_opt:
      - no-new-privileges:true
    deploy:
      resources:
        limits:
          memory: 4g
          cpus: "2.0"
        reservations:
          memory: 1g
    read_only: false  # OpenClaw needs write access to state
    tmpfs:
      - /tmp:size=100m

  browser:
    read_only: true   # Browser container can be read-only
    security_opt:
      - no-new-privileges:true
    deploy:
      resources:
        limits:
          memory: 2g

Key principles: block privilege escalation, cap memory to prevent resource exhaustion, and make the browser container read-only since it does not need persistent write access.

What ClawTrust does: Every container runs with a hardened security profile. Privilege escalation is blocked at the kernel level. Memory and CPU limits are enforced per tier. The browser container runs with a read-only filesystem. Resource exhaustion from a runaway agent is prevented by hard caps.

Layer 5: Disk Encryption

Default behavior: No encryption at rest. Agent state files, conversation logs, cached API responses, and any credentials stored locally are written to an unencrypted disk.

The risk: If the server is compromised at the infrastructure level (a hypervisor escape, a stolen backup, or a decommissioned disk that was not wiped), all data is readable in plaintext. This includes anything the agent has processed or stored.

The fix: Set up LUKS2 full-disk encryption on the data volume.

# Create encrypted volume (WARNING: destroys existing data)
sudo cryptsetup luksFormat --type luks2 /dev/sdb
sudo cryptsetup luksOpen /dev/sdb encrypted_data
sudo mkfs.ext4 /dev/mapper/encrypted_data
sudo mount /dev/mapper/encrypted_data /data

# Point OpenClaw state directory to the encrypted volume
# In your OpenClaw config or environment:
OPENCLAW_STATE_DIR=/data

Important: LUKS2 encryption must be configured before OpenClaw is installed. Retrofitting encryption onto an existing deployment requires migrating data off the volume, encrypting it, and migrating data back. Plan for this from day one.

What ClawTrust does: Every server is provisioned with LUKS2 full-disk encryption from the first boot. All container data, agent state, conversation logs, and cached files are encrypted at rest. The encryption key uses a memory-hard derivation function to resist brute-force attacks.

Layer 6: Credential Management

Default behavior: API keys, bot tokens, and service passwords are stored in environment variables or .env files on the agent's server. The agent process has direct access to every credential.

The risk: If the agent or server is compromised, every credential is immediately exposed. A malicious skill, a prompt injection attack, or a container escape gives the attacker access to your API keys, email passwords, CRM tokens, and anything else stored on the machine. This is the single highest-impact risk in most OpenClaw deployments.

The fix: Use a secrets manager and minimize what credentials live on the agent's server.

• Move secrets off the server. Use a dedicated secrets manager (HashiCorp Vault, Doppler, Infisical, or similar) to store sensitive credentials. The agent retrieves them at runtime rather than reading from local files.
• Rotate credentials regularly. Set up automated rotation for API keys and tokens. If a credential is compromised, the window of exposure is limited to the rotation interval.
• Scope credentials tightly. Give the agent the minimum permissions it needs. A read-only CRM token if it only reads contacts. A send-only email token if it only sends messages. Never use admin-level API keys.
• Audit credential usage. Log every time a credential is accessed, by which process, and for what purpose.

What ClawTrust does: Credentials are stored in an encrypted vault on our control plane, not on the agent's server. When the agent needs to access a service, the request is proxied through our control plane, which injects the credential at the proxy layer. The agent never sees your passwords. Even a full server compromise cannot leak credentials, because they are not there to leak.

Layer 7: Monitoring and Updates

Default behavior: No monitoring, no alerting, no automated updates. If the agent crashes, you find out when someone complains. If a CVE is disclosed, you find out when you check the news.

The risk: Without monitoring, compromised agents can operate undetected for days or weeks. Without patching, known vulnerabilities remain exploitable. When CVE-2026-25253 was disclosed, self-hosted instances that lacked update automation stayed vulnerable until the operator manually discovered, downloaded, tested, and deployed the patch.

The fix: Set up health monitoring, log alerting, and a patching schedule.

• Health checks. Ping the agent's health endpoint on a regular interval. If it does not respond, trigger an alert. Tools like UptimeRobot, Healthchecks.io, or a simple cron job with curl will work.
• Log monitoring. Watch for error spikes, authentication failures, and unusual patterns. Fail2ban can block IPs after repeated failed authentication attempts.
• Resource monitoring. Track CPU, memory, and disk usage. A runaway agent or a crypto miner dropped by a malicious skill will show up as abnormal resource consumption.
• Patching schedule. Check for OpenClaw updates weekly. Subscribe to the project's security advisories. Apply critical patches within 24 hours of disclosure.
• Backup and recovery. Snapshot the encrypted data volume regularly. Test restores. A backup you have never tested is not a backup.

What ClawTrust does: Automated health checks run every 15 minutes across the entire fleet. Each check verifies container status, resource usage, tunnel connectivity, and agent responsiveness. If a problem is detected, auto-remediation kicks in for known issues (service restarts, permission fixes, tunnel recovery). Critical issues generate alerts for our team. Security patches are pushed fleet-wide without any customer action required.

The DIY Hardening Checklist

If you are self-hosting OpenClaw and want to harden it properly, here is the complete checklist. Work through each item in order.

1. Bind the gateway to loopback. Set gateway.bind: "loopback" in your OpenClaw configuration. Verify with ss -tlnp | grep 18789 that it only listens on the local interface. (5 minutes)
2. Enable token authentication. Set gateway.auth.mode: "token" and generate a token with openssl rand -hex 32. Test that unauthenticated requests are rejected. (10 minutes)
3. Configure the firewall. Deny all inbound traffic by default. Allow only SSH (restricted to your IP if possible). Disable SSH password authentication. Enable key-based auth only. (30-60 minutes)
4. Set up a reverse proxy with TLS. Install nginx or Caddy in front of the gateway. Obtain a TLS certificate (Let's Encrypt). Proxy HTTPS traffic to the local gateway. (30-60 minutes)
5. Harden Docker containers. Add no-new-privileges, resource limits (memory + CPU), and read-only filesystem for the browser container. Test that the agent still functions correctly after changes. (30-60 minutes)
6. Enable disk encryption. Provision a LUKS2-encrypted volume for the OpenClaw state directory. This requires re-provisioning if your disk is already in use. Migrate data, encrypt, migrate back. (1-4 hours)
7. Move credentials to a secrets manager. Set up HashiCorp Vault, Doppler, or your preferred secrets manager. Migrate API keys and tokens off the server. Configure the agent to retrieve secrets at runtime. (2-4 hours)
8. Set up monitoring. Configure health checks (UptimeRobot, cron + curl). Set up log monitoring for auth failures. Configure resource alerts for CPU and memory. Install fail2ban for brute-force protection. (1-2 hours)
9. Establish a patching schedule. Subscribe to the OpenClaw security advisory feed. Check for updates weekly. Test patches in a staging environment before applying to production. (30 minutes to set up, ongoing maintenance)
10. Disable mDNS broadcasting. Set gateway.mDNS.enabled: false in your configuration. mDNS broadcasts the presence of your OpenClaw instance on the local network. (2 minutes)
11. Enable tool sandboxing. Set agents.defaults.sandbox.mode: "all" to sandbox every tool execution. This runs tool calls in isolated containers rather than directly on the host. (5 minutes)
12. Configure DM pairing. Set channels.*.dmPolicy: "pairing" for each messaging channel. This requires users to be explicitly approved before the agent will respond to their messages. (10 minutes)

Estimated total time: 4 to 20 hours, depending on your familiarity with Linux server administration, Docker, and secrets management. The wide range reflects the difference between someone who has done this before and someone learning as they go.

Steps 1, 2, 10, 11, and 12 are quick configuration changes. Steps 3-5 require moderate Linux experience. Steps 6 and 7 are the most time-intensive and are frequently skipped, which is why credential exposure and unencrypted disks are the two most common findings in security audits of OpenClaw deployments.

Or Skip the Hardening

ClawTrust handles all seven hardening layers automatically on every deployment. No manual configuration. No checklist to work through. No ongoing maintenance.

• Gateway binding: Always loopback. Always.
• Authentication: Token auth, cryptographically generated, automatically rotated.
• Network: Zero inbound ports. Outbound-only encrypted tunnel.
• Containers: Hardened Docker with resource caps, privilege restrictions, and read-only browser.
• Encryption: LUKS2 full-disk encryption from first boot.
• Credentials: Encrypted vault on separate infrastructure. Agent never sees your passwords.
• Monitoring: Health checks every 15 minutes. Auto-remediation. Fleet-wide patching.

Your agent is provisioned, hardened, and monitored in under 5 minutes. You focus on what the agent does. We focus on making sure it is safe to do it.

Frequently Asked Questions

---

Chris DiYanni is the founder of ClawTrust. Previously at Palo Alto Networks, SentinelOne, and PagerDuty. He builds security infrastructure so businesses can trust their AI agents with real work.