AI助手共享记忆藏泄密漏洞，AMU方案能否堵住

先设想一个场景。

某家中型企业里，财务部与市场部各配了一个AI助手，两者连的是同一个数据仓库。财务部那个AI要筛出高价值客户，于是把含收入信息的客户隐私表和交易记录表关联起来跑了一遍，得到12400个客户ID和一项汇总值。单看这份结果，里面既没有身份证号，也没有收入数字，表面上干干净净，不含任何敏感内容。

系统于是很自然地把这个结果存进了共享记忆库。下一次市场部的AI问起“谁是高价值客户”，系统直接把这个缓存结果递了过去。

问题在于，市场部的AI从来没有被授权查看收入数据。

这个结果虽然“看起来”安全，可它的计算过程里确确实实用到了收入这个字段。也就是说，访问权限的红线，在数据被算出来的那一刻，就已经被悄悄跨过去了，而且没有任何现有系统能发现这件事。

这不是危言耸听。独立研究者Venkata Sangaraju和SAGE7 AI的Sudhir Vissa共同完成的论文指出，这正是当前所有主流AI智能体记忆系统共有的盲区，MemGPT、Zep、A-MEM这些业界知名的框架，无一例外。

问题出在哪：大家都在看“结果”，没人看“过程”

要理解这个漏洞有多普遍，得先搞清楚现在的系统是怎么做权限管理的。

几乎所有现有的智能体记忆系统，不管是MemGPT的分层存储、Zep的时序知识图谱，还是A-MEM的笔记式关联记忆，控制访问权限的方式都差不多：给每条记忆贴标签，标签上写着谁拥有这条记忆、它的敏感等级是什么、哪些角色可以看。请求方只要持有匹配的标签，就能拿到数据。

这套逻辑在大多数场景下管用，但它有一个致命假设：只要结果本身不含敏感内容，就是安全的。

问题恰恰在于这个假设站不住脚。一个数字、一项统计值，字面上确实没有“收入”二字，可它是沿着收入字段算出来的——这件事在最终数值上完全看不出来。现有系统只管“你能不能看这个值”，至于“这个值是怎么算出来的、算它用到的原始材料你本来有没有资格碰”，从来不在检查范围内。

拿银行打个比方：柜员对你说“按风控评估，您的额度是5万元”。这句话没透露你的工资、负债或征信记录中任何一条具体数据。可这个“5万元”的结论，确实是柜员拿着你那些隐私数据算出来的。假如银行把这句“您的额度是5万元”当成完全无害的公开信息，随手放进内部共享系统，供无权查你征信的其他部门取用，你觉得安全吗？当然不安全。但眼下几乎所有AI智能体记忆系统，做的正是这件事。

论文还指出一个更隐蔽的次生麻烦：同一个名字，不同部门算出来的东西可能相差很远。以“流失率”为例，财务部按90天没有交易算流失，市场部则按60天算，口径完全不同，名字却一模一样。缺少检测这类冲突的机制，共享记忆系统就会把其中一个部门的定义悄悄带到另一个部门去——商业智能领域给这种现象起了个专门的名字：语义漂移。

语义漂移*：不同团队对同一个业务指标采用不同计算口径，却共用同一个名称，导致数据在跨团队流转时实际含义发生偏移。

这个问题严重到什么程度？2025年，Snowflake、Salesforce、dbt Labs、贝莱德和RelationalAI五家公司联手搞了个叫“开放语义互通”的行业倡议，专门想解决这件事。但那个倡议针对的是人类分析师用的商业智能工具，不是会自己写查询语句的AI智能体。AI智能体的场景，目前还是真空地带。

AMU：给每条记忆挂一张“出生证明”

研究者提出的解法，思路并不复杂：既然病灶是“只看结果、不看过程”，那就把过程一并记录下来，并且把权限检查放到过程这一层去做。

他们设计了一种新的记忆单元，叫做分析记忆单元（Analytical Memory Unit，简称AMU）。

分析记忆单元（AMU）*：一种记忆数据结构。它不光存计算结果，还把这个结果出自哪几张数据表、哪些字段、经过哪些筛选条件完整记下来，等于给每条缓存结果配了一份详尽的“出生证明”。

具体看，每个AMU装五样信息：指标名称、算出的数值、由哪个部门计算、用于过期清理的时间戳，以及最要紧的“血缘图”——它把这个数值的来龙去脉记全了：动用了哪几张表、碰过哪些字段、套了什么过滤条件。

血缘图*（Lineage Graph）：一种记录数据计算全过程依赖链条的结构，作用类似数据的“族谱”，逐一标明每个“祖先”字段的出处。

