OpenClaw 的功能越实用，其安全模型就越重要。Gateway 可以把消息渠道连接到能够运行 shell 命令、读写文件、控制浏览器和发送消息的智能体。一条常见且影响重大的失效路径是：不受信任或已经被入侵的发送者接触到权限过高的智能体。以下控制措施能减少这种暴露风险，并与传统的主机、依赖项、凭证和网络安全措施配合使用。
OpenClaw 给出的优先顺序是合理的（安全文档）：
- 身份优先：谁能与机器人对话（DM 配对 / 允许列表 / 显式开放）。
- 范围其次：它能在哪里行动（群组、工具、沙箱、设备权限）。
- 模型最后：假定模型可能被操纵，并限制潜在影响范围。
本文假设你已安装网关（个人网关设置）。
dmPolicy="open"与groupPolicy="open"只应作为最后手段。除非你完全信任每个能接触机器人的参与者，否则应优先使用配对和允许列表。向所有人开放、且启用了工具的 DM 实际上是一个公开的远程控制入口。
每个获批发送者都可能成为访问智能体可读内容的入口，包括邮件、文件、浏览器会话和工具中的客户数据。应像批准 SSH 密钥一样批准人员：从严控制、可以撤销，并记录明确理由。
一段话的信任模型
OpenClaw 文档采用的是个人助手信任模型：每个网关对应一个可信操作者边界，而不是面向彼此不信任用户的多租户安全边界。如果互不信任的用户可以向同一个已启用工具的智能体发消息，他们就共享了该智能体被委托的权限。信任边界不同时应拆分网关，最好同时使用独立的 OS 用户或主机。
经过认证的 Gateway 访问属于操作者级权限。sessionKey 只是路由选择器，不是授权 token。不要把共享的个人网关误当成具备逐用户租户隔离的系统。
DM 访问：配对、允许列表、开放、禁用
每个支持 DM 的渠道支持 DM 策略（名称因渠道略有不同；见当前文档）：
| 策略 | 行为 |
|---|---|
pairing | 默认。未知发送者得到配对码；批准前忽略。码过期（文档为 1 小时）。 |
allowlist | 未知发送者被阻止；无配对握手。 |
open | 任何人都可发送 DM；必须在允许列表中显式加入 "*" 才能启用。 |
disabled | 忽略入站 DM。 |
刻意批准：
openclaw pairing list <channel>
openclaw pairing approve <channel> <code>
详情：配对。
个人使用的实用规则： 保持 pairing 或严格的 allowlist。只批准你自己的账户，最多再加入极少数共享同一信任边界的共同管理者。
两层允许列表
1. DM 允许列表（allowFrom / 渠道特定等价物）
谁可以向机器人发送私信。当前 OpenClaw 将待处理和已批准的发送者记录存储在 ~/.openclaw/state/openclaw.sqlite 中，并按渠道和账户建立索引。旧版凭证 JSON 文件只是迁移输入，不是当前授权状态的来源（配对状态文档）。请把 SQLite 文件视为敏感授权数据，并始终与其余网关状态一起备份。
2. 群组允许列表
机器人究竟接受哪些群组、频道或服务器，以及谁可以在群组内触发它（受支持渠道上的 groupPolicy="allowlist" + groupAllowFrom）。
检查顺序很重要：先检查群组策略和允许列表，再判断是否通过提及或回复激活。回复机器人消息并不能绕过 groupAllowFrom。
示例结构（请根据当前渠道 schema 调整稳定的发送者 ID 和智能体名称）：
{
channels: {
whatsapp: {
dmPolicy: 'allowlist',
allowFrom: ['+15555550123'],
groupPolicy: 'allowlist',
groupAllowFrom: ['+15555550123'],
groups: { '<approved-group-id>': { requireMention: true } },
},
},
agents: {
list: [{ id: 'main', groupChat: { mentionPatterns: ['@openclaw'] } }],
},
}
自定义提及模式，使 requireMention 匹配你的机器人名，而非人人偶然输入的通用字符串。
群组提及是安全控制
在繁忙群组中，始终监听的智能体会：
- 在无关消息上浪费 token
- 对埋在笑话、粘贴日志或链接页面中的提示注入采取行动
- 在同一群聊中、但不共享信任边界的人之间泄漏上下文
除非群聊是锁定成员名单的专用智能体渠道，否则要求提及（或等价激活）。
即使有提及门控，机器人抓取的不可信内容（网页、附件、邮件）也可携带指令。提示注入不靠系统提示解决。硬控制是工具策略、审批、沙箱，以及究竟谁能与机器人对话。
提示注入不需要公开 DM。若只有你能给机器人发消息，但机器人会读取公开网络或共享收件箱，对抗文本仍可出现在工具结果内。
多人 DM 的会话隔离
默认行为可将 DM 路由进主会话以保持连续性。若不止一人能 DM 机器人，隔离会话：
{ session: { dmScope: 'per-channel-peer' } }
如果不做隔离，一个人的上下文可能泄露到另一个人的会话轮次中。这既是隐私缺陷，也会放大提示注入风险。
网络暴露
在启用远程聊天之前：
- 个人安装优先
gateway.bind: "loopback" - 对任何非回环访问要求网关认证 token
- 把 Tailscale Serve/Funnel 和反向代理视为扩大暴露面的变更；使用时应遵循暴露运行手册
- 绝不在无认证情况下把 Control UI（
:18789）或模型端口发布到公共互联网
运行：
openclaw security audit
openclaw security audit --deep
openclaw security audit --fix # narrow safe remediations only
文档建议按以下顺序处理风险：先关闭启用工具的开放 DM 或群组，再处理公共网络暴露、远程浏览器控制、文件权限，最后检查插件。
加固基线（起点）
OpenClaw 发布了一份紧凑的加固示例：本地绑定、token 认证、面向消息场景的工具配置、自动化/运行时/fs 工具组拒绝列表、拒绝 exec 并设置 ask: "always"、关闭高权限工具，以及 WhatsApp 式配对和提及要求。应从实时安全页理解这些配置的意图，不要永久照搬可能过时的片段；修改后重新运行审计。
可信单操作者默认可能允许无提示主机 exec（security="full"、ask="off"）。那是个人助手的有意 UX，不是证明渠道扩大后你应保持开启。当你的威胁模型包含任何其他人的消息时收紧。
季度审查问题
每季度（或任何渠道扩展后）：
- 每个允许列表上有谁，为什么？
- 哪些群组仍有机器人，是否仍要求提及？
- 有人“临时”启用了
openDM/群组策略吗？ - exec/浏览器工具是否比上季度威胁模型更宽？
- 自上次配置变更以来是否运行过
openclaw security audit？
把答案写下来。只存在于某个人脑中的安全态势，在这个人第一次休假时就可能失效。
Discord / Slack / Teams 备注（相同原则）
渠道 UI 不同；安全问题相同：
- 哪些服务器、工作区或团队在允许列表中？
- 哪些用户可 DM？
- 渠道中必须 @提及机器人吗？
- 机器人 token 是否仅存在 Gateway 主机上？
对于 Discord 和 Slack，OpenClaw 文档说明了按具体界面配置允许列表的方式，包括 guilds、channels 及相关键；请核对当前 schema。应采取与 WhatsApp/Telegram 示例相同的“默认关闭”策略。公共 Slack 工作区如果接入开放智能体和 exec 工具，很容易被好奇的同事意外触发。
职场聊天常含员工与客户的个人数据。把 OpenClaw 连接到 Slack/Teams 是一项数据处理活动：应明确处理的合法依据、谁可以召唤机器人，以及
~/.openclaw中会保留哪些工具输出。
具体事故模式（而非传闻）
事故通常表现为以下几种模式：
遗忘的开放 DM 策略
机器人 token 泄露到公共仓库，或朋友转发了机器人的账号名。陌生人通过私信发送“总结我的 ~/Documents”之类的提示词。启用工具后，模型可能会尝试执行。
无提及的群组
机器人会响应每个讨论串。有人粘贴一份含恶意指令的 README，智能体获取后照其中指令执行。
共享家庭 WhatsApp
青少年与承包商处在同一个可 @ 机器人的群组中。会话连续性导致不同人的上下文混在一起，一个玩笑可能变成 shell 命令请求。
无认证的远程 UI
:18789 绑定到 LAN 上，“这样手机就能访问”。访客 Wi-Fi 用户因此能进入控制界面。
每种情况都应由配对与允许列表、提及规则、会话隔离以及绑定与身份验证来阻止，而不是依赖更严厉的系统提示词。
撤销与离岗
建一个小运行手册：
- 从
allowFrom中移除该身份，或使用当前的 CLI/UI 撤销其配对条目；通过支持的工具验证标准 SQLite 授权行是否已删除，而不是直接编辑数据库。 - 如果该人曾经看到过通道机器人令牌，请轮换这些令牌。
- 检查
~/.openclaw会话中是否存在敏感残留信息。 - 重新运行
openclaw security audit。 - 如果他们曾进行过节点配对，请解除设备的配对。
应像撤销并轮换 SSH 密钥一样处理，而不是把它当成取消关注机器人。
操作者清单
- DM 策略是
pairing或严格allowlist -
allowFrom仅含可信身份 - 群组要求提及；群组允许列表已设置
- 若存在多个 DM 发送者则
dmScope已隔离 - Gateway 仅绑定回环地址（或只允许经过身份验证的远程访问）
-
openclaw security audit的结果已处理到足以让操作者安心 - 身份访问控制落实前，高风险工具保持关闭
- 状态目录不可由所有本机用户读取
- 已记录各渠道的权限撤销流程
当电话号码、Slack 用户或承包商合作结束时，撤销配对与允许列表条目。被遗忘的允许列表记录相当于长期有效的邀请。当合法基础结束时，导出或删除含他人个人数据的会话历史。
允许列表与配对不是官僚主义。它们决定了你运行的是个人网关，还是一个直接连接到 shell 的未认证智能体 API。应先配置这些安全边界，再启用技能、心跳与便捷自动化；后续内容见技能、心跳与审批。
