开发者复现：直接查询0泄漏，代理写回摘要后2/3任务漏了数据

所有人都依赖 allowed_groups 这类元数据过滤器来锁住多租户 RAG、把它管住。当用户直接查询向量库时，这套机制运转良好，未授权的块会被过滤掉，泄漏率为0%。

但一旦有了后台代理，这套机制在写入路径上就崩溃了。

如果一个代理拥有较高的读取权限，可以跨多个文件夹或团队汇总文档，它就会拉取这些文档，把它们揉成一个摘要块，再把这个摘要提交回共享集合。在写入时，上游文档的访问控制列表直接消失了。在常规的 Chroma 和 LlamaIndex 配置中，派生出来的块保存时没有附带任何 allowed_groups 或分类标签。现在，任何对共享内存发起查询的人，都能拿到他们本无权直接读取的私有源数据。

我搭了一个离线复现测试套件（sentinel-eval，Apache-2.0）来验证这一点：

* 直接 RAG：0% 泄漏（检索到 18 个公开块，0 个受限块暴露）。
* 代理内存：3 个合成任务中有 2 个泄漏了敏感数据（两个跨边界工作负载都失败了，暴露了 6/18 个受限金丝雀，1 个公开对照通过）。

那又怎样？很简单对吧？只要用严格交集（只有当某人对每一个源文档都有访问权限时，才允许他读取摘要），这不就彻底解决了吗？嗯……是的，但这基本上会扼杀检索效用。本质上没有人能再看到多文档摘要了。所以我们不能简单地取交集。我写的那个代理实际上把源文档记录在 source_documents 元数据里，但向量数据库无法在查询时评估动态权限 DAG，这意味着你不能指望通过路径回溯来解决这个问题。

测试套件用模拟向量在几秒内离线运行 23 个测试（无需 API 密钥或调用在线 LLM）：

git clone https://github.com/harishbalasubramanian/sentinel-eval
cd sentinel-eval
uv run sentinel-eval live --framework chroma

仓库：[https://github.com/harishbalasubramanian/sentinel-eval0

对于构建多租户 RAG 的人，当代理把派生摘要写回共享内存时，你们实际是怎么处理权限的？

―― 高票评论（帖子共 6 条讨论）――

[+1] u/f1yingbanana：这听起来不太像读的问题，更像是代理内存摘要器没做好本职工作。如果你不想让没有权限的人读到高层摘要，那做摘要的代理一开始就不该有权限访问那些文档？