OpenClaw Security Hardening Guide: Risks & Best Practices

Self-hosting OpenClaw (formerly Moltbot/Clawdbot) can turn into an incident fast. I've seen this pattern play out: one exposed port, one insecure mode, or one "helpful" skill install and suddenly an attacker has tool execution plus your tokens. Public reporting shows internet exposure at scale, including one count of about 42,665 reachable instances, so opportunistic scanning is the baseline threat here, not some rare edge case.

This guide lays out a hardening path that assumes you want OpenClaw's power without inheriting its default blast radius.

OpenClaw threat model in 3 words: Root, Agency, Keys

textCopy
Root: Can the agent break container boundaries or reach the host?
Agency: Can the agent do more than it should (tools, network, skills)?
Keys: Can the agent or attacker steal credentials (env, logs, mounts, disk)?

I like this model because it stays useful even as advisories change. A new CVE almost always lands in one of these buckets, which quickly tells you which control would've stopped it (or at least made it a lot harder).

Root failures usually come from privileged containers, Docker socket mounts, broad Linux capabilities, and writable host mounts. Agency failures tend to come from "tool sprawl" (too many actions allowed) and "network sprawl" (the agent can reach anything). Keys failures are the classic stuff that still bites teams: tokens in environment variables, debug logs, plaintext local storage, and over-scoped cloud credentials.

High-severity issues and active abuse patterns raised urgency in early 2026, including a one-click chain reported as patched in v2026.1.29 with guidance to upgrade and rotate tokens: The Hacker News, University of Toronto advisory. Other reported flaws include command injection and RCE paths (example: CVE-2026-24763) and gateway plus sandbox handling concerns discussed by Tenable.

Internet exposure is the fastest way to lose: bind, proxy, and firewall

bashCopy
# Minimal exposure pattern: bind the gateway to loopback only
# Replace [OPENCLAW_PORT] with your port (example: 3000)
docker run --rm -p 127.0.0.1:[OPENCLAW_PORT]:[OPENCLAW_PORT] [IMAGE]:[TAG]

Binding to 127.0.0.1 forces all access through the local host. Honestly, that single move eliminates the most common "shodan-grade" failure mode: a public listener with weak auth.

If you need remote access, terminate TLS and enforce auth at a reverse proxy. Keep OpenClaw private behind it.

nginxCopy
## /etc/nginx/conf.d/openclaw.conf
server {
    listen 443 ssl;
    server_name [OPENCLAW_FQDN];

    ssl_certificate /etc/letsencrypt/live/[OPENCLAW_FQDN]/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/[OPENCLAW_FQDN]/privkey.pem;

    # Basic hardening headers
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options DENY always;
    add_header Referrer-Policy no-referrer always;

    location / {
        proxy_pass http://127.0.0.1:[OPENCLAW_PORT];

        # Correct forwarding so the app can validate origin and scheme
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # WebSocket support (common for agent UIs)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

This configuration matters because a lot of real-world chains start with something boring like "user clicks a link" or "attacker can reach the gateway," and then it snowballs into token theft or session hijack. Even when the application patches quickly, the proxy layer gives you a second gate: TLS, allowlists, and consistent header handling.

Now put a network policy in front of it. If you have a fixed admin IP range, enforce it at the firewall.

bashCopy
# Example: allow only a corporate CIDR to reach 443
ufw default deny incoming
ufw allow from [CORP_CIDR] to any port 443 proto tcp
ufw enable

One more control that really pays off in practice: separate admin UI access from agent execution traffic. Expose the UI only over VPN, and keep runtime APIs private. That split often stops "drive-by UI exploitation" from turning into "agent runs tools in prod."

Patch fast and rotate tokens like you mean it

bashCopy
## Inventory running versions (example for Docker)
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.RunningFor}}'

# Pull and roll to a known fixed tag
docker pull [IMAGE]:v2026.1.29
docker stop [CONTAINER]
docker run -d --name [CONTAINER] [OTHER_FLAGS] [IMAGE]:v2026.1.29

Upgrading is table stakes, but token rotation is what cuts off persistence. If an attacker stole a gateway token last week, patching today doesn't magically invalidate it.

Rotate in three places, in this order: gateway/session tokens, API keys used by skills/tools, then cloud provider credentials. Keep a short overlap window only if your service can't tolerate immediate invalidation.

bashCopy
# Fast "find likely secrets" sweep before rotation work
# This catches the common mistake: secrets accidentally committed or logged.
rg -n --hidden -S "OPENCLAW|CLAWDBOT|MOLTBOT|token|apikey|api_key|secret|bearer|Authorization" .

# If logs are on disk, search there too
sudo rg -n -S "bearer|token|Authorization" /var/log

Here's the thing: the underappreciated risk is that agent systems create new secret paths. A normal web app has a few well-known secrets. An agent has model provider keys, tool credentials, skill registry tokens, and sometimes "temporary" debugging tokens that never get cleaned up (yes, that happens more than people admit).

