2026-04-28 05:30:59 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文系统阐述RAG权限安全设计，提出五种核心模式：独立库硬隔离、同库元数据过滤、RAG网关审计、窄接口检索器、网络工具分区。强调权限需与身份验证、工具链管控协同实施，避免模型伪造身份或SSRF风险。给出企业落地建议：业务定数据分级、安全定技术底线、工程实现身份与过滤绑定、网络分区防内网越权。 综合评分： 87 文章分类： 技术标准,安全建设,解决方案,安全运营,数据安全

cover_image

速度与激情3：智能体RAG权限——五种模式与安全团队实践建议

原创

DIMU DIMU

AI简化安全

2026年4月27日 22:56 广东

在小说阅读器读本章

去阅读

摘要：本篇谈三件事：RAG 为何要单独做权限；五种常见设计怎么选、节末有一张总表对照；第三节用飞书、OpenClaw、本机/内网 HTTP 知识服务串起来，说明模式怎么落在真实链路上（不是五种全上）。第四节写企业里安全与业务怎么分活、工程上怎么协同、网关/向量/身份/观测等能力怎么部署、策略上守住哪些底线。

RAG 不只决定「搜到什么」，还同时决定：谁在问、从哪条通道进知识库、工具会不会绕开前两道关。传统网盘靠账号和目录权限；RAG 里段落进向量、按相似度召回，多了几层容易漏看的缝。

常见坑有三类：同一套索引里混了多部门语料时，光看目录名不够，得问「这条命中该不该给这个人」；大模型会调工具、拼 URL，身份若能在提示词里「自称」，越权会在链路上变成真事；智能体走 web_fetch 或本机回环，又会撞上 SSRF、防火墙——于是出现服务在跑、飞书里却问不出来的怪状。

这几件事要一起设计：语料怎么打标、检索怎么按身份过滤、服务入口是否可信、工具和智能体是否在白名单里。缺一环，后面补起来很痛。

二、五种常见 RAG 权限设计模式

企业里做 RAG，常见五种设计取向，可以组合使用，很少只选一种。每种下面有流程图。

先总览五种各解决什么问题，再分节展开。

和 ①～④ 的分工：前四种主要解决「检索出来的块对不对人」；⑤ 解决「模型和工具链能不能绕开业务逻辑直接打到内网 HTTP」——两边常叠用。

1）独立库 / 独立 Collection（硬隔离）

独立库就像分柜：检索只进自己的 collection/namespace。要共享一份材料，要么多柜各存一份，要么换用下面「同库打标」的做法。

做法：每类调用方单独建库（Pinecone namespace、Qdrant collection、多 Chroma 集合等），检索时只进自己的柜。

优点：隔离最直、误配时也不容易串柜。\ 缺点：共享材料要双写/同步；运维与成本上升。\ 适合：多租户强隔离、监管要求「物理/逻辑分柜」、材料交叉少的场景。

图意：检索只连与身份对应的库；无跨库查询则无越权面（共享文档需重复入库到多库或另选模式）。

2）同库 + 元数据 + 系统注入过滤（软隔离、灵活）

同一大库、每条向量带谁能看的标签，检索时由服务端按真实身份加 filter。过滤条件别指望模型在 JSON 里自填 agent_id，那种字段可被伪造。

做法：每条向量打标（租户、项目、allowed_agents 等）；仅在服务端注入 where/后过滤，禁止让模型自行传可伪造的 agent_id 到过滤条件。

优点：一稿多投、共享与独占能并存。

缺点：实现必须审计：过滤漏一层就会逻辑越权；日志与单测要跟上。适合：多智能体、内规+部门材料混合、共享目录 + 独占目录并存的架构。

图意：filter 与当前身份只能由受信服务层加入；模型不能在请求体里改成别人的 agent_id。

3）RAG 网关 + Token / 企业身份（可审计的入口）

调用不直连向量库，先过统一入口：企业身份验完，再映射到允许查的库和配额，全链路有日志，内审好交代。

做法：不直连向量服务；统一经网关，Authorization 或 OIDC 将调用方映射到允许的库/集合与配额，全链路留痕。

优点：等保/内审好讲故事。

缺点：多一层服务与密钥/高可用。

适合：需要强管控证明、多系统共用一簇 RAG 时。

图意：身份与权限策略在网关集中；下游只信网关转发的、已裁剪的查询。

4）编排器层 Retriever 仅注入「窄接口」

编排里只塞已经绑好 filter 的 Retriever，业务侧摸不到无过滤的裸 vectorstore.query，少一层「手滑全表搜」。

