How to run OpenClaw's security audit (and read the results)
OpenClaw ships a built-in security audit. When to run it, what --deep and --fix do, and how to make sense of the findings.
OpenClaw ships a built-in checkup: openclaw security audit. Run it with --deep after initial setup and again after any config or networking change. It inspects your real, running setup (exposure, access policies, permissions, risky flags) and reports findings by severity. Fix the criticals, understand the warnings, and rerun until the output holds no surprises.
Running it
openclaw security audit # standard checkup
openclaw security audit --deep # + probes the live Gateway
openclaw security audit --fix # applies safe remediations
openclaw security audit --json # machine-readable output--deep is the one to make a habit of: beyond reading your config, it probes the running Gateway, so it can catch the gap between what you think is configured and what’s actually live. Drift between config and runtime is one of the specific things the audit looks for. If OpenClaw runs in Docker, run the command inside the container (for example with docker compose exec), so it audits the environment the Gateway actually lives in.
--fix applies the safe subset of remediations automatically: tightening file permissions, restoring log redaction, flipping open policies to allowlists. It won’t redesign your setup, but it cleans up the mechanical findings in one move.
What it checks
- Network exposure: is the Gateway reachable from anywhere it shouldn’t be? This is the finding that matters most; an exposed Gateway is the one mistake with no safe version.
- Inbound access policies: DM pairing/allowlists and group mention-gating (who is allowed to talk to your agent).
- Tool blast radius: how much power the agent’s tools have, and whether elevated capabilities are enabled where they needn’t be.
- Filesystem permissions: config and state readable only by the right user.
- Risky flags and unpinned plugins: debug/insecure settings left on, and plugins installed from moving targets instead of pinned versions.
Reading the results like an operator
Findings arrive with a severity and a structured check ID (things like gateway.trusted_proxies_missing). Three habits turn the output from noise into an actual security practice:
- Criticals get fixed, not filed. A critical is the audit telling you a real attack path exists. Stop and close it.
- Every warning gets a verdict. Some warnings are genuinely fine in context: a proxy-related finding on a machine with no proxy, a probe that failed because the CLI lacks an operator scope rather than because anything is broken. The discipline is writing down why each accepted finding is acceptable. An unexplained warning you’ve stopped seeing is a future incident with good camouflage.
- Rerun on every change. The audit is a snapshot. New channel, config edit, Docker change, version upgrade: each is a reason to run it again. The docs themselves frame it this way: after any config change, and before exposing any network surface.
What a healthy result looks like
Not necessarily zero findings: a real setup often carries a couple of understood, documented notes. Healthy means: no criticals you haven’t fixed, no warnings you can’t explain in one sentence, and no drift between the config you wrote and the Gateway that’s running. That’s the bar every Everpod pod is held to before you get the keys, and a perfectly achievable one for a careful self-hoster too.