audit-openclaw-security

Run a defensive, permissioned security audit of an OpenClaw deployment and turn the results into a practical remediation plan.

This revision is tuned for OpenClaw 2026.3.8 and uses

{baseDir}

when referencing bundled scripts from commands.

Guardrails

Only audit systems the user owns or has explicit permission to assess.
Never ask for raw secrets. Do not request gateway tokens/passwords, model API keys, session cookies, OAuth creds, or raw credential files.

Prefer outputs that are designed to be shareable or redacted:

```
openclaw status --all
```
```
openclaw status --deep
```
```
openclaw gateway probe --json
```
```
openclaw security audit --json
```
```
openclaw security audit --deep --json
```

Treat the Gateway, Control UI, browser control, paired nodes, and automation surfaces as operator-level access.
Default to audit-only. Before any config edits,
```
--fix
```
operations, firewall changes, or restarts, create a backup first and get explicit user approval.
When the user wants remediation, make the backup step explicit:
- ```
openclaw backup create --verify
```
- use
```
--no-include-workspace
```
  if the config is invalid but you still need state + creds
- use
```
--only-config
```
  if the user only wants a minimal safety copy before edits

What “good” looks like

Gateway is bound to loopback unless there is a deliberate, defended reason not to.
Strong Gateway auth is enabled.
No accidental public exposure (LAN bind, port-forward, permissive reverse proxy, Tailscale Funnel).
Control UI is either localhost/Serve or explicitly origin-restricted behind a trusted proxy.
DMs require pairing or strict allowlists.
Groups require mention gating and are not open if broad tools are enabled.
```
session.dmScope
```
is isolated appropriately:
- ```
per-channel-peer
```
  for most multi-user setups
- ```
per-account-channel-peer
```
  when the same provider runs multiple accounts
Tooling is least privilege:
- ```
tools.profile: "messaging"
```
  or stricter for inbox-facing agents
- deny
```
group:runtime
```
  ,
```
group:fs
```
  ,
```
group:automation
```
  on untrusted surfaces
- ```
tools.fs.workspaceOnly: true
```
- ```
tools.exec.security: "deny"
```
  or at least approval-gated
- ```
tools.elevated.enabled: false
```
  unless there is a narrow, intentional need
Plugins and skills are explicitly trusted, minimally writable, and not used as an easy persistence path.
Secrets, transcripts, and logs have tight permissions and an intentional retention plan.

Use the bundled files progressively

Only open the extra files you need for the task:

```
references/command-cheatsheet.md
```
— exact command ladders

references/openclaw-audit-checks.md

— current high-signal

checkId

glossary

```
references/openclaw-baseline-config.md
```
— secure baseline snippets
```
references/platform-mac-mini.md
```
```
references/platform-personal-laptop.md
```
```
references/platform-docker.md
```
```
references/platform-aws-ec2.md
```
```
assets/report-template.md
```
— report structure

Step 0 — Establish context quickly

Collect just enough context to choose the audit path:

Where is OpenClaw running?
- macOS host / Mac mini
- personal laptop
- Docker host
- EC2 / VPS / other cloud VM
Install style?
- native install
- Docker / Compose
- source checkout
Do we have local shell access?
- Mode A: chat-only / user runs commands
- Mode B: agent can run shell commands directly

Mode A — Assisted self-audit (chat-only)

Ask the user to run the following on the OpenClaw host and share the outputs.

Minimum audit set

bash

openclaw --version
openclaw status --all
openclaw status --deep
openclaw gateway status
openclaw gateway probe --json
openclaw channels status --probe
openclaw doctor
openclaw security audit --json
openclaw security audit --deep --json

Helpful extras

bash

openclaw health --json
openclaw backup create --dry-run --json
openclaw backup create --only-config --dry-run --json
openclaw skills list --eligible --json
openclaw plugins list --json

Safe targeted config reads

Prefer targeted reads over a full config dump:

bash

openclaw config get gateway.bind
openclaw config get gateway.auth.mode
openclaw config get gateway.auth.allowTailscale
openclaw config get gateway.controlUi.allowedOrigins
openclaw config get gateway.trustedProxies
openclaw config get gateway.allowRealIpFallback
openclaw config get discovery.mdns.mode
openclaw config get session.dmScope
openclaw config get tools.profile
openclaw config get tools.fs.workspaceOnly
openclaw config get tools.exec.security
openclaw config get tools.elevated.enabled
openclaw config get channels.defaults.dmPolicy
openclaw config get channels.defaults.groupPolicy
openclaw config get logging.redactSensitive

DM / group follow-up checks

If the issue is “the bot is online but DMs or groups behave strangely”, check pairing and mention gating:

bash

openclaw pairing list <channel>

Examples of

<channel>

include

discord

slack

signal

telegram

whatsapp

matrix

imessage

, and

bluebubbles

If the user must share the config

