Amazon Quick RAG 访问控制将权限检查移至查询时

Amazon Quick 通过在企业内容送达模型前增加第二道权限检查，改变了 RAG 访问控制方式。10 月 7 日的公告旨在解决一个长期存在的安全缺口：索引中的权限可能会在同步周期之间过时。

新的 Amazon Quick RAG 访问控制设计，将搜索索引中的快速过滤与针对原始数据源的实时验证相结合。AWS 表示，该功能支持来自 Microsoft SharePoint、Google Drive 和 Atlassian Confluence 等系统的企业知识。

这一差异至关重要，因为检索增强生成（RAG）会利用从已连接信息源中检索到的段落生成答案。如果检索过程纳入了未经授权的段落，模型就可能通过摘要、比较或间接回答暴露其内容。

因此，核心竞争并非 AWS 与其他供应商之间的较量，而是以源系统为权威进行验证，与将权限复制到 AI 索引中并信任这份副本这一广泛做法之间的差别。

AWS 表示，其两阶段方法缩短了权限变更与该变更在 AI 回答中得到执行之间的时间间隔。不过，该公告并未消除身份、配置、延迟、审计或连接器风险。它改变了企业应如何划定检索安全边界。

Amazon Quick RAG 访问控制新增第二道关卡

关键变化并非增加了另一个企业连接器，而是在找到检索候选内容之后、其文本送达模型之前作出权限决定。

许多 RAG 系统会在定时抓取期间同时摄取内容和访问控制列表（ACL）。ACL 会记录哪些用户或群组可以访问特定资源。系统将这些权限作为元数据，与索引中的文档段落一同存储。

当用户提交问题时，检索层会搜索索引，并使用存储的元数据过滤结果。这种安排效率很高，因为相关性排序和权限过滤都在向量索引附近完成。

其弱点在于时间。索引中的 ACL 代表的是上一次成功同步时观察到的权限，并不一定能描述用户在查询当下是否能够打开该文档。

AWS 将其实时 ACL 设计作为索引过滤之上的附加控制措施。第一阶段仍使用存储的 ACL 数据缩小候选集。第二阶段则向已连接的源系统询问用户当前是否拥有访问权限。

只有通过两个阶段的段落，才会成为大语言模型的上下文。上下文是模型准备回答时接收的检索信息。

这一顺序至关重要。系统并不依赖模型在生成后识别机密材料或将其移除，而是试图在生成开始前排除未经授权的段落。

AWS 以 Google Drive 说明该流程。Quick 首先进行语义搜索，即根据含义而非精确关键词匹配来检索段落。它应用索引中存储的 ACL，生成一组更小的候选文档。

随后，Quick 调用 Google Drive API 验证这些候选内容。AWS 表示，该服务使用管理员提供的服务账号凭据，通过模拟创建用户专属访问令牌。

Google Drive 仍是每个候选内容权限的权威来源。即使索引中的 ACL 仍显示具有访问权，未通过实时检查的文档也会被移除。

这一流程保留了索引在速度方面的大部分优势。若通过远程 API 检查大型存储库中的每一份文档，将带来显著的延迟和请求量。仅检查已缩小的候选集，则形成了更实际的安全性与性能平衡。

SharePoint 遵循同样的总体模式，尽管其身份流程有所不同。AWS 文档描述了先进行检索前过滤，再委托验证用户当前 SharePoint 权限的流程。

对于启用了 ACL 的 SharePoint 知识库，当受保护内容变得相关时，Quick 会提示用户登录。随后，该服务会使用委托令牌验证用户对每个候选文档的访问权限。

根据 SharePoint ACL 流程，该登录通常只需进行一次。相关刷新令牌的有效期约为 90 天。

文档还规定了用于读取站点项目、文件、用户基本资料以及维持授权访问的委托权限。这些范围值得审查，因为实时验证依赖于正常运作的身份委托。

这不仅是一次连接器更新。AWS 正在为两个层级分配不同职责：索引负责快速选择候选内容，源系统则提供最终权限答案。

