When an OpenClaw team changes, review the whole allowlist path

An OpenClaw allowlist review often begins with one small edit: remove a teammate, add a room, move a bot to another account, or update an identity after someone changes username. That edit can be correct and still leave the real access path unchanged. OpenClaw does not keep every access decision in one list.

DM sender rules, pairing state, group rules, per-room entries, account overrides, command ownership, session scope, and context visibility answer different questions. A review that checks only allowFrom can miss a pairing record. A review that checks only a group name can miss a new room ID. A review that proves the right person can trigger the agent says nothing by itself about what the agent can expose or send.

The safest unit of review is a change across identity, channel, account, room, and capability. The commands below come from OpenClaw documentation checked on September 13, 2026. The acceptance tests are proposed tests, not results from a hands-on run.

The word allowlist hides several decisions

OpenClaw's access-control reference describes separate DM and group layers. The pairing page adds another state store, while the group documentation adds mention and room rules. Treating them as one permission switch is how a review misses the awkward case.

The group reference says group policy and group allowlists are checked before mention or reply activation. It also separates trigger authorization from context visibility. By default, an allowlist decides who can trigger the agent, not necessarily which quoted, forwarded, or historical snippets the model sees.

There is a useful terminology trap here. If recipient means the person allowed to send an inbound DM, inspect sender identity and pairing. If recipient means an email address, customer, API endpoint, or room where the agent may send something, inspect the tool or provider that owns that side effect as well. Do not sign off an outbound destination because an inbound sender was allowlisted.

Review identities, not display names

Names are convenient in a roster and weak in an access review. The OpenClaw access-groups documentation says that sender IDs are matched under the destination channel and are not translated between channels. One person's Telegram ID and Discord ID must be listed separately. The same rule applies when a team member appears in Slack, Google Chat, WhatsApp, or another connector.

For each approved entry, record an internal person label, the channel, account, room or group ID, exact sender ID, policy path, and evidence used to confirm the ID. Prefer stable numeric or platform IDs where the channel supports them. A display name can change. A stable ID can still be wrong if it belongs to an old account, so verify the mapping rather than trusting its format.

accessGroups: {
  operators: {
    type: 'message.senders',
    members: {
      telegram: ['987654321'],
      slack: ['U01234567'],
      googlechat: ['users/1234567890']
    }
  }
},
channels: {
  telegram: { dmPolicy: 'allowlist', allowFrom: ['accessGroup:operators'] },
  slack: { dmPolicy: 'allowlist', allowFrom: ['accessGroup:operators'] },
  googlechat: {
    groups: {
      'spaces/AAA': { users: ['accessGroup:operators'] }
    }
  }
}

The IDs above are examples. The syntax is illustrative JSON5, not a universal drop-in configuration. An access group is an alias, not a role. It matters only where an allowlist references it; it does not create an owner, approve pairing requests, or grant tools. A membership change can therefore affect several paths at once, but it does not replace a review of separate owner or pairing state.

Missing access-group names fail closed, which is safer than silently granting access but can turn a typo into an outage. Search for every accessGroup: reference before renaming or deleting a group. Also look for wildcards and open policies. A broken alias can block everyone. A wildcard can admit far more people than intended.

Make the change visible as a matrix

Write the change as rows rather than as a single configuration diff. The point is to expose what should change and what must remain unchanged.

That last row matters more than it first appears. OpenClaw's trust-model documentation describes one Gateway as one trust boundary. Allowlists help decide who can talk to the agent; they are not hostile multi-tenant isolation. If the team becomes adversarial, separate users, hosts, or Gateways may be the correct change.

A review runbook that leaves evidence

