OpenClaw Security Audit Guide: Find Exposure Before It Becomes an Incident

A security setting is only useful if it matches the system that is actually running. OpenClaw can have a restrictive-looking configuration while a per-agent override, public channel, elevated tool, plugin, or unsandboxed execution path quietly expands the blast radius.

That is why an audit belongs in the normal operating routine. OpenClaw's security audit command checks the effective exposure around inbound access, tools, network surfaces, browser control, local files, plugins, and policy drift. It is not a replacement for a threat model, and it does not magically sandbox an agent. It is a practical way to find assumptions worth investigating before they become incidents.

This guide shows how to run the audit, read its findings, remediate in a safe order, and verify the result without confusing “the config file looks right” with “the live agent is constrained.” For deeper hardening, start with our OpenClaw Security Setup guide. For runtime boundaries, see the OpenClaw Sandboxing guide.

Quick Answer: What Does an OpenClaw Security Audit Do?

An OpenClaw security audit inspects the Gateway's configured and effective exposure, then reports findings with severity and structured check IDs. It looks for issues such as open inbound policies, excessive tool authority, weak Gateway authentication, browser exposure, unsafe local permissions, unreviewed plugins, and mismatches between intended and effective policy.

Run the basic check first:

openclaw security audit

Use the deeper probe when you need live Gateway checks:

openclaw security audit --deep

For automation or evidence collection, request structured output:

openclaw security audit --json

The audit is a diagnostic. Review each finding against your trust boundary before changing anything. A warning can describe an intentional posture for a trusted personal assistant, while another finding may expose an unauthenticated Gateway or an untrusted channel with access to powerful tools.

1. Start with the Trust Boundary

OpenClaw's documented security model assumes one trusted operator boundary per Gateway. A shared agent or Gateway is not a hostile multi-tenant boundary for mutually untrusted users. If different users should not share credentials, filesystem access, browser sessions, or delegated tools, separate the Gateway trust boundaries—and ideally the OS users or hosts as well.

Write down four things before interpreting the output:

• who can send messages or events to the Gateway;
• which agents those users can reach;
• which tools those agents can call;
• which host files, networks, browsers, and credentials those tools can access.

This prevents a common mistake: treating every finding as a generic “make it stricter” instruction. The right remediation depends on who is trusted and what the agent is intended to do. A personal assistant may deliberately use a broad tool profile, while a public-facing notification agent should be narrow and isolated.

If you are adding a public channel or remote access, review the OpenClaw Webhooks guide alongside this audit. Authentication and routing are part of the boundary, not deployment details to handle later.

2. Run the Audit in Increasing Depth

Use a short feedback loop rather than changing several security controls at once.

Basic configuration review

openclaw security audit

This is the first pass after a configuration change or before exposing a new network surface. Save the output with the date and the OpenClaw version when you need an operational record.

Deep live checks

openclaw security audit --deep

The deep mode attempts a live Gateway probe. Run it when the Gateway is available and you want to test the path that is actually reachable, not only the values in a file. A successful command still does not prove that every channel, reverse proxy, or plugin is correctly isolated; it is one layer of evidence.

Machine-readable evidence

openclaw security audit --json

JSON output is useful for storing findings, comparing two runs, or failing a deployment check when a high-severity condition appears. Keep the output protected if it contains host paths, account identifiers, or network details. Do not paste secrets into issue trackers just because the surrounding audit output is safe to share.

The --fix option exists, but it is not a universal repair button:

openclaw security audit --fix

The documented remediations are narrow. They can tighten open group policies and correct state, configuration, or include-file permissions. Review the proposed posture and rerun the audit afterward. Do not assume that --fix selects the correct trust boundary, removes every plugin, or makes a powerful agent safe for an untrusted channel.

3. Read Findings by Risk Category

Inbound access

These findings answer: can strangers trigger the agent? Review direct messages, group policies, allowlists, Gateway bind settings, and authentication. A tool-enabled agent should not be reachable by an audience you have not included in its threat model.

A permissive group policy may be acceptable for a private, controlled environment and unacceptable for a public room. If you need multiple trust levels, separate agents or Gateways rather than relying on the model to recognize which participants are trustworthy.

Tool blast radius

The audit checks whether inbound prompts can reach elevated tools or other high-impact capabilities. It also looks for a mismatch where file tools are denied but exec or process remains available without meaningful sandbox constraints.

Tool policy controls which named tools are callable; it does not inspect every shell command inside an allowed execution tool. Denying write does not make an allowed exec command harmless. Ask both questions: is the tool available, and where does it run?

Execution and approval drift

A broad execution security mode, automatic skill approval, or permissive interpreter allowlist can be intentional for a trusted operator. It is still worth recording as a deliberate choice. The audit's warning is a prompt to compare the setting with the real threat model—not automatic proof that the installation is broken.

Network and browser exposure

Check Gateway bind and authentication, remote access, Tailscale exposure, browser relay or CDP endpoints, and any nodes that can execute commands. A browser-control surface can be as sensitive as a shell because it may expose logged-in accounts, private documents, or actions performed as the operator.

Local disk hygiene

Review permissions, symbolic links, configuration includes, and synced-folder paths. The Gateway's config and state can contain credentials or authority that should be readable only by the OpenClaw account. Correct permissions without assuming that filesystem permissions solve channel or tool-policy problems.

Plugins and policy drift

