Is This OpenClaw Audit Finding Real? Common False Alarms and How to Check

Published 2026-10-19 · Updated 2026-10-18 · By The Is My Agent Safe team

Why would the audit flag something that's fine?

openclaw security audit reads your config and install records and reports anything that matches a risky pattern. It's deliberately cautious. It can't always see the full context, such as which agent a channel really routes to.

Findings that look wrong usually fall into one of three groups:

• Posture warnings. The setting is real and deliberate, and the audit is telling you it's broad. OpenClaw's docs say exec security="full" on its own is "a broad posture warning, not proof of a bug". It's the default for setups with one trusted operator.
• A real issue with a confusing message. The finding is right, but the title doesn't match how you think about your setup.
• A reported false alarm. Someone has filed an issue saying the check gets a specific case wrong. Until maintainers confirm it, treat it as reported, not settled.

How do I tell whether a finding is real?

1. Note the checkId, such as plugins.installs_unpinned_npm_specs, and read the detail line, not just the title.
2. Look up the checkId in OpenClaw's security audit checks page or in our explainer to see what it tests.
3. Find the setting it names in your config and check whether the finding describes it correctly.
4. Search the OpenClaw GitHub issues for the checkId. If others report the same case, read the maintainers' replies.
5. If you're still unsure, treat it as real. Changing a setting is cheaper than finding out the hard way.

To get the checkIds in a form you can search, run:

openclaw security audit --deep --json

Which false alarms have been reported?

These two issues were open on OpenClaw's GitHub in October 2026. Both are reports from users. An automated triage bot on the repository has reviewed each one, but OpenClaw's maintainers haven't confirmed either as a bug.

Pinned npm plugins flagged as unpinned (#176136)

Finding: plugins.installs_unpinned_npm_specs

What's reported: the audit warned about all 18 of the reporter's npm plugin installs, the stock @openclaw/* packages. Each install record had an exact resolved version and an integrity hash. The reporter says the check reads the install's spec field and ignores resolvedSpec.

What's unclear: the triage review says the check reads spec on purpose, because spec decides what future updates will install. It suggests the warning message may need clearer wording rather than a change in what it flags. That decision is open.

What to do: the version you have installed is fixed by its integrity hash. The warning is about what the next update could pull. If you only run official @openclaw/* plugins and update them deliberately, this is low urgency. For third-party plugins, take the warning seriously.

Exposure criticals that ignore exact channel bindings (#175215)

Findings: security.exposure.open_groups_with_elevated, security.exposure.open_groups_with_runtime_or_fs and a third security.exposure.* critical

What's reported: the reporter had an open AgentMail channel bound exactly to a separate, messaging-only agent. openclaw security audit --deep still reported their privileged main agent as reachable from that channel, with three critical findings.

What's unclear: the triage review agrees that the current code doesn't take channel-to-agent bindings into account. It also warns that a fix must not hide routes that really do reach a privileged agent. It's waiting on a security owner.

What to do: check the binding names both the channel and the account, with no wildcard, and that the bound agent really has only the tools you expect. If any part of that is uncertain, the finding may be right. An open channel that accepts anyone (allowFrom: ["*"]) is still worth narrowing either way.

How do I suppress a finding properly?

OpenClaw lets you accept a standing finding under security.audit.suppressions in your config. Each entry matches an exact checkId. You can narrow it with titleIncludes or detailIncludes, and you should always add a reason. This is the example from OpenClaw's docs:

{
  "security": {
    "audit": {
      "suppressions": [
        {
          "checkId": "plugins.tools_reachable_permissive_policy",
          "detailIncludes": "Enabled extension plugins: gbrain",
          "reason": "trusted local operator plugin"
        }
      ]
    }
  }
}

Suppressing doesn't delete anything:

• Suppressed findings leave the main summary but stay in the JSON output under suppressedFindings.
• The audit adds an info finding, security.audit.suppressions.active, so anyone reading it can tell it was filtered.

Keep suppressions narrow, and review them after every update. When OpenClaw fixes a reported false alarm, remove your suppression so the check works for you again.

When is it definitely not a false alarm?

Don't explain away these:

• Any gateway.* critical saying the Gateway is reachable without auth, or bound beyond loopback when you didn't mean it to be.
• Open DMs or groups combined with shell, file or browser tools.
• Config or credential files other users can read.

For these, fix the setting first. See how to check if your agent is exposed and the OpenClaw security checklist.

Before you suppress anything, make sure you're on a current OpenClaw release. See how to update OpenClaw without breaking it.

Frequently asked questions

Sources

1. OpenClaw docs: openclaw security (CLI), including suppressions
2. OpenClaw docs: running the security audit
3. OpenClaw docs: security audit checks (checkId catalog)
4. GitHub issue openclaw/openclaw#176136: pinned npm plugin records flagged as unpinned
5. GitHub issue openclaw/openclaw#175215: exposure checks ignore exact channel-to-agent bindings