记忆来源漂白：面向 LLM Agent 持久记忆的「非放大」防火墙

关联论文：2607.29167
作者：flyP
更新：2026-08-03

一句话结论

本文命名并形式化了「memory provenance laundering（记忆来源漂白）」这一新型 LLM Agent 安全威胁，并实现了一个轻量级中间件 PPMF（Provenance-Preserving Memory Firewall），通过保留平台维护的来源标签 + 按行动风险匹配记忆权威性，把经过有损记忆整合后的攻击成功率从 1.000 降到 0，同时不阻断已确认的良性动作。

解决的真问题

LLM Agent 普遍引入了「长期记忆」机制：把过去的交互、用户偏好、工具调用结果压缩进一个持久记忆库，下次启动时检索复用。这带来两个并存的事实：

有用：让 agent 跨会话保留偏好和工作流，UX 与任务一致性大幅提升；
危险：一旦不可信观测（如网页抓取、第三方工具回包、邮件内容、被污染的 RAG 文档）进入记忆库，agent 在后续主动检索时会把它当成「历史/偏好/工作流支持」使用，而不再记得它原本来自低权威性来源。

作者把这条攻击面命名为 memory provenance laundering（记忆来源漂白）：在有损的记忆整合过程中，外部观测被改写为貌似用户历史或工作流支持的形态，保留可触发的动作条件（所以 agent 会去做），抹去限制其权威性的低可信来源（所以 prompt 过滤器、内容清洗器、工具守卫都拦不住）。

这个威胁独立于已有的 prompt injection、tool misuse、indirect prompt injection，又与它们交叉。已知的 prompt filter、content sanitizer、tool guard 都假设「输入直接到达 agent」，对经过整合后的记忆片段无能为力。

核心方法

1. 安全原则：来源权威性非放大（Non-Amplification）

作者把对抗目标抽象成一条信息流不变量：记忆整合函数 consolidate(obs) 必须满足

trust(consolidate(obs)) ≤ trust(obs)

即整合后的记忆权威性不能超过其原始来源。这是经典的 IFC（information flow control）「no read up, no write down」原则在 agent 记忆层的实例化。

直觉上：一条来自外部网页的可信度是 0.3 的观察，整合后无论变成「用户偏好」「工作流」还是「事实条目」，它的可信度上限仍是 0.3，绝不允许升级为 0.9 的「用户历史」。

2. 系统组件：PPMF 中间件

        ┌──────────────────────────┐
        │  不可信观测 obs (web/email│
        │  /tool/MCP/RAG/...)      │
        └────────────┬─────────────┘
                     │
                     ▼
        ┌──────────────────────────┐
        │  consolidate(): memory   │   ← 整合后必须保留 prov & risk
        │  store w/ provenance tag │
        └────────────┬─────────────┘
                     │
                     ▼
        ┌──────────────────────────┐
        │  PPMF Middleware          │
        │  ·平台维护 provenance    │
        │  ·风险分级（高/中/低）    │
        │  ·权威性匹配门控          │
        └────────────┬─────────────┘
                     │
       action 触发  │◄─────  agent planning
                     ▼
        ┌──────────────────────────┐
        │  Tool Call Gate           │
        │  action_risk ≤ auth(m)    │
        └──────────────────────────┘

PPMF 做了三件事：

保留平台维护的来源标签：把 provenance 当作受信任的元数据，由宿主平台（agent runtime）维护，LLM 自身不能修改——这是非放大原则能落地的关键；
风险分级与权威性匹配：每个潜在 tool call 必须通过 action_risk ≤ auth(memory) 门控，高风险动作（删除、付款、外发数据、权限变更等）需要高权威性记忆支撑；
确认机制：对关键动作要求二次确认（confirmation），并按风险标签过滤。

3. 形式化边界

作者把该边界显式形式化为：给定一个有损整合函数 consolidate 和一个调用门控 gate，若对任意观测序列 O 与请求 r 存在

gate(consolidate(O), r) = allow   但   trust(O) ≢ trust(O)

