- What is OpenClaw? (plain English)
- Glossary
- What is Moltbook?
- Threat model
- Hardening checklist
- Detecting OpenClaw requests (for hosting services)
- Architecture (technical)
- Repo map
- Deployment: Standalone Mac mini
- Deployment: Isolated VPS
- Deployment: Cloudflare Moltworker
- Deployment: Docker Model Runner
- Commands + troubleshooting
- Optimizations:
- Security documentation:
openclaw security auditcommand reference- Official security advisories (CVEs/GHSAs)
- Security audit analysis (Issue #1796)
- Second security audit (Medium article)
- Third security audit (ZeroLeeks AI Red Team)
- Post-merge security hardening
- Open upstream security issues
- Open upstream security PRs
- Ecosystem security threats
- SecurityScorecard STRIKE report analysis (Feb 2026, 28k+ exposed instances)
- Model poisoning and sleeper agent backdoors (Feb 2026 Microsoft research)
- Cisco AI Defense skill scanner analysis (Feb 2026, blog post + tool evaluation)
- AI model analysis comparison
- Worst-case security scenarios:
- Overview
- Mac Mini risks
- VPS risks
- Moltworker risks
- Cross-cutting vulnerabilities
- ClawHub marketplace risks (Feb 2026 campaign)
- Skills.sh risks (supply chain)
- Prompt injection attacks (27 examples)
- Misconfiguration examples
This folder is a living knowledge base for the OpenClaw framework — actively maintained documentation that has grown from an initial multi-model AI analysis into a broad reference covering security audits, deployment operations, threat intelligence, and beginner-friendly explanations.
What you'll find here:
| Section | What it covers |
|---|---|
| Plain English | What OpenClaw is, glossary, "explain it like I'm new" |
| Technical | Architecture deep-dive, repo map for contributors |
| Deployment | Mac mini (local-first), Isolated VPS (remote + hardened), Cloudflare Moltworker (serverless), Docker Model Runner (local AI, zero API cost) |
| Privacy & Safety | Threat model, hardening checklist, request fingerprint detection |
| Security Audits | Independently verified audit analyses, CVE/GHSA tracking, upstream issue monitoring |
| Worst-Case Scenarios | Attack catalogs, prompt injection examples, supply chain threats, incident response |
| Optimizations | Cost/token reduction, model routing recommendations |
| AI Model Comparison | Accuracy benchmarks across five AI models' analyses |
What started as a synthesis of five AI models' analyses has expanded through continuous upstream tracking and independent code verification. It reconciles analyses from Copilot GPT-5.2, Gemini 3.0 Pro, GLM 4.7, Opus 4.5, and Kimi K2.5 — with an accuracy comparison showing which models verified claims against source code and which accepted them at face value.
Repo docs + code win. Model summaries are supporting material.
OpenClaw is a self-hosted AI assistant platform. You run an always-on process called the Gateway on a machine you control (a Mac mini at home or an isolated VPS). The Gateway connects to messaging apps (WhatsApp/Telegram/Discord/iMessage/… via built-in channels + plugins), receives messages, runs an agent turn (the “brain”), optionally invokes tools/devices, and sends responses back.
Key idea: your Gateway host is the trust boundary. If it’s compromised (or configured too openly), your assistant can be turned into a data-exfil / automation engine.
Official docs starting point:
- https://docs.openclaw.ai/start/getting-started
- https://docs.openclaw.ai/gateway
- https://docs.openclaw.ai/gateway/security
- Standalone Mac mini (local-first, high privacy)
- The Gateway runs on a Mac mini you own.
- Default best practice: keep it loopback-only (
gateway.bind: "loopback") and access it locally. - Optional remote access should be via SSH tunnels or Tailscale Serve, not public ports.
- Isolated VPS server (remote, locked down)
- The Gateway runs on a small Linux VPS.
- Fastest path: DigitalOcean 1-Click Deploy pre-configures security hardening automatically.
- Default best practice: keep it loopback-only and access it via SSH tunnel or tailnet.
- Harden the host like any admin system (dedicated user, firewall, patching, log hygiene).
- Cloudflare Moltworker (serverless, managed infrastructure)
- The Gateway runs inside Cloudflare's Sandbox SDK container on their global edge network.
- No hardware to manage; automatic scaling and isolation.
- Uses R2 for persistence, AI Gateway for model routing, Browser Rendering for web automation.
- Proof-of-concept; requires Cloudflare Workers paid plan ($5/month minimum).
- Docker Model Runner (local AI, zero API cost)
- Run LLMs locally via Docker Desktop's Model Runner.
- Zero API costs after initial model download.
- Complete privacy — no data leaves your machine.
- Requires Docker Desktop 4.40+ and compatible hardware (Apple Silicon, NVIDIA GPU, or AMD GPU).
- Standalone Mac mini (local-first)
- Isolated VPS (remote + locked down)
- DigitalOcean 1-Click Deploy (recommended)
- Cloudflare Moltworker (serverless)
- Docker Model Runner (local AI, zero cost)
The repo strongly recommends using the onboarding wizard; it sets up:
- a working Gateway service (launchd/systemd)
- auth/provider credentials
- safe access defaults (pairing, token)
Recommended installer:
curl -fsSL https://openclaw.ai/install.sh | bashAlternative:
npm install -g openclaw@latestopenclaw onboard --install-daemonopenclaw gateway status
openclaw status
openclaw healthThree levels of security auditing:
# Read-only scan of config + filesystem permissions (no network calls)
openclaw security audit
# Everything above + live WebSocket probe of the running gateway
openclaw security audit --deep
# Apply safe auto-fixes first, then run full audit to show remaining issues
openclaw security audit --fix| Flag | What it adds | Modifies system? |
|---|---|---|
| (none) | Scans config, filesystem permissions, channel policies, model hygiene, plugin trust, attack surface summary (50+ check IDs across 12 categories) | No — read-only |
--deep |
All base checks + live WebSocket probe of running gateway (5 s timeout), verifies auth handshake | No — read-only probe |
--fix |
Applies safe fixes before running the full audit: chmod 600/700 on state/config/credentials, flips groupPolicy open→allowlist, sets logging.redactSensitive off→"tools". Report shows remaining issues post-fix |
Yes — safe defaults only; no destructive changes |
Note:
--fixruns the fix pass before the audit (src/cli/security-cli.ts:46), so the report you see reflects the hardened state. Any findings that remain are issues--fixcannot auto-resolve.
If you only do one security thing, do this:
openclaw security audit --fixSee the full command reference for what each check covers, what --fix changes, and which documented issues the audit can and cannot detect.
(Security audit docs: https://docs.openclaw.ai/gateway/security)
OpenClaw is easiest to understand as 6 layers:
-
Gateway (control plane) — one long-running process that owns:
- message ingress/egress
- sessions + transcripts
- routing rules
- plugin loading
- tool execution policy + sandboxing
- node/device pairing and invocations
-
Channels — adapters from Telegram/WhatsApp/etc. into a normalized message/event shape.
-
Routing + sessions — decides which “agent/session” handles which chat.
-
Agent runtime — takes context (system prompt + history + attachments), calls your chosen model provider, streams responses, and can request tools.
-
Tools — optional capabilities beyond text (web fetch/search, browser control, exec, cron, nodes/devices).
-
Surfaces — where you interact:
- chat apps (WhatsApp/Telegram/…)
- Control UI dashboard (web)
- macOS menu bar app
This matters because your security choices mostly reduce to:
- Who can trigger the agent? (pairing + allowlists + group policies)
- What can the agent do once triggered? (tools/sandboxing/nodes)
- What can the agent reach? (network exposure, filesystem access, accounts)
This FAQ is intentionally long and practical; it’s the “things you’ll actually Google at 2am.”
- Mac mini (recommended for most privacy-first users): always-on, easy local access, no cloud exposure by default.
- VPS (recommended for always-on + remote access): great uptime, but higher security responsibility. DigitalOcean 1-Click handles hardening automatically.
- Cloudflare Moltworker (low-maintenance serverless): no hardware to manage, pay-as-you-go, but proof-of-concept status.
- Docker Model Runner (maximum privacy + zero cost): run local LLMs via Docker Desktop for complete privacy and no API fees. Requires Apple Silicon, NVIDIA, or AMD GPU.
- Laptop (okay for learning/dev): simplest to start, but sleeps often and you may be tempted to expose it.
See runbooks:
No. OpenClaw is a self-hosted assistant platform that talks to models (Anthropic/OpenAI/etc.) and wraps them with routing, sessions, tools, and chat integrations.
The main always-on process is the Gateway (default port 18789) which multiplexes:
- a WebSocket control plane
- the dashboard/control UI (HTTP)
- optional HTTP endpoints (OpenAI-compatible APIs)
See: https://docs.openclaw.ai/gateway
By default, OpenClaw stores state under ~/.openclaw/ (or ~/.openclaw-<profile>/ for profiles). This includes config, credentials, and session transcripts.
See: https://docs.openclaw.ai/gateway/security ("Credential storage map")
This repo's positioning is local-first control. Still, your chosen model provider will receive whatever text/media is sent to it for inference, unless you run a local model.
- Run on a single-user machine you control (Mac mini).
- Keep the Gateway loopback-only.
- Use pairing/allowlists so only you can talk to it.
- Don’t enable powerful tools until you understand the blast radius.
Use the wizard:
openclaw onboard --install-daemonThe Gateway likely has auth enabled and the UI is missing the token/password.
Fast fixes:
- Run
openclaw dashboard(it prints a tokenized URL). - If remote: bring up an SSH tunnel first:
then open
ssh -N -L 18789:127.0.0.1:18789 user@gateway-host
http://127.0.0.1:18789/?token=....
See: https://docs.openclaw.ai/help/faq (Control UI unauthorized)
Pairing is owner approval for:
- DM pairing (who can message the bot)
- device/node pairing (which devices can connect)
See: https://docs.openclaw.ai/start/pairing
openclaw gatewayruns the Gateway in the foreground in your terminal.openclaw gateway restartrestarts the background service (launchd/systemd).
See: https://docs.openclaw.ai/help/faq
gateway.port controls the single multiplexed port for WebSocket + HTTP. Precedence is:
--port > OPENCLAW_GATEWAY_PORT > gateway.port > default 18789
See: https://docs.openclaw.ai/help/faq
Usually no.
Preferred patterns:
- Loopback + SSH tunnel (universal)
- Loopback + Tailscale Serve (best UX)
Only bind to LAN/tailnet when you understand the auth requirements.
See: https://docs.openclaw.ai/gateway/remote and https://docs.openclaw.ai/gateway/tailscale
Yes, but it’s usually unnecessary; one Gateway can run multiple channels and agents.
If you do, you must isolate:
- config path (
OPENCLAW_CONFIG_PATH) - state dir (
OPENCLAW_STATE_DIR) - workspace (
agents.defaults.workspace) - port (
gateway.port)
See: https://docs.openclaw.ai/gateway/multiple-gateways
Use:
openclaw status --all
openclaw logs --followSee: https://docs.openclaw.ai/help/faq (log locations)
All three matter, but the practical order is:
- Inbound access (DM/group policies)
- Tool blast radius (exec/browser/web)
- Network exposure (bind modes, proxies, auth)
- Host compromise (OS hardening, keys, patching)
See: https://docs.openclaw.ai/gateway/security
Plugins run in-process with the Gateway. Treat them like installing arbitrary code.
Recommendation:
- only install plugins you trust
- prefer pinned versions
- keep an explicit allowlist if supported
See: https://docs.openclaw.ai/gateway/security ("Plugins/extensions")
A local model is the strongest privacy posture because it avoids sending content to a third-party provider. However, it changes the safety profile: smaller/weak local models can be easier to prompt-inject and may handle tool policies worse.
See: https://docs.openclaw.ai/gateway/local-models
Consider DM session isolation (multi-user mode) so each peer gets an isolated DM session, and use identity linking only where appropriate.
For multi-agent setups, each agent can also be scoped independently: per-agent sandbox isolation, tool allow/deny policies, and workspace access controls prevent one agent's context from leaking into another. See per-agent access scoping for details.
See: https://docs.openclaw.ai/gateway/security ("DM session isolation") and https://docs.openclaw.ai/concepts/session
Purpose: This section documents what can go wrong in the worst possible misconfiguration or compromise scenarios for each deployment type.
Read this if: You're evaluating OpenClaw for sensitive use cases, want to understand the blast radius of potential failures, or need to build a threat model for your organization.
See the detailed breakdown in 05-worst-case-security/.
| Deployment | Trust Boundary | Biggest Risk | Recovery Complexity |
|---|---|---|---|
| Mac Mini | Your hardware | Physical access, cloud sync | Medium (rotate keys) |
| VPS/1-Click | Shared infra | Internet exposure, root compromise | High (rebuild VPS) |
| Moltworker | Cloudflare | No egress filtering, R2 breach | Very High (no local control) |
Based on source code review of:
src/gateway/net.ts- Network binding with fallback chainssrc/gateway/auth.ts- Authentication mechanismssrc/agents/bash-tools.exec.ts- Shell executionsrc/pairing/pairing-store.ts- Credential storagesrc/security/audit.ts- Security audit checks
Critical vulnerabilities if misconfigured:
- Silent binding fallback - Loopback failure → 0.0.0.0 exposure (
src/gateway/net.ts:159-164) - Dangerous auth flags -
dangerouslyDisableDeviceAuthbypasses device verification (src/config/types.gateway.ts:69-72) - No encryption at rest - Credentials protected only by file permissions (0o600/0o700)
- Egress-free Moltworker - Sandbox can exfiltrate to any server
| Document | Coverage |
|---|---|
| Overview | Attack surface comparison, decision guide, severity levels |
| Mac Mini Risks | Physical access, cloud sync trap, silent network exposure |
| VPS Risks | Internet exposure, multi-tenant risks, credential storage |
| Moltworker Risks | Trust boundaries, egress filtering, R2 single point of failure |
| Cross-Cutting | Prompt injection, tool execution, channel tokens, supply chain |
| ClawHub Marketplace Risks | Skills marketplace supply chain, ClawHavoc campaign, social engineering |
| Prompt Injection Attacks | 27 attack examples with data exfiltration scenarios |
| Misconfiguration Examples | 10 real mistakes with step-by-step fixes |
| Incident Response | Containment, credential rotation, recovery procedures |
📚 Key resource: The Prompt Injection Attacks guide (27 examples with defenses) is referenced throughout this documentation. If you read one security document beyond the threat model, read that one.
Purpose: Documents how third-party services can identify HTTP requests originating from OpenClaw, and what OpenClaw users should know about their request fingerprint.
Read this if: You run a hosting service/API and want to identify OpenClaw traffic, or you're an OpenClaw user who wants to understand what your instance reveals about itself.
| Request type | Header | Value | Detectable? |
|---|---|---|---|
| Media file fetches | User-Agent |
OpenClaw-Gateway/1.0 |
Yes — explicitly names OpenClaw |
| GitHub API (signal-cli install) | User-Agent |
openclaw |
Yes — explicitly names OpenClaw |
| Anthropic OAuth API | User-Agent |
openclaw |
Yes — explicitly names OpenClaw |
| Perplexity/OpenRouter API | HTTP-Referer |
https://openclaw.ai |
Yes — domain identifies OpenClaw |
| Perplexity/OpenRouter API | X-Title |
OpenClaw / OpenClaw Web Search |
Yes — explicitly names OpenClaw |
| MiniMax VLM API | MM-API-Source |
OpenClaw |
Yes — custom header |
| ACP protocol | clientInfo.name |
openclaw-acp-client |
Yes — protocol-level identification |
| WebFetch (browsing websites) | User-Agent |
Chrome browser string | No — indistinguishable from real browser |
| Brave Search API | (no custom UA) | Default fetch UA | Weak — Node.js fetch fingerprint only |
| xAI Grok API | (no custom UA) | Default fetch UA | Weak — Node.js fetch fingerprint only |
The full analysis includes source code references, Cloudflare WAF rules (with regex examples for Business/Enterprise), and a guide for placing Cloudflare as a reverse proxy in front of your Gateway with inbound header protection: Detecting OpenClaw Requests
- Getting started: https://docs.openclaw.ai/start/getting-started
- Install: https://docs.openclaw.ai/install
- Gateway (runbook): https://docs.openclaw.ai/gateway
- Gateway security: https://docs.openclaw.ai/gateway/security
- Remote access: https://docs.openclaw.ai/gateway/remote
- Tailscale: https://docs.openclaw.ai/gateway/tailscale
- Pairing: https://docs.openclaw.ai/start/pairing
- Help / FAQ: https://docs.openclaw.ai/help/faq
- Troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting
- External security guide: https://vibeproof.dev/blog/moltbot-security-setup-guide