基础篇
进阶篇
高频篇
精选篇
手写篇
面经篇
AI 篇
原理篇
每日一题
小程序题库
  • 知识卡片碎片时间过考点
  • 场景篇按分类整理的大前端场景考点
  • 历年面经按年份追踪真实考点
  • 算法题库NEW在线编码即时判题
  • 专项自测100 题快速查漏
  • 前端基础
    • HTTP从报文一路讲到 HTTPS
    • 浏览器渲染、事件循环、进程
    • 计算机基础Linux、网络、操作系统
  • 进阶专项
    • 设计模式23 种模式怎么用
    • 前端系统进阶学习大型项目工程化
    • 前端综合文章长期沉淀的实践文
  • 工程与工具
    • Node学习指南从环境搭建到服务端
    • NPM工作流script、依赖与发布
    • Docker容器化部署上手
    • Canvas图形与动画实战
  • 路线与导图
    • 思维导图知识点全景图
    • 学习路线按图索骥不跑偏
  • 动态
    • 公众号动态公众号历史文章
    • 博客动态站长的技术博客
    • 开发者导航常用工具与文档站
    • AI 热点每日 AI 资讯与动向
AI 工作台
简历
旧版
AIHT
内容
精选全部 AI 动态热点榜AI 日报收藏
分类
模型行业编程产品技术观点开源
更多
Agent 接入
返回首页开发者导航
AIHT
精选 / 资讯详情
8.0
热点
AI SCORE
技术实践2026-11-03 12:22

RAG 防泄露:检索上下文必须先过权限关

dev.to · AI#RAG#权限控制#数据安全
Editor brief · 编辑速览

检索相关性不等于访问权限,答案准确且引用正确也可能泄露受限资料。文章强调在构建模型上下文前完成授权过滤,并让文档拆分后的片段继续遵循原有访问规则。

文章思维导图
Knowledge map
拖拽缩放
AI deep read

AI 深度解读

RAG 助手答得准确、引用也对,仍然可能泄露数据:它找到的资料,未必是当前用户有权阅读的资料。原文讨论的就是这个容易被答案质量掩盖的问题,结论很明确:权限检查必须发生在检索和构建上下文时,不能交给模型临场判断。

对正在做内部知识库、企业问答或多租户 AI 应用的团队,这篇文章的价值在于补齐验收标准。除了「答得对不对」,还得检查「证据能不能给这个人看」,并把权限撤销、缓存复用和检索降级一起纳入设计。

为什么不能让模型负责保密

设想内部助手同时搜索工程运维手册、客户合同和 HR 文档。它们都可能包含相关信息,但允许阅读的人群不同。

原文指出了一条危险流程:先搜索整个文档集合,把命中的片段交给模型,再要求模型隐藏受限信息。问题发生在生成之前,因为受限内容已经进入模型上下文。

相关性决定资料是否有用,授权决定资料是否能被使用。

提示词可以约束回答方式,却不能代替应用的授权检查。即使最终答案礼貌地拒绝了请求,也不能证明受限片段没有进入处理流程。

原文提到,Microsoft 的文档级访问控制资料提供了基于文档权限和安全过滤器限制搜索结果的思路,但没有给出统一实现。具体怎么过滤,仍取决于数据源和搜索平台。

文档切成片段后,权限也要跟过去

RAG 通常把文档拆成片段后检索。如果切分时只保留正文,丢掉租户、用户组等访问规则,后续就难以判断某个片段能否进入上下文。

作者给出了一份示意元数据,用来说明片段需要携带哪些权限线索:

{
  "chunk_id": "runbook-42-chunk-3",
  "document_id": "runbook-42",
  "tenant_id": "tenant-a",
  "allowed_groups": ["platform-operations"],
  "permission_version": 7
}

这里要留意 permission_version:它提供了权限版本信息,但这份 JSON 本身并不构成完整授权实现。版本如何比较、权限如何执行,原文没有展开。

另一个关键点是身份来源。后端必须从可信认证系统解析用户所属租户和访问权限。如果直接接受浏览器传来的任意租户 ID 或用户组列表,过滤条件就可能被调用方操纵。

原文建议用下面的流程组织请求,让权限约束先于上下文构建:

Authenticate user
    → Resolve tenant and access permissions
    → Retrieve within the authorized scope
    → Build context from authorized chunks
    → Generate answer
    → Return permitted citations

要注意 Retrieve within the authorized scope 这一行:授权范围需要覆盖关键词搜索、向量搜索和兜底查询。只给主检索路径加过滤,仍然会留下绕行入口;返回的引用也必须符合访问权限。

权限撤销后,旧索引和缓存怎么办

文档正文没变,不代表它仍然可以被同一批人读取。员工换组、合同转为受限、用户失去工作区权限,都可能只改变访问规则。

如果检索索引还保留昨天的权限,今天的回答就可能继续暴露已经无权阅读的内容。作者因此要求明确三件事:权限更新如何进入索引,撤销多久生效,以及权限信息缺失或过期时如何处理。

缓存也有同样的问题。一个用户曾经获得的答案,不能仅凭问题相同就返回给另一个用户;即便还是同一个用户,也需要考虑他当前是否仍有权限。

作者列出的测试场景很具体:不同权限用户问同一问题、不同租户存在相似标题文档、答案缓存后撤销权限、片段缺失权限元数据,以及没有任何已授权来源能支持答案。

权限测试要检查检索片段和引用,不能只看最终回复。

否则,模型没有输出秘密,可能只是这一次没有输出,并不能证明检索边界成立。

我的判断

我赞同作者把访问边界纳入答案质量:证据有用、回答忠实、来源已授权,这三个条件缺一不可。对企业知识库而言,准确引用受限文档同样属于失败。

不过,这是一篇设计原则文章,没有实测结果、泄露率或方案对照数据,不能据此判断某种过滤方案效果最好。它也没有说明权限同步延迟、缓存隔离策略或具体搜索平台的配置方式。

和生成后再检查答案相比,提前限制检索范围能直接减少受限内容进入上下文的机会;但落地前提是团队能取得可信、可同步的源文档权限。原文的元数据示例只能作为设计起点,不能直接当成生产方案。

能拿来做什么

  • 如果你在写 Node 后端,把租户和用户组的解析放在可信认证链路中,并检查关键词、向量和兜底检索是否都使用了授权范围。
  • 给知识库切分与索引流程补一份权限字段约定,明确权限版本、更新传播方式,以及元数据缺失或过期时的处理规则。
  • 给问答缓存增加当前权限校验,重点验证「缓存后撤权」和「不同用户问同一问题」,避免仅按问题文本复用答案。
  • 在日常 AI 编程中,让助手协助梳理检索入口和拒绝路径,并把检索片段、引用一起纳入验收证据。
Original source

本文由 AI 通读原文后重新编写,观点部分为站内判断,细节以原文为准,来源 dev.to · AI,原文版权归原作者所有。

阅读原文
上一篇
把AI开发中的纠错与遗留问题变成项目资产
下一篇
商汤新模型打通网页、动效与三维创作

资讯速览

dev.to · AI · 2026-11-03 12:22

AI 评分 8.0 / 10

相关标签

#RAG#权限控制#数据安全

继续阅读

  • Agent能读审批验证码,消费限额就可能失效
  • 把AI开发中的纠错与遗留问题变成项目资产
  • 商汤新模型打通网页、动效与三维创作
  • 高通端侧AI开发平台向中国开放
  • 美团 LongCat-2.5 强化视觉与智能体编程