配对与白名单：谁能跟助手说话谁不能
第一道闸是渠道配对（在群聊与配对里讲过日常用法），这一篇把整个访问控制体系拼完整。
四层访问控制
| 层 | 控制什么 | 机制 |
|---|---|---|
| 渠道私信 | 谁能在聊天软件里找助手 | 配对码审批 + 允许列表 |
| 节点接入 | 哪些设备能连上网关 | 设备配对（role: node），网关侧批准 |
| 操作员权限 | 连上后有多大权力 | 完整/受限两档，取决于连接是否加密 |
| 工具执行 | 助手能自己干多大的事 | 沙箱、审批、权限模式（见下一篇） |
配对机制的参数化
- 配对码 8 位、1 小时过期、每渠道 3 个待处理上限——参数都可查证于官方文档，防的是陌生人骚扰，不是熟人使用。
- 允许列表放常联系人：配对过的请求批准后即入列；也可以手工维护。
dmPolicy: open想真正全开，必须允许列表里有*——官方用这个硬性要求防止「以为开了实际没开」或反过来。
节点配对的自动批准（谨慎用）
内网受控环境可以配 CIDR 自动批准首次节点配对（gateway.nodes.pairing.autoApproveCidrs）：
- 默认关闭；只对未请求权限范围的新节点配对生效。
- 操作员配对、浏览器配对、任何角色与权限范围变更仍需手动批准——官方刻意收窄了这个便利的范围。
操作员权限范围
网关还有一套操作员作用域体系（官方称 operator scopes）：不同入口可以授予不同范围的能力，管理员级才能动设置。手机 App 里 Settings → OpenClaw 的设置助手就要求操作员具备管理员范围才能打开。
群组的天然边界
群聊会话相互隔离 + 提及才触发，等于自带访问控制：没拉它进群就够不着。配合群成员管理，团队场景的边界很清楚。
访问控住了，最后是行为控制：沙箱审批。