A mensagem chegou na manhã de sábado, 17 de outubro, com o assunto que nenhum desenvolvedor quer encontrar na caixa de entrada: Action Required: Potential provider key breach. Os destinatários eram clientes do Console, o serviço pago do OpenCode (abre em nova aba). O OpenCode é o agente de programação de código aberto mantido pela equipe Anomaly/SST, que roda no terminal, no editor ou num app de desktop e conversa com modelos de mais de 75 provedores. O e-mail circulou num print do fórum r/opencode, que Matt Johansen, autor que escreve sobre segurança, compartilhou no X. Segundo o texto, alguém obteve acesso não autorizado a um sistema legado que a empresa estava desativando, e as chaves de provedores terceiros salvas no workspace podem ter sido expostas. O pedido era revogar todas elas, no painel de cada provedor.
A versão pública saiu às 18h08 (UTC) do mesmo dia, na conta oficial do projeto no X. Ela trouxe uma palavra que não aparece no trecho conhecido do e-mail, e foi essa palavra que pautou a conversa desde então:
Tivemos uma violação de segurança ontem à noite, relacionada a um ataque de destilação em larga escala, que afetou 1,4% dos usuários do OpenCode Console. Notificamos todos eles hoje de manhã por e-mail. Se você não recebeu um e-mail, não foi afetado; foi um subconjunto de usuários que tinham provedores externos vinculados. O incidente está em andamento, então não podemos compartilhar mais detalhes neste momento, mas estamos trabalhando com Anthropic, OpenAI e Google para remediar.
O que está dito e o que falta
Do post saem três dados com alguma firmeza. O primeiro é que o 1,4% é calculado sobre os usuários do Console. Não vale para todo mundo que usa o OpenCode, ferramenta aberta que qualquer um roda na própria máquina. O segundo é que os afetados formam um subconjunto de quem vinculou provedores externos à conta, ou seja, nem todo mundo que vinculou foi atingido. O terceiro é que, pela palavra da empresa, quem não recebeu e-mail está fora. Falta o principal para dimensionar o estrago: quantas pessoas cabem nesse 1,4%. O número absoluto não foi divulgado.
A lista do que não se sabe é mais longa. A empresa não disse como os invasores entraram, que sistema legado era esse nem como as chaves estavam armazenadas. Também não se sabe se elas foram usadas, e o OpenCode afirma que ainda não consegue confirmar abuso. Os usuários contam outra história. Há relatos de cobranças não autorizadas em contas de provedores conectadas, e um deles calcula o prejuízo em US$ 400. Nenhum desses relatos foi verificado de forma independente até aqui. Sobre reembolso, a empresa não disse nada.
Quem falou em destilação
A ligação com destilação foi feita pelo próprio OpenCode, no post oficial. Não partiu da OpenAI, da Anthropic nem do Google, que não se pronunciaram publicamente sobre o incidente no que circulou até agora. Nenhum pesquisador ou empresa de segurança atribuiu o ataque a um grupo específico. E o OpenCode não explicou como relacionou o vazamento das chaves a um "ataque de destilação em larga escala".
Dá para montar uma explicação plausível. Destilar um modelo de ponta exige um volume enorme de chamadas, e os provedores monitoram padrões de uso conta por conta. Um lote de chaves de clientes pagantes resolve dois problemas de quem destila. A conta vai para outra pessoa, e o tráfego se espalha por contas com histórico legítimo, que demoram mais a levantar suspeita. A hipótese combina com os relatos de cobranças inesperadas. Mas continua sendo hipótese, e a empresa não a apresentou.
A frase sobre "trabalhar com Anthropic, OpenAI e Google para remediar" também admite duas leituras. Pode significar que os provedores detectaram o padrão abusivo e avisaram o OpenCode. Pode significar apenas uma coordenação para revogar chaves em massa. A frase serve para as duas, e só os envolvidos podem dizer qual é a verdadeira.
O sistema que ia ser desligado
De tudo o que foi dito, o único mecanismo confirmado é o mais banal: um sistema em processo de desativação ainda guardava chaves vivas de clientes. Não importa se o objetivo de quem entrou era destilar um modelo, revender acesso ou só queimar crédito alheio. As chaves estavam lá para serem levadas. Num desligamento bem conduzido, as credenciais são a primeira coisa a sair de um sistema condenado, porque todo o resto pode esperar. Pelo que o e-mail descreve, aqui a ordem foi outra.
Por isso o rótulo de destilação, do jeito que foi lançado, mais atrapalha do que explica. Ele empurra a história para a disputa entre laboratórios sobre quem copia o modelo de quem, com um adversário sofisticado e externo. Para quem desenvolve, a pergunta que interessa é de custódia. Onde as chaves ficavam, em que formato, e por que ainda estavam acessíveis num sistema com data marcada para morrer. Se estavam cifradas, a empresa não disse.
O melhor argumento a favor do OpenCode é a rapidez. O e-mail saiu menos de um dia depois da invasão. O post público trouxe um percentual, um critério claro para o usuário saber se foi atingido e o nome dos três provedores envolvidos. Muita empresa leva semanas para dizer menos que isso. Com o incidente em andamento, guardar detalhes do vetor de ataque é prática comum de resposta a incidentes e evita servir de manual para imitadores. E, se a destilação se confirmar, ter citado o termo cedo ajuda provedores e usuários a interpretar padrões de consumo estranhos.
Concordo com quase tudo, mas a prudência cobre o vetor de ataque e não cobre as perguntas cuja resposta a empresa já tem. Quantas pessoas foram afetadas, como as chaves eram guardadas e se haverá reembolso não dependem do fim da investigação. E, entre todos os detalhes que poderia compartilhar, o OpenCode escolheu justamente o mais dramático e o menos documentado. Uma investigação em curso justifica ficar calado, mas não justifica soltar um rótulo sem lastro.
Quem precisa se mexer
- Usuário do Console que recebeu o e-mail: revogue e reemita as chaves no painel de cada provedor, e não dentro do OpenCode. Revise o consumo desde a noite de sexta, 16, e configure um limite de gasto. Se aparecer cobrança que você não reconhece, abra chamado no suporte do provedor.
- Usuário do Console com provedores vinculados que não recebeu o e-mail: segundo a empresa, você está fora. Antes de relaxar, procure no spam pelo assunto citado acima. Como o incidente segue em andamento e trocar uma chave leva minutos, eu trocaria do mesmo jeito.
- Quem roda o OpenCode só localmente, com chaves próprias: nada publicado até agora indica que essas chaves tenham sido expostas. Os comunicados tratam apenas de chaves salvas em workspaces do Console.
O que vale levar daqui
O caso serve de lembrete para quem entrega credenciais a ferramentas de terceiros, e quase tudo o que ajuda custa pouco:
- Uma chave por ferramenta, nunca a chave principal da organização. Se uma vazar, você revoga essa e o resto continua funcionando.
- Limite de gasto rígido no próprio provedor. Os controles do painel do terceiro não servem de nada quando o incidente é no terceiro.
- Alertas de consumo. Neste caso, os primeiros relatos de dano vieram de cobranças inesperadas. Quem tinha alerta configurado soube antes de a fatura fechar.
- Execução local quando o recurso hospedado não for indispensável. O risco mora onde a chave fica guardada, e uma chave numa variável de ambiente da sua máquina não estava no sistema legado de ninguém.
- Perguntas diretas ao fornecedor: como os segredos são armazenados e o que acontece com eles quando um sistema é aposentado.
O OpenCode promete mais detalhes quando o incidente terminar. A explicação que vale esperar é como um ataque de destilação foi parar num sistema que estava sendo desligado. A troca de chaves não precisa esperar por ela.