Pairing and DM Access Control

Most access mistakes do not begin with a dramatic breach. They begin with a helpful impulse. You want one more person to be able to DM the bot. Then one more. Then someone assumes DM approval also means group access, command ownership, or safe access to every tool-backed workflow. That is when a tidy assistant starts turning into a public lobby with shell access.

OpenClaw has a better model than that. Pairing gives you an explicit approval step. DM policies decide how strict direct access should be. Access groups let you reuse trusted sender sets without pasting IDs all over your config. Group rules stay separate on purpose.

This page is about policy and trust boundaries, not about one channel's click-by-click setup. If you need the Telegram bot creation flow, BotFather steps, or channel-specific troubleshooting, use Telegram Channel Setup for that operational path.

The official pairing docs and groups docs are the two key references to read together. One explains who gets through the front door. The other explains what still has to be true once someone is inside the building.

What pairing is actually for

In OpenClaw, pairing is the explicit access approval step. The docs use it in two places: DM pairing for inbound direct chat access, and node pairing for devices joining the gateway network.

For this article, the important part is DM pairing. When a channel uses dmPolicy: "pairing", an unknown sender does not get normal bot processing right away. They receive a short code, and the operator decides whether that sender should be allowed in.

Think of it like a front-desk buzzer in a building. The visitor can signal that they are there. They are not wandering around the office yet.

• pairing codes are short and time-limited
• pending requests expire instead of hanging around forever
• approval is explicit, not accidental
• the system stays private by default unless you widen it on purpose

Open, pairing, and allowlist are not the same policy

This is where people get sloppy. They see three modes and reduce them to a vague spectrum of "more open" versus "more closed." The real differences matter.

• dmPolicy: "open" means direct chats are public only when the effective DM allowlist includes "*". Without that wildcard, open is not secretly universal access.
• dmPolicy: "pairing" means unknown senders have to be approved first.
• dmPolicy: "allowlist" means only pre-approved senders are allowed, usually through explicit sender IDs or accessGroup:<name> references.

Pairing is the sane middle ground for many personal setups. It is less annoying than hardcoding every sender up front, and much less reckless than making direct access public.

Why the first approval matters more than later ones

The pairing docs call out one subtle behavior that is easy to miss. If no command owner exists yet, approving the first DM pairing request can bootstrap commands.ownerAllowFrom to that approved sender.

That is useful for first-time setup, but it also means the very first approval is not just another guest list change. It can define who becomes the trusted command owner for privileged actions and approval prompts.

After an owner already exists, later pairing approvals only grant DM access. They do not quietly mint additional owners. Good. They should not.

DM access is not group authority

This is the mistake that causes a lot of confusion. The pairing allowlist store is for DMs. Group authorization is a separate layer.

The groups docs make the split pretty plain:

• DM access is controlled by allowFrom
• group access is controlled by groupPolicy, groups, and groupAllowFrom
• reply behavior is controlled by mention gating such as requireMention

In other words, letting someone DM the bot is not the same as letting them steer it in a Slack channel, Telegram group, or Discord server. The building metaphor holds up here: a front-desk badge for the lobby is not a master key to every room upstairs.

Access groups are how you avoid sender-list spaghetti

Pairing is about approval. Access groups are about reuse.

The official docs describe access groups as named sender lists referenced from allowlists with accessGroup:<name>. That matters when the same trusted people should be allowed across several channels, or when one trusted set should apply to both DMs and group sender authorization.

Without access groups, you end up copying IDs everywhere. That looks manageable right up until a teammate changes, a contractor leaves, or you forget to update one channel. Then your policy exists in theory, not in reality.

{
  accessGroups: {
    operators: {
      type: "message.senders",
      members: {
        telegram: ["987654321"],
        slack: ["U01234567"],
      },
    },
  },
  channels: {
    telegram: {
      dmPolicy: "pairing",
      allowFrom: ["accessGroup:operators"],
      groupPolicy: "allowlist",
      groupAllowFrom: ["accessGroup:operators"],
      groups: {
        "-1001234567890": { requireMention: true },
      },
    },
  },
}

The exact IDs will differ, of course. The useful pattern is the separation: one reusable trusted sender set, one DM policy, one group policy, and explicit mention behavior in shared rooms.

Where people accidentally overexpose access

Most overexposure comes from blurring trust boundaries, not from one spectacular bug.

1. Someone pairs a few direct-message senders.
2. Those senders are treated like a general trusted class for everything.
3. Group allowlists get widened to match out of convenience.
4. A shared room now has broader trigger authority than anyone intended.

The OpenClaw security model is blunt here, and it should be. One shared gateway is a personal-assistant trust boundary, not a hostile multi-tenant fortress. If several mutually untrusted people can message the same tool-enabled agent, they are effectively sharing that agent's delegated authority.

So if your real situation is mixed trust, do not play games with one giant shared gateway. Split the boundary with separate agents, separate gateways, or at least separate workspaces and stricter tool posture.

How pairing fits with routing and groups

Routing and access control are close relatives, but they are not the same job.

Channel routing decides which agent and session receive the message. Direct messages often collapse into the main session by default. Groups keep their own session keys. That is useful for context management, but it does not magically make access decisions for you.

A clean mental model looks like this:

• pairing and allowlists decide who can get in
• routing decides which agent/session handles the message
• group rules decide who can trigger in shared rooms
• mention gating decides when the bot should visibly respond

Once you keep those layers separate, OpenClaw gets much easier to reason about. When you blur them, you start debugging policy mistakes as if they were routing bugs. That wastes a lot of evenings.

A sane starter pattern

For most private or small-team setups, a strong default looks like this:

• use dmPolicy: "pairing" for direct chats
• define a small reusable operators access group
• keep groupPolicy: "allowlist" in shared rooms
• require mentions in groups unless there is a clear always-on reason not to
• treat the first approved owner as a deliberate decision, not casual admin housekeeping

Boring? Yes. Effective? Also yes. Access control should feel a little boring. That is how you know it is doing its job.

The short version

• Pairing is the explicit approval step for DM access, not a general trust shortcut
• The first approved DM sender may bootstrap command ownership if no owner exists yet
• DM access and group control are separate on purpose
• Access groups keep trusted sender sets reusable and less error-prone
• If users do not share one trust boundary, split the gateway or agent surface instead of pretending config alone will save you

The goal is simple: let the right people reach the bot directly without turning that convenience into vague, inherited access everywhere else.