# 3.4 本地访问边界与设备批准

在开始接入外部渠道之前，先理解 OpenClaw 的本地访问控制机制。本节只讨论“谁能访问你的智能体”这个最基本的问题；更完整的渠道入口治理（私聊策略、群聊门控、多渠道分流）将在[第七章](https://yeasy.gitbook.io/openclaw_guide/di-er-bu-fen-jin-jie-shi-yong/07_multi_agent)详细展开。

## 3.4.1 设备批准：最小信任边界

OpenClaw 默认对新设备采用“先拦截、后批准”的策略。任何首次连接 Dashboard 或 WebChat 的浏览器/客户端，都会被暂时拦截，直到管理员显式批准。

操作闭环：

1. 列出待批准设备：

```bash
openclaw devices list
```

2. 批准指定设备：

```bash
openclaw devices approve <DEVICE_ID>
```

3. 若需要撤销已批准设备的访问权限：

```bash
openclaw devices remove <DEVICE_ID>
```

如果你只是要撤销某台设备持有的某个角色令牌，而不是删除整台设备记录，则使用更细粒度的写法：

```bash
openclaw devices revoke --device <DEVICE_ID> --role <ROLE>
```

设备批准机制是 OpenClaw 的最小信任边界——即使智能体的指令和工具配置都没有限制，未经批准的设备也无法与之交互。理解这个机制是后续配置渠道级安全策略的基础。

## 3.4.2 私聊与群聊的默认行为

在推荐基线下，OpenClaw 对私聊和群聊可以按下面的方式收敛：

* **私聊**：建议采用 `pairing` 策略，陌生用户需要先申请配对，管理员批准后才能对话。这是更安全的推荐基线。
* **群聊**：建议先收敛为 `allowlist` 或等价白名单策略，而不是默认当作所有实例都关闭或开放。是否再叠加提及门控，应按你的渠道能力和业务场景决定。

```javascript
{
  channels: {
    telegram: {
      dmPolicy: 'pairing',        // 私聊先走配对批准
      groupPolicy: 'allowlist',   // 群聊先收敛到白名单
    },
  },
}
```

> \[!TIP] 本章只需要理解“推荐基线”即可。私聊的四种策略（pairing/allowlist/open/disabled）、群聊的三道门槛（群组开关/提及门控/能力收敛）以及多群组上下文隔离方案，将在[第七章 多渠道分发与多智能体协作](https://yeasy.gitbook.io/openclaw_guide/di-er-bu-fen-jin-jie-shi-yong/07_multi_agent)中详细讨论。

## 3.4.3 快速排障：设备批准与消息触发

当遇到“消息不触发”或“访问被拒”时，按以下顺序检查：

1. **设备是否已批准**：`openclaw devices list` 查看设备状态。
2. **渠道能力与配置是否正常**：`openclaw channels capabilities` 先确认当前渠道的能力、配置和联调入口。
3. **日志中的拦截原因**：`openclaw logs --follow --json` 搜索关键词 `approval`、`dm_policy`、`group_policy`。

```bash
# 快速定位拦截原因
openclaw logs --follow --json | grep -E "approval|dm_policy|group_policy|blocked"
```

若本地 WebChat 能正常交互但外部渠道消息不触发，问题通常出在渠道配置而非设备批准。此时应参考[第七章](https://yeasy.gitbook.io/openclaw_guide/di-er-bu-fen-jin-jie-shi-yong/07_multi_agent)的渠道接入指南。