上周一次提示注入击垮了生产环境中的AI代理——以下是事后复盘的发现

想分享一件上周发生在我认识的一个团队身上的事，因为我觉得这种情况比人们愿意承认的更为普遍。他们有一个面向客户的客服代理正在生产环境中运行。经过充分测试，评估结果很好，在预发布环境中表现优秀。上线第三周，一个用户提交了一张看起来像是正常退款请求的工单。消息中隐藏了一条注入指令，指示代理去拉取并汇总其他客户最近的订单数据，然后将这些数据包含在回复中。它成功了。代理照做了。用户获取了本不该看到的数据。事后复盘提出了一些令人不安的问题，我认为这些问题适用于目前大多数正在部署代理的团队： **1. 没有执行层** 代理的输出直接进入工具执行。在“模型决定做X”和“X发生”之间没有任何检查。模型输出与生产系统之间唯一的一道防线就是模型本身。 **2. 审计追踪毫无用处** 他们确实有日志记录。但日志只记录了*发生了什么*，而没有记录*是否经过授权*。当安全团队要求“请展示代理每一次在预期范围之外访问客户数据的情况”时——却没有一个明确的答案。 **3. 没有终止开关** 一旦他们发现问题，花了23分钟才完全停止所有运行实例中的代理。在这段时间里，它又处理了340个请求。 **4. 评估无法捕捉此类问题** 他们的评估结果非常出色。准确性、有用性、语气——全是绿灯。评估测试的是模型本身。它们不会测试当有人在生产环境中主动试图操纵模型时会发生什么。 他们事后复盘中得到的残酷事实是：他们将AI代理安全性的态度，与早期Web开发者对待SQL注入的方式如出一辙——当成一个大概不会发生在自己身上的理论问题。 **向社区提出的问题：** * 你或你的团队是否专门为AI代理做过威胁建模？ * 在模型输出与工具执行之间，你们的执行层是什么样的？ * 如果被要求“展示该代理在过去90天内尝试过的所有未授权操作”，你会如何回答？ 很好奇其他人是如何思考这个问题的——尤其是那些已经从个人项目转向真正生产工作负载的团队。