AMU：用派生血缘门控实现企业 AI Agent 列级访问控制

共享记忆若只按内容放行，无权部门可能取回自己推不出的敏感列结果，同名 KPI 也会按冲突逻辑静默传播。

• 场景：财务智能体把含 income 的连接结果缓存成无原始 PII 的分段后，市场部门仍可能按指标名取回；作者称违规只在计算方式中。作者引用 2026 年 Q1 企业应用嵌入率 80%，以及 AgentLeak 中智能体间消息泄露 68.8%。
• 现有不足：作者称所调研系统按内容、所有权或角色门控，不记录表、列与过滤。源层控制能挡住对受限列的直接查询，挡不住再分发给更低权限请求方的合法缓存。
• 假设：同名 KPI 可用不同业务逻辑经共享记忆传播（作者称为 semantic drift）。作者认为可机械检查列权限边界的记忆层，能把审计问题变成可判定性质，并称这与 EU AI Act 的可解释性义务有关。
• 做法：提出 Analytical Memory Unit（AMU）：每条缓存附推导图，仅当请求方对触及的每一列都获授权才命中。作者称血缘完整时可构造保证拦截权限外敏感列；不含未点名源列的派生特征。
• 威胁模型：
  • 主体：部门智能体被建模为 honest-but-potentially-over-privileged，请求有业务需要的指标，但推导路径未必在列权限内。
  • 目标：T1 为取回由无权敏感列导出的缓存；T2 为写入同名 KPI 的冲突定义。受害系统是共享 analytical memory store。
  • 能力：论文未用白盒或黑盒术语。智能体可检索并写入该存储；自报血缘可能少报（T5，部分应对），提示注入列为 T8（部分应对）。
  • 不覆盖：T4 未声明派生特征、T6 跨检索聚合推断、T7 存储内部人，以及跨指标关联与部门带外共谋。

相关系统按内容、角色或片段放行，作者称没有一个按结果所触的每一源列门控检索。

• 智能体记忆：Du（2026）将记忆写成 write-manage-read 循环。MemGPT 在上下文与外部存储间分页，不表示值如何产生。Zep 的溯源是事实何时为真、何时被记录，不是源列。A-MEM 按笔记语义相似检索。作者称三者的门控都在单个源列之上。
• 治理与多主体记忆：Governed Memory、SSGM、Oracle AI Agent Memory、AgentGuardian 按所有者、角色或工具调用合法性管理整条记忆，作者称因此看不出允许条目是否嵌入禁止列。Collaborative Memory 有片段级溯源，但仍按身份与权限图放行原子片段。GateMem 是基准；作者称所评方法都未在不牺牲效用时做到 robust access control，且泄漏标注在共享事实级，不测列级血缘门控。
• 列级安全与通道隐私：Ranger、Unity Catalog、BigQuery 在查询层做列门控；DePLOI 用 NL2SQL 审计策略。W3C PROV、Herschel 等（2017）与 LINEAGEX 面向 ETL 或 SQL 血缘。作者称它们不在合法结果被缓存并交给更低权限方时触发。AuthGraph 对照执行溯源与授权图，作者称范围是单智能体工具调用。作者称 AgentLeak、OMNI-LEAK 与 Alizadeh 等针对通信通道和单智能体操纵，而本文针对共享分析记忆这一互补向量。
• 指标治理与对照：Open Semantic Interchange（2025）集中人类定义的指标，作者称没有检测智能体用自生成查询计算 KPI 时漂移的机制。实验对照为 No Memory、Naive Shared Memory 与 Lineage-Aware；数据为 5 表合成 schema、TPC-H、Northwind 与 43 对人工标注血缘。作者将 AMU 定位为把列级推导用到记忆条目。Table 1 中源层 ACL 的 Column lineage 为部分支持、检索门控为不支持；作者称比较的是文档里的设计，不少来源是预印本或厂商博客，不是独立复核的性能。

整体思路是给共享缓存附上可检查的推导，再用 Analytical Memory Unit（AMU） 决定能否复用。

记忆单元

