OpenClaw Security Audit: Read Findings as Attack Paths

A security report can be accurate and still send an operator toward the wrong repair. One critical finding may describe a reachable path from an untrusted sender to host execution. Eight warnings may describe settings that never meet on the same path. Sorting the JSON by severity alone treats those two situations backwards.

The useful output of an OpenClaw security audit is not a smaller warning count. It is a defensible answer to four questions: who can initiate work, which agent receives it, what that agent can reach, and what evidence proves a disallowed caller is stopped. The audit supplies facts for that answer. It does not make the trust decision for you.

A finding is a path, not a verdict

openclaw security audit reads configuration and filesystem state without loading every installed plugin runtime. Its findings have stable checkId values, a severity, an explanation, and—where OpenClaw can offer one—a remediation. That makes the report suitable for versioned review and automation. It does not make every row equally urgent.

Start by connecting findings into an attack path. A permissive group policy matters more when the reachable agent also has host execution, broad filesystem access, browser control, or credentials. Host execution matters more when a sender boundary is open. A plugin warning matters more when that plugin is enabled and its tools are reachable by sessions that process untrusted content.

This is why “fix every critical first” is too crude. Severity estimates impact in a general deployment. The local attack path supplies reachability and business consequence.

Failure modes hidden by a flat severity list

The first pass should ignore cosmetic ordering and group findings by ingress, routing, capability, authority, and control plane. That exposes multiplication. An open messaging surface and an exec-enabled agent are not two independent issues; together they may be one immediate route to the host. A warning about an unpinned plugin is a different class: supply-chain drift that deserves change control, but not necessarily emergency containment.

For machine review, preserve the full private report and extract only stable identifiers into the ticket:

openclaw security audit --json \
  | jq -r '.findings[] | [.severity, .checkId] | @tsv'

openclaw security audit --deep --json \
  | jq '.findings[] | select(.severity == "critical") | .checkId'

Do not paste the raw JSON into a public issue, chat, or article. Finding details can reveal channel policy, filesystem paths, enabled tools, plugins, and exposure choices. The check ID is usually enough to assign ownership; the private report remains the evidence.

The trust model comes before the warning count

OpenClaw documents a personal-assistant trust model: one trusted operator boundary, not hostile multi-tenant isolation inside one shared Gateway. That sentence changes how an audit should be interpreted. If mutually untrusted people can reach the same powerful agent, per-user session labels do not create a security boundary. Separate gateways, credentials, and ideally OS users or hosts are the cleaner design.

Even a single trusted sender does not eliminate prompt injection. The agent may read a web page, email, document, attachment, repository, or pasted log containing adversarial instructions. Sender allowlists answer “who may ask the agent to work.” Tool policy and sandboxing answer “what untrusted content can persuade the agent to do.” A sound deployment needs both.

Identity controls the caller. Isolation limits the consequence of content the caller asked the agent to inspect.

That distinction is easy to miss in a clean chat transcript. It becomes obvious when reviewing the entire path: trusted operator → untrusted document → agent with host tools → credentialed service. Nothing in that chain requires a public bot.

What --deep adds—and what it cannot certify

The plain audit stays on the cold configuration, filesystem, and read-only path. --deep adds best-effort live Gateway probes and plugin-owned security collectors. The current CLI also reports whether the Gateway probe was attempted and reached. This is useful because a configuration can look reasonable while the running service is unavailable or behaves differently.

Deep mode is broader inspection, not a penetration test. A successful probe does not prove that an unauthorized Telegram sender is denied, that an identity-aware proxy applies the intended policy, or that a write tool cannot exceed its external account scope. Those are deployment-specific behaviors. They require negative tests at the real boundary.

Run the deep command from an administrative context that can reach the intended Gateway. If authentication is required, supply it through the supported secure mechanism; do not record a token in shell history, a ticket, or the audit artifact. The report’s secretDiagnostics field is also worth checking before treating the output as safe to retain.

Three decisions before any automatic fix

openclaw security audit --fix is deliberately narrow. Current OpenClaw documentation says it can flip common open group policies to allowlists, restore sensitive logging redaction, and tighten state, configuration, credential, and include-file permissions. Those are deterministic repairs with a clear safer default.

