本文研究了LLM API中继(relay)中的提示缓存隔离问题。LLM API中继服务为每个客户进行身份验证,但通常通过共享的上游提供商(如OpenAI和Anthropic)凭证转发请求。提供商将提示缓存限定于上游主体和命名空间,因此当多个中继客户端被映射到同一个缓存身份时,他们能够观察到彼此的缓存状态。先前的研究已经发现某些端点存在缓存共享,但没有系统性地确定究竟是什么因素(如凭证、池、适配器或嵌套跳)最终控制了缓存身份。作者提出了称为KeyPooling的测量方法,通过跟踪缓存查找和写入路径,验证运行时转换,并逐个测试预测的身份组件。在连接OpenAI和Anthropic的五个开源网关中,默认情况下没有任何一个将客户绑定到唯一的上游凭证;在共享凭证下,所有五个网关都暴露了跨客户的缓存读取。通过主体和命名空间分割、池关联、适配器和嵌套中继的对比,作者定位了控制身份转换的关键点。进一步地,在与结果无关的每周OpenRouter测试框架中,测试覆盖了80.5%的合格令牌量,发现28个标签中有12个存在跨账户读取,占33.7%的流量。在一个生产路由上,受控过程在没有目标账户访问的情况下成功恢复了连续八个目标位置。更广泛的测试表明,缓存粒度、路由、速率限制、归属和预算等功能都只是实现逐令牌恢复的条件,而不是安全控制。基于这些发现,作者提出了防御契约:每个客户必须进入提供者强制执行的独立域,或者必须确保从经过验证的身份派生的命名空间能够存活于每一次最终缓存查找和写入。通过将命名空间分割放置在可重用的公共前缀之后,可以在1.7-2.5%的成本增加下保留大部分模型重用收益。该研究指出了LLM API中继缓存隔离的实际缺陷,为网关设计和多租户隔离提供了重要参考。
💡 推荐理由: LLM API中继的缓存隔离缺陷可能造成跨客户信息泄露,影响使用共享上游凭证的多租户环境。该研究揭示了实际网关的普遍风险,提醒安全团队关注缓存侧信道和身份隔离完整性。
🎯 建议动作: 研究跟进,评估自身LLM网关配置是否受此影响。