Canis conteúdos / noticias
Menu
Falar com a Canis ↗
Notícias

OpenCode expõe chaves de API e cobranças passam de US$ 1.000

Por Vinicius Moreira 6 min de leitura
Ilustração em papel recortado sobre fundo creme dividido em parede e chão: uma caixa de papelão aberta, com abas terracota; à frente dela, um chaveiro com duas chaves, um cadeado aberto e uma fatura com linhas de cobrança; à direita, uma chave solta e a sombra triangular projetada no chão; no alto, à esquerda, o título Chaves de API expostas e a linha e cobranças na conta.
A chave que sai da caixa continua válida no provedor — e a fatura continua correndo.
Tópicos desta notícia (7)
  1. 01O que a OpenCode confirmou
  2. 02Por que a cobrança continua depois de apagar a chave
  3. 03O que fazer agora, na ordem
  4. 04O que isso ensina para uma equipe brasileira que usa IA
  5. 05Riscos e o que ainda não se sabe
  6. 06Fontes
  7. 07Conclusão

O que a OpenCode confirmou

A OpenCode, agente de código aberto que vem ganhando espaço como alternativa ao Claude Code e ao Cursor, informou em 17 de outubro que um invasor acessou, na noite anterior, um sistema legado que a empresa estava desativando. O alvo foi o OpenCode Console, serviço opcional em que uma equipe guarda a própria chave de OpenAI, Anthropic ou Google para que os membros usem os modelos sem ver o segredo. Segundo a empresa, 1,4% dos usuários da Console foram afetados — todos os que tinham um provedor externo vinculado — e receberam e-mail na manhã do dia 17 com o assunto “Action Required: Potential provider key breach”.

A empresa foi cuidadosa no verbo: as chaves “podem ter sido expostas”. Não afirmou que tenham sido copiadas, nem quantas, nem quando o acesso começou. Também não detalhou qual era o sistema legado, como o invasor entrou ou como as chaves estavam armazenadas. O comunicado classificou o episódio como relacionado a um “ataque de destilação em larga escala” — a prática de treinar um modelo mais barato com as respostas de um modelo melhor — e disse que o incidente seguia em curso.

O cofundador Dax Raad separou os escopos: o problema ficou na Console, não no aplicativo. As chaves adicionadas no aplicativo de linha de comando ou no desktop ficam em um banco local na máquina do usuário e, segundo ele, “nunca chegam até nós”. A distinção importa porque é justamente a chave guardada em um workspace compartilhado que vira alvo rentável.

Por que a cobrança continua depois de apagar a chave

Uma chave de provedor é uma credencial portadora: quem tem uma cópia consegue fazer chamadas cobradas na conta do dono até que o provedor a revogue. Apagar a chave dentro da Console não a invalida no provedor — só remove a cópia que estava ali. E o limite de gasto configurado na Console não protege a conta, porque a Console só enxerga as requisições que passam pelo gateway dela; o uso feito direto contra a OpenAI, a Anthropic ou o Google não passa.

Foi o que apareceu na madrugada do dia 17. Desenvolvedores relataram alertas de gasto e cobranças não autorizadas em sequência. Um deles escreveu que viu os avisos de OpenAI, Anthropic e Google dispararem antes de dormir; outros relataram centenas de dólares em uma única conta e, em alguns casos, totais acima de US$ 1.000 — cerca de R$ 5 mil pela PTAX de venda de 19 de outubro, segundo o Banco Central.

A resposta dos provedores foi rápida. A Anthropic e o Google bloquearam as chaves que consideravam expostas; a OpenAI disse que trabalhou com a OpenCode para restaurar o acesso e devolver os créditos consumidos no ataque. A OpenCode afirmou que os reembolsos das cobranças não autorizadas estavam em andamento. Nada disso, porém, substitui a revogação pelo dono da conta — o ressarcimento é uma correção posterior, não uma proteção.

Comparação entre as chaves guardadas na Console e as chaves que ficam no aplicativo local
Comparação entre as chaves guardadas na Console e as chaves que ficam no aplicativo local

O que fazer agora, na ordem

