Três Relatórios, Uma Camada: o Risco de IA na Pilha de Serviço

155 respostas. Esse é o número que a Cloudflare informa como afetado quando um bug de KV cache na sua pilha de serviço expôs dados entre requisições, um vazamento que a equipe de segurança reproduziu com duas contas independentes. A causa estava no cache e no motor de inferência ao redor do modelo.

Entre 20 e 26 de outubro de 2026, três empresas publicaram relatórios sobre os próprios sistemas. A Ubicloud saiu primeiro, em 20 de outubro, com uma medição da precisão de chamadas de ferramenta no vLLM. A Railway veio em 22 de outubro, com um relatório preliminar sobre um incidente de segurança. A Cloudflare publicou em 26 de outubro um postmortem sobre exposição de KV cache entre requisições no modelo GLM-5.3 do Workers AI. Cada relatório foi escrito pela empresa cujo sistema falhou ou foi medido.

Lidos em conjunto, os três descrevem uma camada: o software entre o modelo e o cliente. O cache que guarda o contexto. As configurações do motor que moldam a saída. O cofre que guarda as chaves. Nossa leitura é que revisões de risco de IA de terceiros precisam de perguntas para cada uma dessas peças, e os próprios relatórios fornecem as perguntas.

O Motor de Inferência É uma Fronteira Entre Clientes

O postmortem da Cloudflare aponta duas causas agindo juntas. A primeira foi uma janela de contexto maior que o pool de KV cache. A segunda foi um bug no SGLang, o motor de serviço de código aberto, operando no modo desagregado de prefill/decode. Nas palavras da Cloudflare: “In total, 155 responses were affected, all to prompts longer than 681,280 tokens.” O modelo anunciava uma janela de contexto de 1.048.576 tokens, então a falha começava bem abaixo do limite anunciado.

O detalhe que deveria mudar a forma como compradores avaliam fornecedores está na seção de testes. A Cloudflare escreve que validava apenas os códigos de resposta HTTP e o desempenho do motor em contextos longos, sem validar a saída do modelo e sua coerência. Uma requisição que deveria ter sido rejeitada foi aceita: o cliente recebeu HTTP 200 em vez de HTTP 400.

Essa frase descreve uma suíte de testes que conferiu o envelope e nunca abriu a carta. Os códigos de status estavam corretos pela definição da suíte. O conteúdo da resposta, que é a única coisa que importa ao cliente, ficou sem verificação justamente nos comprimentos de contexto em que o bug vivia.

A resposta da Cloudflare merece crédito. O modelo saiu do ar em até 40 minutos após a declaração do incidente. A empresa afirma ter confirmado que nenhum outro modelo hospedado no Workers AI foi afetado. Também relata não ter encontrado evidência de exploração deliberada, e delimita essa conclusão com cuidado: o horário e o volume das requisições afetadas eram compatíveis com uso comum de contexto longo. O relatório registra ainda que o bug no SGLang havia sido reportado publicamente como issue #30233 em 6 de julho de 2026.

Esse último fato importa para quem roda motores de inferência de código aberto. O defeito tinha um número de issue público no projeto original. Se um operador acompanha as issues do projeto contra a versão e o modo do motor que roda em produção é uma pergunta que uma avaliação de fornecedor pode fazer diretamente.

Já escrevemos sobre isolamento de tenant em bancos de memória de agentes. O relatório da Cloudflare leva a mesma preocupação uma camada abaixo. Quando um motor de serviço compartilha cache entre requisições, o cache é onde os clientes se encontram. O isolamento nessa camada precisa ser provado na saída, porque um código de status correto não diz nada sobre de quem são os dados dentro da resposta.

Padrões do Motor São Mudança de Qualidade Sem Aprovação

O post da Ubicloud envolve menos em jogo e ensina tanto quanto. Servindo o Kimi K2.6 com vLLM, a Ubicloud viu o modelo produzir o schema esperado de chamada de ferramenta apenas 92% das vezes. Com decodificação restrita ligada, a precisão chegou a 100% nos modelos mais novos da Kimi e da DeepSeek no benchmark K2VV ToolCall.

Esses 100% precisam vir com o escopo junto. O número vem de um único benchmark conduzido por fornecedor e cobre modelos da Kimi e da DeepSeek. A página da Ubicloud relata que outros modelos tiveram problemas com o recurso ativado. A página também cita versões específicas do vLLM para o recurso e para a flag que o controla.

Uma medição posterior caiu. Quando um padrão do vLLM mudou no projeto original para requisições que não ligam a decodificação restrita, a precisão voltou a cair para 91%. Os 92% e os 91% são medições separadas, feitas em momentos distintos, e o post as apresenta assim. O que as liga é o mecanismo: a configuração do motor de serviço, definida no projeto original, decidiu se as chamadas de ferramenta chegavam num formato utilizável.

Para um time que constrói agentes, uma chamada de ferramenta com schema errado é um passo quebrado. A 91% ou 92%, cerca de oito ou nove chamadas em cada cem chegam no formato errado. Imagine, como hipótese, um time vendo a taxa de falha do agente subir: os suspeitos óbvios são os prompts, o modelo e o próprio código. A causa, no relato da Ubicloud, estava num padrão do motor definido no projeto original.