这一架构使陈旧的 ACL 元数据不再是唯一的决策者。它仍会影响哪些候选内容会被考虑，但在受支持的实时流程中，它不再拥有最终决定权。

缓存权限成为企业 RAG 的薄弱环节

企业 RAG 会继承其源系统中的所有复杂权限规则，同时还会将同步和身份映射引入为新的故障点。

典型的公司存储库很少只有一项简单的访问策略。SharePoint 可以组合站点、群组、继承关系、例外情况和显式授权。Google Drive 则可能包含个人文件、共享云端硬盘、直接共享、群组成员资格以及全组织设置。

Confluence 还包含空间、页面、群组成员资格和继承限制。一家公司可能同时使用这三套系统，并连接 OneDrive、Amazon S3 和内部 Web 应用。

Amazon Quick 目前已记录了针对 S3、Confluence、Google Drive、OneDrive、SharePoint 以及需要身份验证的 Web 内容的集成。其数据访问集成采用多种身份验证模式，包括 OAuth 和服务账号。

将访问规则复制到一个标准化索引中，要求连接器能够正确解读每个源系统。它必须保留用户身份、嵌套群组、继承关系、拒绝规则，以及上一次抓取后发生的变更。

映射缺陷可能导致授权范围过宽。同步延迟可能会在员工调岗后仍保留其访问权限。抓取失败则可能导致内容保持最新，而其权限表示仍停留在旧状态。

当员工将 AI 助手视为跨存储库的快捷入口时，问题会变得更加严重。传统界面会逐个呈现文件，通常具有用户熟悉的文件夹或站点边界。RAG 助手则会将多个来源的证据组合成一个答案。

这种综合提升了实用性，但也改变了暴露模式。用户无需知道某份受限文档的存在。一个宽泛的问题就可能检索到某个段落，并将其转化为简洁表述。

一个答案可能将公开的项目进展与机密预算、人事决定或收购计划结合起来。即使只是部分披露，也可能暴露原始界面本会隐藏的信息。

生成后过滤是一种较弱的补救措施，因为模型已经接收了该段落。护栏可以识别个人数据或不安全内容等类别，但无法自动理解每家公司的所有文档权限。

文档授权的正确位置是在生成之前。这一原则同样适用于引用、后续问题、摘要、导出以及由智能体触发的操作。

AWS 的公告重点关注同步权限与源系统实时状态之间的滞后。设想一名员工在一次定时抓取后不久被移出机密战略群组。

复制并过滤的系统可能会继续识别该员工原有的成员资格，直到下一次成功同步。事件驱动更新可以缩短这一间隔，但无法覆盖每个平台上的每一次权限变更。

AWS 特别指出，某些变更，例如 Confluence 群组成员资格更新，并不总会产生可用事件。连接器无法立即对从未收到的事件作出反应。

源系统也在持续演进。新的共享方式或策略类型可能会快于连接器的转换逻辑。届时，索引可能会错误呈现权限，直至连接器获得更新。

实时验证改变了这种依赖关系。AI 层仍需要正常运行的集成逻辑，但最终决定来自本已负责该资源的系统。

这也是该公告给构建自定义 RAG 技术栈的团队带来压力的原因。当大型云平台已能在检索过程中提供源系统验证时，他们必须说明为何复制的权限快照已足够。

它也促使企业买家提出更精确的问题。“产品是否支持 ACL？”已不再足够，因为索引 ACL 过滤和实时授权提供的是不同保障。

一项有用的评估应明确权限真相来源、检索期间传递的身份、检查时机、故障处理方式，以及可供审计人员查验的证据。

这一更广泛的经验同样适用于个人和团队知识系统。设计良好的 AI 知识库需要与所连接信息相匹配的边界，而非仅仅匹配呈现信息的界面。

两阶段机制以更复杂的流程换取更及时的决策

AWS 通过接受一条包含更多身份、API 和运营依赖的复杂检索路径，提升了权限的新鲜度。

