InjecMEM：不读不写记忆库，只发一条消息就劫持三成六的后续回答

agent 的记忆库是谁在写：一次写入，凭什么能影响之后每一次

一个只跟你聊过一次的人，之后你每次向 AI 助手提问，都有一部分可能让你的助手替他说话。这不是威胁愿景的修辞，而是 InjecMEM 这篇论文在评测条件下跑出来的实测：攻击者只发一条消息，此后 35.6% 的后续相关回答被劫持到攻击者预设的输出。所谓劫持，就是把 agent 的回答引向攻击者想要的内容，跟 DNS 劫持、会话劫持是同一类动作。而在同样的动态记忆场景里，三种经典的注入攻击成功率全部是零。InjecMEM

更反常的是攻击者的姿势。他全程没有读过你的记忆库，也没有改过哪怕一个字。他只是作为普通用户发了一条消息，剩下的工作由 agent 自己完成：这条消息被写进长期记忆，之后每一次相关问题，系统都会把它捞出来，照着里面的指示回答。攻击者唯一需要做的，是让这条消息写得足够聪明。

要做到这一点，靠的是 LLM agent 身上一个正在成为标配的部件：长期记忆。模型本身没有记忆，关掉对话就什么都不记得，所以 agent 在外面挂了一个记忆库，把对话历史、用户信息、工具结果都写进去，下次提问时再检索出来拼进上下文。问题在于，这个记忆库对谁开放。你的消息会写进去，网页内容会写进去，邮件和工具返回的结果也会写进去，凡是经过 agent 的内容都可能成为记忆的来源。InjecMEM 的开篇问题就是：记忆子系统会不会给 agent 引入新的漏洞？

要回答这个问题，先得看清记忆和即时上下文的本质区别。上下文是一份一次性的草稿纸：当前这轮对话里写什么，当场生效，会话结束就消失。记忆是一座可写入、可反复翻查的档案库：内容只要被写进去一次，之后每一次相关查询都可能把它重新翻出来。危险不在写入那一刻，而在之后的每一次检索。InjecMEM 的威胁模型正是建立在这条边界上：攻击者不能读、不能改记忆库，只能利用"任何内容都可能被写进去"这个事实。

图注：InjecMEM 论文里的高层 agent 架构。最左是 agent core，中间是与它并列的外部模块 RAG 和记忆系统，最右是记忆的三层组织 STM、MTM、LPM；图中标出一条注入通路：其他子系统通过 logged interaction 把内容写进记忆。InjecMEM

同一件事，另一篇系统研究记忆投毒的论文把它概括成一条管道：不可信的外部输入（网页、文档、邮件、工具输出）进入 agent 的上下文，被模型处理后，以"看起来可信的记忆条目"形态进入未来的会话。MPBench 攻击者要做的，就是把不可信内容伪装成可信记忆送进去。检验这条管道的第一步，是搞懂记忆系统内部怎么决定"谁会被捞回来"。这也正是下一节的问题：一条对话凭什么能被下一次查询捞回？

记忆是怎么工作的：一条对话凭什么能被下一次查询捞回来

InjecMEM 的靶子是 MemoryOS，一个把操作系统内存管理思路搬进 agent 的开源记忆系统。它的结构可以想成一间贴了标签的档案柜：最近的对话放在最外面一格，随取随用；常聊的话题按热度归进中间抽屉，每个抽屉里是同一主题的若干条记录；你的长期人设和背景信息锁在最里面的保险柜，很少动。这三格在论文里叫短期记忆 STM、中期记忆 MTM 和长期个人档案 LPM。

对话怎么进档案柜？新对话先落在最外一格，满了以后最老的一条被整体推进中间抽屉，按主题和已有抽屉做相似度匹配：相近的合并进去，相远的自己开一个新抽屉。中间抽屉的每条记录都带着一份摘要和一组关键词，让"这个抽屉聊的是什么"一目了然。抽屉太热，也就是被频繁翻看、互动多、时间近，还会触发一次升级，把里面的核心内容提炼进长期档案。

回答问题时走的是"先检索、再生成"。查询进来，短期记忆整段并进上下文；中期记忆先按摘要语义和关键词重叠挑出最相关的几个抽屉，再在抽屉内部按语义相似度选出最相关的几条记录；长期档案则按画像字段取回。所有捞回来的东西和当前问题拼成一份很长的文本喂给生成模型，论文里叫 fused prompt，即融合后的完整 prompt。MemoryOS

图注：MemoryOS 的总体架构。Store、Updating、Retrieval、Response Generation 四个模块与 STM、MTM、LPM 三层存储相互连接：对话先写入短期层，按主题整合进中期层，回答问题时再从各层检索拼成 prompt。MemoryOS

