🤖 AI

Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use

本文针对多租户企业人工智能系统中检索相关性凌驾于授权之上的关键安全漏洞，提出并验证了一种基于开源 OGX 框架的服务器端分层隔离架构，该架构通过实施策略感知的摄取与检索门禁机制，在几乎不增加性能开销的前提下防止跨租户数据泄露。

原作者： Francisco Javier Arceo, Varsha Prasad Narsing

发布于 2026-05-08

📖 1 分钟阅读☕ 轻松阅读

原作者： Francisco Javier Arceo, Varsha Prasad Narsing

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一座庞大且高科技的图书馆，其中成千上万家不同的公司（租户）租用了书架来存放它们的机密文件。在这座图书馆里，还有被雇佣的强大机器人（AI 智能体），负责根据公司的要求查找特定信息并执行任务。

Arceo 和 Narsing 的论文指出了这些图书馆当前运作方式中存在的一个危险缺陷，并提出了一套新的安全系统来修复它。

问题：“相关性”陷阱

在普通图书馆中，如果你询问“食谱”，图书管理员会递给你与这个词最相关的书籍。他们并不关心书籍归谁所有，只是挑选最匹配的。

作者们指出，在 AI 世界中，这对安全来说是一场灾难。

场景：A 公司询问机器人：“我们该如何修复我们的服务器？”
错误：机器人搜索了整个图书馆。它发现了一份来自 B 公司的文件，该文件与问题非常相似（也许也是关于修复服务器的）。
泄露：因为这份文件是问题的“完美匹配”，机器人将其递出。A 公司就这样读到了 B 公司机密的服务器手册。

论文将这种现象称为“相关性 - 授权差距”。该系统在查找相关内容方面表现出色，但在检查谁有权查看这些内容方面却极其糟糕。

解决方案：“分层隔离”建筑

为了解决这个问题，作者提出了一种新的建筑设计，包含三个特定的安全层以及一条关于谁持有钥匙的严格规则。

1. 三层安全

将数据旅程想象成一个包裹通过安全设施的过程：

第一层：标签站（策略感知摄取）
当一家公司送交一箱文件时，系统会立即在每一页上盖上"A 公司”或"B 公司”的标签。你无法在稍后忘记给它们贴标签；这发生在它们到达的那一刻。这确保了每一份文件都知道它属于谁。
第二层：安全门（检索门禁）
在机器人被允许查找书籍之前，它必须通过一道安全门。该门会检查用户的身份徽章。
- 如果用户来自 A 公司，安全门会在物理上阻挡包含 B 公司书籍的过道。
- 机器人永远看不到被禁止的书籍，因此它无法意外地将它们递出。这被称为基于属性的访问控制（ABAC）门禁。
第三层：共享大脑（共享推理）
机器人实际的“思考”部分（AI 模型）由所有人共享以节省成本。通常，你可能会认为需要为每家公司配备一个独立的机器人来保守秘密。但由于第一层和第二层确保了只有正确且已标记的文件会被送入机器人，因此机器人可以安全地被共享。这就像一位厨师为所有人烹饪，但食材是预先分类好的，因此厨师绝不会意外地将一位顾客的机密食谱用在另一位顾客的菜肴中。

2. “服务器端”规则

论文认为，安全检查必须发生在建筑内部（服务器），而不是外部在客户的办公室（客户端）。

旧方式（客户端）客户的计算机进行搜索和检查。一个狡猾的客户可以简单地关闭其安全软件，无视规则，并要求机器人查看所有内容。
新方式（服务器端）客户发送请求，但建筑内部的安保团队负责所有搜索、工具使用和检查工作。客户可以要求一辆“红色汽车”，但他们无法指示安保团队无视规则并向他们展示属于别人的“蓝色汽车”。建筑控制着搜索如何进行，确保规则永远不会被破坏。

结果：他们的测试内容