OpenClaw config is often JSON5-like. Redact it before sharing:

bash

python3 "{baseDir}/scripts/redact_openclaw_config.py" ~/.openclaw/openclaw.json > openclaw.json.redacted

Host / network snapshots

macOS

bash

whoami
sw_vers
uname -a
lsof -nP -iTCP -sTCP:LISTEN
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
/usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode
fdesetup status || true

Linux / cloud VM

bash

whoami
cat /etc/os-release
uname -a
ss -ltnp
sudo ufw status verbose || true
sudo nft list ruleset || true
sudo iptables -S || true

Docker / Compose

bash

docker ps --format 'table {{.Names}}	{{.Image}}	{{.Ports}}'
docker compose ps || true
docker port openclaw-gateway 18789 || true

Mode B — Automated local audit (shell access)

Run the bundled collector and report renderer:

bash

bash "{baseDir}/scripts/collect_openclaw_audit.sh" --out ./openclaw-audit
python3 "{baseDir}/scripts/render_report.py" --input ./openclaw-audit --output ./openclaw-security-report.md

Then review

openclaw-security-report.md

, refine wording where needed, and present the final report to the user.

Notes on the collector

It is read-only by default.
It does not run
```
openclaw security audit --fix
```
.
It collects shareable CLI diagnostics plus basic host/network context.

It now captures current high-value signals such as:

```
openclaw status --deep
```
```
openclaw gateway probe --json
```
```
openclaw channels status --probe
```
targeted safe
```
config get
```
values
backup dry-run metadata

How to interpret the audit

Use OpenClaw’s own security audit output as the primary source of truth, then translate it into a clear threat narrative.

Triage order

Prioritise in this order:

Anything open + tools enabled
Lock down DMs/groups first, then tighten tool policy and sandboxing.
Public network exposure
LAN bind, Funnel, missing auth, weak reverse-proxy handling.
Browser / node / Control UI exposure
Treat these as operator access, not “just another feature”.
Filesystem permissions
State dir, config file, auth profiles, logs, and transcript locations.
Plugin / skill supply chain
Trust only what is intentionally installed and writable by the right user.
Model and prompt-injection resilience
Important, but not a substitute for access control.

Findings that are easy to miss in newer OpenClaw builds

Pay extra attention to these newer or high-signal check IDs:

gateway.control_ui.allowed_origins_required

gateway.control_ui.host_header_origin_fallback

```
gateway.real_ip_fallback_enabled
```
```
config.insecure_or_dangerous_flags
```
```
sandbox.dangerous_network_mode
```

tools.exec.host_sandbox_no_sandbox_defaults

tools.exec.host_sandbox_no_sandbox_agents

tools.exec.safe_bins_interpreter_unprofiled

```
skills.workspace.symlink_escape
```

security.exposure.open_groups_with_elevated

security.exposure.open_groups_with_runtime_or_fs

security.trust_model.multi_user_heuristic

Use

references/openclaw-audit-checks.md

and

assets/openclaw_checkid_map.json

to map each finding to likely config paths and remediation areas.

Core remediation patterns

1) Gateway exposure and auth

Prefer
```
gateway.bind: "loopback"
```
.
Require token or password auth for anything beyond strictly local use.
Do not treat
```
gateway.remote.*
```
values as protection for local WS access; actual protection comes from
```
gateway.auth.*
```
.
If the user needs a new shared secret,
```
openclaw doctor --generate-gateway-token
```
is the safe boring path.

2) Reverse proxies and browser-origin policy

If there is a reverse proxy in front of the Gateway:

configure
```
gateway.trustedProxies
```
keep
```
gateway.allowRealIpFallback: false
```
unless there is a very specific need
for non-loopback Control UI use, set
```
gateway.controlUi.allowedOrigins
```
do not enable Host-header origin fallback unless the user knowingly accepts the downgrade

3) Tailscale Serve vs Funnel

```
tailscale.mode: "serve"
```
keeps the Gateway tailnet-only.
```
tailscale.mode: "funnel"
```
is public and should be treated as urgent/high risk.
```
gateway.auth.allowTailscale
```
can allow tokenless Control UI/WebSocket auth via Tailscale identity headers. That assumes the gateway host itself is trusted.
If untrusted code can run on the host, or if any reverse proxy sits in front of the gateway, disable
```
gateway.auth.allowTailscale
```
and require token/password or trusted-proxy auth.

4) DM and group isolation

Use
```
dmPolicy: "pairing"
```
or
```
allowlist
```
for inbox-facing bots.
For shared or support-style inboxes, set
```
session.dmScope: "per-channel-peer"
```
.
For multi-account channel setups, prefer
```
per-account-channel-peer
```
.
Avoid
```
groupPolicy: "open"
```
unless the tool surface is extremely limited.
Require mentions in groups and use
```
agents.list[].groupChat.mentionPatterns
```
where native mentions are unreliable.

5) Tool surface reduction