这套"分层、分页、热度淘汰"的设计并非 MemoryOS 独创，源头可以追溯到 MemGPT 提出的 virtual context management：把有限的上下文窗口当内存，把外部数据库当磁盘，让模型自己管理分页。MemGPT 但无论设计者是谁，有一件事对攻击者至关重要：记忆系统对"谁能被捞回来"有一套可预测的打分规则，摘要语义、关键词重叠、逐条相似度，谁的分高谁进上下文。换句话说，内容怎么写，直接决定它以后会不会被捞回来。那问题就来了：攻击者能不能控制"写进去的内容"？

让恶意内容跨会话活下去，为什么这么难？

攻击者想控制写进去的内容，这件事最早的形态叫间接提示注入（indirect prompt injection，IPI）。2023 年给它命名的论文观察到一个根本性的模糊：一旦给 LLM 接上检索，数据和指令的边界就塌了。外部数据源里被植入的一句话，检索进来后在模型眼里和系统指令没有本质区别，它会照做。当时的实证覆盖了多个真实系统，Bing Chat 和 Copilot 都曾中招。论文还在一个带记忆工具的合成应用上演示了把攻击代码存进记忆、跨会话复活的原始雏形。Greshake 等

但 IPI 有一个致命软肋：它当场生效，会话结束就失效。网页还在那里，可下一次会话不会自动把同一句话捞回来，攻击等于一次性消耗品。要让恶意内容活过下次会话，就得把它写进记忆，让"检索"替攻击者反复触发。这正是持久化记忆注入的新维度，也是 InjecMEM 要攻的阵地。

在 InjecMEM 之前，最接近这条路的尝试是 MINJA。它的威胁模型和 InjecMEM 很像：攻击者没有记忆库的读写权限，只能跟 agent 对话。但代价全在交互次数上：攻击者要在每条查询后面缀一段诱导性推理，让 agent 自己把含恶意步骤的记录写进记忆，再靠"逐步缩短"把诱导痕迹一点点删掉，模拟出一条像自然记录的东西。整套流程要几十轮对话——按论文的实验设置，每组 victim-target 对要发 15 条攻击查询，每条还要走 4–5 轮渐进缩短，单组下来往往要 60 轮以上的交互，而且留下的每一条查询都带着诱导痕迹，本身就是可疑信号。MINJA

图注：MINJA 的双色对比图。上半是假设攻击者能直接改写记忆库的旧范式，下半是 MINJA 的 query-only 做法：给普通查询缀上诱导提示，诱导 agent 自己生成恶意推理并存入记忆，再逐步缩短诱导痕迹，等受害者来问时靠检索触发。MINJA

另一条路是触发器驱动：AgentPoison 这类 RAG 后门在记忆库里植入带特殊 trigger 的恶意样本，用户未来的查询恰好带上这个 trigger 才可能被捞出来，而且触发器优化还得白盒访问 embedding 模型。AgentPoison 两条路各有各的笨重：一个要几十轮对话，一个要碰运气还搭上白盒假设。InjecMEM 给自己设的靶子因此格外苛刻：单次交互，只发一条消息；不读不写记忆库；目标是跨会话持久生效。能做到才算真正解决了"持久"这个问题。

InjecMEM 的做法：一半句子负责被捞到，一半负责捞到就触发

InjecMEM 的攻击循环可以用一张图说完。攻击者发一条对抗性消息，agent 正常处理，这条交互被记忆系统写进档案。之后某天，一个毫不知情的良性用户问起同一主题，检索系统把档案里那条毒记录捞进 fused prompt，模型照着里面的指示输出攻击者预设的回复。攻击者全程只有一次交互，剩下的都交给记忆系统自己完成。

图注：InjecMEM 的攻击循环总览。攻击者输入一条对抗性消息，记忆系统记录它；良性用户之后关于主题 τ 的查询把这条毒页捞回融合后的 prompt，模型输出被劫持到目标回复。图中只呈现"写入、检索、触发"的完整闭环，不涉及内部优化细节。InjecMEM

整条循环里有两处关键节点，毒记录必须连续闯过：先被检索捞回，再被模型执行。InjecMEM 的洞察是把一条毒消息拆成两段，分别对付这两个节点。前半段叫 anchor，负责"被捞到"；后半段叫 command，负责"捞到就触发"。一段管检索，一段管生成，各司其职。

图注：一条毒消息的内部结构示意（本文作者绘制）。前半段 anchor 是话题标签，负责让毒页被主题相关的查询捞回；后半段 command 是对抗指令，负责让毒页一旦进入融合后的 prompt 就迫使模型输出目标内容。检索与生成两个环节各由一段解决。