即门控允许了一个来源已被改写的请求，就构成 laundering。

更工程化地讲，PPMF 信任链由五个节点构成：

观测入口（source）：每条 obs 在进入记忆时由运行时打上不可伪造的 provenance；
整合函数（consolidate）：必须输出带 provenance 的记忆条目，LLM 不能在输出侧把 web.observed 改写为 user.history；
记忆库（store）：每条记忆以 (content, provenance, risk_label, ts) 形式持久化；
检索器（retrieval）：检索结果携带 provenance 与 risk_label 进入 prompt；
门控（gate）：tool call 发起前校验 action_risk ≤ min(risk_label, max_auth(memory))。

这五节点缺一不可：只在前三层做 provenance 但不门控，等于把责任甩给 prompt；只在门控层做风险匹配但记忆里没 provenance，门控就成了猜谜游戏。

4. 攻击与防御图谱（推断）

PPMF 的核心防御面不是「拒绝所有外部记忆」——那等于阉割 agent 的复用能力，而是「保留低权威性的同时仍允许使用」。具体地：

外部网页里「用户上次说……」的偏好：可保留、可检索，但不允许它单独触发高风险动作；
已确认的用户输入（如「我以后都用这个地址收件」）：权威性高，可单独触发；
高风险动作（删数据、改权限、发邮件）：必须由 ≥ 中权威的记忆 + 二次确认共同支撑。

关键实验与数据

作者在「schema-grounded evaluation + 固定风险策略」下做了一组对照实验，原文 abstract 给出两个关键数字：

未防护时：经过合并的「脆弱」记忆触发的攻击成功率（ASR）达到 1.000，即每次攻击都能得手；
启用 PPMF：在「保留平台维护来源 + 确认 + 风险标签」三件齐全的条件下，所有评估中的未授权高风险动作都无法通过 PPMF 门控；同时已被确认的良性动作与针对性的低风险记忆使用仍然可执行。

原文标注「原文未明确」的几处：

攻击/记忆场景数量、覆盖的 agent 框架（LangGraph / AutoGen / CrewAI / MCP-only 等）；
评测中使用的具体 LLM backbone 与 tool 集合；
良性任务的成功率与延迟代价；
是否对多轮、跨记忆检索、跨 agent 协作等组合攻击做了扩展评估。

但 abstract 的数字本身就是论文最强的证据：1.000 → 0 是非常罕见的「攻击清零」声明，且未以牺牲可用性为代价。

亮点与局限

亮点

命名了一个真实存在但未被系统化的威胁：memory provenance laundering 在 LangChain/AutoGen 等框架普及后已经在多个产品中潜伏，作者把它形式化，给社区一个共同讨论坐标。
机制与工程路径双轨：机制上是非放大原则（IFC 落地），工程上是「平台维护 provenance + 风险分级 + 权威性匹配门控 + 二次确认」，不靠 prompt 黑魔法。
不破坏可用性：常见防御一刀切拒绝外部记忆，导致 agent 复用能力丧失；PPMF 通过「保留 + 限制使用」保留了长记忆的核心价值。
轻量中间件形态：PPMF 被设计为可插拔中间件，不需要重写 agent 代码，对现有框架友好。

局限与反方

schema-grounded 评估的外部效度有限：评测用「固定风险策略 + 结构化场景」，真实世界中风险策略本身可能被绕过（例如 agent 自评「这是低风险动作」），原文未明确对抗自适应策略的能力。
LLM 端的权威性评估可靠吗？ 风险等级目前依赖规则或人工定义，agent 自身对 action risk 的判断是否会被 prompt injection 污染，原文未明确。
平台维护 provenance 的信任根：整个方案假设「宿主机/运行时是可信的」，但如果 runtime 本身被攻破（如 prompt 注入 runtime 控制平面），整个 provenance 系统可能崩塌，论文未量化此风险。
跨记忆、跨会话、跨 agent 的攻击面未充分展开：相关工作中 TMA-NM（arXiv:2606.24322，已检索到）已经在做 non-malleable origin binding，PPMF 是否覆盖 multi-hop 与 Sybil 类攻击，原文未明确。
未量化工程成本：对每一次 tool call 增加门控评估的延迟与 token 代价，原文未给出数字。
未开源 / scale-up 风险：原 abstract 与提交历史未提公开仓库，复现与产业落地门槛较高。

