权限应属于上下文组装阶段
内容提要
文章讨论企业AI检索中的权限控制问题。核心观点是：权限不应作为事后过滤器，而应在“上下文组装”阶段结构性执行，即根据用户身份决定模型能看到哪些数据。文章以AWS、微软等平台为例，指出仅靠元数据过滤存在泄露风险，并强调需在系统间传递用户身份，确保授权在每一步被检查。
延伸解读
权限检查的时机决定成败
文章强调，权限控制的关键在于检查时机。在检索后过滤已获取的文档，不如在上下文组装阶段就根据用户身份决定包含哪些内容。因为一旦文档被模型读取，泄露就已发生。因此，权限控制应前置到数据组装环节，而非事后补救。
平台差异：可用性与架构理念
AWS和微软虽在同一天宣布类似的身份感知检索方案，但微软的Work IQ API已正式可用，而AWS Context仍处于“即将推出”状态。这提醒企业，在评估供应商时，不仅要看架构理念，更要关注产品的实际可用性和部署条件，避免因等待而延误安全建设。
跨系统权限的边界与挑战
文章指出，单一系统的权限控制（如Lake Formation）无法覆盖Salesforce、Slack等其他系统。当AI代理需要跨系统获取数据时，必须依赖各系统自身的授权机制。因此，企业需明确权限控制的边界，并确保在系统间传递用户身份，以实现端到端的授权检查。
权限图正确性：必要非充分条件
即使实现了身份感知的上下文组装，如果底层权限图本身存在错误或过时，检索系统仍会忠实执行错误的权限。因此，企业需定期审查和更新权限配置，确保权限图的准确性。组装环节是最后一道防线，但并非权限管理的全部。
Q&A
为什么权限不应该作为事后过滤器，而应在上下文组装阶段执行？
因为上下文组装是拒绝包含某些内容仍意味着模型从未看到它的最后时刻。如果权限作为事后过滤器，在文档已被获取、水合、重排或缓存后执行，授权就是在追赶问题而不是预防问题，可能导致敏感信息泄露。
什么是上下文组装（context assembly）？
上下文组装是系统决定为特定身份、在特定时刻、针对特定问题，将哪些企业知识片段交给模型的过程。它位于存储和推理之间，是身份信息得以体现的关键环节。
AWS和微软在身份感知检索方面有哪些进展和差异？
微软于6月16日发布了Work IQ API，它运行在已登录用户的上下文中，遵循Microsoft 365权限，可立即使用。AWS于6月17日宣布了AWS Context，设计上继承调用用户的IAM和Lake Formation权限，但截至文章发布仍处于“即将推出”状态，没有GA日期、区域列表或定价。
为什么仅靠元数据过滤存在泄露风险？
因为元数据过滤是应用层执行，不是身份边界。AWS明确指出，bedrock:Retrieve API不将元数据过滤内容作为IAM条件键暴露。标签只是提示，应用程序代码被信任去执行，但一旦代码有漏洞或被提示注入，整个数据集可能暴露。
在检索系统中，如何正确使用过滤器以避免权限泄露？
正确的做法是：检索系统可以搜索混合索引，检索不透明的ID，然后进行授权，只水合用户有权读取的文档。这样，未经授权的信息从未离开检索边界。而错误的做法是在文档已被获取后再检查权限，这会导致授权滞后。
为什么说上下文组装是必要的但不是充分的？
因为上下文组装继承了权限图的实际状态。如果权限图本身错误、过时或过于宽泛，检索系统会忠实地执行错误的权限。组装不是让权限正确，而是正确权限仍然重要的最后地方，因为之后模型已经读取了文档。
OWASP Top 10 for LLM Applications 2025修订版对权限问题有何建议？
OWASP将敏感信息泄露从第六位提升到第二位，并新增了LLM08“向量和嵌入弱点”，该条目指出了共享向量数据库的用户之间上下文泄露的风险，并推荐使用权限感知的存储作为修复方案。
微软Copilot在企业部署中遇到了哪些权限问题？
根据2024年Gartner对132名IT领导者的调查，由于过度共享，40%的人将Microsoft 365 Copilot的部署推迟了3个月或更长时间。Copilot本身会检查用户权限并裁剪结果，但问题在于权限图本身可能过宽，导致本应私密的数据被检索到。