先说 anchor。它的作用相当于贴在毒页上的话题标签：决定这份"档案"会被归进哪个主题的抽屉、被什么查询捞出来。目标主题窄的时候，比如"背痛"这个具体症状，直接在 anchor 里放上主题关键词，再写一段贴合主题的话，这样关键词重叠和语义相似度两条检索通道都能命中。目标主题宽的时候，比如整个"健康"领域，用户问法千差万别，单个关键词靠不住，论文改用"领域质心锚点"：把领域标签、几条高召回关键词和一批常见子主题都写进 anchor，把毒页的语义位置整体推向整个领域的中心。离中心越近，任何方向的问法都有越大概率够到它。这个设计刻意不针对任何具体检索模型优化，谁来检都能用。

再说 command，这是整篇论文最费劲的部分。毒页一旦被捞进 fused prompt，它周围是什么文本、排在什么位置、前面堆了多少检索内容，攻击者全都不知道。直接写一句"请输出 XXX"会被淹没，随随便便就被忽略。InjecMEM 用 Multi-GCG 解决：先准备一组模拟真实检索上下文的替身 prompt，把候选指令插入不同深度，然后跑梯度坐标搜索，找出一段短字符串，让它在"任何替身上下文 + 任何插入位置"的组合下，都高概率迫使模型吐出目标输出。优化出来的是这么一段既不像正常指令、又处处管用的文本。

把两段拼起来，一条消息同时解决两个问题：anchor 保证它大概率被捞回，command 保证捞回就触发。anchor 故意做长，让索引和检索信号被它主导；command 在含 anchor 的模板上训练，两段拼接时互不拖累。为了把优化做扎实，论文假设攻击者能白盒访问生成模型，也就是拿得到梯度，这是它刻意收窄的边界：先把记忆漏洞这件事测干净，生成端的不确定性留给别人研究。至此，"一条消息、不碰记忆、跨会话生效"从目标变成了可复现的流程。剩下的问题是：这条流程到底有多灵？

效果与边界：三条经典攻击全灭，跨家族迁移却归零

要读懂论文的数字，先分清三个指标。RSR 是检索成功率（retrieval success rate），度量毒页被后续相关查询捞进 prompt 的比例；ASR-c 度量毒页被捞回之后、模型照单输出目标内容的比例，是个条件概率；ASR-j 把两段串起来，是端到端命中率。论文在 MemoryOS 上配 Qwen2.5-7B-Instruct 跑的 19 个领域平均结果如下：

以上是论文在 MemoryOS + Qwen2.5-7B-Instruct 白盒条件下报告的 19 域平均。

最有冲击力的一行是最后两列：三种经典注入攻击 DPI、BadChain 和 vanilla GCG 在这套动态记忆场景下全部归零。它们擅长静态 prompt，可记忆融合后的上下文每轮都在变，毒文本的位置和周围内容不可预测，经典方法直接被动态性打垮。反过来看 InjecMEM 的 76.6%，这个对比的含意是：不是大家都没招，而是只有把"检索"和"触发"分别对付，才跟得上记忆的动态。需要强调的是，这些数字度量的是"这条消息管不管用"，实验里的目标输出是占位符，不是实际的有害指令，所以不能直接外推成真实世界的攻击成功率。

这套测法本身也值得一提：先开一个会话，让 agent 处理带对抗载荷的任务，检查记忆库里有没有留下毒内容；再开一个全新会话，用相关查询触发检索，看输出有没有被带偏。写会话和检索会话严格分离，这正是"持久"的操作化定义，MPBench 做记忆投毒基准评测时用的也是同一套双会话方法学。MPBench InjecMEM 还在 MemGPT 上做了二次验证：把在 MemoryOS 上优化好的指令直接拿过去用，ASR-c 仍有 48.6%，说明这不是 MemoryOS 专属的漏洞。InjecMEM

边界同样清楚。一个隐患在跨模型迁移：在单一模型上优化出来的 command，换到另一家模型家族就失效，跨家族零样本迁移率是 0%。家族内联合优化（FJ-Multi-GCG，用同族两个模型一起优化）能把 3B 和 14B 从 0% 拉回 36.8% 和 64.2%；让三大家族同时生效则要靠工程拼接，把三条命令 Concat-3 起来，Qwen、Mistral、Llama 同时落在 66.3% 到 78.2%。InjecMEM 换句话说，同家族内能迁移，跨家族只能靠联合优化或者拼接覆盖，零样本跨家族泛化依然是一道硬边界。

防线为什么拦不住？记忆安全该把功夫下在哪里