1. Freeze the intended change. Record the old and new identity, channel, account, room, intended surface, approving owner, and rollback. Keep tokens and private message content out of the ticket and diagnostic output. If a sync job creates the change, review one bounded patch instead of allowing it to rewrite unrelated policy.
2. Identify the active configuration. Use openclaw config file and inspect non-secret paths with the documented config commands. Then check pairing state with openclaw pairing list <channel>; use the account selector for multi-account channels where needed. The pairing reference places approved sender rows in ~/.openclaw/state/openclaw.sqlite, keyed by channel and account. The access-control reference explains that pairing approvals can be combined with configured allowlists. A config-only diff is therefore incomplete.
3. Resolve inheritance. Check channels.defaults, the provider-level block, the account block, and the room or topic override. The shared channel policy reference says defaults are fallbacks when a provider policy is unset, while an explicit account value wins. It also documents promotion and inheritance behavior when a non-default account is added. Review the effective path, not the nearest JSON object.
4. Separate trigger, context, and owner decisions. If several people can DM the bot, consider session.dmScope: 'per-channel-peer' instead of leaving all DMs in the main session. If quoted or historical context from unallowlisted senders should not reach the model, review contextVisibility separately. Check commands.ownerAllowFrom independently. The pairing documentation is explicit that DM approval does not grant group access, and chat access does not automatically make someone an owner.
5. Guard the write. For automated changes, the config CLI reference documents conditional expectations such as --expect-current-json and --expect-current-absent. A mismatch exits without writing, which protects against updating an old snapshot over a newer operator edit. This is a race guard, not an authorization decision. Use it only with the exact path and expected value, and keep secrets out of shell arguments.
6. Validate before relying on reload. Run openclaw config validate --json and openclaw doctor. The validation and probes guide says an invalid hot-reload edit can be skipped while the previous runtime configuration remains active. Look for rejected or clobbered config artifacts when a write fails. A successful file edit does not prove that the new policy is active.
7. Run the security checks. Use openclaw security audit --deep and inspect structured findings, not just a final status word. Relevant checks include open DMs, open groups with exec or filesystem access, broad Discord group membership, and the multi-user trust-model heuristic. The audit catalog describes these as configuration findings and points to the policy paths that need review.
8. Probe the live channels. Run openclaw channels status --probe on the Gateway host, then capture openclaw status --all --json. The channels CLI reference says the probe path performs live account checks when the Gateway is reachable, while an unreachable Gateway produces config-only summaries. The status reference also warns that a healthy lifecycle state does not necessarily mean a live probe ran. Save redacted output with the change record.

Proposed acceptance tests

These tests should run against disposable accounts, rooms, and destinations. They are proposed acceptance criteria, not reported results.

• Send from a removed identity. In allowlist mode it should not enter the agent workflow. In pairing mode, an unknown sender may create a pending request, but the message must not be processed as an approved conversation.
• Send from the new identity on the intended channel and account. Confirm that the same person is still blocked on channels where their native ID was not added.
• For a group, test room admission, sender authorization, and mention gating separately. A DM pairing approval must not make the sender a valid group trigger.
• Change a room ID or add a second account in a disposable configuration. Confirm the effective policy after inheritance and confirm that the existing account keeps its intended behavior.
• Check the old pairing state after offboarding. If you cannot demonstrate that the old approval is removed, ignored, or contained by the active DM policy, mark the change blocked rather than assuming the config diff revoked it.
• Use a sink or disposable destination for an outbound test. Change the recipient or payload after the review preview and confirm that the integration refuses the stale action or requires a new review.
• Ask an ordinary allowlisted sender to perform an owner-only operation. The expected result is a denial or an explicit owner requirement, not a privilege upgrade.

Failure paths and residual risk

A good review includes the cases that make the dashboard look reassuring.

• Invalid configuration: OpenClaw can keep the previous valid runtime configuration when a direct edit fails validation. Treat the new policy as unverified until validation and a live probe both pass.
• Missing group alias: A missing access group fails closed, but that can create a denial of service. Keep the previous known-good configuration available and distinguish blocked access from a successful offboarding.
• Stored pairing state: Pairing approvals live outside the main allowlist text. The official pages consulted do not provide one universal revocation command for every channel and account. Document and test the removal path used by the deployed connector.
• Context leakage: A narrow trigger allowlist does not automatically filter all quoted or historical content. If that context matters, make contextVisibility part of the review.
• Wildcard expansion: An open DM or group policy can overwhelm a careful sender list. Check for * entries and for account-level overrides that make the effective policy broader than the root configuration suggests.
• Shared trust boundary: Allowlists do not stop a trusted user from asking the agent to misuse tools, and they do not turn a shared Gateway into hostile-user isolation. Use sandboxing, tool restrictions, or separate Gateways when the users do not share a trust boundary.

Sign-off criteria

Mark each matrix row as passed, unverified, or blocked. Sign off only when the review can answer all of these questions:

• Does every approved entry map to a verified, channel-specific identity?
• Did the review cover configuration, pairing state, account overrides, rooms, and owner state?
• Are trigger authorization, context visibility, session scope, and tool capability treated as separate controls?
• Did validation, the security audit, and a live channel probe run against the intended Gateway?
• Did the tests prove both that the new path works and that the old path no longer works?
• Is there a documented rollback and a tested way to handle stale pairing or owner state?

If you cannot prove that the old identity no longer has a path, leave the affected surface blocked and keep the change in review. A clean configuration diff is not the same thing as a clean access boundary.

Sources

All sources were accessed on September 13, 2026. The official documentation pages did not expose publication dates when checked.

• Access control and allowlists - OpenClaw
• Pairing - OpenClaw
• Access groups - OpenClaw
• Groups - OpenClaw
• Configuration: shared channel policies - OpenClaw
• Config - OpenClaw
• Config validation and probes - OpenClaw
• Security audit checks - OpenClaw
• Channels - OpenClaw
• openclaw status - OpenClaw
• Security trust model - OpenClaw