作者构建了一个名为OGX（Open GenAI Stack）的原型系统来测试这一想法。他们使用虚构的公司和棘手的问题进行了实验，以观察会发生什么。

安全性：如果没有新的安全门，98–100% 的情况下，机器人会泄露其他公司的机密文件。有了新的安全门，0% 的秘密被泄露。安全门完全阻止了泄露。
速度：添加安全门仅使速度略微减慢（约 19 毫秒）。这就像在对话中增加了一个瞬间的停顿——人类几乎察觉不到，但对安全至关重要。
质量：由于机器人没有被来自其他公司的无关文件所迷惑，它实际上更快、更准确地找到了正确的答案。

结论

该论文得出结论，你可以为许多不同的公司建立一个共享的、具有成本效益的 AI 系统，而无需它们窃取彼此的秘密。你只需要停止信任搜索结果的“相关性”，转而在门口执行严格的“权限”检查，所有这些都由服务器内部的中央安保团队管理。

他们强调，这是一个供应商中立的解决方案，意味着它不会将你锁定在一家特定的 AI 公司（如 OpenAI 或 Google）；它适用于你选择的任何开源或商业 AI 工具。

技术摘要：在多租户企业环境中保障智能体安全

1. 问题陈述

本文探讨了在企业环境中部署检索增强生成（RAG）和智能体（Agentic）AI 系统时存在的一个基本安全漏洞。尽管学术研究和面向消费者的 API 通常假设数据访问是单租户且同质的，但现实世界的企业部署涉及多个租户共享基础设施，数据异构，且需满足严格的监管合规要求和细粒度的访问控制需求。

identified 的核心问题是相关性 - 授权缺口（relevance-authorization gap）。现有的检索系统（向量、关键词或混合）旨在优化语义相关性或关键词匹配，但缺乏原生机制来执行授权策略。因此，如果一个租户的查询检索到的数据在相关性指标上得分最高，该查询就可能检索并泄露属于另一个租户的机密数据。在智能体系统中，这一缺口因以下情况而加剧：

工具介导的泄露：当智能体使用广泛权限而非最终用户授权来调用工具时发生。
上下文累积：多轮对话允许跨租户数据泄露，而无需在每轮对话中重新验证策略。
客户端编排：将安全关键逻辑分发到可能不可信的客户端，从而绕过授权检查。

标准的隔离方法，例如为每个租户复制整个智能体栈（向量存储、推理端点），被认为成本过高且导致运营碎片化。

2. 方法论与架构

作者提出了一种通过服务器端编排强制实施的分层隔离架构，以保障智能体 AI 的数据流和控制流安全。该方法在 OGX（Open GenAI Stack）中实现，这是一个与供应商无关的开源框架，提供与 OpenAI 兼容的 API。

2.1 分层隔离（数据路径）

该架构在服务器信任边界内通过三个不同的层级保障数据流安全：

策略感知摄取：在文档摄取时附加租户元数据（所有权、属性）。这确保每个文档块继承一致的租户属性，防止意外的跨租户耦合。
检索门控：应用两层执行机制：
- 搜索前：在搜索开始前评估基于属性的访问控制（ABAC）授权。
- 检索后：检索后应用块级过滤。
- 系统支持谓词下推（即向量后端在搜索期间原生应用过滤器），以在大规模下保持完美的召回率。如果无法进行下推，检索后过滤可确保安全（零泄露），但可能会降低大型语料库的召回率。
共享推理：大型语言模型（LLM）推理层在所有租户间共享。由于第 1 层和第 2 层确保只有授权文档进入提示上下文，模型本身不需要按租户隔离，从而将基础设施成本从 $O(N \cdot M)$ 降低到 $O(M)$ 。

2.2 服务器端编排（控制路径）

为了解决客户端绕过风险，作者主张对“推理 $\to$ 工具 $\to$ 推理”循环进行服务器端编排。

