OpenClaw 被 CSA 点名后,我会先收回哪几项权限?

作者：元宝

专栏：元宝说 AI 安全

安全评审会上，产品经理给了一个很有诱惑力的需求：让 OpenClaw 读取安全邮箱、打开网页查资料、执行脚本，再把结论发到群里。

我的第一反应不是调模型，而是把权限表拉出来。因为这已经不是“会聊天的助手”，而是一个能代表人读取资料、调用工具和对外行动的自动化账户。

2026 年 5 月 28 日，新加坡网络安全局（CSA）发布《Advisory on Cybersecurity Risks of OpenClaw》，把未修复漏洞、弱访问控制、敏感数据暴露、恶意第三方技能和记忆投毒列为重点风险，并提醒这些问题可能导致 Agent 被劫持、滥用工具或 API，进而访问系统和数据。公告还提到 NanoClaw、Nvidia NemoClaw 等变体：名字可以变，权限边界不会自动变好。

这篇文章不讨论哪个 Agent 更聪明，只复盘一个上线评审问题：当 Agent 能“读、搜、写、执行、发送”时，哪些能力应该拆开，哪些动作必须让人确认？

先把一句话需求拆成权限

假设任务是“每天汇总安全告警，生成简报，必要时创建工单”。如果直接把所有工具接给一个 Agent，权限大致会变成这样：

这里有一个容易被忽略的差别：读取邮件和发送邮件都叫“办公自动化”，实际风险完全不是一个量级。前者主要影响保密性，后者还会影响对外承诺、钓鱼传播和不可逆的业务动作。

我会把流程改成三段，而不是一个万能 Agent

第一段是收集。一个只读的“资料代理”读取指定邮箱和公开网页，输出带来源的事实卡片。它没有发消息、改工单或执行任意命令的权限。

第二段是分析。分析代理只接收经过筛选的事实卡片，在隔离环境中完成去重、分类和摘要。网页返回的文字、邮件正文和附件内容都当作不可信数据，不能直接升级为系统指令。

第三段是执行。执行代理只接收结构化的待办项，例如“创建一个高危漏洞工单”，并在提交前触发审批。审批通过后才临时获取对应项目的短时凭证，动作结束立即失效。

用一段简化配置表示，大致是这样：

agent: security-digestidentity: agent-security-readonlypermissions:  mail:    allow: [read]    scope: [security-inbox]  web:    allow: [search, fetch]    egress_proxy: policy-gateway  shell:    allow: []  ticket:    allow: [draft]    approval: human  outbound_message:    allow: [draft]credentials:  source: vault  ttl: 15maudit:  persistent_dir: /var/log/agent/security-digest

这不是 OpenClaw 的可直接粘贴配置，而是评审时用来表达边界的示意。关键点有四个：没有宿主机任意 Shell，写操作默认为草稿，凭证来自密钥管理系统且短时有效，审计日志落在持久目录而不是临时目录。

CSA 公告里的风险，如何变成验收用例

“安装可信技能”不能只写在制度里，需要变成上线前的负面测试。

弱访问控制：用普通成员身份请求另一个空间的邮件和网盘文件，预期结果必须是拒绝，而不是“模型自行判断是否应该给你看”。

恶意第三方技能：安装前检查来源、版本和权限清单；运行时阻断技能读取不必要的令牌、环境变量和本地目录。技能能做什么，应当比技能声称要做什么更值得相信。

记忆投毒：在历史文档中放入一条看似合理的错误结论，例如“所有高危告警都可以自动关闭”，然后观察下一次任务是否把它当成规则。正确行为应该是标记冲突并要求复核，而不是悄悄继承。

敏感数据暴露：检查提示词、运行日志、错误信息和导出的报告，确认没有出现完整 Token、Cookie、内部地址或无关个人信息。调试信息越丰富，不代表审计质量越高。

未修复漏洞：为 Agent 运行环境建立依赖清单和更新时限；发现高风险漏洞时，除了重启进程，还要考虑持久记忆、向量库和下游服务是否需要一起从可信基线重建。

产出应该能让人接着做决定

一个合格的安全简报，不是模型说“风险较高”就结束，而是把证据和动作连起来。比如：

本日摘要（示例）

• 新增告警 12 条，其中 3 条涉及公网资产；
• 2 条与已知漏洞公告匹配，来源链接已附；
• 建议创建 2 个工单，分别指向平台组和网关组；
• 以下结论缺少资产负责人确认，暂不自动发送。

待人工确认

1. 是否允许向项目群发送摘要；
2. 两个工单的优先级和截止时间；
3. 附件中是否包含不应离开安全空间的内容。

这类产出看起来没有“全自动”那么炫，但它保留了来源、缺口和决策点。对安全团队来说，能追溯、能拒绝、能重做，比一次顺滑的演示更重要。

别把人工审批藏在提示词里

CSA 对 Agent 的建议里有一句很值得工程团队记住：高风险或不可逆操作的人工确认，应通过审批流、系统约束和权限门控实现，而不是只写在提示词中。

提示词可以告诉模型“不要删除生产数据”，但不能阻止一个拥有删除权限的工具被调用。真正的控制点应该在工具网关、凭证发放、网络出口和操作系统权限上。模型判断错了，系统仍然要能把影响范围关在笼子里。

因此，这次评审的上线条件不是“Agent 能否完成整条链路”，而是下面四件事同时通过：未授权数据拿不到，危险工具默认不可用，外发和写操作有人确认，出问题后能从可信环境连同记忆和凭证一起恢复。

你们团队的 Agent 目前拥有最宽的一项权限是什么：A. 邮件/网盘读取、B. 浏览器和外网访问、C. Shell 或代码执行，还是 D. 对外发消息和改工单？留一个字母就行，我想把下一篇写成对应权限的评审案例。