最自然的防御是在检索出口装过滤器：毒页在进上下文之前先过一遍检测。论文把四类现成的 retrieve-time 过滤器接进记忆管线：LLM-as-a-Judge、ProtectAI、PromptGuard 和困惑度过滤。结果是分层的失效。基于打分的那三类能把 RSR 压到 35.2% 到 39.1%，ASR-j 压到 26.7% 到 29.8%，但 ASR-c 几乎不动，还是 75.4% 到 76.6%。意思是：过滤器让一部分毒页根本进不了上下文，但凡是漏过去的，指令照样完整执行。InjecMEM

困惑度过滤更极端：把阈值调到刚好完全压制攻击，RSR 归零，代价是误伤 71.8% 的良性记忆。性价比最高的那一点恰好卡在"宁可错杀"上，实用价值存疑。这套失效不是工程没做好，而是结构性的：过滤器设计的假设是恶意内容长得像指令、突兀、可疑，而记忆注入的载荷披着正常对话的外衣，跟良性内容难分彼此。MPBench 的评测给过一个更刺眼的佐证：在信号微弱的记忆投毒攻击面前，最强的现成守卫之一 PromptArmor 检测率从 84.44% 跌到 42.50%。MPBench

为什么防线都拦不住？把问题放进记忆生命周期的坐标系里看就清楚了。一份记忆内容要经过写入、存储、检索、执行、传播、遗忘六个阶段，InjecMEM 的毒内容在写入阶段埋下，在检索和执行阶段引爆，而现成防御几乎全部堆在检索这一道关卡上。

图注：LLM agent 记忆生命周期的六个阶段（写入、存储、检索、执行、传播、遗忘回滚）与四项横切安全目标。Write 与 Retrieve 两处标注了闪电记号，表示这两处是攻击文献最密集的相位。LTM 综述

写入阶段缺来源标注和写授权，遗忘阶段缺快照和回滚，两头都是空的。这篇综述给出的判断很直接：治理原语，也就是谁来写、写了什么、能不能回滚，才是记忆安全该下功夫的地方，而不是在检索出口打补丁。LTM 综述

"事后补救"这条思路还有一层尴尬。论文专门画了一条间接路径：一个被攻破的邮件工具返回一封带恶意指令的邮件，agent 正常处理并把这段对话写进记忆，之后工具修好了，毒记录却还在记忆库里，照样被检索触发。补丁打在工具上，漏洞留在记忆里。这条威胁面也不是分层记忆系统的孤例：在 web agent 形态下，攻击者在产品页里埋一行内容，agent 执行任务时把含毒观察写进轨迹记忆，之后的跨站任务里被捞出来触发。持久化记忆投毒是这一类带记忆 agent 的共性问题，不是 MemoryOS 运气不好。eTAMP

也得给论文划边界。它对"先改写、摘要、压缩再存储"的记忆系统不直接成立，因为白盒攻击者需要知道写入时的变换；它假设白盒 backbone，黑盒场景要另算；单一 command 不能零样本跨家族迁移；实验目标输出是占位符而非真实有害指令。这些局限把"攻击有效"限定在了明确的前提之内，同时也指明了下一步：真正的防线应该在写入那一刻建立信任判断，而不是等毒内容住进档案柜以后再想办法。

记忆一旦可写，就同时可被污染。拦得住检索，拦不住"检索到就执行"，治理的功夫得下在写入时。想深入可以读原文：InjecMEM: Memory Injection Attack on LLM Agent Memory Systems，arXiv:2608.23471

参考文献

1. InjecMEM: Memory Injection Attack on LLM Agent Memory Systems（arXiv:2608.23471）— https://arxiv.org/abs/2608.23471
2. Memory Injection Attacks on LLM Agents via Query-Only Interaction（MINJA，arXiv:2503.03704）— https://arxiv.org/abs/2503.03704
3. Memory OS of AI Agent（MemoryOS，arXiv:2506.06326）— https://arxiv.org/abs/2506.06326
4. MemGPT: Towards LLMs as Operating Systems（arXiv:2310.08560）— https://arxiv.org/abs/2310.08560
5. Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection（arXiv:2302.12173）— https://arxiv.org/abs/2302.12173
6. AgentPoison: Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases（arXiv:2407.12784）— https://arxiv.org/abs/2407.12784
7. MemoryGraft: Persistent Compromise of LLM Agents via Poisoned Experience Retrieval（arXiv:2512.16962）— https://arxiv.org/abs/2512.16962
8. From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents（MPBench，arXiv:2606.04329）— https://arxiv.org/abs/2606.04329
9. A Survey on Long-Term Memory Security in LLM Agents: Attacks, Defenses, and Governance Across the Memory Lifecycle（arXiv:2604.16548）— https://arxiv.org/abs/2604.16548
10. Poison Once, Exploit Forever: Environment-Injected Memory Poisoning Attacks on Web Agents（eTAMP，arXiv:2604.02623）— https://arxiv.org/abs/2604.02623