Durante algumas horas na tarde de 2026-06-05, a API da Claude parece ter estado a devolver respostas que não pertenciam ao utilizador que as tinha pedido. Envia um pedido e recebe de volta uma saída que se lê como a resposta ao prompt de outra pessoa.
A página de estado da Anthropic registou o evento como «erros elevados em muitos modelos da Claude», afetando o Opus 4.5 ao 4.8 e o Sonnet 4.6. Não descreve, à data de hoje, uma fuga de dados. A leitura de que houve dados cruzados entre utilizadores vem de capturas de ecrã que circulam e de relatos em primeira mão, por isso convém tratá-la como uma interpretação inicial, não como uma violação confirmada.
O que é interessante não é se um fornecedor teve uma má tarde. É a classe de falha. Quando algo assim acontece, quase sempre remonta a estado mutável partilhado sob carga, e esse é um risco que qualquer fornecedor de IA que escale depressa carrega neste momento.
O que parece ter acontecido
Segundo a página de estado da Anthropic, o incidente decorreu ao longo da tarde de 2026-06-05: a investigação abriu por volta das 15:19 UTC, o problema foi identificado por volta das 15:43 UTC e marcado como resolvido por volta das 18:28 UTC. Os modelos afetados foram o Claude Opus 4.5, 4.6, 4.7 e 4.8, além do Sonnet 4.6. A etiqueta oficial foi «erros elevados», a gaveta genérica que os fornecedores usam para tudo, desde tempos de espera esgotados até respostas malformadas.
Os relatos que chamaram a atenção descrevem algo mais concreto. Alguns utilizadores disseram que certas chamadas à API devolviam conteúdo sem qualquer relação com o seu próprio prompt e, em pelo menos um caso muito partilhado, a tarefa de uma pessoa apareceu dentro da resposta de um utilizador completamente alheio. Várias pessoas disseram ter recebido o que parecia ser a saída de inferência de outro cliente, e que verificaram com cuidado antes de concluir que era um erro do lado do servidor e não um bug do seu lado.
Duas coisas são verdadeiras ao mesmo tempo. A Anthropic não confirmou uma exposição de dados entre utilizadores, e a evidência pública é consistente com ela. Uma leitura responsável sustenta ambas: isto parece uma fuga de respostas entre clientes (cross-tenant), e ainda não está oficialmente confirmada como tal. Não reproduzo aqui as capturas divulgadas, porque contêm o prompt e a saída de outro cliente, ou seja, exatamente os dados que não deveriam circular mais.
A classe de falha: estado mutável partilhado sob carga
A fuga entre clientes acontece quando os dados de um cliente surgem na sessão de outro. É um dos bugs mais antigos e perigosos dos sistemas multi-inquilino, e raramente vem de uma violação espetacular. Costuma vir de um pedaço de estado partilhado e mutável que deveria estar isolado por pedido e que, nas condições erradas, não estava.
Uma API de IA moderna não é um único programa a responder a um pedido de cada vez. É uma pilha de camadas partilhadas: balanceadores de carga, encaminhadores de pedidos, gateways, filas, caches em memória e pools de ligações, todos a servir cada cliente ao mesmo tempo para manter a latência e o custo baixos. Cada uma dessas camadas guarda estado. Cada uma é um lugar onde um pedido pode apanhar a resposta errada se uma chave de cache colidir, uma ligação for reutilizada depois de dever ter sido descartada, ou um pedido cancelado deixar para trás um objeto obsoleto.
O sintoma é quase sempre o mesmo: pede os seus dados e recebe os de outra pessoa. A causa é quase sempre banal: um pequeno erro na forma como um objeto partilhado é reutilizado, despoletado pela carga ou por um caso-limite como um pedido cancelado ou expirado.
Já vimos este mesmo padrão antes
O precedente mais claro é a OpenAI, em março de 2023. A 2023-03-20, uma alteração nos seus servidores provocou um pico de pedidos Redis cancelados, que despoletou um bug na biblioteca cliente redis-py. Durante uma janela nesse dia, alguns utilizadores do ChatGPT conseguiram ver os títulos de conversa de outros utilizadores ativos e, nalguns casos, a primeira mensagem de uma conversa recém-criada.
O mesmo incidente expôs dados de faturação limitados. A OpenAI notificou cerca de 1,2% dos subscritores do ChatGPT Plus de que outro utilizador poderia ter visto o seu nome e apelido, morada de faturação, tipo de cartão, data de validade e os últimos quatro dígitos do cartão. Os números completos do cartão nunca foram expostos. Como o Help Net Security noticiou na altura, e como a OpenAI confirmou na sua própria análise, a causa raiz foi uma camada partilhada de cache e ligações que devolvia dados ao cliente errado após pedidos cancelados.
Essa é a mesma classe de falha que o sintoma descrito nos relatos sobre a Claude: uma camada partilhada e mutável que entrega os dados de um cliente a outro sob carga. Empresa diferente, biblioteca diferente, a mesma forma.
Porque é que escalar torna isto mais provável, não menos
Aqui está a parte estrutural incómoda. Os fornecedores de IA estão a adicionar capacidade mais depressa do que quase qualquer infraestrutura na história da informática. A procura ultrapassa o hardware, por isso as equipas continuam a empilhar camadas para aguentar: mais cache para reduzir o custo dos tokens, mais encaminhamento para distribuir a carga por regiões e versões de modelo, mais proxies e gateways para gerir quotas e failover.
Cada uma dessas camadas é um ganho de desempenho e um novo lugar por onde o estado pode fugir. Uma cache que serve a chave errada, um encaminhador que reutiliza uma ligação, um proxy que dobra uma resposta noutro fluxo: cada um está a um único bug de uma fuga entre clientes. Quanto mais agressivamente um fornecedor escala, mais destas camadas opera e mais carga empurra através delas.
Por isso, isto é menos uma história sobre a Anthropic e mais uma história sobre toda a gente. Os fornecedores que mais correm para adicionar capacidade são precisamente os mais expostos a esta classe de bugs, porque a velocidade e a infraestrutura partilhada são a forma de servir milhões de pedidos de forma barata. Não é sinal de que uma empresa é descuidada. É uma propriedade da arquitetura sobre a qual toda a indústria está a construir.
O que isto significa se constrói sobre APIs de LLM
A conclusão prática é uma mudança de mentalidade. A resposta de uma API de LLM não é um canal privado e de confiança entre si e o modelo. São dados que voltam de um sistema enormemente partilhado e em rápida mudança e que, num mau dia, podem estar errados, desatualizados ou cruzados com outro cliente.
Trate-os assim:
- Assuma que uma resposta pode, de vez em quando, pertencer ao pedido errado. Não desenhe fluxos em que uma única resposta cruzada corrompa em silêncio o registo de um utilizador ou o exponha a outra pessoa.
- Não envie para uma API de LLM dados que não toleraria ver surgir noutro lado, a menos que o seu contrato e os controlos do fornecedor os cubram realmente. As condições de retenção zero e de isolamento empresarial importam aqui.
- Valide e restrinja as respostas antes de agir sobre elas. Verifique a forma, o tipo e a plausibilidade, tal como validaria qualquer entrada não fiável.
- Registe o suficiente para detetar fugas. Se nunca guardar metadados de pedido e resposta, não consegue distinguir um erro do modelo de uma resposta que nunca foi sua.
Há uma versão disto na camada do navegador que é fácil de ignorar. Um número crescente de aplicações injeta a saída do modelo diretamente na página: respostas em streaming, HTML gerado por IA, resultados de ferramentas apresentados em linha. Se essa saída puder estar cruzada ou injetada, apresentá-la às cegas transforma um problema de backend num problema do lado do cliente. Pode acabar a mostrar o conteúdo de outro utilizador ao seu utilizador, ou a executar marcação que não escreveu, dentro de uma sessão em que o seu utilizador já está autenticado.
O que fazer esta semana
- Mapeie cada lugar por onde uma resposta de API de LLM entra no seu sistema e marque quais são apresentadas diretamente no navegador.
- Trate essas respostas como entrada não fiável: valide a estrutura, faça escape de tudo o que é apresentado na página e nunca injete HTML em bruto do modelo sem o sanear.
- Decida explicitamente que dados está disposto a enviar para cada fornecedor e confirme as condições de retenção e isolamento que se aplicam.
- Adicione registo e alertas que distingam uma resposta malformada de uma que não corresponde ao pedido que enviou.
- Vigie a camada do navegador, onde a saída de IA, os scripts de terceiros e os dados do utilizador se encontram agora na mesma sessão.
Como a cside se encaixa
A cside não corre dentro do backend da Anthropic nem de nenhum fornecedor, e não consegue corrigir uma cache que devolve os dados do cliente errado. O que aborda é a mesma classe de problema um passo mais perto do seu utilizador: o navegador, onde as respostas de IA, os scripts de terceiros e as sessões autenticadas partilham agora a mesma página.
A cside oferece visibilidade em tempo de execução sobre o que realmente é executado nessa sessão do navegador: que scripts carregam, como mudam após o deployment, que dados leem e para onde os enviam. À medida que mais aplicações apresentam a saída do modelo diretamente na página, essa visibilidade é a forma de apanhar as consequências do lado do cliente de uma resposta errada ou cruzada, como conteúdo apresentado na sessão errada ou um script que procura dados que nunca deveria tocar.
O ponto mais amplo é o mesmo que a cside sempre defendeu sobre os scripts de terceiros, agora generalizado à infraestrutura de IA. Cada camada que adiciona para ir mais depressa é uma camada por onde os dados podem surgir no lugar errado. Não pode remover essas camadas, mas pode instrumentar a que está mais perto do seu utilizador.
Comece pela segurança do lado do cliente para a monitorização de scripts em tempo de execução, ou pela Privacy Watch para ver exatamente o que o código das suas páginas recolhe e envia.
Leitura adicional na cside
- Como scripts de terceiros comprometidos podem injetar prompts em agentes de IA
- A inferência no dispositivo está a chegar à sua stack de segurança
- A IA está a comprimir o ciclo de exploração
- Boas práticas para proteger os scripts de terceiros
À data de 2026-06-05. Os detalhes do incidente da API da Claude refletem a página de estado da Anthropic e os relatos públicos de utilizadores disponíveis nessa data. A Anthropic caracterizou o evento como erros elevados e não confirmou, à data de hoje, uma exposição de dados entre utilizadores.