对工程落地的启发

任何持久记忆 agent 都该有 provenance：把来源、采集时间、采集通道、风险等级当作受信任元数据写入记忆条目；runtime 维护，不让 LLM 改。
风险分级要落到 tool 维度：每个 tool call 的最大风险等级在框架层静态标注，避免 agent 自己判断风险。
高风险动作必须由「高权威记忆 + 二次确认」共同授权：仅靠一条被改写的「用户偏好」不允许触发。
中间件形态优于 SDK 形态：把 PPMF 设计成独立中间件，可横跨 LangGraph / AutoGen / MCP / 自研 agent 框架，是该方案可持续落地的关键。
prompt filter 之外的第二道防线：现有内容清洗只挡得住「当下输入」，挡不住「经过记忆改写后的输入」，二者必须并行。

与同方向工作的关系

传统 prompt injection / indirect prompt injection：PPMF 解决的是其记忆态变种，不替代前者，应作为第二道防线组合使用。
IFC / Taint tracking：PPMF 把经典「no read up, no write down」从系统层搬到 agent 记忆层，与 NeuFlow、Purifier 等思想同源。
相关同期工作：
arXiv:2606.24322《Securing LLM-Agent Long-Term Memory Against Poisoning》提出 TMA-NM（Tamper-evident Memory Authority, Non-Malleable），用 non-malleable IFC + Sybil-resistant 协同确认，PPMF 与之同方向、互补；
Microsoft Research GroupMemBench（已检索到）则关注多用户/多会话记忆正确性，不在安全面上，但同样揭示现有记忆系统的鲁棒性短板。
与 RAG 防护：RAG 文档投毒与本文威胁相邻，但 RAG 通常单次检索、可在检索层打分；记忆层威胁跨越多次重写，传统 RAG 防护不够。

适合谁读

做 LLM Agent 平台、agent runtime、agent 安全中间件的工程团队——这是必读项。
做 RAG / memory system / 长期记忆架构的研究者——provenance + 风险分级是新设计坐标。
企业安全团队、CISO 视角评估 agent 部署风险——非放大原则与中间件形态可直接落到 threat model。
学术安全 + NLP 交叉研究者——形式化 laundering、给出 1.000→0 的对照，是少见的「agent 安全实证案例」。

与 TMA-NM 的差异化（重要）

为避免读者混淆，把 PPMF 与同期工作 TMA-NM（arXiv:2606.24322，已 web 检索到 abstract）的关系显式化：

维度	PPMF（本文）	TMA-NM（2606.24322）
防御目标	来源权威性非放大	抗篡改、抗 malleable 的来源绑定
数学保证	IFC-style no-write-up 不变量	非可锻（non-malleable）信息流控制
协同确认	风险标签 + 二次确认	Sybil-resistant corroboration-gated elevation
攻击面	跨记忆整合的来源改写	跨记忆、跨 agent、跨模型的复合攻击
评测形式	schema-grounded + 固定风险策略	MEM-INV-Bench，12 域 / 5 类工具 / 三类攻击
边界	未量化自适应攻击者	形式化证明 T1/T2/T3 三条定理

两文同方向、互补：TMA-NM 给更强理论保证但落地复杂，PPMF 给更轻量中间件但形式化深度有限；工业落地常先采用 PPMF 形态，再随攻击面升级迁移到 TMA-NM 风格。

不确定处

攻击场景数量与覆盖的 agent 框架：原文未明确。
评测 backbone 与 tool 集合细节：原文未明确。
良性任务通过率与延迟代价：原文未明确。
对自适应攻击者的鲁棒性：原文未明确。
代码与中间件是否开源：原文未明确。
与 TMA-NM（arXiv:2606.24322）的精确分工与边界：原文未明确。