Plugins expand the available code and tool surface. Require an explicit allowlist and review what each enabled plugin can reach. Policy drift findings can also reveal a configured Docker backend with sandbox mode still off, a global minimal profile overridden per agent, or a command deny rule that matches an exact command ID but not arbitrary shell text.

These categories are connected, but they are not interchangeable. A clean plugin list does not authenticate the Gateway. A sandbox does not make an untrusted multi-user Gateway a supported tenant boundary.

4. Remediate in a Safe Order

Use this sequence when the audit reports a problem:

1. Close unintended inbound access. Restrict DMs, groups, hooks, and remote binds before continuing.
2. Remove unnecessary authority. Disable tools, plugins, browser access, and elevated paths the workflow does not require.
3. Choose the runtime boundary. Configure sandboxing for the sessions that need it, then verify the effective mode and scope.
4. Limit data exposure. Remove broad mounts and secret-bearing paths; prefer read-only access for inputs.
5. Harden the host and Gateway. Fix file permissions, authentication, proxy exposure, and browser endpoints.
6. Retest with a harmless task. Confirm the intended session can perform its job and cannot see or modify unrelated data.
7. Record the decision. Note why a broad setting remains, who reviewed it, and when it should be revisited.

Do not make unrelated changes during remediation. A security audit is more useful when each change has a clear before-and-after result.

5. Verify the Effective Sandbox Separately

The audit can identify sandbox policy drift, but it is not the detailed runtime inspector. After changing sandbox or tool policy, use:

openclaw sandbox explain
openclaw sandbox explain --session agent:main:main
openclaw sandbox explain --agent work
openclaw sandbox explain --json

Check the effective mode, scope, workspace access, current session status, tool allow/deny rules, and elevated gates. OpenClaw sandboxing is off by default, and the Gateway process remains on the host even when tool execution moves into a sandbox. An elevated execution path can bypass that isolation.

This distinction explains why two operators can edit the same global configuration and get different results: a per-agent override or a main-versus-non-main session can change the effective boundary. Verify the session that will receive the real traffic.

6. Pre-Flight Checklist

Before connecting a new channel, hook, browser, or remote operator, confirm:

• openclaw security audit has no unexplained high-risk findings;
• openclaw security audit --deep succeeds when a live probe is appropriate;
• JSON output is stored without exposing secrets;
• inbound users and groups match one trusted operator boundary;
• the selected agent has only the tools it needs;
• sandbox mode, scope, workspace access, and mounts are intentional;
• elevated execution is disabled or explicitly gated;
• Gateway authentication and HTTPS or private-network routing are in place;
• browser and node endpoints are not exposed unnecessarily;
• plugin sources and permissions have been reviewed;
• a harmless test confirms the expected allow and deny behavior;
• the next review date is recorded.

For scheduled jobs, add the basic audit and the effective-state check to the same change checklist used for configuration updates. Our OpenClaw Task Flow guide covers durable jobs; the security review should happen before those jobs receive broader tools or channels.

Common Problems and Fixes

“The audit says my trusted setup is broad”

Compare the finding with your trust boundary. Some warnings describe a deliberately broad posture for a personal assistant. Document the decision, reduce authority where practical, and do not expose that same configuration to mutually untrusted users.

“I configured Docker, but tools still run on the host”

Check the effective sandbox mode. A backend setting alone does not enable sandboxing; the documented default mode is off. Run openclaw sandbox explain for the real agent and session.

“I denied file tools, but the agent can still change files”

Check whether exec or process remains available and where it runs. Tool names are not a shell-side-effect filter. Restrict the execution path or put it behind the appropriate sandbox and approval controls.

“--fix changed permissions but the audit still reports exposure”

That is expected when the remaining finding concerns inbound access, tools, network exposure, plugins, or policy. Review each category separately; the automatic remediation is intentionally narrow.

FAQ

How often should I run an OpenClaw security audit?

Run it after configuration, channel, plugin, remote-access, or tool-policy changes, and before exposing a new surface. Operators with frequent changes can store JSON results and compare them during routine maintenance.

Does a passing audit guarantee that an agent is safe?

No. It is a diagnostic against documented checks, not a complete threat model or penetration test. Verify the effective session configuration, test harmlessly, protect the host, and keep the trust boundary explicit.

Is openclaw security audit --deep always required?

No. Use the basic audit for routine review and the deep mode when a live Gateway probe adds useful evidence. Treat a failed probe as a transport or availability issue to investigate, not as proof that the configuration is secure.

Should I share one Gateway between untrusted users?

No. OpenClaw documents a personal-assistant trust model. Use separate Gateways and, ideally, separate OS users or hosts when users are mutually untrusted or adversarial.

Does the audit replace sandboxing?

No. The audit finds exposure and drift. Sandboxing changes where tool execution runs and what it can access. Use both when the threat model requires both, then inspect the effective result.

Sources

• OpenClaw Security — trust model, audit modes, finding categories, check IDs, and remediation scope.
• OpenClaw Sandboxing — sandbox defaults, modes, scope, tool boundaries, and elevated execution.
• OpenClaw Configuration — authoritative configuration reference and schema guidance.
• LobsterDome: OpenClaw Security Setup — related host and Gateway hardening context.
• LobsterDome: OpenClaw Sandboxing Guide — related sandbox, policy, and elevated-access detail.
• LobsterDome: OpenClaw Webhooks Guide — inbound event and delivery considerations.

Sources accessed August 13, 2026.