OpenClaw gives your AI assistant shell access, browser control, and connections to a dozen messaging platforms. That power comes with real security consequences — and how you host it determines whether those risks are managed or ignored.
Last updated: February 15, 2026 · Based on OpenClaw releases through v2026.2.14 and 41 published security advisories.
OpenClaw is an open-source personal AI assistant that connects LLMs (Claude, GPT, Gemini, and others) to messaging platforms like Telegram, WhatsApp, Slack, Discord, Signal, and more. Unlike simple chatbot wrappers, OpenClaw runs a local Gateway process that gives the AI unrestricted shell access, browser control, file system operations, cron scheduling, and tool execution.
This makes OpenClaw extraordinarily useful — and extraordinarily sensitive. Your instance holds LLM API keys, messaging platform tokens, conversation history, and a shell environment where the AI can run any command. If misconfigured, anyone on Telegram (or WhatsApp, Slack, Discord) could talk to your bot, trigger tool execution, or drain your API budget.
OpenClaw (originally named ClawdBot, briefly MoltBot) has undergone rapid security hardening since late 2025. Understanding this timeline matters because older tutorials and configs may use insecure defaults that have since been changed.
The earliest ClawdBot versions (v0.x–1.x) had no DM access control. Anyone on the messaging platform could message your bot. Basic allowFrom filtering was added in v1.3.0 (Dec 2025), but it was opt-in.
The 2.0.0-beta series (still under the ClawdBot name) moved the Gateway to loopback-only binding, removed PAM authentication in favor of token/password auth, added per-group allowlists for Discord, and required explicit enabled: true for providers (no more auto-start from env tokens).
Versions v2026.1.8 through v2026.1.11 changed the default dmPolicy from "open" to "pairing" across all messaging providers. Sandbox scope was changed to one container per agent. Slash commands were gated to authorized senders only. This was the single biggest security shift in the project's history.
Default-deny for slash/control commands (v2026.1.16). The project was renamed from ClawdBot to MoltBot (Jan 27) and then to OpenClaw (Jan 29) following trademark concerns. Credential redaction from gateway API responses (v2026.2.6). Explicit SSRF deny policy and browser auth requirements (v2026.2.12). Plugin safety scanner. Nostr API tampering patch. 41 security advisories published and patched.
The pace of change is itself a risk factor. OpenClaw releases almost daily — sometimes multiple times per day. Each release can introduce new security controls, change defaults, or fix vulnerabilities. If you self-host, you're responsible for tracking every one of these.
As of v2026.2.14, OpenClaw's security model rests on four pillars:
Unknown senders must provide a pairing code before the bot responds. The default dmPolicy is "pairing". Groups require explicit allowlists. Slash commands are gated to authorized users. Older versions used "open" by default.
The WebSocket control plane binds to 127.0.0.1:18789. Remote access requires Tailscale or SSH tunnels with password/token authentication. The Canvas UI and A2UI endpoints require auth since v2026.2.6.
Docker sandbox containers (one per agent by default) isolate tool execution. The exec approval system requires user consent for elevated operations. But sandbox usage is optional and not enforced — many users run without it.
The openclaw doctor command audits DM policies, OAuth token expiry, Telegram privacy settings, and provider configurations. It surfaces risky settings. But it only helps if you run it.
As of February 2026, OpenClaw has published 41 security advisories on GitHub.
The project maintains responsible disclosure through a dedicated security contact (Jamieson O'Reilly, Security & Trust lead), a MITRE ATLAS-based threat model, and a trust.openclaw.ai trust center.
The high advisory count reflects both the project's transparency and the inherent attack surface of an AI agent with shell access. Here are some of the most severe findings:
| Vulnerability | Severity | Impact |
|---|---|---|
| Node invoke approval bypass | Critical | Remote code execution — attacker can execute arbitrary commands without approval |
Gateway /tools/invoke escalation | High | ACP permission auto-approval lets unauthorized tool calls bypass policy |
| Arbitrary transcript file write | High | Attacker controls sessionFile path, enabling arbitrary file writes |
| macOS deep link truncation | High | Conceals agent messages in confirmation dialogs, hiding malicious actions |
| Chrome extension relay binding | High | Wildcard binding treated as loopback, exposing relay to network |
| SSRF via media URL hydration | Moderate | Server-side request forgery through attachment URLs |
| Nostr profile API tampering | Moderate | Unauthenticated profile modification |
For self-hosters, each advisory means monitoring the project's release notes, verifying your version is patched, and restarting your instance. Missing even one critical patch — like the RCE via node invoke bypass published on February 14, 2026 — can leave your instance fully compromised.
Self-hosting OpenClaw is a valid choice — the project is open source for a reason. But running it securely requires understanding and mitigating these specific risks:
The open-source version stores API keys and tokens in ~/.openclaw/credentials/ in plaintext. OpenClaw's own threat model classifies this as P0 (highest priority) and recommends encryption at rest with rotation capability — but this hasn't been implemented in the open-source release yet.
If your server is compromised, your Anthropic, OpenAI, Google, or OpenRouter API keys are immediately exposed.
OpenClaw releases almost daily. Security defaults have changed multiple times (DM policy, sandbox scope, command gating). Upgrading without reviewing changelog can silently preserve old insecure settings via legacy config migration. Downgrading or pinning versions means missing security patches.
Your instance could be running with dmPolicy: "open" from a pre-v2026.1.8 config while you believe the new defaults protect you.
Binding the Gateway to 0.0.0.0 instead of the default 127.0.0.1 exposes the WebSocket control plane to your network or the internet. Before v2026.2.6, the Canvas host and A2UI assets didn't require authentication at all.
An exposed Gateway lets attackers send messages as you, invoke tools, and control the agent remotely.
A bare-metal or VM self-host typically runs OpenClaw alongside other services. If the AI agent is tricked via prompt injection into running curl, cat, or env, it can access anything on the same machine — your database, other services, SSH keys, environment variables.
Prompt injection leads to lateral movement across your server. The blast radius is unbounded.
OpenClaw's plugin system runs third-party code without sandboxing. There's no skill signing, no version pinning by default, and auto-updates can pull malicious versions. The plugin safety scanner (added in v2026.2.6) provides basic static checks but isn't comprehensive.
A compromised or malicious plugin has full access to your OpenClaw environment and credentials.
41 security advisories in a project that ships daily releases. Each advisory requires verifying your version, understanding the impact, updating, and restarting. There is no auto-update mechanism for the Gateway itself — only for plugins.
A single missed patch window can leave your instance vulnerable to known exploits. The RCE published on Feb 14, 2026 affected the previous day's release.
If you choose to self-host, these steps significantly reduce your attack surface. This isn't optional hardening — each item addresses a documented vulnerability or risk from the threat model.
Required for security patches addressing DoS and permission model vulnerabilities in the Node.js runtime itself.
dmPolicy: "pairing" or "allowlist" Run openclaw doctor and verify the DM policy for every configured messaging platform. Never use "open" in production.
Never bind to 0.0.0.0. Use Tailscale Serve or SSH tunnels for remote access. Enable password or token authentication.
chmod 700 ~/.openclaw and chmod 600 ~/.openclaw/credentials/*. The credentials directory contains plaintext API keys.
Configure sandbox.scope: "agent" for containerized tool execution. Especially important when web tools are enabled.
Don't auto-update. Read the release notes for security changes, breaking changes, and new defaults.
Only install plugins from trusted sources. Review plugin code. Disable auto-updates for plugins.
groupPolicy: "allowlist" for all group chats Without this, any group member can trigger the bot. Group messages are a common prompt injection vector.
Watch the repository for security alerts. With 41 advisories and counting, you need to be notified promptly.
Ideally a dedicated VM or container with no access to other services. Network-level isolation (firewall rules blocking private IPs from the OpenClaw process) reduces the blast radius of prompt injection.
Following this checklist puts you in a strong position. But maintaining it requires ongoing vigilance — every OpenClaw update can change defaults, every new plugin introduces risk, and every missed advisory is a potential exposure window.
The hardening checklist above is effectively what our managed platform implements at the infrastructure level — except it's enforced by architecture rather than configuration, and maintained by the platform rather than by you.
All API keys and tokens are encrypted with AES-256-GCM before being stored in the database. The encryption master key is a Kubernetes Secret in the platform namespace, inaccessible to user pods. Credentials are decrypted only at provision/restart and written to auth-profiles.json inside the pod — never to environment variables.
Each user gets an isolated Kubernetes pod with NetworkPolicy enforcement: no pod-to-pod communication, no access to the Kubernetes API, cluster services, or cloud metadata endpoints. Egress is limited to public internet on ports 80/443, with all private IP ranges blocked. Even if the AI is tricked by prompt injection, it can't reach your database, other users' pods, or internal services.
Every managed instance launches with dmPolicy: "allowlist" and groupPolicy: "allowlist". Only the Telegram, Slack, or Discord IDs you explicitly configure during setup can message the bot. Unknown senders are silently ignored — they don't even get a "not authorized" response.
Security patches and OpenClaw version updates are applied across all instances. You don't need to monitor release notes, track CVEs, or figure out if a breaking change affects your config. The platform handles version management and restarts.
CPU (500m), memory (512Mi), and storage (20Gi) limits are enforced per pod. The seccomp default profile is applied. allowPrivilegeEscalation: false. No Kubernetes service account token is mounted. These aren't suggestions in a hardening guide — they're enforced by the infrastructure.
Token consumption and LLM costs are tracked and visible in the dashboard. If a prompt injection attack triggers excessive API calls, you'll see it immediately in your usage analytics — not in a surprise bill from your LLM provider weeks later.
| Security dimension | Self-hosting | OpenClaw Setup |
|---|---|---|
| Credential encryption | Plaintext on disk (P0 in threat model) | AES-256-GCM at rest |
| Network isolation | Manual firewall rules, often skipped | Kubernetes NetworkPolicy, enforced |
| DM access control | Correct defaults since v2026.1.9, but legacy configs may override | Allowlist-only, enforced at provisioning |
| CVE patching | Manual: monitor, update, restart, verify | Managed: platform applies patches |
| Blast radius of prompt injection | Entire server (unless containerized) | Single isolated pod with blocked private IPs |
| Resource limits | Manual configuration | Enforced: 500m CPU, 512Mi RAM, 20Gi storage |
| Usage monitoring | Build your own dashboards | Built-in token and cost analytics |
| Setup time to secure state | Hours to days (K8s, NetworkPolicy, encryption, auditing) | Minutes (guided wizard) |
OpenClaw has matured significantly since its early open-by-default days. With pairing-first DM policies (since v2026.1.9), default-deny command gating, and SSRF protections, the current version is substantially more secure — but only if you keep it updated and configure it correctly. Self-hosting still carries risks around credential storage, configuration drift, and CVE tracking.
As of February 2026, OpenClaw has published 41 security advisories on GitHub, including critical RCE vulnerabilities, tool escalation bugs, SSRF issues, and file write exploits. The project maintains a responsible disclosure program through its trust center and patches issues promptly.
The safest approach is either (1) using a managed hosting platform like OpenClaw Setup that provides encrypted credential storage, Kubernetes pod isolation, network policies, and allowlist-enforced access control by default, or (2) replicating this infrastructure yourself with Kubernetes, NetworkPolicy, encrypted secret management, and strict DM policies — which requires significant DevOps expertise.
In the open-source self-hosted version, credentials in ~/.openclaw/credentials/ are stored in plaintext. The project's own threat model flags this as P0 (highest priority). Managed hosting platforms like OpenClaw Setup encrypt all credentials with AES-256-GCM before storing them.
Since v2026.1.9, the default DM policy is "pairing" — unknown senders must provide an approval code. Before this version, the default was open to everyone. If you're running an older version or have set dmPolicy to "open", anyone on the messaging platform can interact with your bot.
Yes, in theory. You'd need to set up Kubernetes, write NetworkPolicies that block all private IP ranges, implement AES-256-GCM encryption for credentials at rest, configure per-pod service accounts with no RBAC bindings, enforce resource limits, and build monitoring dashboards. The comparison page details the full scope of what's involved.
OpenClaw is powerful. Running it securely shouldn't require a dedicated DevOps engineer. OpenClaw Setup gives you encrypted credentials, network isolation, and allowlist access control from the first minute — for free.
LLM subscriptions beat raw API keys by 5–20x. Plus: save even more with Codex CLI and Claude Code integration.
OpenClaw internal memory files explainedA practical guide to AGENTS.md, IDENTITY.md, SOUL.md, TOOLS.md, MEMORY.md, and the rest of the workspace files.
AI team vs AI assistantWhy multiple specialized OpenClaw instances beat a single generalist — and how to set it up.
Get started with built-in security: isolated runtime, encrypted credentials, and allowlist-only access.