引用指向一份合同，但它属于另一位客户。这个示例里，支持助手在两位客户的文件夹中搜索续约日期，找到另一位客户的一份相似合同，将其放进上下文，再流畅地回答。
这不是已报告事件。引用让答案看起来谨慎，却泄露了错误客户的数据。缺陷在模型写出句子前就已经发生。
一段关于 AI 知识放在哪里的已收录讨论提出有用的架构观点：因用户而异的知识需要控制访问的检索层。Microsoft 的文档级访问指南介绍与索引文档和查询时身份绑定的权限检查。一般原则比任何单一搜索产品更简单：只有获准材料能进入回答路径。
把边界放在答案之前
提示可以让助手简洁、引用来源、必要时请求澄清。但在给模型错误客户文档的同时，只说“记得别用它们”并不安全。检索已经跨越边界，再让提示挽回访问失败，是本末倒置。
应用必须建立调用者身份。搜索查询要携带相应范围：按业务需要绑定租户、角色、账户或文档权限。在文本交给模型前，对候选结果过滤或授权。如果答案还可能触发写入，写入路径要针对目标记录重新核查授权。
- 调用者身份
在应用中验证
- 限定范围的检索 租户 · 角色 · 文档
进入模型上下文前过滤
- 有依据的回答
引用许可的证据
- 写入授权
重新检查目标记录
这不只是向量搜索问题。关键词搜索、缓存摘要、对话记忆和工具结果，都可能携带私密内容。来自某租户文档的摘要，即使文字缩短，仍然私密。
连接业务工具的指南询问每条记录的负责人和权威系统。对助手，还要加一个问题：谁有权知道这条记录存在？
一个小例子揭示顺序
假设示例索引有四份文档：两篇公开帮助文章、租户 A 的合同、租户 B 的合同。来自 A 的用户问账单条款。语义最接近的结果恰好是 B 的合同。
没有范围的检索会返回它。后来指示“只回答租户 A”，无法保证安全，因为内容已进入模型上下文。限定范围的检索在排序前移除 B 的文档，或只返回获准候选。助手于是可以根据 A 的合同回答，或承认缺少所需来源。
具体实现取决于平台。Azure AI Search 的安全过滤模式给文档附加组标识符，在每次查询使用过滤器。文档也提醒，把权限字段藏在响应之外，本身并非访问控制。可强制的部分是过滤器及其背后的调用者身份。
权限变化时，这个区别尤其重要。员工失去访问权后，旧缓存或过时索引不能继续提供文档。团队需要定义更新路径、测试撤销权限，而不只测试初次授予。如果检索服务无法遵守来源的访问模型，把来源复制到该索引的架构可能就不对。
权限与相关性是两项不同测试
获准文档可能无关或过时；准确答案也可能未经授权。失败模式不同，就分别评估。
先测试边界：一个租户的调用者能检索、引用或推断另一租户的私密内容吗？要包括直接提问、改写和摘要。再在许可集合内测试答案质量：助手是否选择当前政策，并在没有证据时承认？Microsoft 的 RAG 指南明确建议在检索时执行访问控制，并把检索内容视为不可信。
这里有成本。考虑权限的索引需要元数据、身份映射与权限撤销处理。过滤后某些结果会变空。如果调用者没有证据访问权，空结果就是正确结果。自信地猜测填补空白，会把访问保护变成准确性问题。
这个边界还可检验更广泛的自动化异常原则：获准搜索集合为空时怎么办？好的设计可以回答“我无法访问回答此问题所需的来源”，并提供正确的升级路径。它不应搜索更广的租户、重复旧答案，或从文档标题推断私密细节。把空结果当作工作流的正常、可测试状态。权限是正确性的一部分，不是上线后再打补丁的特殊情况。
有用的助手不是知道公司所有事情的助手，而是在调用者权限内找到正确证据，并在边界使问题无法回答时直说的助手。
常见问题
提示能让助手不泄露私密记录吗？
提示可以描述行为，却不能代替授权。检索只应访问调用者有权看的文档，有后果的动作前还要再次强制权限。
租户权限应在检索系统的哪里应用？
把已验证的调用者绑定到查询，在候选文档内容进入模型上下文前过滤或授权。访问变化时保持权限元数据准确。
有引用就能信任答案吗？
不能。引用只说明答案来自哪里，无法证明调用者有权看来源，也不能证明底层数据是当前且正确的。