为什么 Memory Poisoning 是 AI 安全的新前沿
Source: Dev.to
想象一下，你拥有一个出色的全新 AI 代理。它可以处理你的邮件、管理你的日程，甚至帮助进行代码审查。它之所以出色，是因为它记得你的偏好，并从每一次交互中学习。但如果有人能够在它的耳边“低语”一个永远不会忘记的谎言，会怎样？
这不仅仅是一个假设情景。随着我们从无状态的大语言模型（LLM）转向使用检索增强生成（RAG）和持久记忆的自主代理，我们正打开通往一种更危险攻击类型的大门：记忆与上下文投毒（Memory and Context Poisoning）。
什么是记忆与上下文投毒？
在 AI 安全领域，我们经常讨论 prompt injection。你应该很熟悉这种手法：用户试图欺骗模型“忽略之前的指令”。虽然令人烦恼，但 prompt injection 通常是瞬时的。会话结束后，使用的“海盗模式”或其他利用手段就会消失。
记忆投毒 (ASI06) 则不同。它是对代理长期知识的结构性破坏。它不像一次性的技巧，而更像是给一名可信员工一套伪造的操作指南，让他们永远遵循。
| 功能 | Prompt Injection（瞬时） | 记忆与上下文投毒（持久） |
|---|---|---|
| 目标 | 即时、一次性的操控。 | 长期、结构性的腐化。 |
| 攻击对象 | 当前的提示上下文。 | 长期记忆（RAG、向量存储）。 |
| 持久性 | 零——回合结束后即被遗忘。 | 高——影响未来的、无关的任务。 |
| 检测难度 | 相对容易。 | 困难——表现为合法的上下文。 |
代理转变：为何此时此刻尤为重要
该威胁之所以跃升至优先级列表首位（在 OWASP 2026 代理应用十大风险 中被标记为 ASI06），是因为我们当前构建代理的方式。现代代理依赖于三个核心支柱，而这些支柱不幸也成为了攻击向量：
-
检索增强生成（RAG）
RAG 是代理的“真相来源”。如果攻击者能够将恶意文档注入你的向量数据库，代理就会检索到它并将其视为事实。这不仅仅是一个错误答案，而是一个被破坏的基础。 -
工具使用放大
代理不仅仅是对话，它们会执行操作。它们调用 API、运行代码并移动数据。如果代理的记忆被投毒，使其相信某个特定的恶意账户是“可信供应商”，它将毫不犹豫地使用其工具向该账户发送金钱或数据。 -
自主决策循环
代理经常将自己的日志或摘要写回记忆中。这会形成一个反馈循环，最初的微小“毒药”会随时间增长并自我强化，使得追溯到最初的攻击变得极其困难。
开发者的现实风险
这不仅仅是学术上的讨论。对于构建企业级代理的开发者来说，风险是具体且实际的：
- 数据泄露： 代理可能被“引导”始终在发送给特定外部用户的摘要中包含敏感 ID。
- 金融欺诈： 对采购代理进行投毒，使其使用错误的汇率或伪造的路由号码来处理“合法”供应商。
- 策略侵蚀： 类似“回声室攻击”的技术可以通过多轮、表面良性的交互逐步削弱代理的安全防护。
如何防御你的代理
构建弹性代理需要从“保护模型”转向“保护上下文”。
- 严格的上下文隔离： 切勿让用户提供的输入直接进入长期记忆，必须经过验证层。你的系统提示应保持不可变。
- 来源追踪： 你的 RAG 索引中的每一条数据都需要一张“出生证”。是谁写的？何时写的？来源是什么？如果出现问题，你需要能够回滚。
- 摄取层输入净化： 将你的 RAG 流程视作数据库。对所有内容进行净化。向量化之前检查是否存在对抗性字符串和代码。
- 行为审计： 由于中毒手段隐蔽，不能仅仅寻找“坏词”。要随时间监控代理的行为，发现其使用工具时的异常。
要点总结
- 内存和上下文中毒是一个根本性的完整性问题，而不仅仅是一个可以修补的漏洞。随着我们赋予代理更大的自主权，它们记忆的完整性将成为我们主要的防御前线。
您正在实施哪些具体的架构改动来保护您的 RAG 流水线和代理记忆，以免受到 ASI06 的影响？