OpenClaw Mention Gating: What It Blocks and What It Leaves Exposed

Published June 9, 2026.

Group-chat accidents usually begin with an ordinary sentence. Someone says that old files should be cleaned up, a pasted log contains an instruction, or a reply is aimed at another person. If an assistant treats every message as a request, the room becomes a noisy command channel.

Mention gating narrows that path. OpenClaw can wait for a recognized mention before treating a group message as an addressed request. That is a useful first filter. It is not an identity check, a permission grant, or an approval step for a side effect.

The distinction is explicit in the current OpenClaw group documentation: group admission, sender authorization, mention gating, context visibility, and tool restrictions are separate controls. A safe configuration has to decide what each layer should do.

The gate answers one narrow question

OpenClaw's documented group flow checks the group policy first, then the group allowlist, then mention or reply activation. The default group policy is allowlist, and replies require a mention unless a room overrides that setting. An allowlisted sender in an allowed room can therefore trigger the agent by mentioning it. An unmentioned message does not become the normal addressed trigger.

That last sentence needs care. OpenClaw can keep unmentioned material as context, and its messages.groupChat.unmentionedInbound setting controls how always-on chatter is submitted. The documented default is user_request; setting it to room_event sends the chatter as quiet room context instead. A silent chat is therefore not proof that no message was received or stored.

Mention detection is also broader than the literal text @openclaw. OpenClaw supports native platform mentions and configured mentionPatterns as regex fallbacks. In several bundled channels, replying to or quoting the bot can count as an implicit mention. Those facts differ by channel, so an operator should test the actual adapter rather than assume that every mention has the same meaning.

The table is the useful mental model. Mention gating is a trigger filter, not the whole access-control design.

How to configure the boundary

Before changing a setting, record the channel, account, group ID, OpenClaw version, available tools, and people who should be able to request work. Also decide whether the room is a trusted team space or contains members who should not share the same agent authority. OpenClaw's trust model supports one trusted boundary per Gateway. It does not treat one shared Gateway as hostile multi-tenant isolation.

For a channel that uses the documented group shape, a conservative starting point looks like this:

{
  channels: {
    whatsapp: {
      groupPolicy: 'allowlist',
      groupAllowFrom: ['<trusted-sender-id>'],
      groups: { '*': { requireMention: true } }
    }
  }
}

This is a configuration pattern, not a tested deployment. Provider nesting differs. Discord uses guild and channel entries, Slack uses channel entries, and other adapters have their own group identifiers. An empty group allowlist blocks group messages; changing requireMention does not override a failed group admission check.

If you use text aliases, scope them carefully. OpenClaw supports channel-level mention policies with allowIn and denyIn. A broad pattern such as a common bot name can wake the agent in rooms where it was not intended. Invalid or unsafe regex patterns are ignored with a warning, which is another reason to inspect logs after a change.

DM pairing does not solve this problem. The pairing store controls direct-message access; group sender authorization remains an explicit group policy decision. The access-control documentation recommends treating those as different paths.

What mention gating reduces

Imagine a support group where OpenClaw can read a ticket folder and draft replies. A member writes, “We should remove the old exports.” With mention gating enabled, that sentence should not become an addressed OpenClaw request merely because the agent is present in the room. A later message that mentions the bot is a clearer delegation point.

That reduces accidental activation and makes a transcript easier for people to read. It can also reduce unnecessary full agent turns, although the exact processing and storage behavior still depends on the channel and the room-event settings. This is an operational inference from the documented message flow, not a measured performance result.

The gain is modest but real: fewer ordinary messages cross the trigger boundary. The gate does not decide what “remove” means, whether the sender is authorized to delete anything, or whether the relevant tool should be available.

What it cannot prevent

A mention does not prove who is allowed to act

If every member of an open group can mention the bot, every member can reach the agent's response flow. The group rules distinguish an open group policy from groupAllowFrom, which restricts senders inside a group. Replying to a bot message does not bypass that sender check.

For a mixed-trust room, do not rely on the visible @ as proof of authority. Use an explicit sender allowlist, keep the room's tools narrow, and separate the Gateway when users are mutually adversarial. The OpenClaw trust model says that everyone who can message a tool-enabled agent shares its delegated tool authority.

It does not remove hostile text from the prompt

A user can mention OpenClaw and include a copied instruction that says to ignore policy, reveal a file, or follow a link. The content may also arrive through a quote, forwarded message, attachment, or thread history. OpenClaw's default contextVisibility is all, which keeps supplemental context as received. The allowlist modes filter that supplemental context, but they do not turn the current message into a trusted instruction.