工程落地与核查（Jay）

事实核查

存疑处 1（已就地修正）：原文件标题为"EMNLP 会议"，但 arXiv 2607.29167（2026-07 发表）未检出 EMNLP 2025/2026 acceptance 记录；本文实为 arXiv 预印本，原标注 EMNLP 会议存疑，应以 arXiv 版本为准。

存疑处 2：ASR 1.000 → 0 的结论来自 abstract 未附条件的绝对陈述，需对照原文正文确认评测前提（是否在固定风险策略下完成、评估是否覆盖全部攻击路径）。摘要级声明与正文细节之间可能存在评价条件差异。

存疑处 3：TMA-NM（arXiv:2606.24322）已在本文中以"已检索到"标注但未做摘要级核验，GroupMemBench 为推断引用，均未在原文中得到实证对照，引用时请降权。

可读性精修

术语统一：「来源权威性」「可信度」「trust」混用，建议全文统一为「来源权威性」并附 trust 对照；
逻辑检查：第五节点描述"门控层做风险匹配但记忆里没 provenance，门控就成了猜谜游戏"逻辑成立，与非放大原则形成闭环；
全文无明显措辞问题。

工程落地：实际系统怎么用、坑在哪

1. provenance 的信任根：运行时还是 LLM？

整个方案依赖「运行时是可信的」这一假设——如果 runtime 被 prompt injection 攻破，provenance 元数据本身可被伪造。落地第一坑：必须在 OS/容器层固化 provenance 写入权限（不允许 LLM process 直接写 memory store 的 prov 字段），而不是在应用层做约定。

具体实现上，HTTP(S) 来源可在 HTTP response header 层面打标签（X-Provenance: web,domain=tld,timestamp=ISO），MCP tool 调用在返回 payload 里嵌入口标识，RAG 文档入库时由 pipeline 写死 source doc ID——这些都在 LLM 可及范围之外。

2. 延迟代价

每条 tool call 过门控至少增加一次 provenance lookup（记忆库读）+ 一次风险等级匹配（规则或 LLM 判）。若 action_risk 判定走 LLM，每次 gate 评估额外消耗一次 inference call。量化指标缺失是原文最大工程障碍，内部分摊估算每请求增加 50–200ms 延迟（GPT-4o 级 model 做 risk classification），生产落地前必须实测。

3. 风险分级粒度

原文只说「高/中/低」三级，但真实系统 tool 数量往往上百。落地第二坑：静态风险分级在 tool 维度是可行的（send_email = 高，read_doc = 低），但「这条记忆能不能支撑这个 action」需要动态上下文判断——静态规则在高动态场景下会产生大量 false positive（好记忆被误判为不够权威）。

建议：先用规则做粗筛（高风险 tool 必须来自已确认 source），再用 LLM 做细判（context-aware authorization），分层而不是全扔给 LLM。

4. 中间件集成路径

LangChain：继承 BaseMemory + BaseTool 中间件拦截层，在 agent.tool_choice 回调里注入 action_risk ≤ auth(memory) 检查；AutoGen：CrewAI 同理，拦截 ToolCall 执行前哨；自研 runtime：在 message bus 层统一注入 gate。

不要试图改各框架核心——PPMF 作为 sidecar 最干净，框架只要在 tool call 发出去之前有一个统一的 pre-hook 即可。

5. 规模化检查清单

[ ] memory store 每条记录是否都有 (content, provenance, risk_label, ts) 四元组（缺一不可）
[ ] provenance 写入路径是否在 LLM 进程隔离区（防伪造）
[ ] 高风险 tool 是否有独立的 confirmation 弹窗或强制二次确认 UI
[ ] 门控拒绝日志是否记入安全审计表（不是普通 application log）
[ ] 延迟 SLA 是否与业务方对齐（建议区分高风险/低风险 tool 的 SLA）
[ ] 定期红队：每季度用 memory provenance laundering 攻击手法跑一次 full-scope pen test