For a deeper read on the one-click chain and the fix version, see: The Hacker News and UofT advisory. For broader mitigation steps and multiple CVEs, use Tenable's guide.

Skills and extensions are a supply chain: treat ClawHub like npm in 2016

bashCopy
## Policy: install skills only from an internal allowlist repository
## Example: block outbound access to public registries from the runtime network
iptables -A OUTPUT -p tcp -d [PUBLIC_REGISTRY_IP_OR_CIDR] --dport 443 -j REJECT

I'd start from a deny stance because the ecosystem has already been abused at scale. Reports describe 400+ malicious skills distributed via the ClawHub registry (386 confirmed), often disguised as crypto tooling and used to steal credentials and keys: Security Affairs, plus enterprise targeting coverage from Bitdefender.

The unique twist with agent skills is that dependency confusion isn't the only problem. A malicious skill doesn't need to pull off memory corruption. It just needs to call the tools you already allowed, then quietly ship the results out over HTTPS.

Make skills pass a gate before they ever reach the runtime. A practical gate is: pin versions, verify hashes, scan the package, and require code review. If you can't do all four, do pinning plus review at minimum (it's not perfect, but it moves the needle).

yamlCopy
# skills-allowlist.yaml
allowed_skills:
  - name: [SKILL_NAME]
    version: "[PINNED_VERSION]"
    source: "[INTERNAL_REPO_URL]"
    sha256: "[EXPECTED_SHA256]"

blocked_patterns:
  - "crypto"
  - "wallet"
  - "seed"

Yes, this looks strict, but it's basically how mature teams treat CI plugins and Terraform providers. Skills are code execution with branding.

Constrain agency: build "tool budgets" and confirmation gates

jsonCopy
{
  "tools": {
    "filesystem": {
      "allow": true,
      "read_paths": ["/workspace"],
      "write_paths": ["/workspace/out"],
      "deny_paths": ["/", "/etc", "/home", "/root", "/var/run/docker.sock"]
    },
    "shell": {
      "allow": true,
      "allowed_commands": ["git", "python", "node", "npm", "pip"],
      "deny_flags": ["-c", "--eval"]
    },
    "network": {
      "allow": true,
      "egress_allowlist": ["api.github.com:443", "[INTERNAL_API_FQDN]:443"]
    }
  },
  "high_risk_actions": {
    "require_human_approval": ["shell", "filesystem.write", "network.external"]
  }
}

