Enterprise Security Guide

OpenClaw SecurityHardening Guide

The definitive guide to securing your OpenClaw deployment. Learn how to protect against prompt injection, credential theft, and supply chain attacks with our proven RAK framework.

25 min read
Last updated: February 5, 2026
Advanced

The OpenClaw Security Problem

OpenClaw (formerly known as Clawdbot, then Moltbot) has rapidly become one of the most popular open-source AI agents, with over 149,000 GitHub stars and thousands of active deployments. But its meteoric rise has exposed a critical truth: most deployments are dangerously insecure.

"Personal AI agents like OpenClaw are a security nightmare."
— Cisco Security Blog, January 2026
21,000+
Publicly Exposed Instances
Censys, Jan 2026
341
Malicious Skills Found
Koi Security
85%
Attack Success Rate
OWASP Research

Security researcher Laurie Voss, founding CTO of npm, described the situation bluntly: "OpenClaw is a security dumpster fire." The combination of powerful capabilities, default-insecure configurations, and a vulnerable extension ecosystem creates what experts call a "perfect storm" for attackers.

Critical Vulnerability Alert

In January 2026, CVE-2026-25253 was disclosed—a high-severity flaw (CVSS 8.8) enabling one-click remote code execution via token theft and WebSocket hijacking. If you haven't updated to v2026.1.29 or later, do so immediately.

Real Security Risks You Face

Data Exfiltration

AI agents can become covert data-leak channels that bypass traditional DLP, proxies, and endpoint monitoring.

Command Injection

Multiple CVEs allow attackers to execute arbitrary commands on your system with user-level permissions.

Credential Theft

Default plaintext storage of API keys and tokens makes credential theft trivial for attackers.

Supply Chain Attacks

335 malicious skills on ClawHub install the Atomic Stealer malware. Fake VS Code extensions distribute trojans.

Threat Model: What Can Go Wrong

Understanding the attack surface is the first step to defense. OpenClaw's power comes from its capabilities—but those same capabilities create significant security risks when combined.

The Lethal Trifecta

Security researcher Simon Willison identified the "lethal trifecta" that makes AI agents uniquely vulnerable:

The Lethal Trifecta: Three Dangerous Capabilities

Private DataAccess
UntrustedContent
ExternalCommunication

Combined = Data Exfiltration Risk

Attacker emails prompt → Agent reads private data → Agent sends to attacker

Why This Matters

If your agent has access to private data, can process untrusted content (like emails or web pages), AND can communicate externally, an attacker can trick it into accessing your private data and sending it to them. This is not theoretical—it's the primary attack vector.

Attack Vectors in Detail

1. Prompt Injection Attacks

OWASP lists prompt injection as the #1 security risk for LLM applications in 2025. Attack success rates against state-of-the-art defenses exceed 85% when adaptive strategies are employed.

Attack Example: Malicious instructions embedded in an email or web page that the agent processes, overriding its safety guidelines.

2. Unauthorized Access

An authentication bypass flaw in how the gateway handles localhost connections allows external attackers to bypass login protections when deployed behind common reverse proxies.

Real-World Impact: Thousands of instances exposed without password protection, administrative dashboards accessible on public internet.

3. Credential Compromise

OpenClaw stores authentication tokens, API keys, user profiles, and memories in plaintext Markdown and JSON files. Attackers who gain access can steal keys or conduct "Cognitive Context Theft."

Default Paths: ~/.openclaw/credentials/, ~/.openclaw/memory/

4. Supply Chain Attacks

Cisco found that popular skills contained silent data exfiltration, direct prompt injection to bypass safety guidelines, and tool poisoning—effectively malware wrapped in "useful" plugins.

Statistics: 341 malicious skills identified, 335 installing the Atomic Stealer (AMOS) macOS malware.

