audit-openclaw-security

What this skill does

# 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

1. **Only audit systems the user owns or has explicit permission to assess.**
2. **Never ask for raw secrets.** Do not request gateway tokens/passwords, model API keys, session cookies, OAuth creds, or raw credential files.
3. 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`
4. Treat the **Gateway**, **Control UI**, **browser control**, **paired nodes**, and **automation surfaces** as operator-level access.
5. Default to **audit-only**. Before any config edits, `--fix` operations, firewall changes, or restarts, create a backup first and get explicit user approval.
6. 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:

1. **Anything open + tools enabled**  
   Lock down DMs/groups first, then tighten tool policy and sandboxing.
2. **Public network exposure**  
   LAN bind, Funnel, missing auth, weak reverse-proxy handling.
3. **Browser / node / Control UI exposure**  
   Treat these as operator access, not “just another feature”.
4. **Filesystem permissions**  
   State dir, config file, auth profiles, logs, and transcript locations.
5. **Plugin / skill supply chain**  
   Trust only what is intentionally installed and writable by the right user.
6. **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.