有了这份“出生证明”，检索时系统就能做一件此前没人做过的事：不再只问“你有没有权限看这个值”，而是追问“算出这个值所涉及的每一个字段，你是不是都有权限看”。血缘图里只要冒出一个你无权触碰的敏感字段，这条记忆就会被拦下，哪怕最终数值本身看着毫无危害。

这就像海关查行李：不能光看箱外标签写着“普通日用品”就放行，得把箱子打开，逐件核对里面有没有违禁品。标签可能造假，也可能漏写；开箱细查，只要查得彻底，就很难糊弄过去。反过来想，海关若只认标签不开箱，走私者贴张干净标签就能过关——现有记忆系统的处境，正是如此。

这套机制真的能防住泄露吗：一个“条件性”的数学证明

研究者并未停留在"提出一个看上去合理的机制"这一步，论文中给出了形式化证明，被称为定理一。

证明的思路谈不上复杂。检索算法只有两条出路：一是从历史缓存中挑出一个安全候选直接返回，二是缓存里找不到安全项，就让请求方在自身权限范围内重新算一个结果。证明对两条路径分别做了分析。第一条路径上，候选结果必须通过"血缘图中涉及的敏感字段全部落在请求方权限内"这一关，通不过就谈不上返回；第二条路径上，新结果本身就是在请求方权限内产生的，不会越界。两条路径都安全，系统整体也就安全。

不过研究者反复强调了一点：这个结论属于有条件的正确性论证，并非实验观察到的经验发现。

什么条件？证明成立的前提是血缘记录必须完整，论文称之为"完整血缘假设"。一旦血缘记录出现遗漏——比方说某次查询实际触碰了敏感字段，系统却没记下来——这道检查就起不到作用，证明也随之失效。

这有点像看病：医生要做出正确诊断，得有一份完整准确的病历。假如病历漏掉了病人对某种药物过敏，医生水平再高、态度再谨慎，也可能因为信息缺失开出危险的处方。证明再严谨，也扛不住最底层的数据残缺。研究者专门做了实验来验证，结论后面会讲到，结果很能说明问题。

代价有多大：13.8微秒和13个百分点

安全机制都要付出代价，关键在于这笔代价划不划算。

研究团队建了一个纯Python的离散事件模拟器，有意把大语言模型推理、网络延迟这些会带来噪声的环节排除在外，只测量核心机制自身的表现。对比对象有三个：完全不共享记忆（零泄露，但复用也为零）、朴素的内容门控共享记忆（代表现有系统）、以及他们提出的血缘感知方案。

在一个三部门、五张表的合成场景里，朴素共享记忆的跨部门泄露率为18.8%。换到更接近真实业务的TPC-H标准测试集上（八张表，连接关系更密集），这个数字升到25.5%。血缘感知方案则在两种场景下都保持0%泄露。这个0%，靠的是前面那个数学证明，不是碰巧走运。

防护当然也有成本。血缘感知方案的记忆复用率从95.8%降到81.5%至82.6%之间，算下来每100次请求里，大约有13次原本能直接复用缓存结果，如今得重新计算。

这笔账值不值？研究者拿了一组数据作参照：IBM 2025年的数据泄露成本报告显示，一次数据泄露的平均成本为444万美元，美国本土更是达到1022万美元。用13个百分点的计算成本，去堵住一个18.8%到25.5%的结构性泄露渠道，看起来相当划算。

更关键的一点是，权限检查自身的开销小到几乎可以忽略。研究团队在一台配置普通的虚拟机上实测，单次检查只要0.09微秒，属于百万分之一秒的量级。最坏情况下，记忆库里堆了50条候选记录需要逐条检查，总耗时也只有13.82微秒。而一次真实的数据库分析查询，通常要几毫秒到几秒，两者差了两到三个数量级。换句话说，用户基本感知不到这道安全闸门的存在；真正慢的地方不在闸门本身，而在被拦下之后需要重新跑一遍查询。

血缘记录不完整会发生什么：从"滴水不漏"到"形同虚设"

前面说过，证明成立的前提是血缘记录完整。研究者为此专门设计了一个实验：一旦这个前提被打破，情况会坏到什么程度。

他们定义了一个"完整度"指标，用来表示每一步计算中有多少比例的字段被正确记录，取值从0到1。随后让系统故意"健忘"，只记一部分血缘信息，同时用一个影子存储悄悄保存真实的完整血缘作为对照，据此测量实际泄露情况。