第一阶段是为规模而设。Quick 会搜索向量索引，并在联系源平台之前应用已同步的 ACL 元数据。

这一步将实时调用限制在既具有语义相关性、又表面上可访问的文档上。如果没有这种缩减，每个问题都可能在更大范围的语料库中触发权限请求。

第二阶段是为正确性而设。Quick 会通过相关源 API 检查候选文档，并丢弃用户当前无法访问的候选内容。

这种混合模式类似于先进行粗筛，再作出权威决定。粗筛控制成本和延迟，最终决定则处理访问权被撤销以及权限复制不完善的问题。

模型只会接收通过实时检查的段落。该设计降低了未经授权的材料进入提示词、生成答案、引用或下游模型处理流程的可能性。

这一机制也阐明了在此语境中“实时”的含义。它并不意味着 Quick 会持续同步每一项权限，而是指系统在处理查询时验证被选中的文档。

这种方法可以比定时抓取更快地反映权限撤销。AWS 表示，变更会在短时间内体现在 AI 回答中，而无需等待数小时或数天的同步。

这一时效性是公司声明，并非经独立测量的服务级别保证。实际表现将取决于所连接的平台、令牌状态、API 可用性、连接器配置以及具体的知识库模式。

该架构带来了若干运营问题。源 API 可能限制请求频率、返回瞬态错误，或发生服务中断。委派令牌也可能过期或失去所需授权。

企业需要了解 Quick 如何处理每一种情况。安全的默认策略应是失败即拒绝（fail closed），即在权限不确定时排除文档，而不是允许访问。

失败即拒绝能够保护机密性，但在身份验证失败时，可能降低回答质量或导致无结果。用户可能将这种缺失理解为知识缺失，而非一项安全决策。

因此，可观测性至关重要。管理员需要记录，显示检查了哪个来源、使用了哪种身份、验证是否成功，以及文档为何被排除。

延迟同样值得关注。单次远程权限检查的成本可能不高，但一次回答可能依赖多个存储库中的多份文档。

并行验证可以缩短等待时间，但也可能增加对已连接 API 的突发流量。顺序验证可控制并发，但可能让助手显得响应缓慢。

缓存一次成功的实时决策可以提升性能，但缓存也会重新引入数据新鲜度窗口。AWS 的公开文章没有提供足够细节，无法评估每一项缓存、超时、重试或限流策略。

身份映射仍然是另一条棘手的边界。Amazon Quick 中的查询身份必须对应于 Google Workspace、Microsoft Entra 或其他来源所识别的身份。

配置正确时，服务账号模拟可以保留针对特定用户的决策。但它也引入了凭据、委派策略、审计轨迹和管理权限，安全团队必须对此进行审查。

源系统仍然比向量存储更重要，但集成层会成为安全敏感型基础设施。模拟或令牌处理上的错误，可能削弱实时检查的价值。

AWS 关于自定义 Bedrock 数据源的文档说明了一项重要限制。其自定义 ACL 文档指出，这类来源使用客户提供的 ACL 元数据，而非实时源验证。

同一份文档还作出了更明确的区分。ACL 感知过滤并非身份验证边界，因为 Bedrock 无法验证调用应用提供的身份上下文。

应用程序必须在上游对用户进行身份验证，并传递已验证的身份信息。企业不应将仅依靠元数据的过滤视为完整的授权机制。

对于自定义来源，应用程序会随每份文档提供允许和拒绝条目。Bedrock 会在检索前应用这些条目，且拒绝条目优先于允许条目。

然而，这些权限是否最新、是否准确，完全取决于客户的摄取流程。当自定义连接器自行定义 ACL 时，Bedrock 没有可供查询的权威源 API。

这一限制避免了对 AWS 公告作出过度宽泛的解读。实时验证是一项连接器特定能力，而非每种 Bedrock 知识库配置都具备的通用属性。

该架构仍然意义重大。它为受支持的存储库确立了更优目标，同时也明确指出，自定义实现需要承担更多责任。

实时检查并不会让 Bedrock 成为安全边界

