文件在原应用里已经打不开，并不代表 AI 助手立即失去了利用它的能力。如果检索索引仍承认昨天的群组成员资格，用户的问题就可能把该文件带入模型上下文。用户甚至不必知道文件存在：摘要或比较便可能披露其中一部分内容。
Amazon Quick 在2026年10月7日公布的方案，针对的正是这个时间差。它在生成答案前向来源核验候选文档，将索引中的访问控制列表（ACL）与第二次实时判断结合起来。变化在于谁最终决定文档能否进入模型，而不是让所有 Bedrock 知识库都具备实时验证，更不等于用检索过滤代替用户身份认证。
从搜索到模型之间设置两道关口
常见的数据接入流程会把文档及其权限复制到搜索索引。查询时，系统依据语义相关性和已存储的 ACL 元数据返回片段。这很高效，但权限快照反映的是上一次成功同步时的状态，而未必是源系统此刻的状态。
Quick 保留了快速的第一阶段：搜索相关片段，依据索引 ACL 过滤，再通过来源 API 验证缩小后的候选集。即使索引仍显示用户有权访问，未通过实时核验的文档也会被剔除。只有同时通过两道关口的片段才能进入语言模型上下文。
这里的“实时”是查询期间验证选中文档，并不是持续同步整个资料库的每一项权限。减少候选数量能够控制远程请求和延迟。初始索引仍决定哪些文档有机会成为候选，因此最后一次实时校验本身并不能补救所有检索遗漏。
AWS 的 Google Drive 示例使用管理员提供的服务账号凭据，通过用户模拟取得对应用户的访问令牌，仍由 Drive 判断候选文档当前是否允许访问。因此，Quick 身份必须正确对应 Google Workspace 识别的用户；委托凭据、令牌处理与管理员权限都成为检索链路中的敏感环节。
SharePoint 使用另一套身份流程。对于启用 ACL 的知识库，当受保护内容与问题相关时，Quick 会要求用户登录，再通过委托访问验证候选文档。AWS 将其描述为通常只需完成一次的登录，关联的刷新令牌约可维持90天；这不表示所有访问令牌都能使用90天。
委托权限范围涉及读取站点项目和文件、用户基本资料及维持已授权访问。管理员管理的接入应用则可能另外要求读取目录和群组，以及访问选定或更广泛的 SharePoint 站点。这是两种应用、两类职责，不能将接入授权与查询期间的用户委托验证混为一谈。
SharePoint 还有重要的配置约束：必须在创建知识库时启用 ACL 管理，之后无法更改。若创建时遗漏，就要另建知识库，从而影响重新索引、上线安排和验收测试。
复制来的权限为何可能不够
企业权限不是一张简单的平面名单。SharePoint 结合站点、群组、继承和例外；Drive 涉及个人文件、共享云端硬盘、直接分享、群组和全组织设置；Confluence 还有空间、页面限制与继承访问。将这些规则翻译成同一个索引，既有映射风险，也有时效风险。
员工若在一次抓取刚结束后被移出机密战略群组，复制的元数据可能继续承认其权限，直到下一次同步成功。事件驱动更新能缩短部分空窗，却无法响应根本收不到的事件。AWS 特别指出，某些 Confluence 群组成员变更不一定产生可用事件；新的分享方式也可能领先于连接器的解释能力。
RAG 会跨资料库组合片段，因此这种偏差的后果更加明显。公开项目进展可能与受限预算或人事决策一起被综合进答案。事后过滤不是有效替代，因为模型已经收到信息。引用、后续问题、导出和代理触发的操作，都需要同样的生成前边界。
由源系统实时决定权限，能够降低索引必须完整复现每条规则的负担，但修复不了来源本身过宽的授权。机密文件放进广泛共享的文件夹，仍会通过实际访问策略。最小权限、资料库归属、访问审查和离职权限回收依然必要。
获准访问的文档也不等于可信内容。它可能包含操纵助手的恶意指令。Bedrock Guardrails、事实依据检查、安全策略与工具限制处理的是不同风险；它们不会自动理解企业的文档权限，而正确 ACL 也不会消除间接提示注入。
连接器覆盖不能由产品标签推断
Quick 文档列出 S3、Confluence、Google Drive、OneDrive、SharePoint 和需认证网页内容等集成，并使用不同的 OAuth 与服务账号模式。存在集成，不代表每一种连接器及其配置都进行相同的实时检查。公告重点提到 SharePoint、Drive 和 Confluence，详细流程则主要解释 Drive 与 SharePoint。
因此，管理员管理、用户管理和自定义配置必须分别看待。仅凭来源名称受支持，无法确定采用哪种身份、检查依据是实时来源还是索引，以及错误如何影响检索。
Bedrock 自定义数据源文档明确体现了这种差别。这类来源使用客户提供的 ACL 元数据，而非实时来源验证。应用为文档附加允许和拒绝条目，过滤发生在检索之前，拒绝优先于允许。其准确性和时效取决于客户的接入流程；若权限本身由自定义连接器定义，Bedrock 可能没有可查询的权威来源 API。
文档也警告，支持 ACL 的过滤不是身份认证边界。Bedrock 无法验证调用应用提交的身份上下文，应用必须先完成用户认证，再传递经过验证的身份信息。即使权限查询本身可靠，针对伪造或错误用户标识做出的判断仍可能不安全。
自定义来源的失败还可能表现为“缺少知识”，而不是安全错误。ACL 字段大小写错误、名单缺失或用户邮箱不匹配，都可能使文档静默退出检索。AWS 描述这些情况下会采用拒绝访问的处理方式，而不抛出授权异常。不能把这一明确的局部行为，扩大为所有连接器面对所有故障都具有同样保证。
权限更及时，也引入运行依赖
AWS 表示，来源验证可在很短时间内反映权限撤回，不必等待数小时乃至数天的同步。这是公司说法，不是独立测得的服务等级保证。实际效果取决于源平台、令牌状态、API 可用性、连接器配置和知识库模式。
远程 API 可能限流、暂时失败或不可用；用户同意可能撤回，令牌也可能过期。权限无法确认时排除文档是安全的默认选择，但有权用户可能因此得到不完整答案。若系统靠频繁遗漏合法证据来避免泄露，它仍可能不是合格的知识产品。
额外调用也带来性能权衡。并行检查缩短等待，却会增加请求突发；串行检查控制并发，却增加延迟。缓存成功的判断可以加速，同时重新引入时效窗口。公开材料没有交代所有缓存、超时、重试和限流策略，也没有提供泄露率、延迟、API 开销或故障场景的对照基准。
运行证据应将答案与来源检查对应起来：提交了哪个身份、验证结果如何、为何排除文档，同时避免在诊断信息里暴露敏感文档名称。区分内容不存在、检索失败和访问被拒，对事故响应与日常支持都很重要。
AWS 给出了客户信号，而非独立安全测试。公司称 Mondelēz International 已为四个地区超过35,000名员工部署 Quick。其 M365 创新高级专员 Jamahl Wiggins 表示，实时访问控制有助于满足安全及合规审查要求。这说明存在需求且获得组织认可，并不能证明所有情况下的防泄露效果和性能。
AWS 的 Generative AI Lens 早已提醒，通过元数据重建复杂 ACL 会增加工程工作并可能产生权限缺口。查询时验证解决了其中一部分，自定义实现仍承担更多责任。个人和团队 AI 知识库也有相似问题：使用同一个界面，不会消除所连接信息原有的边界。
决策位置变了，责任并未消失
具有代表性的部署，需要检验从登录到答案的完整路径：撤回访问、群组和继承变化、明确拒绝、令牌过期、API 故障以及知识库重建。授权准确率之外，还要观察检索完整性、额外延迟、续期失败、限流，以及验证导致无法回答的问题。
替代方案包括精心同步的 ACL、按安全域分离索引、原生支持权限的企业搜索，或者额外调用来源。它们对时效、运行复杂度、检索灵活性和外部依赖的取舍不同。查询时授权有可能成为采购基线，但这次公告并不能证明它已经如此。
Quick 的贡献是一个具体的架构改进：在受支持且配置正确的环境中，文本进入模型前，源系统可以作出最后一次权限判断。其实际强度取决于连接器的明确保证和可观察的故障行为，而不是把“支持 ACL”当成完整安全体系。
来源与相关阅读
AWS 公告；公告规范地址；SharePoint ACL 配置；Quick 数据访问集成；个人与团队知识库相关阅读；Bedrock 自定义来源 ACL；AWS Generative AI Lens。