It does not rotate credentials, disable powerful tools, choose a Gateway bind or authentication mode, rewrite plugins or skills, configure the OS firewall, or harden SSH. That boundary is a feature. Those changes depend on how the operator reaches the machine and what the agent is supposed to accomplish.

Before applying --fix, decide:

• Will the allowlist retain the real operator? Capture the numeric sender identities and account variants first. A secure policy that locks out the only recovery path is not a successful unattended change.
• Which file-permission changes are expected? Confirm the OpenClaw state owner and service user. Tightening a directory owned by the wrong account can turn a security repair into an outage.
• Which findings remain design work? Assign tool, sandbox, network, credential, and plugin findings to explicit owners. Do not let a lower count after --fix imply those decisions disappeared.

For a remote host, prepare rollback and preserve an authenticated management path before any state change. OpenClaw can repair its own supported settings and permissions; it cannot know whether a firewall rule will sever SSH or whether a credential rotation will strand an external webhook.

When the audit becomes incident response

A reachable control plane without the intended authentication, an unexpected sender with command access, or evidence that a powerful agent processed hostile input is no longer a hardening backlog. Stop exposure first. The official exposure runbook prioritizes removing public forwarding or proxy routes, rotating Gateway and affected integration credentials, narrowing sender access, and reviewing sessions.

Order matters. Editing a tool allowlist while a leaked Gateway credential remains valid preserves the attacker’s access to the control plane. Rotating one token while a broadly scoped external credential remains available to the same runtime preserves the useful authority. Containment follows the path in reverse: public route, Gateway identity, sender access, session state, agent tools, then downstream credentials.

One allowed path is only half the acceptance record

Re-running the audit is necessary after remediation, but it is not the final test. Configuration findings can disappear while the operator’s actual route is broken—or while an alternative unauthorized route remains open.

A compact acceptance record should cover the behavior that matters:

• The intended sender can reach the intended agent through the intended channel.
• A sender outside the allowlist is rejected before a session or tool call is created.
• The agent can complete one approved read-only task with the smallest required tool set.
• A prohibited runtime, filesystem, browser, or external-service action is denied at the enforcement boundary.
• The Gateway accepts the approved authenticated route and rejects the closest unauthenticated or incorrectly authenticated route.
• Logs and retained audit artifacts do not expose secrets.

Test denials with disposable identities and harmless operations. Do not attempt a destructive command merely to prove it is blocked. A read outside an allowed test directory, a disabled tool name, or a sender not present in the allowlist can exercise the same boundary without risking data.

Record decisions, not screenshots of green badges

The durable artifact is small: OpenClaw version, audit timestamp, report hash, remaining check IDs with owners, approved sender scope, effective agent/tool/sandbox profile, Gateway exposure path, credential scopes, and the results of one positive and one negative test. Screenshots are weak evidence because they lose the exact configuration and are hard to compare after upgrades.

Suppressions belong in that record only when the accepted risk is specific and time-bounded. A suppression should name the check ID, explain why the path is unreachable or intentionally accepted, name an owner, and set a review date. Suppressing a title because “the service is internal” is not a threat model; internal routes still carry compromised accounts and hostile content.

The audit ends when the boundary behaves

An OpenClaw security audit is most valuable as a map of composable risk. It shows which policies, tools, plugins, files, and Gateway settings deserve attention. The operator supplies the deployment context, decides which paths should exist, and proves both halves of the contract: approved work succeeds; unapproved work stops.

That is a stricter finish line than zero warnings, and a more realistic one. Some warnings document deliberate capability. Some criticals reveal an accidental route that should be contained immediately. The difference is not the color in the report. It is whether an untrusted input can cross from ingress to authority.

Primary documents used for this analysis

• OpenClaw security CLI — audit modes, JSON output, suppressions, and the exact boundary of --fix.
• OpenClaw Gateway security — trust model, sender policy, sandbox and tool boundaries, prompt injection, network exposure, and host-security limits.
• Security audit check reference — stable check IDs, severity, inspection inputs, deep-only collectors, and auto-fix coverage.
• Gateway exposure runbook — containment, credential rotation, routing review, and post-change authorized/denied validation.