Is OpenClaw Safe? Security Verdict and Checklist

The verdict

OpenClaw can be operated safely for a trusted personal-assistant boundary, but it should not be treated as a secure hostile multi-tenant platform.

To work through the controls as practical exercises, take the free OpenClaw Security Hardening course. It covers threat modelling, prompt injection, tool boundaries, secrets, audit and incident response.

That is not hedging. It is the trust model stated in OpenClaw’s own security documentation.

A sensible personal deployment keeps the Gateway private, authenticates its control plane, restricts who can message it, limits tools and credentials, reviews third-party extensions and assumes that model instructions can be manipulated.

An unsafe deployment exposes a tool-enabled agent to strangers, gives it broad host access, shares one Gateway between mutually untrusted users or assumes “self-hosted” means “nothing can leak.”

Why OpenClaw carries more risk than a normal chatbot

A conventional chatbot mostly returns text. OpenClaw can be configured to:

• read and write files;
• execute commands;
• control browsers;
• call external APIs;
• send messages;
• use persistent credentials;
• schedule future work;
• install or invoke plugins and skills.

That agency is the product. It is also the attack surface.

The right security question is not “Can the model be tricked?” Models can be manipulated. The useful question is:

If the model is tricked, what authority can the attacker reach?

OpenClaw’s supported trust model

The official model assumes one trusted operator boundary per Gateway. People inside that boundary may operate agents and the control plane. The Gateway is not intended to isolate adversarial tenants from one another.

If two users should not trust each other with the same credentials, files or tools, give them separate Gateways—preferably under separate operating-system users or on separate hosts.

A session ID is a routing selector, not an authorization token. Separate chat sessions do not turn one shared Gateway into a hardened SaaS tenancy boundary.

The six risks that matter most

1. Untrusted senders can trigger a powerful agent

Open DMs or groups can let strangers submit instructions or malicious content. Use pairing and allowlists before enabling dangerous tools.

2. The Gateway is exposed without strong authentication

A publicly reachable control plane is materially different from a loopback-only service. Keep it local by default. Use reviewed private networking or reverse-proxy controls when remote access is required.

3. Prompt injection reaches real authority

Web pages, documents, messages and retrieved text can contain instructions designed to manipulate the agent. Treat external content as data, not authority, and keep the agent’s permissions narrow enough that a bad decision is recoverable.

4. Tools have excessive host access

Host shell, broad filesystem access and unattended approvals create a large blast radius. Use a sandbox, workspace boundaries and explicit tool policies where the task permits them.

5. Skills and plugins are trusted without review

Current OpenClaw documentation says to treat third-party skills as untrusted code. Skill verification metadata and registry scanning are useful signals, not a substitute for reading what will run and which credentials it can access.

6. Secrets are scattered across config and integrations

Provider keys, channel auth and skill credentials may live in different stores. File permissions, backups, logs and screenshots can leak them even when the Gateway itself is private.

Run the built-in security audit

Start here:

openclaw security audit
openclaw security audit --deep
openclaw security audit --json

The audit checks inbound access, Gateway exposure, tool blast radius, execution approvals, local file permissions, plugins, sandbox drift and other policy problems.

A narrow auto-fix mode exists:

openclaw security audit --fix

Review its output. “Auto-fix” does not mean the tool understands your whole threat model, and it does not convert a shared hostile deployment into an isolated tenant architecture.

A hardened starting point

The official security guide publishes a baseline shaped like this:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-a-long-random-token" },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
}

Do not paste this blindly into a live config. It is a starting posture: local Gateway, isolated DMs and no broad runtime/filesystem authority. Re-enable capabilities deliberately for a specific agent and task.

Pairing, allowlists and groups

For direct messages, prefer:

• pairing when approved people need a join flow;
• allowlist when the permitted sender set is fixed;
• disabled when DMs are unnecessary.

Treat open as an explicit public-exposure decision, not a convenience default.

For groups, restrict which rooms are accepted, which people may trigger the agent and whether a mention is required. Mention gating reduces accidental activation; it does not replace sender authorization.

Pairing commands follow this pattern:

openclaw pairing list <channel>
openclaw pairing approve <channel> <code>

Sandboxing: useful, but understand the boundary

Sandboxing can constrain tool execution, filesystem visibility and container scope. It is especially valuable for untrusted inputs and non-primary sessions.

But sandbox configuration only helps when sandbox mode is actually enabled, and it does not secure credentials or services deliberately mounted into the sandbox. The audit checks for configuration that appears restrictive while the effective mode remains off.

For strong isolation between hostile users, use separate operating-system boundaries or hosts—not merely separate containers under one broadly trusted control plane.

Privacy: self-hosted does not mean fully local

OpenClaw can keep its Gateway state, sessions and tool execution on your machine. Prompts still go to a hosted model when you configure one. Web search, transcription, image generation, embeddings and third-party skills may contact additional services.

Review:

• which model provider receives conversation content;
• which tools can send files or extracted text;
• which skills receive API keys;
• what logs and transcripts retain;
• how backups are encrypted and accessed.

Use the official API usage and costs map as a data-flow inventory, not just a billing document.

Safe-launch checklist

Before the first channel

• Gateway binds to loopback or a deliberately private interface.
• Gateway authentication uses a strong token or reviewed equivalent.
• openclaw security audit --deep has been reviewed.
• State, config and credential files have restrictive permissions.
• Backups exist and are protected.

Before allowing other people

• DM policy is pairing or allowlist.
• Group rooms and triggering senders are restricted.
• Multi-user DMs use an appropriate isolated dmScope.
• Mutually untrusted users have separate Gateways.

Before enabling tools

• Filesystem access is limited to required paths.
• Shell and elevated execution are denied or approval-gated.
• Sandbox mode is actually active where expected.
• Credentials are task-specific and minimally scoped.
• Destructive actions require confirmation or a reversible workflow.

Before installing a skill or plugin

• Publisher and source are identified.
• Files and requested binaries have been reviewed.
• Registry verification and scan status have been checked.
• The skill gets only the credentials and tools it needs.
• The installation can be removed or rolled back.

Is OpenClaw safe for a business?

It can be, when the business treats it like privileged automation infrastructure rather than a chat widget.

Use separate trust boundaries, centrally managed credentials, change review, logging, tested backups and incident procedures. Do not place customers or departments that should be isolated from one another behind one shared personal-assistant Gateway.

Is OpenClaw safe on WhatsApp?

The channel can be operated safely with a dedicated number, QR-linked session, pairing or allowlists and conservative group rules. A WhatsApp login authenticates the linked account; OpenClaw sender pairing separately controls who may trigger the agent.

Do not confuse those two pairing events. Use the current official WhatsApp guide because plugin and reconnect behaviour changes over time.

Bottom line

OpenClaw is not inherently unsafe, and it is not magically safe because it is open source or self-hosted.

It is powerful delegated software. Keep one clear operator boundary, authenticate the Gateway, control senders, minimise permissions, review extensions and assume any model can eventually make a bad decision. If the resulting blast radius is acceptable and recoverable, the deployment is on the right track.