• 字段：AMU 为 ⟨metric, v, d, τ, L⟩：指标名、结果值、产出部门、用于 TTL 的 epoch，以及步骤序列 L。每步是 (table, C, φ)，即表、触及列和过滤字符串。
• 敏感标签：创建时缓存 S(a)=\bigcup_{i=1}^{k}(C_i\cap S)，即各步列与敏感登记 S 的交之并。检索门控只看这个集合，不看过滤字符串。
• 定义哈希：H(a) 取 SHA256，输入为排序后的表、排序后的列，以及过滤字符串前 12 个字符。Table 2 还缓存 sensitivity_tags 与 definition_hash。
• 图示：Figure 1 中 Finance 的 churn_rate 为 0.114（epoch 17），S(a)={income}。图注称值本身不暴露计算方式，但连接触及 income 后，无该列权限的部门不应被服务。

两个算法

• 检索：Algorithm 1 取出该指标的全部 AMU，在循环外解析 P(d)，并按最新优先扫描。S(a) 不是 P(d) 子集则跳过；被拒条目不返回、不部分返回，也不带值记日志。全部不安全时，写入调用前已在权限内算好的 fresh 并返回。
• 复杂度：作者称出口只有这两条 return。最坏 O(n·|S|)，因 |S| 视为小常数，Table 3 记为 O(n)；扫描中第一个候选即安全时为 O(1)。作者保留线性扫描以返回最新安全值，不换成按 (metric, S(a)) 索引的最坏 O(1)。
• 写入：Algorithm 2 对跨部门同名条目比较 H；不同则标冲突并停止扫描，但始终写入，冲突只上报（T2）。
• 接入：Figure 2 图注写明游标处抽取血缘，读路径检查 S(a) 是否含于 P(d)，不安全则回退到权限内新计算并写回。抽取失败时 S(a) 设为整个 S；权限集不可用则拒绝。

形式保证与判定

• 假设 1：lineage 记录产生该值的全部表、列和过滤谓词。作者称 Theorem 1 依赖该假设。
• Theorem 1：作者用两条返回路径作情形分析：命中要求 S(a) 含于 P(d)；回退要求 fresh 在调用前完全落在 P(d) 内。陈述是：不向部门 d 返回由 c 属于 S 且 c 不在 P(d) 导出的结果。作者称这是条件性设计正确性，不是经验发现，且不含未写入血缘的派生特征。
• 推论：Corollary 2 称越权条目会被跳过。Corollary 3 称策略更新后，旧缓存标签可能漏掉新敏感列，懒重算后后续检索恢复（T3）。
• 泄漏如何计：模拟器已知真实血缘与权限。完整度实验用影子存储对照截断血缘，以计算真实泄漏率。

威胁覆盖

• Table 4：T1、T2 为 Addressed；T3、T5、T8 为 Partial；T4、T6、T7 为 No。作者把跨指标关联和部门带外共谋放在 T1–T8 之外。
• 开销取舍：作者称相对既有系统的 O(1) 字典查找，安全保证换来的是线性扫描；并称所观察工作负载中，每个指标至多每个（部门，血缘变体）一条，建议用 TTL 避免 n 无界。

实验设置

• 模拟器：纯 Python 离散事件模拟器，把检索和冲突检测与 LLM 推理、网络、优化器分开。对照为 No Memory（设计上无泄漏、零复用）、Naive Shared Memory（内容门控，代表既有系统）、Lineage-Aware。
• 两套 schema：Experiment 1 为 5 表合成、3 个部门，S={ssn, email, income}（Table 5）。Experiment 2 为 8 表 TPC-H，|S|=9。敏感变体比例均为 5 个指标中的 2 个。
• 统计：Experiment 1–2 为 30 个种子的均值±总体标准差，bootstrap 95% CI，Mann-Whitney U。逐 seed 表在 Supplementary Material；主文未给出每个种子的请求条数。
• 其余设置：ρ 为每步列被正确报告的比例。冲突集为 43 对人工标注血缘。运行时用 time.perf_counter()，n 取 1、5、10、20、50，各 2000 次。
• 真实集成：Northwind；部门 Finance、Sales、Operations、HR；敏感登记 {unitprice, freight, homephone, birthdate}。LangChain+Ollama 发出真实 SQL 与 demo-mode canned SQL，sqlglot（文中为 version 23+）从 AST 抽血缘。论文未说明 Ollama 的模型名。摘要另写 LLM-generated SQL。
• 指标：泄漏率、复用率、冲突召回；模糊检测的 precision、recall、F1；延迟。Table 5 写明门控只强制 S 中的列。

主结果

据 Table 6（30 种子）。泄漏率 0.0% 的表注写明这是 Theorem 1 的形式保证，不是独立经验发现。

表格较宽，可左右滑动

