多租户 Prompt Cache 的权限隔离检查方法

Prompt Cache 可以复用重复输入前缀，但“前缀相同”与“用户有权读取”是两件事。若应用为了提高命中率，把不同租户的私有文档拼进公共前缀，或在权限撤销后继续沿用旧会话，上游缓存是否隔离都不能修复应用已经发送了错误数据。本文只解决多租户权限边界：先在应用层完成授权和资料筛选，再按租户、权限、内容、提示词、工具与模型版本构造请求；最后用跨租户负向测试、权限撤销和版本更新场景验证不会复用不应出现的上下文。

1. 缓存不负责业务授权

Claude Prompt Caching 官方文档 描述的是重复前缀的处理方式，不是应用的租户权限模型。应用在请求模型前仍需决定：

当前主体属于哪个租户。
主体拥有哪些角色和资料范围。
哪些文档允许进入本次请求。
文档版本是否仍然有效。
输出是否允许返回给当前渠道。

授权失败时应在模型调用前停止。不能先把全部资料发给模型，再依赖提示词要求它“不要泄露”。

2. 公共前缀与私有前缀要分开

可以考虑作为公共上下文的内容包括：

对所有租户公开的产品说明。
不含私有数据的工具定义。
统一的输出格式与安全规则。

需要按权限单独构造的内容包括：

用户上传文件。
客户合同、订单和工单。
内部人事、财务与经营资料。
角色限定的知识库。
包含个人信息的会话历史。

“同一模板”不等于“同一前缀”。模板里一旦插入租户私有资料，请求就必须按照该主体的授权结果重新构造。

3. 请求上下文需要哪些版本维度

应用日志和请求构造可以关联这些维度：

tenant_id
subject_id 或不可逆主体标识
permission_scope
knowledge_version
prompt_version
tool_version
model_id

这些字段用于判断两次请求是否属于同一授权和内容版本。字段命名不是标准协议，可以按系统现有数据模型调整；关键是权限或内容变化时，旧上下文不能继续当作当前有效资料。

不要把随机请求标识和当前时间放进需要稳定复用的前缀。它们适合放在业务日志中；若运行时确实需要发送，应按当前 API 结构放到不破坏稳定语义的位置。

4. 正确的请求构造顺序

一次请求可以按以下顺序处理：

验证主体身份。
        ↓
计算本次 permission_scope。
        ↓
查询该范围允许的文档版本。
        ↓
只读取和脱敏允许内容。
        ↓
构造公共规则与私有资料前缀。
        ↓
追加本轮问题。
        ↓
调用模型并记录上下文版本。

每一步失败都应停止或缩小范围。检索不到资料时应返回“无可用依据”，而不是扩大到其他租户或旧版本。

5. 权限撤销和文档更新如何处理

权限撤销后，新的请求不能继续携带已撤销资料。应用需要使相关会话、检索结果和任务队列失效，并阻止后台重试沿用旧上下文。

文档更新后应产生新的受控版本。旧版本是否保留取决于业务审计需求，但它不能自动进入要求“当前制度”的请求。缓存命中率下降是内容变化的正常结果，不应为了复用而继续发送过期资料。

6. 日志记录边界

为排查权限与缓存问题，可以记录：

请求和租户关联标识。
权限范围与内容版本。
模型、提示词和工具版本。
缓存创建与读取 usage。
授权、检索和模型调用结果。

不要默认记录完整提示词、私有文档或模型输出。可使用受控版本号、长度、内容哈希和脱敏摘要定位问题，并按现有日志访问策略限制人员和保留周期。

哈希只能帮助识别内容是否变化，不能证明内容获得授权；权限判断仍然来自业务系统。

7. 负向测试矩阵

多租户测试不能只验证“正确用户能看到资料”，还要验证错误路径：

测试记录应包含进入模型前的资料清单或受控标识，这比只看最终回答更容易发现越权输入。

8. 缓存验收与权限验收分开

缓存验收回答“前缀是否被创建或读取”，权限验收回答“这个前缀是否允许进入请求”。两者都通过才可继续：

权限测试：当前主体只能构造允许的上下文。
缓存测试：相同授权和内容版本下，usage 符合预期。
内容测试：回答只依据允许资料，未知时不猜。

缓存未命中通常影响效率；权限未通过则是数据边界错误，必须先阻断。

9. 结论与限制

多租户 Prompt Cache 的安全前提是应用先完成身份、权限和内容版本判断。公共规则可以复用，私有资料必须在当前授权范围内构造；权限撤销、文档更新和后台重试都要重新检查，不能依赖旧会话或缓存状态。

本文不描述任何厂商的底层租户隔离实现，也不提供价格、命中率或性能结论。实际系统还需结合身份服务、检索层、任务队列和日志策略做威胁建模；只有在进入模型前检查请求资料，并通过跨租户负向测试，才能验证应用侧边界。