Já mostramos uma flag de implantação quebrando chamadas de ferramenta com pesos idênticos. A medição da Ubicloud acrescenta um segundo caminho: um padrão do motor mudou no projeto original, e a precisão das chamadas de ferramenta caiu no mesmo modelo sem que o operador ativasse uma flag nova. Se a sua gestão de mudanças cobre versões de modelo e ignora versões de motor, ela cobre metade do que determina o comportamento.

A Chave de IA É o Ativo

O relatório da Railway é preliminar, e a linguagem é cautelosa do começo ao fim. Leia com esse peso. A empresa afirma que no máximo 1,85% de todos os workspaces tiveram algumas variáveis de ambiente potencialmente comprometidas, o que representa, em números, cerca de 100.000 workspaces. Cada qualificador dessa frase tem função: no máximo, algumas, potencialmente.

Sobre o motivo, a Railway oferece apenas evidência inicial. O atacante provavelmente procurava chaves de API de IA e de plataformas, para destilar pesos de modelos. Essa é a hipótese de trabalho da empresa, apresentada como tal, e um relatório final pode revisá-la.

A consequência comercial vem dita sem rodeios: a Railway não consegue reembolsar clientes por gastos feitos com chaves de API comprometidas.

Coloque a hipótese e a política de reembolso lado a lado. Se a hipótese se confirmar, o ativo que o atacante buscava era a própria chave de IA, e o cliente arca com o custo do gasto que a chave roubada gerou. Onde os clientes guardavam chaves de IA nessas variáveis de ambiente, a política de reembolso deixa a conta com o dono da chave. Nenhum desses fatos diz respeito a um modelo. Os dois dizem respeito a onde as credenciais ficam e a quem paga quando elas vazam.

Já escrevemos sobre manter credenciais fora do contexto do agente. O incidente da Railway aponta para a etapa anterior: credenciais guardadas nas variáveis de ambiente de uma plataforma de hospedagem, legíveis por quem alcançar esse armazenamento. Uma chave de IA sem limite de gasto, guardada ao lado de todos os outros segredos de um workspace, é um passivo cujo tamanho é definido pelo teto de cobrança do provedor.

O Que os Três Relatórios Têm em Comum

Nos três relatórios, a causa ou a correção está na camada ao redor do modelo. O vazamento da Cloudflare veio de um cache e de um bug no motor. As mudanças de precisão da Ubicloud vieram da configuração do motor. Na Railway, o atacante chegou às variáveis de ambiente dos clientes depois de entrar na infraestrutura de build e no CI, segundo a linha do tempo preliminar. O modelo estava no centro de cada história, e o risco estava em volta dele.

Os relatórios também compartilham uma qualidade que merece registro. Cada empresa publicou a própria falha ou a própria medição, com números. A Cloudflare deu a contagem de respostas e o limite de tokens. A Ubicloud deu os percentuais e as versões. A Railway deu um teto e declarou a própria incerteza. Esse é o material que uma revisão de risco deveria pedir a todo fornecedor de IA.

Perguntas sobre dados de treinamento, viés, segurança da saída e retenção de dados continuam importando. Elas não alcançam o cache, o motor ou o cofre de chaves, que é onde esses três relatórios encontraram seus problemas.

Acrescente Três Perguntas à Sua Avaliação de Fornecedores Esta Semana

Pegue o questionário de fornecedores de IA que seu time usa hoje e acrescente estas três perguntas. Faça-as a todo provedor que serve modelos para você, inclusive aos que você considera de baixo risco.

Como o isolamento é testado na saída? Pergunte se os testes do fornecedor validam o conteúdo da resposta nos comprimentos de contexto anunciados, ou apenas códigos de status e latência. Peça o maior comprimento de contexto em que a coerência da saída foi verificada. Se a resposta for o máximo anunciado, pergunte como. O relatório da Cloudflare mostra quanto a distância entre esses dois números pode custar.

Como as versões do motor são fixadas e verificadas? Pergunte qual motor de inferência e qual versão servem o seu tráfego, como mudanças de padrão no projeto original são revisadas antes de entrar em produção e se o fornecedor acompanha issues públicas do projeto contra o modo que roda. Pergunte se a precisão do schema de chamadas de ferramenta é medida a cada atualização do motor. A Ubicloud mediu a precisão de schema do Kimi K2.6 em 92%, depois 91% após a mudança de um padrão no projeto original, e chegou a 100% só com a decodificação restrita ligada, num único benchmark.

Onde ficam as chaves de IA, e quem paga quando elas vazam? Pergunte se as chaves dos seus provedores de IA ficam em variáveis de ambiente comuns numa plataforma de hospedagem, quais limites de gasto estão definidos em cada chave e qual é a política de reembolso da plataforma para gastos com chaves comprometidas. A Railway já respondeu a última pergunta para os próprios clientes.

Depois volte as mesmas três perguntas para dentro de casa. A sua própria pilha de serviço, se você roda uma, também tem um cache, um motor e um cofre de chaves.

Fontes

Cloudflare. “Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang.” Outubro de 2026.
Ubicloud. “Fixing Tool-Call Accuracy in vLLM.” Outubro de 2026.
Railway. “Preliminary Report: Oct 21st Security Incident.” Outubro de 2026.

A Victorino ajuda organizações de engenharia a levar a revisão de risco de IA do modelo para a pilha de serviço ao redor dele: contato@victorino.com.br | www.victorino.com.br