这一新层缩小了一个暴露窗口，但企业仍需负责身份验证、配置、源系统治理、测试和事件检测。

AWS 将源端权威验证定位为对抗陈旧或错误映射 ACL 数据的保护措施。对于通过受支持源 API 成功评估的权限变更，这一说法是合理的。

但这并不意味着所有访问控制问题都会消失。系统只能执行源系统针对其所检查身份和资源返回的权限。

如果源系统本身授予的访问范围过宽，Quick 也会遵从这一宽泛授权。如果管理员将机密信息放入广泛共享的文件夹，实时验证不会自行推断出更严格的业务政策。

同样的问题也适用于继承权限。源端权威性提升了技术一致性，但无法判断一项继承授权是否恰当。

组织仍需要对共享存储库进行访问审查、最小权限策略、离职流程和所有权规则。RAG 可能更快暴露薄弱的源系统治理，因为它让分散的内容更容易被发现。

身份验证是另一项独立控制。Bedrock 的文档明确警告，ACL 感知过滤不会对终端用户进行身份验证。调用应用程序必须在提供用户上下文前先建立身份。

这一警告十分重要，因为针对不可信身份进行再可靠的权限检查，意义也有限。除非上游控制措施能够阻止，否则恶意或存在缺陷的应用程序可能传递其他用户的标识符。

企业应测试完整路径，从登录开始，到生成响应结束。测试应涵盖访问撤销、群组变更、继承权限、显式拒绝、令牌过期、API 故障以及知识库重建。

SharePoint 带来了一项值得注意的配置限制。AWS 表示，必须在创建知识库时启用 ACL 管理，之后无法更改。

遗漏该设置的团队必须创建另一个知识库。这一要求可能影响发布计划、重新索引、验收测试和变更管理。

所需的 Microsoft 权限同样需要仔细审查。由管理员管理的设置可能需要目录和群组读取权限，以及对选定或更广泛 SharePoint 站点的访问权限。

委派验证应用程序则请求单独的权限，用于读取文件和站点内容。安全团队应区分这两个应用程序，并了解哪些凭据用于摄取，哪些用于查询时检查。

自定义连接器需要另一套测试计划。错误的 ACL 字段大小写、缺失的列表或不匹配的用户邮箱，都可能让文档悄然无法被检索。

AWS 表示，这类检索失败会关闭访问，而不会报告授权错误。这种行为能够保护数据，但也让诊断变得复杂，因为用户可能只是得到更少的结果。

内容安全的范围超出权限本身。获授权文档可能包含旨在操纵模型的恶意指令，这种风险通常称为间接提示注入。

正确的 ACL 并不意味着文档安全。它只确认用户可以访问该文档。企业仍需要内容控制、模型防护、工具限制和监控。

AWS 在 ACL 架构之外还提到了 Bedrock Guardrails、事实依据检查和可配置的安全策略。这些控制措施应对的是不同风险，不应被视为授权的替代品。

该公司自己的 Generative AI Lens 曾警告，通过元数据重建复杂 ACL 会带来工程工作量和潜在权限缺口。该文档建议谨慎选择托管或自定义方法。

这一指导支持查询时检查的动机，也进一步说明需要审视实施细节，而不能接受“权限感知 RAG”之类的宽泛标签。

独立验证仍然有限。AWS 提供了架构、文档和客户案例，但没有公开基准比较泄露率、延迟、API 开销或故障行为。

Mondelēz International 是该公告中主要的客户信号。AWS 表示，该公司已在四个区域为超过 35,000 名员工部署 Amazon Quick。

Mondelēz 的 M365 创新高级专家 Jamahl Wiggins 表示，实时访问控制有助于满足安全和合规审查人员的要求。这一表述显示出企业需求，但不能替代独立安全评估。

采购方应从自身环境中索取证据。一项具有代表性的试点需要真实的群组结构、频繁的权限变更、敏感内容，以及受控的撤销信息检索尝试。

