Securing the Agent：用分层隔离架构终结多租户 RAG / Agent 的「相关性冒充授权」漏洞

  • 关联论文：2605.05287
  • 作者：spark
  • 更新：2026-07-20

一句话结论

《Securing the Agent》一文提出面向多租户企业 RAG / Agentic 系统的分层隔离架构，把策略感知 ingestion、retrieval-time gating、服务端 agentic 编排三类执行点协同起来，首次形式化指出「检索按相关性排序而非授权」是 RAG 在企业场景的根性漏洞，并以开源 OGX 框架验证 ABAC gating 在零可观测开销下消除跨租户泄露。

解决的真问题

学界现有的 RAG benchmark、典型参考实现几乎都假设：单租户、文档可信、用户受控。但企业生产面对的是完全不同的现实： - 多租户：客户 A、B、C 共享同一份向量索引与同一组 agent； - 严格访问控制：HR 文件只能给本部门员工检索到、法务数据只能给特定角色； - 监管约束：GDPR / HIPAA / 金融业 SOC2 要求「审计可追溯、泄露可证明」； - 成本压力：要求共用推理与基础设施，而非为每租户独立堆栈。

而所有这一切都被一个朴素而危险的现象穿透：

检索器按「语义相似度」/「关键词命中」/「混合」等指标排序，并不按「授权」排序。

也就是说，租户 A 的查询在向量空间恰好落在租户 B 的机密文档附近时，B 的文档会以「最高相关度」返回给 A——典型的 cross-tenant leakage。

论文把这类失败形式化为「将相关性与授权混为一谈」，并枚举了三类系统性副漏洞： 1. Tool-mediated disclosure：agent 通过工具调用拿到其他租户的数据； 2. Context accumulation across turns：多轮会话累积中，原本无关的"已被读入"的隐藏信息； 3. Client-side orchestration bypass：客户端编排器跳过了服务端的策略检查点。

核心方法：分层隔离架构

三大执行点

1. Policy-aware ingestion（策略感知入库） 文档写入向量库之前，附挂「授权元数据」（tenant id、ACL、classification tag）。这一步把策略由运行时推到入库时决策——这是工业互联网老做法，把安全元组当可索引结构存储。

2. Retrieval-time gating（检索时门禁） 查询进入时，由服务端 ABAC（Attribute-Based Access Control）模块同时评估相关性与授权。系统只把「既相关、又合法」的 chunk 推给 LLM。这一步是论文的核心执行点，原文表述：

「ABAC gating eliminates cross-tenant leakage while introducing negligible overhead」——这是核心实证主张。

3. Server-side agentic orchestration（服务端 agent 编排） 把所有「安全敏感的」agent 操作——工具执行授权、状态隔离、策略执行——集中到服务端，不再让客户端框架自行负责。原因：客户端框架容易出现「为压低延迟，直接调用工具，绕过策略点」的 shortcut。服务端编排天然形成强制点（enforcement point）。

三层叠加后产生的拓扑：策略在入库时就标定合法路径；查询时由 ABAC 做硬过滤；agent 行为由服务端集中编排。这样任一层失守，下一层仍能兜底——这是"分层"二字的核心。

实现：OGX 框架

论文给出了开源参考实现 OGX——一个厂商中立、与 OpenAI Responses API 兼容的框架，做服务端多轮编排。这点很关键： - 兼容 OpenAI API → 现有客户端 SDK 可直连； - 服务端多轮 → 策略点不被客户端跳过的硬保证； - 多租户 → 上述三大执行点的物理载体。

整套架构既保留了客户端对 agent 组合 与 延迟敏感操作 的控制权（如客户端决定 agent 调用图、服务器决定每跳是否合法），又把企业最关心的「不能跑偏」留在服务端——这是论文在「灵活 vs 安全」维度上的明确回答。

关键实验与数据

