我成功对一个AI智能体的记忆实施了投毒。在216次尝试中全部成功，开发者因此在一个月内就发布了修复补丁。

不久前，我对编码代理使用的记忆服务器产生了兴趣。它们大多有个便捷功能：如果关于同一事物的更新笔记到来，它会自动替换旧记录。当你从Postgres切换到MySQL时，代理会立即识别变化，你无需手动清理任何数据。但如果新笔记是错误信息呢？比如代理读取了一个被篡改的README文件，并用“备份保留3天”的错误信息覆盖了你真实的“35天”记录。我在开源MCP记忆服务器Knowl的议题中提出了这个问题，维护者回应说："当然，可以好好测试一下。"于是我就照做了。（他也同意我将这次测试整理成文，并公开项目名称。） ## 测试设置 我编写了12条编码代理实际会存储的事实信息，如令牌生命周期、部署审批规则、数据存储区域和备份保留期限，并将它们标记为已验证状态。随后，我通过多种形式尝试写入伪造数据：直接矛盾的信息、伪造的“已观察”标签、与真实修正记录完全一致的写入操作，以及那些保留真实值但添加例外情况的隐蔽修改（例如“需要两位评审人批准或管理员覆核”）。 ## 测试结果 在测试版本中，216次攻击性写入全部成功替换了真实事实，且伪造信息成为代理返回的首选答案。事后系统未检测到任何异常，因为冲突检查器仅对仍处于激活状态的事实进行核验——而被替换的真实记录已不再活跃状态。更令人担忧的是，这类攻击在写入时同样无法被识别：我将每次攻击性写入与同一事实的真实修正记录并列比对，系统检查的所有特征指标都完全相同。最令我震惊的是，即使写入内容没有明确说谎，也可能彻底覆盖事实。用“请查阅运维手册”这样的表述替代具体数值，在36次测试中有36次都成功覆盖了真实数据。 ## 维护者的修复措施 维护者积极应对此问题，针对我提出的5项建议中的4项进行了修复。我在新代码上重新运行测试： - 自动写入（如数据采集）在全部攻击测试中，替换已验证事实的次数从36次降为0次 - 独占事实的覆盖失败次数从36次降至0次 - 所有被替换的事实现在都会在冲突视图中显示（此前显示数量为0） - “请查阅运维手册”的误导技巧成功率从100%降至25%——当目标值为纯文本时仍可能被绕过 新版本（Knowl 5.24.0）已发布。 ## 后续测试发现 重新测试揭示了新问题：当伪造笔记与真实事实并存而非替换时，在搜索结果中仍可能排名第一，出现概率高达21/36。我提交了一个小型修复补丁，维护者采纳后将我列为共同作者。目前该问题出现率已降至0。 ## 遗留的安全考量 如果代理被诱导直接调用存储工具，形似修正记录的虚假信息仍可能通过校验。在写入时刻，系统仍无法区分这类写入与真实修正。关键改进在于：现在系统能向非写入者展示这类事件发生记录。 ## 给记忆服务器使用者的建议 如果你运行的代理具有长期记忆功能，可以进行简易测试：输入几条你已知的真实信息，通过代理使用的相同路径写入合理但错误的版本，然后再次查询。你可能对结果感到惊讶。 完整报告与测试设置详见首条评论。欢迎提问，如果你正在为代理开发记忆功能，我很想知道你将如何处理“形似修正的虚假信息”这类情况。