The RAK Framework (Cognio's Approach)

We developed the RAK Framework to systematically address the three primary risk categories in OpenClaw deployments. This framework guides our security-hardened setups and serves as a mental model for ongoing security decisions.

The RAK Framework: Three Pillars of OpenClaw Security

R

Root Risk

Running as root user with full system access

A

Agency Risk

Unrestricted tool access and autonomous actions

K

Keys Risk

Exposed credentials and API tokens

Mitigating Root Risk

Running OpenClaw as root (or with excessive privileges) means any vulnerability gives attackers complete system control. Docker makes this worse—containers run as root by default.

Docker Hardening

  • • Run as non-root user (USER directive or --user flag)
  • • Enable read-only root filesystem (--read-only)
  • • Drop all capabilities except required (--cap-drop=ALL)
  • • Use Docker Hardened Images (DHI) where available

Volume Mount Isolation

  • • Never mount /root, /, or sensitive host directories
  • • Use named volumes instead of bind mounts where possible
  • • Mount configuration as read-only when possible
  • • Restrict access to only necessary paths
Secure Docker Compose Configurationyaml
version: '3.8'
services:
  openclaw:
    image: openclaw/gateway:latest
    user: "1000:1000"  # Non-root user
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # Only if binding to ports < 1024
    tmpfs:
      - /tmp:noexec,nosuid,nodev
    volumes:
      - openclaw_data:/app/data:rw
      - ./config.yaml:/app/config.yaml:ro
    environment:
      - NODE_ENV=production
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 4G
        reservations:
          cpus: '0.5'
          memory: 1G

volumes:
  openclaw_data:

Mitigating Agency Risk

OpenClaw's power comes from its tools—but unrestricted tool access is the primary vector for prompt injection attacks. The official documentation recommends limiting high-risk tools to trusted agents or explicit allowlists.

Tool Allowlisting

Sandbox defaults include an allowlist. Configure explicitly:

  • Allow: bash, process, read, write, edit, sessions_list
  • Deny: browser, web_fetch, web_search, exec (high-risk)

Human-in-the-Loop

For sensitive actions (sending emails, making payments, accessing external APIs), require explicit human approval. OpenClaw supports this via the gateway configuration.

Sandbox Configuration

Set agents.defaults.sandbox.mode: "non-main" to run non-main sessions in per-session Docker sandboxes, isolating untrusted content processing.

Sandbox and Tool Configurationyaml
# config.yaml - Agency Risk Mitigation
agents:
  defaults:
    sandbox:
      mode: "non-main"  # Sandbox non-main sessions
    tools:
      allowlist:
        - bash
        - read
        - write
        - edit
        - sessions_list
        - sessions_history
      denylist:
        - browser
        - web_fetch
        - web_search
        - canvas
        - nodes
        - cron

tools:
  exec:
    safeBins:
      - /usr/bin/git
      - /usr/bin/npm
      - /usr/bin/node
    requireApproval:
      - rm
      - curl
      - wget

# Human-in-the-loop for sensitive actions
approvalRequired:
  - tool: email_send
    threshold: always
  - tool: payment_process
    threshold: always
  - tool: file_delete
    threshold: always

Mitigating Keys Risk

Default plaintext credential storage is one of OpenClaw's most criticized security decisions. JFrog's security analysis emphasizes: "Don't store credentials in ~/.openclaw/credentials/ unencrypted—use a secrets manager."

Credential Isolation

  • • Use environment variables for runtime secrets
  • • Integrate with secrets managers (HashiCorp Vault, AWS Secrets Manager, 1Password)
  • • Keep credentials separate from sandbox containers
  • • Only inject allowed keys into sandbox at startup

API Key Rotation

  • • Use short-lived tokens with OAuth refresh tokens
  • • Implement automatic rotation (monthly minimum, weekly preferred)
  • • Rotate immediately after any incident—assume compromised
  • • Scope keys to minimum required permissions

Audit Logging

  • • Log all credential access with timestamps
  • • Monitor for unusual access patterns
  • • Set up alerts for failed authentication attempts
  • • Retain logs for compliance requirements (typically 1 year)
Secrets Management with Environment Variablesbash
# Instead of storing in plaintext files, use env vars
# .env file (add to .gitignore!)
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...

# Or use a secrets manager CLI
# Example with 1Password:
export OPENAI_API_KEY=$(op read "op://Private/OpenAI/api-key")

# Docker Compose with secrets
docker-compose --env-file .env up -d

# Better: Use Docker secrets for production
docker secret create openai_api_key ./openai_key.txt
# Then reference in compose as:
# secrets:
#   - openai_api_key

Docker Security Hardening

Docker provides powerful isolation capabilities, but default configurations are insecure. Docker Hardened Images (DHI), now free under Apache 2.0 license, provide a more secure baseline—but additional configuration is still required.

Docker Security Checklist

  • Run as non-root user (USER directive or --user flag)
  • Enable read-only root filesystem (--read-only flag)
  • Drop all capabilities except required (--cap-drop=ALL)
  • Use strict volume mounts (no /root or / access)
  • Configure network policy (restrict outbound connections)
  • Set resource limits (CPU and memory)
  • Use Docker Hardened Images where available
  • Enable no-new-privileges security option
  • Mount /tmp as tmpfs with noexec,nosuid,nodev
  • Use named volumes instead of bind mounts
Complete Secure Docker Run Commandbash
docker run -d \
  --name openclaw \
  --user 1000:1000 \
  --read-only \
  --security-opt no-new-privileges:true \
  --cap-drop ALL \
  --tmpfs /tmp:noexec,nosuid,nodev,size=100m \
  --memory 4g \
  --cpus 2 \
  --pids-limit 100 \
  --network openclaw-network \
  -v openclaw_data:/app/data:rw \
  -v ./config.yaml:/app/config.yaml:ro \
  -p 127.0.0.1:18789:18789 \
  --env-file .env \
  --restart unless-stopped \
  openclaw/gateway:latest
Network Isolation

Create a dedicated Docker network and restrict outbound connections. Only allow connections to specific required services (your LLM API endpoints, etc.):

docker network create --driver bridge --internal openclaw-network

VPS Security Checklist

If you're running OpenClaw on a VPS (DigitalOcean, AWS EC2, Linode, etc.), the underlying server must be hardened. A compromised host means a compromised agent.

VPS Security Checklist

  • Configure UFW firewall (allow only SSH, reverse proxy ports)
  • SSH key-only authentication (disable password auth)
  • Install and configure Fail2Ban for brute force protection
  • Enable automatic security updates (unattended-upgrades)
  • Set up regular automated backups
  • Use SSL/TLS everywhere (Let's Encrypt)
  • Disable root SSH login
  • Configure intrusion detection (AIDE or similar)
  • Set up log monitoring and alerts
  • Use Tailscale or WireGuard for secure remote access
VPS Initial Security Setup (Ubuntu/Debian)bash
#!/bin/bash
# VPS Security Hardening Script

# Update system
apt update && apt upgrade -y

# Install security tools
apt install -y ufw fail2ban unattended-upgrades

# Configure UFW firewall
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 443/tcp  # HTTPS only
ufw --force enable

# Configure Fail2Ban
cat > /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
EOF

systemctl enable fail2ban
systemctl start fail2ban

# Disable password authentication
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart sshd

# Enable automatic security updates
dpkg-reconfigure -plow unattended-upgrades

echo "✅ Basic VPS hardening complete"
echo "⚠️  Make sure you have SSH key access before closing this session!"
Recommended: Use Tailscale

Instead of exposing ports to the public internet, use Tailscale for secure remote access. OpenClaw supports Tailscale natively with gateway.auth.allowTailscale: true. This provides identity headers and eliminates the need for public port exposure.

OpenClaw Configuration Security

OpenClaw's configuration determines your security posture. Gateway authentication is now required by default—if no token/password is configured, the Gateway refuses WebSocket connections (fail-closed).

Gateway Authentication Setup

Secure Gateway Configurationyaml
# config.yaml - Gateway Security

gateway:
  bind: "127.0.0.1"  # Localhost only - use reverse proxy for external
  port: 18789

  auth:
    enabled: true
    mode: "token"
    token: "${OPENCLAW_AUTH_TOKEN}"  # Set via environment variable
    # Generate with: openssl rand -hex 32

    # If using Tailscale
    allowTailscale: true

  # Trusted proxies for proper IP detection
  trustedProxies:
    - "127.0.0.1"
    - "10.0.0.0/8"      # If using internal network
    - "172.16.0.0/12"   # Docker networks

  # Rate limiting
  rateLimit:
    enabled: true
    maxRequests: 100
    windowMs: 60000  # 1 minute

  # Session settings
  session:
    timeout: 3600000  # 1 hour
    maxConcurrent: 5

# Security audit settings
security:
  audit:
    enabled: true
    logPath: "/app/logs/audit.log"
    retention: "90d"

  # Skill verification
  skills:
    allowUnsigned: false
    trustedSources:
      - "https://clawhub.com/verified"

# Model selection (use instruction-hardened models)
models:
  default: "claude-opus-4-5-20251101"  # More robust against prompt injection
  fallback: "gpt-4-turbo"
Reverse Proxy Configuration

If running behind nginx, Caddy, or Traefik, configure gateway.trustedProxies correctly. Without this, proxied connections appear to come from localhost and receive automatic trust—a common authentication bypass.

Skill Permission Reviews

The skill ecosystem is a major supply chain risk. Cisco found malicious skills containing data exfiltration and prompt injection. Before installing any skill:

✓ Safe Practices

  • • Only install from verified ClawHub sources
  • • Review skill source code before installation
  • • Check skill permissions and required access
  • • Monitor skill behavior after installation

✗ Red Flags

  • • Skills requiring shell/exec access
  • • Obfuscated or minified source code
  • • External network requests to unknown domains
  • • Skills from unverified authors
Run Security Doctor Before Startingbash
# Always run the security doctor before starting
openclaw doctor

# Example output:
# ✓ Gateway authentication enabled
# ✓ Sandbox mode configured
# ⚠ Warning: DM access enabled - ensure you trust DM senders
# ✓ Tool allowlist configured
# ✓ No high-risk tools in allowlist
# ⚠ Warning: browser tool in allowlist - potential prompt injection vector

Compliance Considerations

If you're handling sensitive data, regulatory compliance isn't optional. Production AI agents handling PII, financials, or health data need explicit compliance controls—adding $8k-25k to development costs according to industry estimates.

GDPR (EU Data Protection)

Requirements

  • • Data residency (EU servers for EU data)
  • • Right to deletion (erasure requests)
  • • Explicit consent for AI processing
  • • Data portability

Implementation

  • • Use EU-based hosting providers
  • • Implement data deletion workflows
  • • Add consent banners and records
  • • Document data flows

SOC 2 (Service Organization Controls)

Requirements

  • • Access controls and authentication
  • • Comprehensive audit logs
  • • Encryption at rest and in transit
  • • Incident response procedures

Implementation

  • • Implement RBAC (role-based access)
  • • Enable audit logging (90+ day retention)
  • • Use TLS 1.3 everywhere
  • • Document and test IR plan

HIPAA (Healthcare)

Requirements

  • • PHI protection safeguards
  • • Encryption at rest and in transit
  • • Access audit trails
  • • Business Associate Agreement

Implementation

  • • Use HIPAA-compliant hosting
  • • Implement AES-256 encryption
  • • Log all PHI access with retention
  • • Sign BAAs with all vendors
Healthcare Warning

HIPAA violations can result in fines from $100 to $50,000 per violation, with annual maximums up to $1.5 million. We strongly recommend professional implementation for healthcare use cases.

Security Audit Script

Run this script weekly to check your OpenClaw deployment for common security misconfigurations. Save it as openclaw-security-audit.sh and run with bash openclaw-security-audit.sh.

openclaw-security-audit.shbash
#!/bin/bash
# OpenClaw Security Audit Script by Cognio Labs
# Version: 1.0.0 | Last Updated: February 2026
# Usage: bash openclaw-security-audit.sh

set -e

echo "OpenClaw Security Audit"
echo "=========================="
echo ""

ISSUES=0
WARNINGS=0

# Helper functions
pass() { echo "  [PASS] $1"; }
fail() { echo "  [FAIL] $1"; ((ISSUES++)); }
warn() { echo "  [WARN] $1"; ((WARNINGS++)); }
info() { echo "  [INFO] $1"; }

# 1. Check if running as root
echo "Checking Process Security..."
if [ "$(docker exec openclaw id -u 2>/dev/null)" = "0" ]; then
    fail "Container running as root user"
else
    pass "Container running as non-root user"
fi

# 2. Check exposed ports
echo ""
echo "Checking Network Security..."
EXPOSED=$(docker port openclaw 2>/dev/null | grep -v "127.0.0.1" | wc -l)
if [ "$EXPOSED" -gt 0 ]; then
    fail "Ports exposed to 0.0.0.0 (should be localhost only)"
else
    pass "No ports exposed to 0.0.0.0"
fi

# 3. Check for public gateway
if curl -s --max-time 5 "http://localhost:18789/health" > /dev/null 2>&1; then
    RESPONSE=$(curl -s --max-time 5 "http://localhost:18789/api/status" 2>/dev/null)
    if echo "$RESPONSE" | grep -q "unauthorized"; then
        pass "Gateway authentication enabled"
    else
        fail "Gateway authentication NOT enabled"
    fi
else
    info "Gateway not accessible on localhost:18789"
fi

# 4. Check Docker security options
echo ""
echo "Checking Docker Security..."
INSPECT=$(docker inspect openclaw 2>/dev/null)

if echo "$INSPECT" | grep -q '"ReadonlyRootfs": true'; then
    pass "Read-only root filesystem enabled"
else
    fail "Read-only root filesystem NOT enabled"
fi

if echo "$INSPECT" | grep -q '"NoNewPrivileges": true'; then
    pass "No-new-privileges security option"
else
    fail "No-new-privileges NOT enabled"
fi

# Summary
echo ""
echo "=========================="
echo "Audit Summary"
echo "Issues found: $ISSUES"
echo "Warnings: $WARNINGS"
echo ""
echo "Run 'openclaw doctor' for additional checks"
Automated Auditing

Set up a cron job to run this script weekly and send results to your security team:

0 9 * * 1 /path/to/openclaw-security-audit.sh | mail -s "OpenClaw Weekly Audit" [email protected]

Incident Response Plan

When (not if) a security incident occurs, having a pre-defined response plan minimizes damage and recovery time.

Incident Response Workflow

Detect
Contain
Recover
Learn

Phase 1: Detection

Signs of potential compromise:

  • • Unusual outbound network traffic
  • • Unexpected API calls or credential usage
  • • Agent behaving erratically or ignoring instructions
  • • Failed authentication attempts in logs
  • • Users reporting phishing or suspicious messages

Phase 2: Containment

Immediate steps (within minutes):

  1. Stop the OpenClaw container: docker stop openclaw
  2. Block network access: ufw deny out to any
  3. Rotate ALL credentials immediately
  4. Revoke active sessions/tokens
  5. Preserve logs for forensics (don't delete)

Phase 3: Recovery

Restoration procedures:

  1. Deploy fresh instance from known-good backup
  2. Apply all security patches and updates
  3. Implement additional hardening measures
  4. Configure new credentials in secrets manager
  5. Gradually restore services with monitoring

Phase 4: Post-Mortem

Document and improve:

  • • Timeline of events and actions taken
  • • Root cause analysis
  • • What worked, what didn't
  • • Specific improvements to prevent recurrence
  • • Update this runbook with lessons learned

When to Hire Security Experts

You Need Professional Security If:
  • Handling sensitive data (PII, financials, health records)
  • Enterprise compliance required (SOC 2, HIPAA, GDPR)
  • High-value target (large company, public figure, financial services)
  • Multi-tenant deployment (serving multiple customers)
  • Integration with critical systems (payment processing, infrastructure)

Cognio Labs Security-Hardened Setup

Our security-hardened OpenClaw deployments implement everything in this guide—and more.

RAK framework implementation
Compliance-ready configuration
Penetration testing included
24/7 monitoring available
Incident response support
Ongoing security updates
Learn About OpenClaw Setup

Frequently Asked Questions

Resources

Written by Cognio Labs Security Team

Experts in AI agent security and enterprise deployments

This guide is updated regularly to reflect new vulnerabilities and best practices. Last updated February 5, 2026.

Don't Risk Your Security

Get a professionally hardened OpenClaw deployment with our RAK framework implementation, compliance configuration, and ongoing security support.