OpenClaw: The Complete Beginner's Guide to Your Self-Hosted AI Assistant

Section 5 of 12

OpenClaw Security Basics and Trust Model Setup

9 min read Updated May 21, 2026

A running OpenClaw instance — Control UI loading, test messages returning responses, daemon staying alive — is a satisfying thing to arrive at. But before this instance gets wired to the real world — before any messaging channels get connected, any tools enabled, or any access granted to files and APIs — the trust model needs to be understood clearly.

Here's where most guides get this wrong: they bury security in an appendix, treating it like optional polish. That doesn't work here. When a chatbot gives bad advice, the human is the one who has to act on it — the damage stops there. An AI agent is fundamentally different: it is the one acting. The moment OpenClaw connects to a messaging channel, a filesystem, or an API, it carries execution authority. If something goes sideways — a misconfiguration, a spoofed message, instructions hidden in content the agent processes — the agent acts. You find out after. That asymmetry is exactly why this section comes before any real capabilities get added.

The security decisions in the next few pages aren't optional tweaks. They're the foundation that makes everything built on top actually trustworthy.

The Three-Layer Trust Model

OpenClaw's security architecture operates at three distinct levels. Miss any one of them and the picture is incomplete.

1. Operator-level trust. This is the highest level of trust in the system. An operator is the person who installed OpenClaw and controls its configuration files, the runtime environment, and the local filesystem. Operator actions aren't mediated by the DM pairing policy or the allowFrom allowlist — they bypass channel-level trust entirely. This matters because anything that can act as the operator (a compromised config file, a malicious skill with local execution access, an exposed Control UI) inherits that authority automatically. Running OpenClaw under a dedicated OS user, not your primary account, is the structural protection against operator-level compromise cascading into your personal data.

2. Gateway-level trust. The Gateway is the control plane: it routes sessions, manages channel connections, and enforces tool policy. Anyone authenticated to the Gateway operates at Gateway scope. This isn't granular per-user authorization — it's a single operator role. If one Gateway serves multiple users (a team setup, for instance), everyone on that team effectively shares the same delegated tool authority over every tool-enabled agent connected to it. That's a powerful configuration for a tight team; it's a significant exposure if it's unintentional.

There's a critical concept to internalize here: session identifiers are routing selectors, not authorization tokens. A sessionKey tells the Gateway which conversation to pull up — it doesn't verify who's actually sending the message^[1]. Conflating "I'm tracking the conversation" with "I've confirmed who's talking" is the root of several classes of security mistake.

3. Channel-level trust. This is where most beginners first interact with security, and where the most common mistakes happen. Each channel connected — Telegram, WhatsApp, Slack, Discord — is an entry point into the agent. Who can actually message the agent through that channel is controlled by allowFrom configuration and the DM pairing policy.

The DM Access Model: Your Primary Trust Boundary

The single most important security control in a default OpenClaw installation is the DM pairing policy. Understand this before connecting any channel.

By default, across Telegram, WhatsApp, Signal, iMessage, Microsoft Teams, Discord, Google Chat, and Slack, OpenClaw runs with dmPolicy="pairing"^[2]. Here's what that actually means in practice:

An unknown sender (someone not already on the allowlist) sends the bot a DM.
The bot responds with a short pairing code and stops there — it doesn't process the message.
The sender gets approved by running openclaw pairing approve <channel> <code> from the terminal.
The sender gets added to a local allowlist and their messages work normally from then on.

It's elegant because it's simple. The agent won't respond to random people who stumble across the bot's handle. The first message from any new sender is always just a code exchange — nothing executes until explicitly approved.

Two things break this model:

1. Setting dmPolicy="open" with a wildcard allowlist. Public inbound DMs require deliberate opt-in — dmPolicy="open" and "*" added to the channel's allowFrom list. Neither one alone is enough, which is a sensible two-step confirmation. But do both? Anyone who finds the bot's handle can send it instructions. On an agent with tools enabled, that means anyone can trigger tool calls — file operations, browser control, network requests — within the agent's current policy.

2. Misunderstanding what allowFrom actually protects. This is the subtler one, and it deserves specific attention.

AllowFrom Spoofing: The Attack Vector Most People Miss

allowFrom controls which identifiers the Gateway accepts messages from. It's a useful filter — but it's not cryptographic identity verification. It checks the sender identifier that the channel reports.

Here's the threat: on some channel configurations, an attacker who can manipulate the sender metadata that OpenClaw receives can appear to be someone trusted. This is AllowFrom spoofing. If the allowlist says "only messages from account X," and an attacker can make a message look like it came from account X, the trust boundary collapses.

The practical defenses against this:

Stick with pairing mode wherever possible. Pairing adds an out-of-band approval step that spoofing can't bypass on its own.
Treat inbound DMs as untrusted input regardless of apparent sender. This is the correct mental model for any action-capable system: "This appears to be from a trusted source" is categorically different from "I have verified this is from a trusted source."
Run OpenClaw on a dedicated machine or VPS, under a dedicated OS user. One user per machine, one Gateway per user. This contains the damage if an attacker breaks through the channel-level boundary.
Don't sign the Gateway's runtime into personal accounts — no personal Apple ID, no personal Google account, no browser profiles connected to a password manager. Use a dedicated OS user and a separate browser profile just for the agent's runtime.

Warning: Running OpenClaw connected to a shared Slack workspace where "everyone in Slack can message the bot" gives every workspace member delegated tool authority. The security documentation^[3] is direct about this: "any allowed sender can induce tool calls (exec, browser, network/file tools) within the agent's policy." This isn't theoretical — it's the designed behavior, operating exactly as intended, in a configuration that wasn't fully thought through.

What a Misconfigured OpenClaw Can Actually Do