做法：在 LangChain/LlamaIndex 等工厂里只注入已绑定 filter 的 Retriever；业务侧不直接持有裸 vectorstore.query。

优点：研发单测围绕 retriever；认知负荷低。

缺点：不能替代网络边界；若有直连向量 API 的后门，仍须封。

适合：自建 Agent 编排、希望构造期就限死范围。

图意：智能体只拿到窄检索器实例，改不了全局无过滤的查询面（前提是无旁路）。

5）网络与工具侧：公网/不可信区与内网 RAG 分区

大模型和工具在「不可信面」，内网 RAG 在「可信面」：防的是通过工具链对私网、回环做 SSRF 式访问。内网知识一般走固定脚本、Sidecar 或白名单，而不是让模型自己拼一个 http://127.0.0.1。

做法：web_fetch 等默认不访问私网/回环；内网 RAG 经受控桥、Sidecar、或白名单脚本访问，禁止模型任意拼危险内网 URL（含云元数据地址）。

优点：与 SSRF、IMDS 防护叙事一致。

缺点：业务要多一步——需产品化（一条命令/固定脚本），而非单纯「全封」。

适合：大模型能出网、工具链在「不可信面」、知识库在「可信内网」 的典型企业部署。

图意：控制面在工具与网络策略上收束「谁能打到内网 HTTP」，与 (1)～(4) 的数据面正交、常叠加使用。

五种模式：总结对比

组合建议（非互斥）：生产上常见 ② + ③（数据软隔离 + 可审计入口），强监管叠加 ① 或 ③ 多实例；凡有 web_fetch/exec 触达内网，⑤ 必叠一层。工程上仍须保证：身份只来自受信链（会话/路径/Token），不在提示词里「假装」有权限。

三、工程实践：RAG 不止要能搜，还要「在真环境里可信」

为什么拿「飞书 + OpenClaw + 本地 RAG」举例 常见场景是：人在飞书里问智能体，请求经本机或自管的 OpenClaw 类网关，知识命中跑在笔记本或内网的 HTTP 服务上。渠道、网关、知识库不在同一信任域里；第二节里的「锁法」如果只写在 RAG 进程里，不和飞书身份、工具出网、防火墙对齐，就会出现本机 curl 有结果、线上渠道调不通，或者能调通但审计对不上。这里只讲这一条链，不是说企业里只有这一种架法。

这条链上，第二节里经常要动的几样（仍是组合，很少五种全开）

• ②：RAG 服务侧对命中向量做元数据过滤 / 二次过滤，与「谁录入、谁可查」一致。
• ⑤：飞书侧工具若打不到本机回环，往往走 exec + 固定脚本调本地 HTTP，并与 firewall\rules.json 等 allow 窄门对齐。
• ①：若你给不同角色分了不同库 / 不同路径，链路上要保证路由与库一一对应，不串柜。
• ③：若企业另布了统一 RAG/API 网关，链路上多一道可审计入口（可选项，本例不假设必有）。
• ④：若用 LangChain / LlamaIndex，在代码里只注入带 filter 的 Retriever；若是脚本 + 直调 HTTP，用固定路径 + 服务端过滤表达同一类约束即可。
拆开看就三条线：

1. 认人（别靠模型嘴上说「我是财务」）在 OpenClaw 里，人是谁通常来自渠道会话与绑定关系；把「是谁在问」写进受信、难伪造的通道——例如路径固定为 /kb/{角色}/retrieve，身份在路径上可核对，query 体里不夹可自改的 agent 字段。这样，② 里的 filter 才和真身份绑在一起，而不是纸面安全。
2. 检索（命中的块再过一道「谁能看」）向量先命中候选，再按元数据二次过滤（如 allowed_agents），和谁录进入库的规矩一致。这是 ② 在工程上必落地的一截。
3. 工具与防火墙（对应 ⑤） web_fetch 往往打不到回环/内网，于是用固定脚本经 exec 调本机 HTTP；而 exec 常被防火墙规则默认拒绝，就会「本机行、飞书不行」——需给该智能体 + 固定脚本开窄门 allow，不是全盘放开。

四、安全与治理：制度、数据、工程与平台能力

单换产品过得了代码扫描，未必过得了内网里的扯皮。RAG 一上来，如果「谁对数据主责、谁出规则、谁能审计」没讲清，安全很容易变成接锅的。安全熟的是风险和控制，没法替业务给每份材料定性；文章里把制度和技术放在一条线上写，不是为了让业务觉得安全只会说不。

（一）分类分级和权限表：谁主责、安全干什么

