重新思考 RAG 的访问控制：Amazon Quick 与 Bedrock 的实时权限验证方案
企业正在用 RAG 从 SharePoint、Google Drive、Confluence 等知识源中挖掘洞察，但这些源里往往藏着受复杂权限结构保护的敏感信息。让 AI 生成的答案严格遵守这些权限，是企业 AI 落地中最棘手的难题之一。
Amazon Quick 与 Amazon Bedrock Knowledge Bases 给出的思路是：不再把权限复制到 AI 系统里，而是在查询时直接向权威源实时验证用户的访问权限。
问题出在哪
设想这样一个场景：SharePoint 站点所有者为企业创建了一个知识库，多个部门的成员通过 AI 助手从中获取答案。关键要求是——每个成员只能拿到自己有权访问的文档所生成的洞察。这是一个普遍的企业挑战：既要让 AI 洞察普惠全员，又不能破坏现有的安全态势。一份未经授权的文档出现在 AI 回答中，就可能泄露机密战略文件、未公开的财务数据或敏感的人力资源信息。
传统方案的三处硬伤
常见的 RAG 访问控制采用“复制再过滤”的方式：数据源连接器（如 SharePoint 连接器）在周期性同步任务中拉取 ACL，将其作为属性复制并存储到索引中；查询时，AI 系统把登录用户映射到已存储的 ACL 属性上，据此过滤结果。
这一做法表面合理，却有三个根本性弱点。
第一，AI 系统并非权限的权威来源。 在这种模式下，AI 系统独自承担权限执行的责任，却并不掌握权限的源头。这要求数据连接器在各类数据源之间准确复刻复杂且源特有的 ACL 逻辑。每个数据源都有自己的权限模型，要在几十个连接器中映射继承层级、群组成员关系、条件访问策略和拒绝规则，极易出错。
第二，权限过期带来风险。 周期性同步意味着权限变更无法即时反映，用户可能在一段时间内看到本已无权访问的内容。
第三，维护成本高。 每新增一个数据源，就要为其权限模型单独适配，扩展性差。
实时验证的思路
Amazon Quick 与 Amazon Bedrock Knowledge Bases 转而采用实时 ACL 执行：在查询时刻直接与权威源核验权限。这样一来，AI 系统不再需要复制和推断权限，而是把判断权交还给真正掌握权限的系统。
对于正在推进企业 RAG 落地的团队而言，这提醒我们：访问控制不是事后补丁，而是架构设计的第一性问题。把权限验证放在正确的位置，才能在开放知识获取的同时守住安全底线。