设置	泄漏率	复用率	冲突召回
Synthetic 5-table，Naive	18.8 ± 3.7%	95.8 ± 0.0%	0.0 ± 0.0%
Synthetic 5-table，Lineage-Aware	0.0 ± 0.0%	82.6 ± 2.3%	100.0 ± 0.0%
TPC-H 8-table，Naive	25.5 ± 4.5%	95.8 ± 0.0%	0.0 ± 0.0%
TPC-H 8-table，Lineage-Aware	0.0 ± 0.0%	81.5 ± 4.8%	100.0 ± 0.0%

• 作者解读：作者称经验内容是朴素基线结构上非零，并给出效应量 d≈7.2–8.0。论文报告全部 Naive 与 Lineage-Aware 差异的 bootstrap 95% CI 不含 0，Mann-Whitney U 的 p<0.001。
• 代价：作者称复用率下降 13–14 个百分点，约每 100 次请求多 13 次查询；门控谓词为 0.09 µs。Figure 3 标注的点估计与 Table 6 一致。
• schema：作者把 |S| 与连接密度的差别和朴素泄漏率的差别并列，称与单调关系相符，但不是证明。No Memory 未列入 Table 6。

血缘完整度降解

• 测了什么：用截断血缘和影子存储测量假设 1 被违反时的真实泄漏（§VI-B，Figure 4）。
• 结果：ρ=0.50 时合成 schema 为 16.3±3.3%，TPC-H 为 10.3±4.7%。合成在 ρ≥0.75、TPC-H 在 ρ≥0.90 时测得泄漏率为 0%。摘要写消除测得泄漏需要 75–90% 完整度，并以 90% 为保守部署目标。
• 作者解读：作者称 ρ=0.50 时几乎没有保护；TPC-H 需要更高完整度，因为敏感列分布在更多连接步上。Figure 4 横轴标有 0.50、0.75、0.90、0.95、1.00；图注称两套曲线在 0.75–0.90 收敛到 0%，ρ=0.50 时合成 schema 接近朴素基线。其余横轴点的读数正文未给出。

模糊冲突检测

• 测了什么：43 对，含 15 个 True Conflicts、15 个 Threshold Variants、8 个 Logic-Operator、5 个 Column-Subset。检测器为 D1 精确哈希、D2 Jaccard（τ=0.70）、D3 列图（Table 7，Figure 5）。
• 结果：D1 的 precision/recall/F1 为 0.651/1.000/0.789，LO 正确 8/8；D2 为 0.676/0.821/0.742，LO 3/8；D3 为 1.000/0.714/0.833，LO 0/8。
• 作者解读：作者称 D3 在原 10 对上 F1=1.00，扩集后漏掉全部 8 个 LO 对，因为忽略过滤字符串，并称这是此前未报告的盲点。作者称两者单独都还不能作为生产检测器，D4 被提出但未评估。图注称 D3 在 TV 上的 specificity 为 perfect，到 LO 上变为零检测；各柱数值正文未单列。

运行时与真实智能体

• 运行时：Table 3 只给出 n=1 与 n=50。检索最坏从 0.66 µs 到 13.82 µs；作者称这是 21 倍，并称由此符合 O(n)。摘要与结论写 13.8 µs。环境为 4 核 Apple Silicon 虚拟机、3.8 GB RAM、Ubuntu 22.04、CPython 3.10.12、Docker、无 GPU。n=5、10、20 的数值在 Supplementary Material，主文未列出。作者称尚未在第二种硬件上复测。
• 较小 n：作者称 Experiment 1–2 与 6 中 n≤5，此时最坏检索至多 1.74 µs（§IV-A）。
• Experiment 6：9 次跨部门往返的敏感列泄漏为 0；5 次新 SQL 被执行并写入（2 次在拦截之后），4 次完全来自缓存；2 次拦截与 2 次自动检出的定义冲突重合。缓存命中 0.009 ms。作者称命中延迟比所替换 SQL 低三到四个数量级，论文未给出该 SQL 延迟。作者称这是可行性演示，不是生产可行性证据。

其他消融与分析

• 写路径冲突检测：n=1 为 0.28 µs，n=50 为 1.63 µs（Table 3）。
• 期望情形检索：n=1 为 0.66 µs，n=50 为 0.64 µs（Table 3）。
• 门控谓词：0.09 µs（Table 3）。
• 存储：作者称约为裸值的 4–8 倍，典型 200–600 字节（§IV-A）。
• |S|：合成 3，TPC-H 9；敏感变体均为 2/5 个指标（§VI-A）。
• 作者建议的部署目标为 ρ≥0.9，并倾向自动抽取而非智能体自报（§VI-B）。