Most OpenClaw incidents aren't "AI went rogue." They're more like: the agent had permission to do the dangerous thing, and a prompt or a skill nudged it there. A tool budget forces you to decide what the agent is actually for (and what it absolutely isn't for).

The deny_paths list blocks classic foot-guns: reading /etc, touching host sockets, or walking home directories. The allowed_commands list prevents "shell as a universal backdoor," where any prompt injection becomes arbitrary command execution. The egress allowlist turns data theft into a blocked connection instead of a postmortem.

A confirmation gate is not just a UI prompt. It should create an auditable event with the exact action, arguments, and diff of what will change.

pythonCopy
# Minimal confirmation gate pattern: hash the planned action payload
import hashlib, json, time

def approval_payload(action: dict) -> dict:
    body = json.dumps(action, sort_keys=True).encode()
    return {
        "action": action,
        "sha256": hashlib.sha256(body).hexdigest(),
        "requested_at": int(time.time())
    }

planned = {
    "tool": "filesystem.write",
    "path": "/workspace/out/report.md",
    "bytes": 4812
}
print(json.dumps(approval_payload(planned), indent=2))

Hashing the payload stops "approve write" from quietly becoming "approve write plus exfil." The approver can verify the hash matches what they saw in the UI or ticket.

For more on Zero Trust patterns that map well to agent tools (identity, device posture, and policy gates), see our Zero Trust Security: A Comprehensive Guide.

Harden the runtime: non-root, no new privileges, read-only, no Docker socket

yamlCopy
## docker-compose.yml (hardening baseline)
services:
  openclaw:
    image: [IMAGE]:v2026.1.29
    user: "10001:10001"
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=256m
    ports:
      - "127.0.0.1:[OPENCLAW_PORT]:[OPENCLAW_PORT]"
    volumes:
      - type: bind
        source: ./workspace
        target: /workspace
        read_only: true
      - type: bind
        source: ./out
        target: /workspace/out
        read_only: false
    environment:
      - OPENCLAW_LOG_LEVEL=info

This is where "Root" gets contained. The user: "10001:10001" directive removes default root inside the container. cap_drop: ALL eliminates most kernel-level privilege paths. read_only: true makes many exploit chains fail because they can't drop binaries or edit configs.

The split mounts are deliberate. A read-only /workspace prevents the agent from editing its own code or build scripts. A writable /workspace/out gives it a safe place to produce artifacts. I've watched teams mount the whole repo read-write and then act surprised when a compromised agent can backdoor CI.

If someone suggests mounting /var/run/docker.sock so the agent can "manage containers," treat that as host-level access. Docker socket access is effectively root on the host.

bashCopy
# Quick check for the most dangerous mount in the fleet
docker inspect $(docker ps -q) | rg -n "/var/run/docker.sock"

Network egress control is the other runtime hardening lever. If the agent can only reach a few endpoints, prompt injection becomes a lot less valuable.

bashCopy
## Example: create a dedicated Docker network and block outbound except allowlist via host firewall
docker network create openclaw_net
docker network connect openclaw_net [CONTAINER]

The exact enforcement method varies (iptables, cloud security groups, Kubernetes NetworkPolicies), but the goal stays the same: the runtime should not have default internet access.

Detection that works for agents: log the tool calls, not just HTTP

jsonCopy
{
  "event": "tool.call",
  "request_id": "[REQ_ID]",
  "actor": "agent",
  "tool": "shell",
  "args": ["git", "remote", "-v"],
  "cwd": "/workspace",
  "egress": null,
  "result": "success",
  "ts": "2026-02-11T12:34:56Z"
}

Traditional app logs tell you who logged in and which endpoint they hit. Agent incidents often happen after login, using legitimate features. Tool-call logging gives you the missing layer: what the agent executed, what it read, and where it tried to connect.

Alert on patterns that rarely belong in normal operation: base64 encoding, archive creation, credential file access, and unexpected outbound domains. Also alert on "tool denied" events. From what I've seen, a spike in denials often means prompt injection attempts are already underway.

bashCopy
## Example hunting queries on JSON logs (jq)
jq -c 'select(.event=="tool.call" and .tool=="shell")' /var/log/openclaw/events.jsonl | head

jq -c 'select(.event=="tool.call" and .tool=="filesystem" and (.path|test("id_rsa|\\.aws|\\.ssh|kubeconfig")))' /var/log/openclaw/events.jsonl

Tie this into your SIEM if you have one, but don't wait on SIEM work to start. A local JSONL file with rotation is enough to investigate your first incident (and you will want that paper trail).

Tools and platforms that make OpenClaw safer (and what they're really good at)

These aren't generic "security stack" picks. They map cleanly to Root (Falco, Gatekeeper), Agency (Cilium), and Keys (Vault), plus patch hygiene (Trivy) and image trust (Cosign).

If you only add one thing, I'd add egress control, because it turns many data theft attempts into noise.

Real-world signals: what the industry data points imply for your controls

Spotify achieved a 50% reduction in mean time to recovery (MTTR) by adopting incident response automation and standardized runbooks, reported in engineering talks and SRE practice summaries. That same discipline applies here: pre-approve safe tool paths, and make sensitive actions require an explicit workflow.

Netflix runs large-scale containerized workloads with strong runtime isolation and continuous patching practices described in their security and SRE publications. The takeaway for OpenClaw is simple: treat the agent as an untrusted workload, even when it's "your" agent.

Stripe is widely cited for strict access control and strong secrets management patterns in high-compliance environments. For OpenClaw, that maps to short-lived credentials and narrow scopes, not "one API key to rule them all."

These aren't "copy their toolchain" examples. They show the direction: automation plus guardrails beats hoping prompts stay clean.

Start Here

Start here (your first step)

Upgrade OpenClaw to v2026.1.29 or later, then rotate all gateway tokens within 60 minutes.

Quick wins (immediate impact)

• Rebind the gateway to 127.0.0.1 and put TLS + auth in front of it within 1 day.
• Disable debug/insecure modes and set OPENCLAW_LOG_LEVEL=info with tool-call logging within 2 hours.

Deep dive (for those who want more)

• Implement a skills allowlist with pinned versions and hash verification, then block outbound access to public registries within 2 weeks.
• Apply container hardening: non-root user, cap_drop: ALL, read_only: true, and no Docker socket mounts across all environments within 1 week.

Useful Resources

• OpenClaw Bug Enables One-Click Remote Code Execution - Patch version and attack chain overview.
• OpenClaw vulnerability notification - Timeline and impacted versions.
• Clawdbot: How to Mitigate Agentic AI Security Vulnerabilities - Hardening steps and risk breakdown.
• MoltBot Skills exploited to distribute 400+ malware packages - Supply chain risk details for skills.
• Tens of thousands of OpenClaw systems exposed - Exposure scale and misconfiguration patterns.

The Bottom Line

OpenClaw security comes down to controlling Root, Agency, and Keys with layered friction: private binding, strict proxy auth, fast patching plus token rotation, skills allowlists, least-privilege tools, and hardened containers with constrained egress.

The threat isn't hypothetical. Public reporting ties real abuse to exposed gateways, high-severity bugs, and malicious skills in the ecosystem. If your team needs a structured hardening review and DevSecOps rollout for agentic systems, Joulyan IT Solutions can run a security assessment that turns these controls into a repeatable baseline across environments.