“Friendly Fire” 安全研究表明，只需在 README 文件中植入一条恶意指令，就可以欺骗 AI 智能体，而智能体会直接执行该指令，甚至根本不会查看底层的代码。同样的缺陷也出现在一个个人博客自动化流水线中，该流水线在无人监督的生成阶段依赖“自动批准”（auto-approve）标志，从而暴露了一个隐藏的攻击面。
“Friendly Fire” 研究揭示了隐藏的攻击向量
“Friendly Fire” 论文背后的研究人员展示了一种微小但强大的利用方式：攻击者在文档文件中嵌入一条命令，而 AI 会将其作为正常工作流的一部分进行读取。由于智能体信任文件的内容，它会像执行合法指令一样执行该隐藏命令。这种攻击不需要破坏 AI 模型本身；它只需要在无人看管时影响模型处理的数据。
该研究的核心贡献不在于有效载荷（payload）的新颖性，而在于揭示了“自动批准”模式——即告知 AI 直接对所读内容采取行动而无需二次检查的设置——会与外部数据源建立一种隐性的信任关系。当这种信任变成盲目信任时，流水线就会变成任意代码执行的入口。
一个无人看管的博客流水线是如何崩溃的
研究作者将同样的逻辑应用于一个个人博客自动化系统。该工作流包含三个阶段：
- 生成阶段 (Generation stretch) – AI 在没有任何人工监督的情况下编写文章。
- QA 环节 (QA gate) – 通过自动化质量评分检查来评估输出。
- Telegram 按钮 – 人员必须按下按钮才能发布文章。
在生成阶段，作者启用了一个名为 dangerously-skip-permissions 的标志，该标志告诉 AI 将任何输入视为已批准。这个标志本质上复制了 “Friendly Fire” 论文中提到的“自动批准”模式。
随后的审计发现了一个影响深远的漏洞：如果攻击者能在该窗口期内影响 AI 读取的任何文件，他们就能操控整个流水线。作者自己的系统在六次中有五次发生了无声的故障，原因是配置脚本无意中覆盖了另一个脚本的设置。由于没有对退出码或 QA 评分进行记录，该问题在被发现前已经持续了三天。
这一事件证明，安全性并非源于对 AI 输出的信任，而是源于围绕生成阶段设置的三个明确检查点。
安全性究竟存在于何处
该研究与博客自动化失败案例共同指向了一个核心点：保护措施必须位于生成过程之外。当 AI 在自动批准状态下运行时，它可以被诱导做出任何行为；只有周围的控制措施才能检测并拦截不需要的操作。
关键观察结果：
- 末端人工批准之所以有效，是因为它审查的是最终产物，而不是那些因速度过快、数量过多而无法进行实时监督的中间步骤。
- 在生成后但发布前应用的质量阈值可以拦截可能被篡改的低置信度输出。
- 对每个退出码、QA 评分和配置更改进行全面记录，可以在故障发生连锁反应之前使其显现。
给运行“自动批准”智能体的所有人的建议
- 记录一切 – 捕获退出码、QA 评分以及配置文件的任何更改。看不见就无法修复。
- 执行严格的质量关卡 – 设置一个在流水线进入下一阶段之前必须达到的、不可逾越的阈值。
- 将人工批准保留在最后一步 – 试图在 AI 生成时进行实时监控是不现实的；在所有检查完成后通过单次按键进行确认要可靠得多。
- 保护配置文件 – 将其与可能重写设置的其他工具隔离，并定期审计任何写入权限。
总结
无人看管的 AI 智能体，其安全性取决于你填补了多少周围的漏洞。“自动批准”标志会将便利转化为一个隐蔽的后门；详尽的日志记录、严格的质量关卡以及最终的人工确认，才是防止流水线演变为攻击向量的切实防御手段。