结果很直观。完整度只有50%时，防护近乎失效，合成场景泄露率为16.3%，TPC-H场景为10.3%，跟完全不设防的系统差不了多少。完整度升到75%至90%区间后，泄露率才降到0%，达到理论证明所承诺的效果。

更有意思的是，两种场景所需门槛并不相同：合成场景75%就够，TPC-H则要90%。研究者的解释是，TPC-H中的敏感字段分布在更多连接步骤上，连接层次越深，血缘记录出错或遗漏的机会窗口就越大。

这好比让几个人接力传话。一条消息只经一个人转达，哪怕他偶尔漏掉一两个字，大意多半还在。可要是消息经过五个人依次传递，每人都有一点遗漏的可能，传到末尾，关键信息彻底走样的概率就会明显上升。连接步骤越多，传话链条越长，对每一环记录准确性的要求自然越高。

据此，研究者给出了一条明确的实践建议：血缘记录完整度至少要达到90%，并且最好不要指望AI智能体自觉汇报它用了哪些字段，而应在数据库驱动层用自动化手段拦截查询语句，自动解析提取。道理很简单——自我汇报难以审计，智能体生成的查询一旦复杂起来，遗漏率可能毫无征兆地飙升，而且往往偏偏出在最需要精确记录的复杂多表连接场景。

指标冲突检测：三种探测器，各有各的盲区

除防泄露之外，论文还要处理前文提到的"语义漂移"：两个部门用同一个名字算出不同的结果，如何自动识别？

研究者设计了一套"定义指纹"机制，为每个指标的计算逻辑生成一个哈希值，只要用到的表、字段、过滤条件存在任何差异，指纹就会不同。写入新记录时，系统自动比对同名指标在不同部门间的指纹是否一致，不一致就标为潜在冲突，交给人工复核，但不阻断写入。

三种探测器先拿10个手工标注的案例做了测试。有一种叫"列关系图"的，成绩最扎眼：F1分数直接打满，1.00。F1分数*：把检测方法的"查得准不准"和"查得全不全"放在一起看的指标，范围0到1，离1越近越理想。

可当测试集扩充到43对，覆盖真实冲突、阈值变更、逻辑运算符改变（比如把"且"换成"或"）、字段子集变化四类场景之后，这个原本满分的探测器直接失手，F1跌至0.833，而且在8个"逻辑运算符改变"的案例里全部漏判，一个都没抓到。

原因也不难想明白。这类探测器只认用了哪些字段，压根不看过滤条件是怎么写的。“收入大于2万且最近90天有交易”换成“收入大于2万或最近90天有交易”，字段集合一个字没变，可两句话对应的业务含义完全是两码事。

这个结果本身也提了个醒：小样本测试集特别容易撑起“效果完美”的假象，真正的边界情况，往往要等样本量上去以后才冒出来。研究者自己也没回避这一点，这在整篇论文里算难得的坦率——拿着最初还算满意的成绩，主动把测试规模扩大，然后承认发现了此前没人报告过的盲区。

真实世界里跑一遍：九轮对话，零泄露

前面那些实验，都压在一个假设上：血缘记录是完整的。现实里这件事靠什么保证？

研究者做了一次小规模的真实场景验证。开源的LangChain框架加上本地部署的Ollama模型，驱动财务、销售、运营、人力资源四个部门的AI智能体，在经典的Northwind示例数据库上跑真实查询；另有一个叫sqlglot的纯Python SQL解析工具，在每条查询语句执行前自动拆出语法树，把用到的每一张表、每一个字段都提出来。

这个设计巧就巧在，智能体根本不用“自觉”汇报自己碰了哪些字段——它压根不需要主动声明什么，血缘信息是从它实际执行的SQL语句里被动抽出来的。智能体“偷懒”也好、“记错”也罢，都漏不掉。

九轮跨部门交互跑完，零泄露。五次全新计算，四次成功从缓存复用，两次被检测到指标定义冲突而挡下；这两次阻断正好对应系统自动识别出的两起真实语义冲突，误报一次都没有。

当然，这只是九轮对话规模的概念验证，离大规模生产级验证还差得远，研究者自己也反复强调了这一点。但它至少说明了一件事：自动化血缘提取这条路走得通，不必指望智能体主动配合。

这套机制管不住什么：八大威胁里的明显短板

研究者没把这套机制吹成万能药。他们专门列了八项威胁清单，老老实实标出哪些能解决、哪些只能缓解、哪些完全管不了。

