KeyPooling: gateways de relay de API de LLM vazam cache de prompt entre clientes diferentes

Pesquisadores (Bowen Sun, Yixi Cai, Xiaogeng Liu, Zhengyue Zhao, Yinzhi Cao, Chaowei Xiao) estudam 'relays' de API de LLM, serviços que autenticam seus próprios clientes de forma individual mas encaminham as requisições upstream para OpenAI ou Anthropic usando um conjunto menor de credenciais de provedor compartilhadas, já que os provedores escopam seu cache de prompt, uma otimização de latência e custo que reaproveita computação para prefixos de prompt repetidos, à credencial ou namespace upstream, não aos clientes finais do relay.

Tecnicamente, os autores desenvolvem o KeyPooling, uma metodologia de medição que rastreia a qual identidade uma leitura ou escrita de cache é de fato atribuída, verifica quais transformações o gateway aplica às requisições em trânsito, e isola qual componente específico, credencial, pool, adaptador ou salto de relay aninhado, determina a identidade final do cache, testando um componente hipotético de cada vez. Aplicado a cinco implementações de gateway open source conectadas a OpenAI e Anthropic, os autores descobrem que nenhuma das cinco vincula seus clientes finais a credenciais upstream distintas por padrão, e que, sob uma credencial upstream compartilhada, todas as cinco expõem leituras de cache de prompt entre clientes diferentes, para ambos os provedores, ou seja, um cliente de um relay pode, em princípio, observar o estado de cache, e inferir conteúdo de prompt, pertencente a outro cliente do mesmo relay.

Os resultados demonstram impacto real, não apenas teórico: em uma medição semanal independente do resultado, no OpenRouter (um grande relay público de LLM), cobrindo 80,5% do volume elegível de tokens, os autores encontraram leituras de cache entre contas em 12 de 28 rotas testadas, representando 33,7% do volume medido; em uma rota de produção, usaram um procedimento controlado para recuperar oito posições consecutivas de tokens de um prompt em cache de outro cliente, sem qualquer acesso direto a esse cliente-alvo, uma exploração concreta de recuperação de tokens, não apenas um vazamento hipotético.

Relays e gateways de LLM, agregadores como o OpenRouter e inúmeros wrappers menores de SaaS, são amplamente usados justamente porque simplificam faturamento e roteamento entre múltiplos provedores de modelo, mas o trabalho mostra que uma otimização central do lado do provedor, o escopo de cache de prompt, quebra silenciosamente o isolamento de inquilinos que o relay deveria garantir assim que múltiplos clientes compartilham credenciais upstream, um vazamento de dados real e demonstrado, não hipotético, dado o resgate de oito tokens em uma rota de produção ao vivo. A correção proposta pelos autores, todo cliente deve entrar em um domínio isolado imposto pelo provedor, ou um namespace derivado de identidade autenticada deve sobreviver a toda leitura e escrita de cache final, tem custo relativamente baixo (aumento de 1,7% a 2,5%), mas depende de ação dos operadores do relay, o que significa que qualquer organização roteando prompts sensíveis por um gateway de LLM de terceiros hoje deveria tratar isso como uma classe de vulnerabilidade ativa e não corrigida por padrão, até verificar o comportamento de isolamento específico do seu provedor.