向量库返回的20条数据，可能正在喂给不该看的人

一个员工打开企业内部应用，他只能看到UI给他的那几个字段，下拉框里能筛什么就筛什么，后端应用决定取哪几行。几十年的企业安全，悄悄建立在这个模型上：应用层做粗粒度的角色权限控制，因为应用控制着"问题"。

自主AI智能体没有屏幕。它直接拼查询，以机器速度，穿过凭证能触达的任何数据库接口。和人不一样的是，它会被说服——PDF里的隐藏文字、工单里的一句注释、一段注入的提示词，都能让它执行没人打算让它执行的查询。

数据外泄的路径不是那段提示词，是数据检索的返回载荷。如果你不控制存储引擎，你就无法保证隐私。

检索后过滤，是一个安全谎言

RAG应用里最常见的架构缺陷，是检索后过滤。这个朴素模式是这样的：应用向向量数据库查询最相似的top-k文档，从索引里拿回20个分块，然后再检查请求用户是否有权读这些文档。

问题在于，向量数据库已经把调用者无权查看的行返回了。即便应用代码试图在显示到屏幕前丢掉未授权的行，在智能体流水线里，这些行往往被直接喂进模型的上下文窗口。一旦进入上下文，信息就能影响模型输出，或者被写进调试日志。

还有一条侧信道：如果智能体请求10条，却因为全部被检索后过滤而收到0条，攻击者就学到了"匹配的文档存在，但被限制了"。"没有匹配数据"和"拒绝访问"之间的区别，本身就是一次信息泄露。

正确的做法是查询时强制执行。授权必须由存储引擎作为查询执行的一部分来评估。如果调用者没有权限，存储引擎的执行规划器必须把这些页从磁盘读取中完全排除。

嵌入向量不是哈希

很多安全团队把向量嵌入当成"非敏感元数据"，因为它们只是一串浮点数。他们假设，既然原始文本不以明文可见，向量库就不需要和SQL数据库同等级别的安全控制。

这个假设很危险。嵌入反演方向的研究（比如Vec2Text）表明，高维向量嵌入可以被重建为人类可读的原始文本，精确短语还原率超过80%。

如果一家企业锁死了自己的PostgreSQL数据库，却把Qdrant、Milvus向量索引以更弱的凭证暴露在外，攻击者可以查询向量索引，直接重建出机密数据。规则很简单：向量索引必须按照生成它的源文档完全相同的敏感级别来分类、加密和访问控制。

ACL漂移问题

当一名员工换部门或离职，他的用户权限会在Active Directory或Okta里更新。在传统数据库里，他的访问权瞬间消失。但在向量驱动的RAG系统里，权限常常在数据摄入时就被烤进了向量元数据。

第1天，文档A以元数据{"department": "Finance"}摄入。第30天，文档A被重新归类为{"department": "Executive-Only"}。结果是：向量索引里仍然存着{"department": "Finance"}的元数据。

除非你的向量流水线实时主动传播ACL更新事件，否则在SharePoint或Confluence里撤销某人的文档访问权，并不会撤销他在向量索引里的访问权；删除源文件，会在索引里留下一个孤立的嵌入向量，无限期地待在那里。

修复方式是动态的查询时权限解析：不要在向量元数据标签里存静态角色列表，而是在查询时传入用户经过加密签名的JWT权限声明，与一张实时的权限表做连接。在PostgreSQL或pgvector里，就是一条带权限连接的相似度查询。

五个数据底座健康指标

要验证你的数据架构在审计下站得住，可以监控这五项：

• 索引到源ACL延迟：源ACL变更到它在向量索引中生效之间的时间。目标：小于30秒。
• 孤立向量比例：源记录已不存在或不可读的向量嵌入占比。目标：0.0%。
• 存储层拒绝率：被存储层行级安全拦截的查询数，对比应用层拦截数。
• 上下文窗口污染率：非授权token进入LLM执行窗口的事件数。目标：零。
• 审计账本哈希完整度：每一次数据检索事件都写入不可篡改的追加式存储账本，验证率100%。

检索后过滤之所以是企业RAG里的关键安全漏洞，是因为它在评估用户访问权之前，就把未授权的文档分块取进了中间应用内存。在多步智能体流水线里，这些原始文本分块经常污染上下文窗口、系统提示词或运维遥测日志，即便下游UI屏幕挡住了最终渲染，攻击者仍能重建受限的企业情报。

AI智能体的数据安全，解决不了在提示词层，也解决不了在应用UI层。如果你不在存储引擎内部强制执行行级授权、不把向量嵌入当作敏感数据、不在查询时动态解析ACL，你拥有的就不是一个安全的数据底座，而是一个未受保护的向量泄露口，等着一段对抗性提示词来攻破它。