数据算不算机密、能不能进知识库、能给谁看，业务条线要说出个子丑寅卯，毕竟客户、合同、经营口径他们最熟。安全不必在会议室里替业务给每份材料断「商业味」；能做的是把公司已有办法（数据安全制度、分类分级指引，或选用的国标、行标、行业细则）往 RAG 场景里落：定级、脱敏、出网、出境、和第三方/模型/云的边界，写成可执行条款，灰区进例外审批。没有公司级总册的，用 RAG 项目推一版能上会的定级和审批矩阵，比关起门写一叠没人签的东西有用。

RAG 特有的要在规则里先写清：进向量的、原文的、摘要不要同一套密级，能不能进公网模型、出不出境。上线后再打标，往往是整条链返工。交付物可以很简单：数据域/源、人/智能体、能检索/管理/还是导出、走哪道审批，一张表；离职、换岗、智能体和库的绑定，进变更单。核心库别一上来就全量喂给全公司共用的智能体，旁路库、只读副本、脱敏样例先跑通，责任和例外有纸面，大家才好一起扛。

（二）制度与意识：和上面连着读

语料、索引、模型、提示谁发版，灰度、回滚、保留多久；智能体、工具、内网地址上谁的白名单、谁改谁批；出了事谁接、日志留多久——写短一点，能进项目附件或验收条款，等保、内审拿得起来。业务知道什么能喂、什么要走批；研发知道身份在链上、filter 在服务端；运维管密钥、备份、别把内网地址贴聊天里。可审计、可回滚、可举证写清楚，出事别只剩一句「当时口头上说过」，设计阶段才容易把安全拉在同一张桌上。

（三）工程协同：三样做实就能签字

把第二、第三节里要落地的活收成套路，安全、研发、运维都能照做，每步有东西可归档。

接入包 约定 RAG 的 URL/路径怎么带身份、元数据必带哪几个键、请求体里不许塞可伪造的主身份。预发、灰度里用同一批问题反复跑，安全进用例评审，别等上线当晚才第一次看页面。新智能体照表扩列，少从「大模型要安全」从头吵起。

对拍同一句用户问法，换不同账号或不同智能体各问一遍；A 不应看到 B 域材料时，界面结果和网关或 RAG 侧日志截下来归档。要扯皮时手里有东西。

工具与 exec 走 exec 调本机脚本进内网 RAG 时，防火墙常默认拒。用智能体 ID 加脚本绝对路径做白名单，别图省事开任意 shell。第三节里「本机行、飞书不行」一类问题，多是这样收口的。

和下图同序：模板、对拍留档、exec/防火墙窄门。

（四）平台能力怎么落：形态、布法、策略

下表是技术选型时常对照的能力域和设问方式，不往单一品牌上套。自研、开源、云、软硬一体都能往里填，留神接口是否标准、策略能不能外置、以后换一截组件痛不痛。

几条原则在方案评审里可以对一下：权限尽量在网关或策略层说清，别每个脚本自己发明一套。新链路上先旁路、影子、只读，全留痕，再收紧。对工具打内网、对敏感上公网模型，默认关、登记后开窄门。RAG 里同一条数据不比源系统更「公开」；拿去做训练、评测的另批、另脱敏。接口和可观测的约定别绑死在一家黑箱上。

（五）小结

1. 数据：业务说清能不能进 RAG，安全在定级、出网、出境、例外上给规则和复核，权限能落到表。
2. 制度：语料、版本、白名单、事件，写短、能进附件；几类人各有一句能照做的。
3. 工程：接入包、对拍、exec/防火墙窄门，三步有归档。
4. 能力：上表是设问和盯法，旁路、影子、默认关、能替换，当技术原则写，不必凑成产品发布会。

五、结语

没有哪种模式一把梭就管十年。监管严、隔离要硬，常叠①和③；要一稿多投、多智能体共享，常叠②和受信服务层；只要还有公网、web_fetch、exec 之类，数据面外头还要叠⑤。具体选法看第二节末总表和「组合建议」。

内审关心的是：身份跟着会话、Token 或固定 API 路径走，不跟着提示词编；谁能检索什么，日志和策略里对得上。业务关心的是：防火墙和工具白名单拦的是乱来，登记过的入口、固定脚本、窄 allow 开清楚，正当的 RAG 能稳着上线。红队关心的是：攻击面能分斤掰两，伪造身份、绕过滤、工具打内网，各有一层应，别糊成一锅粥。

总体来说就三句话：身份在受信链上，元数据在检索里真生效，工具有门有槛、别误伤正经事。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI简化安全 DIMU DIMU《速度与激情3：智能体RAG权限——五种模式与安全团队实践建议》