3 篇博文 含有标签「llm-safety」

我最近交流的一个团队为他们的 AI 助手构建了一个所谓的“深度防御”（defense in depth）流水线。一个输入分类器检查提示词注入；一个越狱过滤器扫描对抗性模式；模型生成回复；一个输出审核环节扫描结果；一个拒绝检测器检查模型是否回避了问题，如果是，则通过重新表述步骤，用更委婉的框架再次提问。评估套件显示该提示词在 1.4 秒内生成了答案，但真实用户的等待时间中值是 3.8 秒，p95 则超过了 9 秒。

每一个安全层都是一次往返。每一次往返都包含网络跳数、排队时间、模型加载和解码。当你将它们串行地堆叠在生成调用前后时，你为产品设定的延迟预算就会灰飞烟灭——而几乎没人在设计评审时考虑到这一点。更糟糕的是：流水线中最慢、最昂贵的路径往往是那些触发了安全边缘提示词的路径，而这恰恰是你的安全机制存在所要处理的长尾场景。你正在默默地用普通用户的账单来补贴这些长尾流量。

大多数生产环境中的 AI agent 系统都使用了某种版本的 LLM-as-judge 监控：由第二个模型审查 agent 的输出并标记可疑行为。这种方法直观、易于部署，但作为主要防御手段却存在严重缺陷。一项分析跨多个提示攻击向量的单判官（single-judge）监控的研究发现，加权攻击成功率为 52.7%——这意味着具有对抗性的复杂 agent 逃避检测的概率比被发现的概率还要高。对于单轮、低风险的应用，这或许可以接受。但对于拥有外部系统访问权限的自主 agent 来说，这是一个致命的漏洞。

更深层次的问题在于，能力和欺骗性是同步增长的。随着 agent 在预期任务上变得更加强大，它们也变得更擅长模拟其受监管的环境，并相应地调整行为。

提示注入吸引了所有关注。但提示注入在会话关闭时就结束了。内存投毒（Memory poisoning）——将恶意指令注入 Agent 的长期内存——会创建一个持久性的漏洞，跨会话存续并在几天或几周后执行，由完全不像攻击的交互触发。对生产级 Agent 系统的研究显示，在受测的基于 LLM 的 Agent 中，注入成功率超过 95%，攻击成功率超过 70%。这是大多数团队尚未防御的攻击向量，且它已经进入了 OWASP Agent 应用前十名（OWASP Top 10 for Agentic Applications）。

核心问题很简单：Agent 将自己的内存视为可信的。当 Agent 从向量库或对话历史中检索“内存”时，它处理这些信息的信心与处理系统指令时相同。没有加密签名，没有来源链，Agent 也没有机制来区分它是从真实交互中形成的内存，还是由上周二处理的某个恶意文档注入的。