Abstract security concepts don't stick. Concrete scenarios do. Here's what a misconfigured or compromised OpenClaw installation can actually do — grounded in the real capabilities the platform is designed to provide.

OpenClaw's bundled tools^[4] include browser control, file operations, external API access, and code execution. These aren't hypothetical — they're the entire point. When thinking about the damage from a misconfiguration, think about an attacker (or injected instruction) able to use all of those capabilities within the agent's current policy.

Concrete scenario 1 — Open DM policy on a tool-enabled agent: dmPolicy="open" and allowFrom: ["*"] are set on Telegram. File system tools are enabled. An attacker who finds the bot's handle can send it instructions to read files from the home directory and return the contents. The agent will do it — that's exactly what it's built to do.

Concrete scenario 2 — Shared Slack workspace: A company Slack is connected to a single Gateway. The agent has exec enabled. Any Slack user can message the bot and ask it to run shell commands. Every allowed user in that workspace is a potential source of execution instructions.

Concrete scenario 3 — Exposed Control UI: OpenClaw is deployed on a cloud VPS for remote access, but port 18789 isn't restricted. Anyone who scans the IP and finds the port can access the browser dashboard directly — no DM pairing, no allowlist check. The Control UI is operator-level access, unmediated by any channel-level trust controls.

None of these require a sophisticated attacker. They require a misconfiguration that's easy to make and easy to overlook if the trust model hasn't been thought through carefully.

Configuration Hardening: The Settings That Actually Matter

Three questions organize every hardening decision: who can talk to the bot, where the bot is allowed to act, and what the bot can touch.

Who can talk to the bot:

Keep dmPolicy="pairing" on every channel unless there's a specific, conscious reason to change it.
Keep allowFrom lists as short as possible. Only identifiers personally verified belong there.
Wildcards ("*") belong in deliberately public service deployments — a different model from what this guide covers.

Where the bot is allowed to act:

The Control UI defaults to http://127.0.0.1:18789/ — localhost only^[5]. Remote access requires explicit configuration. Don't expose the Control UI to a public IP without knowing exactly what that means.
On a VPS, verify port 18789 isn't publicly accessible. A Gateway exposed to the internet without authentication is an open door.
For any node paired (iOS, Android), treat pairing as establishing an operator-trusted connection. After pairing, node actions carry operator-level trust on that node — pair deliberately.

What the bot can touch: This is least privilege applied concretely. The default security="full" with ask="off" for exec is an intentional UX default for trusted single-operator setups — not a vulnerability in itself. But it's a choice to make consciously, not just inherit.

Before enabling any tool — file operations, browser control, external APIs, code execution — ask: is this actually needed right now? If the answer is "maybe eventually," the answer is no. Enable it when needed, then audit afterward.

The Security Audit Command

OpenClaw includes a built-in diagnostic tool designed to catch the most common misconfigurations before they become problems. Run it now, before connecting anything else:

openclaw security audit

It flags common footguns (Gateway auth exposure, browser control exposure, elevated allowlists, filesystem permissions, permissive exec approvals, and open-channel tool exposure)^[1].

The --fix flag: Running openclaw security audit --fix applies intentionally conservative automatic fixes: flips common open group policies to allowlists, restores logging.redactSensitive: "tools", tightens state/config/include-file permissions, and uses Windows ACL resets instead of POSIX chmod^[6]. It won't make every decision — the fixes are narrow, targeting clear footguns.

Also run openclaw doctor, which emits warnings when a provider is open to DMs without an allowlist, or when a policy is configured in a dangerous way, alongside broader operational issues^[7]. It's the complement to the security audit: where the audit focuses on attack surface, doctor flags configurations that are likely to cause unexpected behavior in practice.

Tip: Run openclaw security audit regularly — not just at setup. Every time a channel gets added or a new tool enabled, run the audit afterward. Make it routine.

Reading the output: The audit organizes findings by risk area. Each flagged item explains the risk and how to fix it. Don't skip items marked "low severity" — in the context of an action-capable agent, a small exposure that enables tool calls isn't actually low-stakes.

Verifying Your Security Configuration

Before enabling any sensitive capability, work through this checklist:

DM policies

[ ] Run openclaw doctor and confirm no DM policy warnings appear
[ ] Confirm dmPolicy is set to "pairing" on every connected channel
[ ] Confirm allowFrom lists contain only identifiers personally verified

Network exposure

[ ] Confirm the Control UI is not reachable from the public internet (unless remote access has been intentionally configured)
[ ] If running on a VPS, verify port 18789 is firewalled to trusted IPs only

Host security

[ ] Confirm ~/.openclaw directory permissions are restrictive (the security audit checks this)
[ ] Confirm OpenClaw is running under a dedicated OS user, not a primary user account
[ ] Confirm the Gateway's runtime is not signed into personal accounts

Audit

[ ] Run openclaw security audit — zero findings, or all findings reviewed and consciously accepted
[ ] Run openclaw security audit --fix to apply narrow automatic remediations if needed

There is no perfectly secure setup. The goal is to be deliberate. The checklist above isn't a guarantee — it's a foundation of conscious choices. Everything added after this (channels, models, tools, skills) expands the attack surface. Starting from a hardened baseline means knowing exactly what gets added each time.

If you take one thing from this section: An acting AI's mistake propagates without you — so the only sensible time to understand trust boundaries is before granting any capabilities, not after.

Recap — three things to remember

Three trust layers stack in order: operator → Gateway → channel. Understand all three before connecting anything.

DM pairing mode is the primary channel-level trust boundary — don't open it without a deliberate reason.

Run openclaw security audit after every configuration change, not just at setup.

Sources cited

OpenClaw Installation Guide for Beginners How to Choose and Configure an AI Model for OpenClaw

Only visible to you