信任边界：所有安全关键操作（工具执行授权、状态隔离、策略执行）均集中在服务器进程内。
权衡：虽然与本地执行相比，这为工具调用引入了延迟，但它防止了受损客户端跳过过滤器或操纵工具调用。
混合方法：该架构允许客户端框架保留对智能体组合和延迟敏感操作的控制权，而服务器则强制执行安全不变量。

3. 主要贡献

本文做出了四项主要贡献：

相关性 - 授权缺口的形式化：作者从数学上定义了为何仅靠相关性排序不足以实现隔离，并提供实证证据表明，未加门控的检索在 98–100% 的探测中会泄露跨租户数据。
分层隔离架构：提出了一种结合策略感知摄取、检索时门控和共享推理的设计，并以服务器端编排作为执行层。
实证验证：通过六项实验评估，测量了安全性（泄露、提示注入抵抗力）、系统性能（延迟、吞吐量）以及检索质量，评估范围涵盖编排模式（客户端 vs. 服务器）和检索门控（无门控 vs. ABAC 门控）的 $2 \times 2$ 矩阵。
开源实现：该架构已在 OGX 中实现，这是一个与供应商无关的框架，提供与 OpenAI 兼容的 API（包括用于多轮编排的 Responses API）以及用于部署的 Kubernetes Operator。

4. 实验结果

评估利用了一个包含三个租户（金融、工程、法律）和 300 份文档的合成测试床。

安全性（跨租户泄露）：
- 无门控配置：无论编排模式如何，无门控检索均导致 98–100% 的跨租户数据泄露。
- 门控配置：ABAC 门控完全消除了跨租户泄露（0% 泄露），实现了安全目标（G1）。
- 提示注入：在门控配置下，所有 90 次提示注入探测均被阻止（0% 泄露）。在无门控配置下，62–80% 的探测成功检索到了未授权数据。
- 执行：研究强调，虽然客户端门控（配置 B）可以实现 0% 泄露，但它依赖于客户端的完整性。服务器端编排（配置 D）通过将逻辑移至信任边界内，提供了必要的执行保证（G2）。
性能：
- 延迟：检索门控为搜索路径增加了约 19ms（授权往返 + 策略评估 + 查找），与推理时间（秒级）相比可忽略不计。服务器端编排由于往返增加了约 3 秒的总延迟，但支持流式传输以减少首字延迟。
- 吞吐量：门控并未降低吞吐量。吞吐量随并发量线性扩展。在高并发下，由于请求路径更短，客户端编排实现了服务器端编排约 2 倍的每秒查询数（QPS）。
检索质量：
- 块级门控通过过滤跨租户噪声，将 Precision@5 提高了 2.2 倍（从 0.200 提升至 0.433）。
- 谓词下推：支持谓词下推的后端在所有语料库规模下均保持 Recall@5 = 1.0。不支持下推的后端（使用检索后过滤）随着语料库规模增加到 5 万个块，召回率显著下降（从 1.0 降至 0.002），但安全保证依然 intact。

5. 意义与范围

本文声称，这项工作首次解决了标准化智能体 API 设计、服务器端编排和共享基础设施上的多租户隔离的交叉领域。

意义：该架构证明，可以在不复制每个租户基础设施的情况下，同时实现安全的多租户、与供应商无关的 OpenAI 兼容 API 以及自主智能体功能。它将安全范式从“基于相关性”转变为“基于策略”的检索。
范围与局限性：
- 该解决方案专为多租户企业环境设计；对于单租户部署或公共数据则不必要。
- 该架构保障上下文构建，但不保障参数化记忆；模型仍可能生成在预训练期间吸收的信息。
- 信任边界是服务器进程；该架构无法防御受损的服务器进程、内部操作员或侧信道攻击。
- 客户端功能工具仍处于服务器信任边界之外，尽管 OGX 通过明确的工具分类减轻了这一风险。

作者总结道，虽然客户端编排为受信任环境提供了更低的延迟，但对于需要严格隔离和合规的企业场景，带有 ABAC 门控的服务器端编排是必不可少的。