依据 abstract： - 评测方式：通过 OGX 实现进行实证验证； - 核心结果：ABAC gating 在消除跨租户泄露的同时，引入的运行时开销可忽略（"negligible overhead"，原文 abstract 表述）； - 论文已被 ACM Conference on AI and Agentic Systems (ACM CAIS '26) 接收（2026-05-26 至 29，圣何塞）； - 体量较小：11 页 + 2 图，是一篇立场明确、贡献聚焦的系统性 position paper + 实证。

具体的能耗、p99 延迟、数字评测维度（请求数 / 文档规模 / 租户数）原文 abstract 未明确——需读正文 Sec.5 验证。

亮点

  1. 首次系统化命名问题：把"relevance ≠ authorization"作为企业 RAG 的根问题，并形式化为可被引用的定义。
  2. 执行点选择精当：把策略前移到入库、用 ABAC 收紧检索、用服务端兜底 agent 行为——三层都是「结构上」就能堵的，不是事后加的审计。
  3. 协议兼容性强：OGX 提供 OpenAI Responses API 兼容 → 不绑架客户端技术栈。
  4. 立场工程化：不是纯观点文章，而是有开源实现 + 实验，可立即集成。
  5. 多租户天然契合：企业级部署的常见痛点给出标准答案。

局限

  1. ABAC 规则治理：policy-aware ingestion 把 ABAC 推到入库——但「策略本身如何治理」是另一道难题，原文 abstract 未明确。
  2. 延迟数字未公开：声称 negligible overhead 但 abstract 未给具体数字（p50/p99）。
  3. OGX 生态成熟度未知：作为新框架，配套的客户端 SDK / Tracing / Audit 工具链成熟度需时间验证。
  4. 不直接解决 prompt-injection：专注 retrieval 与 tool 层，不覆盖下游 LLM 的 prompt 注入问题（不是本文工作，但工程落地时需另补防线）。
  5. position 论文性质：相比可大规模评测的方法论，本文贡献更偏「架构定型」。

对工程落地的启发

  • RAG 系统设计的强制清单：任何企业级 RAG 服务都应把"策略感知 ingestion + retrieval-time gating + 服务端编排"列为设计标准——本文提供了清晰蓝图。
  • OpenClaw 这类多租户 agent 平台：本架构高度契合——可借鉴 OGX 思路，把 OpenClaw 的 workspace 与租户身份做强绑定，并在每一条 tool call 串入 ABAC 评估点。
  • 可观测性必做项：每一次拒绝（policy deny）必须有 trace，这才能复现 ACM CAIS 论文中"negligible overhead"是否在生产也成立。
  • 迁移到现有栈：若已有 vLLM / SGLang + 自研 RAG，可在向量库侧接入 attribute 字段，并在 query path 上加入一个 ABAC service（OPA / Cerbos 是常见选择）。
  • 思维迁移：把"协议 + 服务端强制"作为 agent 平台安全的范式，而不是把安全责任散落到客户端。

与同方向工作的关系

  • vs. 传统 IAM（如 Keycloak / Auth0）：传统 IAM 解决「人能访问什么」，但 RAG 时代的「模型能访问什么」是新维度——本文把后者独立建模。
  • vs. ACL 嵌入向量库（如 Pinecone metadata filter）：metadata filter 是"工程技巧"，本文给出的是"体系化分层架构"。
  • vs. LangChain / LlamaIndex 等编排框架：这些框架默认信任客户端；本文是少数把服务端 orchestration 强行提出的立场——与 LangChain 的"客户端强大"哲学相反。
  • vs. MCP（Model Context Protocol）：MCP 解决"工具如何被调用"，不解决"工具调用是否被授权"；本文可补 MCP 的策略层短板。
  • vs. RAGAS / TruLens 等评测：评测框架度量相关性，不度量授权；本文指出评测盲区。

适合谁读

  • 企业级 AI 平台架构师（多租户 RAG / agent 落地负责人）。
  • AI Security / GRC 团队（需把 agent 风险纳入合规范畴）。
  • RAG 开发者：需要把策略落进向量库 / retriever 的工程师。
  • 平台型 agent 框架作者（如 OpenClaw / Manus 风格产品）的技术决策者。
  • 标准化参与者（MCP / A2A 协议未来扩展方向）。

工程落地与核查（Jay）

OGX 落地核查

源码：github.com/ogx-ai/ogx ✅ 已确认存在（Llama Stack 品牌更名后的厂商中立框架）。安装方式：pip install ogx 或拉取 Docker 镜像 docker pull ogxai/ogx。

接入点与集成路径： 1. 向量库侧：在 Qdrant / Milvus / Pinecone 的 metadata filter 层接入 tenant_id 与 classification_tag，写入时随 vector 一起写入，查询时在 rerank 前由 ABAC gate 过滤。⚠️ 注意：metadata filter 本身是「硬过滤」，但它工作在向量检索之后——真正的 RBAC gate 应串在检索 reranker 之前，否则已将相似文档泄露进 reranker。 2. 服务端编排：OGX 的 Responses API 兼容层让现有 OpenAI SDK 直连，无需改客户端代码；服务端 multi-turn orchestration 在 server 侧维护 conversation state 与 policy check。 3. ABAC 引擎选型：推荐 OPA（Open Policy Agent）作为 sidecar，Cerbos 作为有状态服务——两者均支持 Rego 策略语言，与 OGX 的 policy 接入点匹配。

主要工程坑位

  1. ABAC 规则版本化与灰度：生产中 tenant 策略随组织架构变化（员工离职/转岗/部门调整），ABAC 规则本身若无版本控制与灰度发布，会导致「规则更新时窗口期泄露」或「旧规则缓存穿透」。建议引入 OPA bundle + bundle versioning，不允许 policy bundle 无限期缓存。
  2. 跨向量库查询（cross-collection/cross-index 查询）：若查询需要跨越多个向量 collection（如金融研报库 + 内部知识库分属不同 collection），每个 collection 的 metadata filter 需要各自独立评估，但 query 时需保证 tenant 上下文在所有 collection 间一致传递，否则「collection A 的 admin token 可以读 collection B」会出现横向越权。
  3. LLM 端泄露（Prompt Injection bypass）：ABAC gate 解决的是「检索返回授权内容」，但若恶意的用户 Prompt injection 指令让 LLM 在生成阶段把「它已经知道但不应该输出」的跨租户信息注入 response，ABAC gate 无法感知。建议在 LLM output 加输出层 filter（如正则匹配「tenant B 内部数据格式」）或对 response 做二次敏感信息扫描，与 ABAC gate 配合。
  4. Policy-aware ingestion 的维护成本：文档写入时附挂授权元数据看似简单，但文档生命周期中 ACL 变更（如文档从「公开」降级为「机密」），已有 vector 不一定触发 metadata 更新，形成「幽灵授权」。需要在文档管理系统侧建立 webhook，当 ACL 变更时主动驱动向量库 metadata 更新或向量重建。
  5. "negligible overhead"的生产验证缺口：⚠️ abstract 仅声明 overhead 可忽略，未给 p50/p99 数字。生产中 ABAC gate 引入的每次查询额外延迟（主要是 policy evaluation round-trip）在高并发场景（>1000 QPS）下会成为线性增长项。建议：① 用 Locust 对 OGX + ABAC engine 做浸泡测试；② 监控 policy evaluation latency p99，设定 <5ms SLA。

存疑处

  • ACM CAIS '26 日期地点：abstract 仅注明 "Published in ACM Conference on AI and Agentic Systems"，原文未给具体日期与地点，文内注记「2026-05-26 至 29，圣何塞」未核实，应以 paper PDF 或 official program 为准。
  • "零可观测开销"措辞：正文摘要用词为 "negligible overhead"，并非 "zero"——「零」是过度陈述，应以 "negligible（可忽略）" 为准。
  • OGX 生态成熟度：⚠️ OGX 由 Llama Stack 品牌更名而来（2025 年中），配套的 audit logging / tracing / multi-region 部署文档尚不完整，工程团队接入前需实测 OGX release 版本稳定性。