RAG 系统为什么会泄露数据

一个基于您内部文档作答的语言模型，对许多企业而言是首个可切实感知的 AI 价值：报价、手册、合同条款、工单——一声吩咐即可得到回答，而不必在文件夹结构里翻找。其背后的技术称为检索增强生成（Retrieval-Augmented Generation，RAG）：模型在回答某个问题时，会一并获得您文档中匹配的片段，并据此组织出答案。其吸引力显而易见。风险则往往被忽视。

因为 RAG 在本质上是一台前置了措辞模型的搜索引擎。而一台面向企业数据的搜索引擎，其可信度只等同于它所强制执行的权限。若在构建 RAG 系统时没有把源系统的访问权限一并带上，那么必然发生的事就会发生：某位用户被端上了他本不该看到的内容。这不是什么稀奇的特例，而是最常见、也最昂贵的 RAG 故障。

标准错误：权限被落在了后面

在一套管理规范的文件存储中，由一份访问清单来决定谁可以打开某个文档。销售人员看得到自己的报价，但看不到管理层的薪资表。然而在构建 RAG 系统时，这些文档会被切分、换算成向量，并存入一个向量数据库——而恰恰在这一步，权限往往丢失了。此时向量数据库就只认识内容，不再认识访问权限了。谁提问，谁就会得到内容上匹配的答案，而不是他有权看到的答案。

OWASP 项目在 2025 年明确提升了这一类错误的重要性。在更新后的 OWASP Top 10 for LLM Applications 中，“Sensitive Information Disclosure”（敏感信息泄露）上升至第 2 位，并新增了“Vector and Embedding Weaknesses”（向量与嵌入弱点，LLM08）这一全新的类别，正好点出了这些 RAG 特有的弱点：被操纵的检索、跨租户和跨权限的访问、从嵌入（Embedding）反推出明文。其信息很明确：谁若采用 RAG，就开辟了一个全新的、独立的攻击与泄露领域。

两种真实模式：以 Copilot 为示例对象

这在实践中是什么样子，可以以 Microsoft 365 Copilot 为例来研究——它是有史以来部署最广泛的 RAG 系统之一。

第一种模式是权限的过度共享。Copilot 基于某位用户按权限可以访问的范围来作答。若企业中多年来一直宽松地授予这些权限——那臭名昭著的“公司内所有人皆可”的 SharePoint 共享——AI 就会突然把这一历史遗留问题变得可见、可检索。分析服务商 Concentric 发现，15% 的业务关键资源受到过度共享的影响，本不应有访问权限的人却可以查看它们。AI 并没有制造这个问题。它只是把它从隐蔽处揪了出来。

第二种模式是针对 RAG 链条的定向攻击。Aim Labs 的安全团队于 2025 年以“EchoLeak”（CVE-2025-32711，CVSS 9.3）为名描述了一次针对 Microsoft 365 Copilot 的零点击（Zero-Click）攻击：一封精心构造的电子邮件即已足够——无需收件人打开或点击——就能诱使 Copilot 从 SharePoint、OneDrive 和 Teams 中收集内部内容并外泄至一台外部服务器。Microsoft 在服务器端封堵了该漏洞，并报告未发现在野利用。此案仍有教益：不可信输入——此处是一封电子邮件——得以越过通往可信内部数据的边界。得克萨斯大学（University of Texas）一项相关研究成果（“ConfusedPilot”，2024）还表明，被暗中植入的文档可以促使 RAG 系统作出错误陈述，并在此过程中利用访问控制的错误配置。

多租户：最昂贵的泄露

最严重的情形是：当一个 RAG 系统为多个租户共用同一个向量数据库时——例如某个为多家客户开放知识访问的服务商。若没有硬性隔离，不同客户的文档就共享同一个检索空间，而相似度检索并不认识客户边界。此时客户 A 的一个请求就可能返回客户 B 的内容——不是因为什么惊人的黑客攻击，而是因为该数据库从未学到存在一条边界。

许多向量数据库在设计时并未把文档级别的精确访问控制作为核心功能。实践者报告称，一旦检索未经过滤地进行，几乎在所有测试查询中都会出现跨租户泄露。而其后果并不抽象：某款广泛使用的向量数据库中的一个访问控制缺陷，暴露了超过 200,000 条健康数据记录。因此，跨租户泄露不仅是技术上的瑕疵，更是一起数据保护、责任和声誉事件。

修复之道不是 AI 魔法，而是手艺

好消息是：应对措施是已知的。它们与 AI 之外构成可靠安全架构的那些原则完全相同——只是被一以贯之地应用到了 RAG 链条上。

先把权限理清楚。 在数据流入 RAG 系统之前，应当先清理共享上的混乱。RAG 会把既有的过度共享暴露出来；谁若不事先加以清理，就等于把问题导出到了模型里。
把访问控制一直带到文档级别。 每个存入向量数据库的片段，都把其权限元数据——允许的用户和群组——作为组成部分随身携带。查询时进行两级过滤：检索前通过元数据过滤，检索后通过针对源系统的一次真正的权限校验来过滤。权限一旦变更，新的权限即刻生效，而无需等到下一次重新索引。
对租户进行硬性隔离。 在多租户场景中，租户边界要在向量索引这一层强制执行，而不是仅在其上层的应用逻辑中执行。
无遗漏地记录日志。 每一次调取都留下一行记录：谁、什么请求、返回了哪些片段、拒绝了哪些。没有这份日志，既无法查清一起事件，也无法通过审计。
把不可信输入当作不可信来对待。 电子邮件、上传的文件、外部网页内容，不得不受控地越过通往内部数据的信任边界——这是 EchoLeak 给出的教训。

冷静地看，这就是经典的访问控制、数据分类、日志记录和网络分段。能够构建一套经得起审计的 RAG 架构，并不是一种 AI 能力。它是一种安全能力。

为什么这是一项安全任务，而非 AI 玩票

谁若把 RAG 系统当作一个数据项目来对待——“我们把文档倒进去，再在前面摆一个模型”——就会可靠地构建出一个泄露口。谁若把它当作一个安全项目来对待，就会在给出第一个回答之前先提出正确的问题：提问者拥有什么权限？每个片段携带什么元数据？租户边界在哪里？日志里记录了什么？这些问题决定了：这份生产力上的收益，会不会变成一起数据保护事件。

道路恰恰在此分岔。在自有数据上的主权 AI，并非因某个模型格外强大而产生，而是因为围绕模型的架构强制执行了企业的访问规则——可靠、可证明、可审查。

sector7 如何提供支持

我们在我们位于德国的自有服务器集群上运营受保护的私有语言模型和 Managed RAG——数据不会离开由我们控制的环境。决定性的区别在于我们的出身：sector7 来自安全与网络实践。我们构建 RAG 链条的方式，与我们构建边界防护和备份的方式相同——具备文档级别的精确访问控制、硬性的租户隔离、无遗漏的日志记录，以及一套经得起检验的架构。这把我们的主权 AI 直接与我们既有的网络安全实践，以及我们在 Juniper、Cisco、HPE、F5、Fortinet 和 Palo Alto Networks 上经厂商认证的工程经验联系在一起。我们不训练自己的基础模型，也不承诺什么自主的 AI 员工队伍；大规模 GPU 算力我们通过主权合作伙伴获取。我们所交付的，正是让 RAG 变得安全的东西：安全手艺。来自索林根（Solingen）一家业主自营的公司。

在您数据上运行的 AI 是一项安全任务：为什么 RAG 系统会泄露数据