团队也应衡量误拒绝。一个因频繁丢弃已获授权内容而从不泄露信息的系统，仍可能无法作为知识产品发挥作用。

有用的验收指标包括授权准确性、检索完整性、额外延迟、令牌续期失败、限流率，以及因验证导致未获回答的问题占比。

因此，最有力的结论比营销信息更为有限。Amazon Quick RAG 访问控制为受支持的部署提供了更及时的授权决策，同时保留了周边安全系统的必要性和完整性。

三个信号将表明该设计能否在企业规模下成立

接下来的考验在于，源端权威验证能否在真实存储库和连接器类型中保持准确、可观测且响应迅速。

第一个信号是有文档记录的连接器覆盖范围。AWS 的公告将 SharePoint、Google Drive 和 Confluence 列为核心企业来源，而其详细示例主要聚焦于 Google Drive 和 SharePoint。

采购方应关注源系统特定文档，了解哪些连接器执行实时检查。文档还应区分由管理员管理、由用户管理和自定义的配置。

这一区分十分重要，因为名称相似的知识库可能具有不同的授权行为。一种 Google Drive 配置可能使用用户授权，而另一种则依赖服务账号和模拟。

如果 AWS 在更多连接器中发布一致的验证语义，建立通用企业安全模型的理由将更充分。如果覆盖范围依然有限，团队仍需运营不同保障等级的混合环境。

第二个信号是运营证据。企业需要延迟分布、限流行为、超时处理、重试规则、失败即拒绝语义，以及将每个回答关联到相应授权检查的日志。

实时验证在正常请求期间颇具说服力。它的可信度取决于 Microsoft Graph、Google Drive 或其他来源响应缓慢或完全无响应时会发生什么。

成熟的实现应在不暴露敏感文档名称的前提下，让这些故障可见。管理员应能够区分内容缺失、检索失败和授权拒绝。

AWS 可以通过记录审计事件和服务限制来增强信心。若客户案例包含测量到的行为，而不仅是治理审批，也会有所帮助。

Mondelēz 的部署提供了一个重要参考点，因为 AWS 报告称其覆盖四个区域、超过 35,000 名员工。未来若披露有关采用情况、可靠性和支持运营的细节，将使这一案例更具参考价值。

如果大型客户报告称系统在频繁权限变更下仍保持稳定性能，该架构将获得实际支持。如果他们需要大量豁免或频繁排障，其运营负担将更加明确。

第三个信号是竞争对手和内部平台团队如何回应。查询时授权可能成为企业 RAG 的标准采购要求，而不再是一项可选的安全功能。

供应商可能会提供类似的源端验证，通过原生企业搜索提供权限感知检索，或认为同步索引能够以更低延迟实现同等保障。

自定义 RAG 团队也面临同样的选择：增加源端调用、依赖精心同步的 ACL 元数据、将安全域隔离到独立索引中，或查询现有的权限感知搜索系统。

每条路径都有取舍。实时检查会增加依赖，复制的 ACL 存在时效性风险，独立索引会提升运维复杂度，而继承企业搜索则可能限制检索设计。

市场的反应将揭示：源端权威验证会成为基准能力，还是始终作为面向高度敏感存储库的高端架构。

对于企业采购方而言，眼下的行动很直接：询问每一家 RAG 供应商，最终的文档授权决策发生在哪里。

随后，撤销对某个敏感文件的访问权限，并在下一次计划同步之前查询其内容。通过直接提问、摘要、引用和后续提示，重复进行这一测试。

当访问失败时，审查日志。确认系统是否联系了权威源、它呈现的是哪种身份，以及文档是否曾进入模型上下文。

Amazon Quick RAG 的访问控制通过将最终检查移至更接近源端、也更接近查询发生时间的位置，提高了标准。这一设计值得关注，因为它解决了一个具体的暴露窗口。

其长期价值将取决于连接器覆盖范围、透明的失败行为，以及在真实企业负载下可量化的性能表现。你当前的 RAG 系统能否同样以证据而非保证，回答这些授权问题？