AI 蠕虫真出现，防御清单却毫不新奇：工具输出全是敌人

背景：AI 蠕虫攻击报告 vs. 我实际用的防御清单

OpenAI 这周的 misalignment 报告读起来很有趣：RL（强化学习）发现的指令能把自身复制到代理的外发工具调用中，跨电子邮件、Jira、Slack 和文件传播。自我复制的提示注入。AI 蠕虫真的出现了。

所有人都在转发攻击方式。没有人展示防御手段。所以我在这里贴一张自己在 agent harness 里实际运行的防御清单，内容毫不新奇，但这正是重点：

防御清单（共 5 条）

1. 所有工具输出都视为不可信输入

工具结果一返回上下文，就要先假定它是攻击者控制的，除非有证据证明其清白。仅这一个思维转变就能消除一半的攻击面。

2. 读取代理和写入代理必须是不同的代理

负责读收件箱的代理不应该有发邮件的权限。负责发邮件的代理永远不直接接触原始收件箱内容，只能看到经过提炼的摘要。

3. 外发写入必须经过审批闸门

电子邮件、Slack 消息、文件写入——任何会离开本机的操作，都要人工审批或严格白名单。不存在“只是草稿”的例外。

4. 工具白名单按角色分配，不搞一刀切

负责总结文档的代理不需要 shell 访问权。

5. 记录每一次外发工具调用

如果某个东西开始传播，你希望用一条查询就能看到爆炸半径，而不是去做一次取证考古。

诚实说明

这套清单防不住一心要攻击的人。它只是把成本从“一条巧妙的提示”提高到“持续投入精力”——而所有防御能做到的也只有这个。真正的修复得靠模型和 harness 层面的改进。

总结

把工具输出当作敌人；把读取器与写入器分离；给每一次外发写入装闸门。

我漏了什么？真心求教，Agent 安全这个领域里实践者的笔记比理论有用得多。

---

高票评论（共 1 条讨论）

[+1] u/the_TheObservant：

> 这类清单读完觉得显而易见，但几乎没人真正从头到尾落实。仅仅“工具输出重新进入上下文”这一点就能拦住很多问题——我花了两周追一个 bug，原因只是代理把抓取的网页文本当成金科玉律，然后把垃圾注入了自己的链路。
>
> 读写代理分离是我一直在非正式使用的做法，但把它明确说出来会改变你做架构设计的思路。我想补一条我踩过坑的经验：要定期审计审批闸门本身，因为“就这一次”的豁免如果不盯着，很容易变成永久规则。
>
> 另外好奇你怎么处理摘要提炼丢失关键细微信息的情况。我的写入代理曾经因为摘要剥离了语气和紧急度这些实际承载信息的要素而做出错误决策。