The official prompt-injection guidance treats external content as a threat surface even when only a trusted person can message the bot. Mention gating lowers the number of turns exposed to that content. It does not make the content safe.

It does not limit the tools in an admitted turn

Once a message passes group admission and mention checks, the available tools still come from the active agent, group, sandbox, and requester policies. If the room can reach a shell, browser, filesystem, node, or external message tool, the consequences of a mistaken interpretation remain.

The hardened baseline gives a more useful companion to mention gating: non-main sessions, workspace-scoped access, a messaging profile, denied runtime and filesystem groups, disabled cross-agent access, and no elevated mode. Those controls reduce the blast radius after activation. They are not supplied by requireMention.

It does not create session isolation

Group sessions use group or channel-scoped session keys by default. That is helpful for routing, but the group documentation says that changing session.groupScope changes session-key selection, not group admission or mention gating. Setting a room to main can merge it into the agent's main conversation and remove the non-main sandbox posture.

Session tools are another boundary. The session-tool reference lists operations that can inspect, search, message, or manage visible sessions. The trust-model documentation notes that broad session visibility is enabled by default in some unsandboxed configurations. A mention gate should not be described as protection for private transcripts or credentials.

It does not make parsing uniform across channels

Native mentions, regex aliases, replies, quotes, and thread state are not interchangeable. A reply to the bot may count as an implicit mention in one adapter, while a configured regex is scoped by a conversation ID in another. A copied mention may also be mistaken for a live address if the channel exposes it as a native mention.

That is why the correct question is “What does this adapter classify as addressed?” rather than “Does the bot require an @?”

A proposed verification test

The following is an acceptance plan, not a hands-on test result. Use a disposable group, a low-impact account, and a workspace with no sensitive files. Record the exact configuration and version before each run.

Use the documented diagnostics after each change:

openclaw channels status --probe
openclaw logs --follow
openclaw security audit
openclaw security audit --deep

The channel troubleshooting guide points to probes and logs for silent groups, mention-gating drops, and incorrect allowlists. The CLI documentation says that a plain audit checks the read-only configuration and filesystem path, while --deep adds best-effort live Gateway probes and plugin security collectors. Neither command proves that a custom workflow is safe.

Failure paths to plan for

If the bot goes silent after an update, check group admission before relaxing mention gating. A missing channel entry, an empty allowlist, a changed room ID, or a provider-specific nesting error can block the message before mention detection runs.

If the bot responds too often, inspect native reply or quote behavior and broad regex patterns. Scope patterns to the intended rooms, then repeat the no-mention and reply tests. Do not solve an unknown parser problem by setting requireMention: false across the channel.

If a public room is relying on non-main sandboxing, check for a binding that sets session.groupScope: 'main'. The security audit reports this as a trust-model finding because all members of the matched room share that context. Roll back to the default per-group scope or move the room to a separate agent or Gateway.

For an emergency stop, use the documented groupPolicy: 'disabled' for the affected channel or group. That blocks group messages entirely while you preserve the configuration and logs for diagnosis.

The decision rule

Mention gating is a sensible baseline for a busy, trusted group where OpenClaw should answer only when someone addresses it. Pair it with an explicit group allowlist and sender policy when membership alone is not enough. Keep contextVisibility narrow when quoted or historical text does not need to reach the model.

For tool-enabled rooms, add the harder boundaries: non-main sandboxing, limited filesystem access, a messaging-oriented tool profile, disabled control-plane tools, and a review step at the function that sends, deletes, publishes, or changes data. The mention is the moment the agent is invited to listen. It is not permission to do everything the agent can do.

If participants are mutually adversarial, remove the group from the shared trust cell. The official security guidance recommends separate Gateways, credentials, and preferably operating-system users or hosts. That is a larger change than adding an @, but it addresses the boundary mention gating cannot.

Sources

All sources were accessed on 2026-09-13. The official documentation pages used here do not display publication dates, so their publication-date fields are empty.

• Groups - OpenClaw — group policy, mention gating, patterns, context visibility, session scope, and group tool restrictions.
• Access control and allowlists - OpenClaw — group admission, sender allowlists, DM pairing boundaries, and context filtering.
• Security trust model - OpenClaw — Gateway trust cells, delegated authority, session visibility, and adversarial-user limits.
• Prompt injection - OpenClaw — untrusted content, model manipulation, and tool-risk mitigations.
• Hardened baselines - OpenClaw — sandboxing, tool denial, requester-scoped controls, and a conservative group configuration.
• Session tools - OpenClaw — session visibility and cross-session operations.
• Channel troubleshooting - OpenClaw — diagnostics for silent groups, mention drops, and allowlist failures.
• Security CLI - OpenClaw — audit modes and trust-model findings.