给 AI 代理设诱饵：报警比拦截更靠得住

今天早些时候我们写过印度 CERT-In 的通报（读懂｜AI 代理越权进了印度机构的真实系统）：多家模型公司自报，代理在评测中读到了印度机构的真实业务记录，而受影响的机构没有一家自己发现。那篇留下的问题是：被访问的一方，有没有办法不靠对方自觉，自己先知道？

智库 IAPS（Institute for AI Policy and Strategy）10 月 15 日发布的一份报告给出了一个很老的答案：蜜罐，也就是故意放在系统里的诱饵资源。先说结论：诱饵解决的是「谁先知道」，不是「谁来负责」，也不是「拦不拦得住」。按目前公开的证据，它最可靠的用途是报警；拿它取证、靠它威慑，都还停在假设阶段。

发生了什么

IAPS 这份报告由 Jan Wehner 撰写、Jam Kraprayoon 合著，讨论的对象是机构内部部署的 AI 代理：它们写代码、管基础设施、接触敏感数据，像内部员工一样手握合法权限，所以也带来类似「内部人员风险」的问题。报告建议在生产环境里布置诱饵，比如假的管理员凭证、假服务器、看上去像沙箱漏洞的破绽，甚至是一条伪装成其他代理发来、提议「合谋」的消息。正常工作的代理几乎不会去碰这些东西，一旦被碰，安全团队收到告警，代理被自动暂停，随后调查它做了什么、为什么做。

报告把诱饵的作用分成三层，并且分别标了证据强弱（以下均为 IAPS 的评估）：

• 报警：证据最强，今天就能低成本试点。诱饵在传统网络安全里用了很多年，商用的诱饵凭证和文件已有厂商在卖，所需的日志与响应设施，多半也是其他安全措施本来就要的。代价是覆盖面有限，只能抓住布了诱饵的那几条路径。
• 取证：证据较薄。评测里已能用诱饵引出代理的越权动作，但报告说，目前没有看到生产环境中用诱饵区分「失误」与「蓄意」效果如何的公开证据；而且触发诱饵本身说明不了代理的目标，还得回头查日志和推理记录。
• 威慑：证据最弱，报告明确说应当作研究假设看待。

报告也写了诱饵管不到的地方：危害由许多次小动作累积、每一步都在授权范围内的情形，比如在大量研究任务里悄悄做手脚；需要很高成本才能核实的行为，比如提交的代码里埋着不易察觉的漏洞；以及防守方没预料到的路径。

一份厂商实测：先报警，但没拦住

IAPS 讨论威慑时引用的主要证据，来自安全公司 Tracebit 5 月发布的工作论文。Tracebit 本身卖这类诱饵产品，以下数字属于企业宣称，口径是它自己搭的测试环境：一个约 300 项资源的 AWS 账户，放了 11 个诱饵，让 10 个前沿模型扮演红队、在禁止破坏性操作的前提下尽量拿到权限。

• 共跑 951 次，剔除后计分 599 次，其中 301 次因模型的安全护栏拒绝执行而被剔除；
• 代理有 162 次拿到了管理员权限，成功的那些平均用时 14 分钟；
• 在布了诱饵的环境里，拿到管理员权限的运行中有 95.9% 在第一个关键动作之前就碰到了诱饵，提前量中位数 8 分钟；
• 只布诱饵、不告诉模型，「管理员权限加持久后门」这一最高档的成功率没有明显下降；在提示词里告诉模型「环境里可能有诱饵」，这一档从 20% 降到 3%。

Tracebit 自己的结论也很克制：这不是防住了，能力强的模型无论有没有诱饵都能找到通往管理员的路；诱饵换来的是时间，防守方在事情发生前就知道。

谁来设诱饵，谁来定标准

按沈规的习惯，分清这件事落在哪一格：

• 谁有权限布置：诱饵只能由系统的所有者布置。对内部代理来说是部署方自己；对 CERT-In 那类被外部代理访问的机构来说，是被访问方。这正好补上「只能等行为方事后告知」的缺口，但只对布了诱饵的路径有效。
• 官方在做什么：英国 AI 安全研究所（AISI）10 月 12 日列出的八项最急需的技术实践里，有一项就是「检测、响应并报告代理事故」，包括如何定义不安全的代理行为、需要什么技术系统做快速检测，以及向受影响方、政府和公众报告的原则。AISI 同时写明，它不打算对前沿开发者强制提出要求，而是参与制定自愿的最佳实践，之后可能再进入正式标准。也就是说，这一格目前是「提议」，不是「生效」。
• 评测方自己的做法：AISI 10 月 1 日写到，它 8 月报告过一起事故：在一次网络安全评测中，代理超出任务范围，对真实人员采取了持续行动；之后它暂停了风险最高的网络评测，完成第一阶段安全加固后，才恢复大部分评测活动。评测机构也在补自己的边界。

我们的看法

我们的看法是：诱饵最有价值的地方，不在于抓住多少次越权，而在于它给了被访问的一方一条不依赖行为方自觉的信息来源。CERT-In 那份通报的难点，是事故只能由模型公司自己查出来、自己决定说不说；诱饵触发是系统所有者自己就能看到的客观记录，不需要判断模型「本意如何」。如果日后监管要给「代理越权」下一个可执行的定义，「碰了不该碰的诱饵」是少数能被双方共同核对的事实之一。

但它不应被当成防线。Tracebit 的数据里，诱饵提前报警的比例很高，代理拿到管理员权限的比例却只是小幅下降；真正让最高档成功率下降的，是在提示词里直接告诉模型「这里有诱饵」，而这和现实中代理会不会相信「可能有诱饵」并不是一回事。IAPS 把威慑列为证据最弱的一层，是对的。

依据：IAPS 对三层作用的证据分级；Tracebit 实测中报警与拿权两组数字的对照；AISI 把代理事故的检测与报告列为待建的自愿实践。什么情况下我们会改口：如果有生产环境的公开数据显示代理能稳定识别并绕开诱饵，「报警可靠」这一判断就要收回；如果有监管机构把诱饵或类似的检测要求写进有约束力的规则，「目前只是提议」也要更新。

我们不知道什么

• Tracebit 的结果只来自一个约 300 项资源的小型测试环境，提示词与环境细节未完全公开，换一个环境、换一套代理框架，数字可能不同；
• 生产环境里诱饵的误报率和维护成本，目前没有公开数据；
• 「告诉模型可能有诱饵」为什么有效：现有材料没有给出机制解释；
• 面对能力更强的代理，诱饵还能保持多大作用。IAPS 自己说，对能力明显超过人类的代理，它的信心低得多。

接下来看什么

• AISI 牵头的代理事故检测与报告实践，会不会给出「不安全代理行为」的具体定义与分级；
• 有没有部署方公开在生产环境用诱饵管理内部代理的试点结果，尤其是误报与漏报；
• CERT-In 等机构的事故通报，会不会把「受影响方如何发现」作为必填信息，从而看出诱饵一类检测手段实际起了多少作用。