能直接解决的，是开篇提到的两个核心痛点：缓存结果里暗藏敏感字段造成的泄露，以及同名指标口径不一致。能部分缓解的，包括策略更新后旧缓存数据过期失效、血缘记录被恶意伪造或遗漏。这几项之所以只能算部分解决，共同原因是它们都押在“血缘记录完整且真实”这个前提上，自动化提取能让情况好转，风险却没法彻底根除。

完全管不了的里面，研究者特别点出一个他们认为是生产环境中最棘手的缺口：推断攻击。某个衍生特征在计算时偷偷用了敏感字段，却在任何地方都没明确声明这层依赖，机制就毫无察觉。比如用收入数据算出一个风险评分，这个计算过程没被系统追踪到，风险评分这个数值看上去跟收入毫无关系，可它实际上带着收入信息的影子。

这就好比把一张写满隐私信息的纸烧成灰，然后跟别人说“这堆灰烬不是隐私信息”。从物理形态看，灰烬确实不再是那张纸；可要是有人能从灰烬的化学成分反推出原始内容，这堆“看起来无害”的灰烬依然危险。技术上能不能从灰烬反推内容是另一回事，这个类比想说的是：形态变了不等于信息没了，而现有机制恰恰只能追踪“显式声明”的转变路径，对隐式的、没被记录下来的信息泄漏束手无策。

另外两类完全覆盖不了的威胁，一是跨多次查询的组合推断——单看每次请求都合规，把多次安全的结果拼起来却能反推出不该知道的信息；二是内部人员直接攻击存储系统本身。这些得靠差分隐私这类更上游的技术手段，或者可信基础设施、审计日志这类组织层面的管控，一个记忆层的访问控制机制单独扛不下来。

写在后面

读完这篇论文，我感触最深的不是某个具体算法设计，而是研究者反复强调的那句话：这是一个条件性的设计正确性结论，不是一个经验发现。

这句话背后有一种少见的克制。不少论文拿到漂亮的数学证明，恨不得包装成“颠扑不破的安全保证”，这篇却一直在提醒读者：证明的威力完全取决于“血缘记录完整”这个前提假设在真实世界里站不站得住脚。实验三那个从0%到16.3%泄露率的断崖式变化，恰恰是用数据在狠狠提醒读者，这个前提远没有听起来那么容易满足。

另一个让我意外的细节，是论文里那张写满“?”和“?”的系统对比表。MemGPT、Zep、A-MEM这些业内知名度很高的框架，在“列级血缘追踪”这一栏全部是叉号。这倒不是说它们设计得不好，它们在各自要解决的问题上确实做得挺出色；问题是“追踪数据是怎么算出来的”这件事，在整个领域几乎是一片无人涉足的空地。一个已经被广泛部署、被大量企业采用的技术方向，底下居然藏着这样一个结构性盲区，这件事本身比论文给出的方案更值得琢磨。

还有一点值得单独拎出来说。研究者在论文里专门加了一段，交代所有对比系统各自处在什么同行评审阶段：有的发表在顶会上，有的只是厂商博客文章，有的连公开技术报告都没有。研究者坦承自己无法独立验证这些系统的性能数据，只能比较“这些系统自己声称的设计特性”。这种近乎较真的严谨，在一篇安全论文里格外珍贵——过度承诺安全保证的边界，本身就是一种治理风险，这句是论文原话，也是我读完最想转述给所有做安全系统设计的人的一句话。

如果血缘记录永远做不到百分之百完整，这道防线到底该建在哪一层，才能既不拖垮系统性能，又不给隐式推断攻击留下可乘之机？

Q&A

Q1：AMU 要处理的核心问题是什么？A：它针对的是 AI 智能体之间共享记忆时那种不易察觉的泄露。过去的系统只看缓存下来的结果里是否夹带敏感内容；AMU 的做法是往前追一步，查清这个结果由哪些数据字段运算得出。只要计算时用到了请求方无权查看的字段，即便最后算出来的数值本身看不出问题，也会被拦下，不返回给请求方。

Q2：这套血缘感知机制会不会让系统变得很慢？

A：延迟几乎可以忽略。实测里，一次权限检查只要0.09微秒；最坏的情况是查50条候选记录，加在一起也不过13.82微秒。真实数据库查询往往要毫秒乃至秒级，两者差了两到三个数量级，用户基本感觉不到卡顿。

Q3：那它能不能把数据泄露百分之百挡住？

A：挡不住。这套机制的安全保证有个前提——"血缘记录完整"。研究者做过实验，记录完整度一旦掉到75%到90%以下，防护效果就会明显下滑。碰上"衍生特征隐式携带敏感信息却没被记录"这类推断攻击，它更是完全没办法，得搭配别的手段一起用。