Start from the conservative baseline in

references/openclaw-baseline-config.md

Good defaults for user-facing agents:

```
tools.profile: "messaging"
```
deny
```
group:automation
```
deny
```
group:runtime
```
deny
```
group:fs
```
```
tools.fs.workspaceOnly: true
```

tools.exec.security: "deny"

and

ask: "always"

tools.exec.applyPatch.workspaceOnly: true

```
tools.elevated.enabled: false
```

6) Node / browser / automation trust

Paired nodes are remote execution surfaces. Audit them like you would audit operator access.
Browser control is not “just viewing pages”; it is effectively remote operator capability.
```
gateway
```
/
```
cron
```
tools create persistence and should not be reachable from untrusted chat surfaces.

7) Secrets, logs, transcripts, and writable paths

Audit and discuss these paths carefully without asking for raw contents:

```
~/.openclaw/openclaw.json
```
```
~/.openclaw/secrets.json
```

~/.openclaw/agents/<agentId>/agent/auth-profiles.json

~/.openclaw/agents/<agentId>/sessions/*.jsonl

```
/tmp/openclaw/openclaw-YYYY-MM-DD.log
```
pairing stores under
```
~/.openclaw/credentials/
```

Platform-specific guidance

Load the matching playbook when the environment is clear:

macOS host / Mac mini ->
```
references/platform-mac-mini.md
```
personal laptop ->
```
references/platform-personal-laptop.md
```
Docker / Compose ->
```
references/platform-docker.md
```
EC2 / VPS ->
```
references/platform-aws-ec2.md
```

Deliverable format

Use

assets/report-template.md

or the rendered report from

{baseDir}/scripts/render_report.py

The final deliverable should include:

executive summary
environment overview
findings table with redacted evidence
sequenced remediation plan
verification commands
residual risk / operational practices

Troubleshooting notes

“openclaw: command not found”

Confirm the CLI is installed and on
```
PATH
```
.
On Windows, prefer WSL2 for shell-driven audit flows.
Re-run the official install / update path, then retry
```
openclaw --version
```
.

“Gateway won’t start — configuration invalid”

OpenClaw now fails closed on invalid config keys, invalid values, or invalid types. That is intentional and security-relevant.

Use:

bash

openclaw doctor
openclaw doctor --fix

Even when the config is invalid, diagnostic commands such as

openclaw status

openclaw gateway status

openclaw gateway probe

, and

openclaw health

are still useful.

“Runtime: running” but “RPC probe: failed”

Trust the probe details, not just the supervisor status:

```
Probe target
```
```
Listening
```
```
Last gateway error
```

This often means service/config drift, auth mismatch, or a listener that is not actually reachable by the CLI.

“Bot is online but DMs fail”

Check:

bash

openclaw channels status --probe
openclaw pairing list <channel>

Common root causes:

pending pairing approval
```
dmPolicy
```
too strict for the expected sender
provider-side permission or token drift

“Groups are silent”

Check:

```
groupPolicy
```
```
requireMention
```
```
mentionPatterns
```
audit findings about open groups combined with runtime/fs/elevated tools

Trigger tests (skill author sanity check)

Should trigger:

“Can you audit my OpenClaw setup for security?”
“My OpenClaw gateway is exposed through Tailscale Serve — is that okay?”
“Interpret my
```
openclaw security audit --deep --json
```
findings.”
“I’m running OpenClaw in Docker on a VPS; help me harden it.”
“Why is my OpenClaw Control UI complaining about origins and trusted proxies?”
“My bot is online but DMs don’t reply; can you audit pairing and access policy?”

Should not trigger:

generic macOS hardening unrelated to OpenClaw
generic Docker security unrelated to OpenClaw
general AWS or VPS hardening unrelated to OpenClaw
unrelated software audits

audit-openclaw-security

NPX Install

Tags

SKILL.md Content

audit-openclaw-security

Guardrails

What “good” looks like

Use the bundled files progressively

Step 0 — Establish context quickly

Mode A — Assisted self-audit (chat-only)

Minimum audit set

Helpful extras

Safe targeted config reads

DM / group follow-up checks

If the user must share the config

Host / network snapshots

Mode B — Automated local audit (shell access)

Notes on the collector

How to interpret the audit

Triage order

Findings that are easy to miss in newer OpenClaw builds

Core remediation patterns

1) Gateway exposure and auth

2) Reverse proxies and browser-origin policy

3) Tailscale Serve vs Funnel

4) DM and group isolation

5) Tool surface reduction

6) Node / browser / automation trust

7) Secrets, logs, transcripts, and writable paths

Platform-specific guidance

Deliverable format

Troubleshooting notes

“openclaw: command not found”

“Gateway won’t start — configuration invalid”

“Runtime: running” but “RPC probe: failed”

“Bot is online but DMs fail”

“Groups are silent”

Trigger tests (skill author sanity check)