作者指出的局限与后续方向

• 基率：18.8–25.5% 的朴素泄漏率是所用工作负载混合的性质，不是普遍基率；作者称结构性论证不依赖该百分比（§VII-B）。
• T4：机制抓不到把敏感信息编进派生特征、却不在血缘中点名源列的推断；作者称这是生产使用中最重要的缺口（§VII-B）。
• 数据集规模：43 对模糊数据集仍然小（§VII-B）。
• 硬件：运行时常量只在一种硬件与操作系统配置上测量；作者称 O(n) 与 O(1) 的缩放不依赖该机器，但常数在其他平台可能变化（§VII-B）。
• 抽取缺口：视图、存储过程和深层别名会使 SQLGlot 的静态 AST 漏记敏感列；作者称这使 Experiment 6 的零泄漏存在完整度缺口，失败关闭会过度拦截而不是泄漏。目录级展开被标为后续工作（§VII-B）。
• 后续计划：对抗性血缘测试；向量库、REST/GraphQL 与进程内推导的非 SQL 血缘；真实 20–50 表仓库上按周、且在多于一个硬件平台上的部署研究；实现并评估 D4，并开源参考实现（§VII-B）。结论称目前还不是生产规模可行性的演示（§VII-C）。

实验覆盖范围

• 六组实验包括两套 schema（合成 5 表、TPC-H 8 表，各 30 种子）、完整度降解、43 对冲突、五档存储规模各 2000 次，以及 Northwind 上 9 次往返（§VI）。
• 对照为 No Memory、Naive Shared Memory、Lineage-Aware；Experiment 1–2 报告 bootstrap 95% CI 与 Mann-Whitney U（Table 6）。
• 合成部门为 Finance、Marketing、Support；Northwind 为 Finance、Sales、Operations、HR。SQL 由 LangChain+Ollama 发出，血缘由 sqlglot 从 AST 抽取（§VI-E）。
• 论文未报告 Ollama 的具体模型名，也未在主文给出每个种子的请求条数；n=5、10、20 的延迟指向 Supplementary Material（§VI、§VI-D）。
• Table 5 写明门控只强制 S 中的列。运行环境为 4 核 Apple Silicon 虚拟机、3.8 GB RAM、Ubuntu 22.04、CPython 3.10.12、无 GPU（§VI-D）。

AMU 用列级推导门控共享记忆，拦截经缓存流出的无权敏感列，并标出同名 KPI 的定义冲突。

• 问题：内容门控看不到合法结果里嵌入的无权列，部门还可能写入冲突的同名指标。主体被建模为 honest-but-potentially-over-privileged 的部门智能体，机制直接处理 T1 与 T2。
• 方法：每条缓存带推导图、敏感列标签和定义哈希。检索按最新优先，只在敏感列含于部门权限时复用，否则回退到权限内新计算；写入不因冲突而阻断。保证以完整血缘为前提，不含未点名源列的派生特征。
• 结果：Table 6 上，合成 5 表朴素泄漏率 18.8±3.7%，血缘门控为 0.0±0.0%，复用率 82.6±2.3%；TPC-H 朴素泄漏率 25.5±4.5%，门控后 0.0±0.0%，复用率 81.5±4.8%。作者把 0.0% 标为 Theorem 1 的推论。冲突召回在 Naive 上为 0.0%，在 Lineage-Aware 上为 100.0%。
• 边界：ρ=0.50 时合成泄漏率 16.3±3.3%，TPC-H 为 10.3±4.7%；合成 ρ≥0.75、TPC-H ρ≥0.90 时测得泄漏为 0%。43 对上 D3 的 Logic-Operator 正确数为 0/8。n=50 最坏检索 13.82 µs。Northwind 的 9 次往返泄漏为 0，并捕获 2 次冲突。
• 作者结论：作者称这是源层访问控制的补充；Experiment 6 只是可行性演示，还不是生产规模可行性的证据。未声明派生特征（T4）不在该记忆层的覆盖内。作者在 §VII-A 称消除 18.8–25.5% 的结构性泄漏通道会实质改变风险画像，并引用 $4.44 million 的平均泄露成本。