A orientação da empresa e os guias de segurança convergem para uma sequência simples, e a ordem importa. Primeiro, revogar a chave no painel do próprio provedor e criar outra — não basta apagar na Console. Segundo, atualizar todos os aplicativos, scripts e agentes que usavam a chave antiga; uma chave esquecida em um arquivo de configuração mantém o problema aberto.

Terceiro, conferir a fatura e o histórico de uso de cada provedor desde 16 de outubro, procurando requisições que a equipe não fez. Quarto, criar uma chave por ferramenta ou por projeto, com limite de gasto e alerta configurados no provedor, para que uma cópia vazada faça menos estrago e seja mais fácil de rastrear. Quem não recebeu o e-mail da OpenCode não foi afetado, segundo a empresa — mas a revisão de chaves antigas e de limites de gasto vale para qualquer equipe.

Quatro passos para responder ao vazamento de chaves de API
Quatro passos para responder ao vazamento de chaves de API

O que isso ensina para uma equipe brasileira que usa IA

Para uma agência ou PME que usa ferramentas de código com IA, o incidente não é só uma notícia de segurança: é uma conta que pode chegar sem aviso. As cobranças relatadas vão de centenas a mais de mil dólares por conta afetada; em um time com vários projetos, o total pode passar de um orçamento mensal de tecnologia.

A lição prática é tratar chave de provedor como credencial de produção, não como atalho de configuração. Isso significa uma chave por cliente ou por projeto, guardada em cofre ou variável de ambiente — nunca no workspace compartilhado de uma ferramenta de terceiro —, com limite de gasto e alerta no provedor. Também significa saber onde as chaves estão: quem nunca fez esse inventário descobre o tamanho do problema só quando a fatura chega.

Há um segundo aprendizado, de resposta a incidente. A própria OpenCode relatou que os modelos de IA que sua equipe usou para analisar o código malicioso começaram a recusar o trabalho quando os filtros de segurança foram acionados, e que o acesso a um programa de modelos liberados para defesa (o Daybreak Blue, da OpenAI) melhorou a investigação. A Hugging Face passou por algo parecido em julho. Para uma empresa pequena, a conclusão não é contratar um modelo especial: é ter um plano que não dependa de uma única ferramenta para descobrir o que aconteceu.

Riscos e o que ainda não se sabe

O primeiro risco é o escopo. A OpenCode fala em “podem ter sido expostas” e não disse quantas chaves foram copiadas ou efetivamente usadas. Também não informou quando o acesso começou — o que impede saber se o uso indevido é maior do que o relatado até agora. O incidente foi descrito como em curso em 17 de outubro, sem atualização pública posterior até o fechamento deste texto.

O segundo é a leitura do episódio. O rótulo “ataque de destilação” foi contestado por pesquisadores, que o consideram uma interpretação ampla demais para um vazamento de credenciais cujo uso para treinar modelo não foi comprovado. O fato verificável é o acesso a um sistema legado e a exposição possível de chaves; a motivação declarada pela empresa é hipótese.

O terceiro é a dependência de terceiros. Quem guarda chaves em um serviço de console depende de como esse serviço armazena, segmenta e descarta credenciais — e o episódio mostra que “desativar um sistema” não é o mesmo que apagá-lo. Para uma PME, a alternativa realista é reduzir o número de lugares onde uma chave vive e revisar esse inventário periodicamente.

Fontes

Valores em dólar foram convertidos pela PTAX de venda de 19/10/2026 (R$ 5,0564); arredondamentos indicados no texto.

Conclusão

O episódio da OpenCode Console deixa uma regra que vale para qualquer porte: a chave que a sua equipe cola em uma ferramenta de terceiro é uma credencial da sua conta, com poder de gasto real. Se ela não tem inventário, limite e rotação, o problema não é o ataque — é a falta de controle antes dele.

Sua empresa usa IA com chaves de provedor espalhadas pelo time? A Canis organiza credenciais, limites de gasto e políticas de uso de IA para equipes pequenas — do inventário à resposta a incidente. Falar com a Canis →

Canis · Diagnóstico

Início da conversa