Se você usa o OpenCode e guardou suas chaves da OpenAI, Anthropic ou Google no Console, talvez queira sentar antes de continuar lendo. No dia 16 de outubro de 2026, atacantes exploraram uma vulnerabilidade em um sistema legado da plataforma e tiveram acesso a API keys de aproximadamente 1,4% dos usuários do Console. E o que fizeram com essas chaves? Rodaram milhares de queries em modelos frontier para treinar seus próprios modelos. De graça. Na sua conta.

O que é o OpenCode (e por que ele guarda suas chaves)

O OpenCode é um agente de IA para código que roda direto no terminal. Open source, licença MIT, sem assinatura. Você conecta o modelo que quiser (Claude, GPT, Gemini, Llama, o que for) e usa como assistente para editar arquivos, rodar comandos, navegar pelo codebase. Pensa num Claude Code de código aberto, e você está perto.

Até aí, tranquilo. O problema mora em um recurso chamado Console. O Console é um gateway hospedado onde times armazenam credenciais de provedores terceiros. A ideia é que membros do time usem os modelos sem nunca ver a chave real do provedor. Você cadastra a API key da OpenAI, da Anthropic, do Google, e o Console distribui o acesso.

Parece conveniente, certo? É. Até alguém invadir esse cofre.

Como o ataque aconteceu

A vulnerabilidade foi explorada em um sistema legado que estava em processo de descomissionamento. Sabe aquele servidor antigo que “ainda funciona” e ninguém quer mexer? Que fica num canto, sem monitoramento, sem atualizações, esperando o dia em que alguém vai desligar? Pois é. Esse servidor era a porta de entrada.

Os atacantes conseguiram acesso não autorizado às chaves de API armazenadas nos workspaces do Console. A timeline foi rápida:

O OpenCode classificou o incidente como um “ataque de destilação em larga escala”. Mas o que exatamente isso significa?

Destilação: quando roubam suas chaves para treinar IA

Destilação (distillation) é uma técnica onde um modelo menor aprende estudando as respostas de um modelo maior e mais capaz. Você pega um Claude Opus, por exemplo, manda milhares de prompts complexos, coleta as respostas, e usa esses pares de entrada/saída para treinar um modelo competidor. O modelo menor “destila” o conhecimento do maior.

Na prática, funciona assim:

# Pseudocódigo de um ataque de destilação
import openai

# Usando a API key roubada da vítima
client = openai.Client(api_key="sk-CHAVE_ROUBADA_DA_VITIMA")

prompts = carregar_dataset_de_prompts()  # milhares de prompts complexos
respostas = []

for prompt in prompts:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}]
    )
    respostas.append({
        "input": prompt,
        "output": response.choices[0].message.content
    })

# Agora treina seu próprio modelo com os dados coletados
treinar_modelo_menor(respostas)

O custo? Zero para o atacante. Centenas de dólares para a vítima.

Uma chave roubada de um modelo frontier pode gerar dados de treinamento que valem muito mais para um competidor do que a conta que ela deixa para trás. É roubo de propriedade intelectual disfarçado de consumo de API.

A Anthropic já tinha documentado táticas similares em fevereiro de 2026, sugerindo que a indústria já monitorava esse tipo de abuso. Agora ele se materializou em escala.

O estrago: contas drenadas e surpresas na fatura

Usuários afetados relataram cobranças não autorizadas significativas. Alguns viram suas contas sendo drenadas rapidamente, com faturas subindo para centenas de dólares. Um usuário reportou um prejuízo de US$ 400 em uma única noite.

O problema é que muitos devs configuram API keys e esquecem. Não colocam spending caps, não monitoram usage, não revisam dashboards. É como deixar o cartão de crédito salvo num site e nunca olhar o extrato.

Aqui vai o checklist que o OpenCode recomendou:

1. Revogue imediatamente todas as API keys armazenadas no Console
2. Gere novas chaves nos dashboards dos provedores (OpenAI, Anthropic, Google)
3. Revise o histórico de uso em cada provedor buscando atividade suspeita
4. Configure spending caps no nível do provedor (se ainda não tinha, agora você tem motivo)
5. Verifique repositórios e histórico do shell para chaves vazadas em outros lugares

“O sistema antigo é o que ninguém vigia”

Essa frase, repetida em várias análises do incidente, resume perfeitamente o que aconteceu. É um padrão que se repete em quase todo breach significativo na indústria: a vulnerabilidade não está no sistema novo, reluzente, auditado. Está no legado.

Pense nos últimos grandes vazamentos:

• SolarWinds (2020): build system legado comprometido
• Equifax (2017): servidor Apache Struts desatualizado
• Heartbleed (2014): biblioteca OpenSSL sem patch por dois anos

O OpenCode cometeu o mesmo erro. Tinham um sistema em processo de descomissionamento, provavelmente com menos logging, menos alertas, menos olhos em cima. E foi exatamente ali que os atacantes entraram.

Se você trabalha com infraestrutura, anote: o sistema que está “quase sendo desligado” é o mais perigoso da sua rede. Enquanto ele existir, ele precisa de monitoramento. Se não dá pra monitorar, desligue agora. Não amanhã. Agora.

OpenCode vs Claude Code vs Cursor: quem guarda suas chaves?

O incidente levanta uma questão maior: quem deveria guardar suas API keys?

O modelo do OpenCode Console é inerentemente mais arriscado porque centraliza chaves de múltiplos provedores em um servidor remoto. É conveniente pra times, mas a superfície de ataque é dramaticamente maior.

A lição aqui não é “nunca use gateway centralizado”. É: se você vai centralizar segredos, trate esse sistema como o ativo mais crítico da sua infraestrutura. Não como “aquele serviço ali que o DevOps cuida”.

Como proteger suas API keys (de verdade)

Eu já vi projetos onde a API key da OpenAI estava hardcoded num .env commitado no GitHub público. Já vi chaves da AWS em Dockerfiles. Já vi tokens do Slack em screenshots de tutorial. O problema não é novo.

Mas com o crescimento de agentes de IA que precisam de múltiplas chaves de múltiplos provedores, a superfície de ataque multiplicou. Aqui vão práticas que realmente funcionam:

1. Nunca armazene chaves em texto plano

Use gerenciadores de segredos: AWS Secrets Manager, HashiCorp Vault, 1Password CLI, ou até o keyring do sistema operacional.

# Em vez disso (NÃO FAÇA):
export OPENAI_API_KEY="sk-proj-abc123..."

# Faça isso:
export OPENAI_API_KEY=$(op read "op://Dev/OpenAI/api-key")
# ou
export OPENAI_API_KEY=$(aws secretsmanager get-secret-value \
  --secret-id openai-key --query SecretString --output text)

2. Use chaves com escopo mínimo

A maioria dos provedores permite criar chaves com permissões restritas. Crie chaves separadas para cada projeto, com limites de gasto individuais.

Projeto A: sk-proj-a-*** (limit: $50/mês, só GPT-4o-mini)
Projeto B: sk-proj-b-*** (limit: $100/mês, GPT-4o + embeddings)
Pessoal:   sk-proj-c-*** (limit: $20/mês, só chat)

3. Monitore uso com alertas

Configure alertas de gasto nos dashboards dos provedores. Se a fatura diária ultrapassar X, você recebe um email/SMS. Isso teria pego o ataque de destilação em horas, não dias.

4. Rotacione chaves regularmente

Defina um ciclo de rotação (a cada 90 dias, por exemplo) e automatize:

# Script de rotação (exemplo conceitual)
NEW_KEY=$(curl -s -X POST "https://api.openai.com/v1/api-keys" \
  -H "Authorization: Bearer $ADMIN_KEY" | jq -r '.key')

# Atualiza no vault
op item edit "OpenAI" "api-key=$NEW_KEY"

# Revoga a chave antiga
curl -s -X DELETE "https://api.openai.com/v1/api-keys/$OLD_KEY_ID" \
  -H "Authorization: Bearer $ADMIN_KEY"

5. Audite onde suas chaves estão

Faça um grep no seu ambiente inteiro. Você vai se surpreender:

# Procura chaves da OpenAI em qualquer arquivo
grep -rn "sk-proj-\|sk-ant-\|AIza" \
  --include="*.env" --include="*.json" --include="*.yaml" \
  --include="*.toml" --include="*.py" --include="*.js" \
  ~/projetos/

O que o OpenCode está fazendo agora

O OpenCode confirmou que está trabalhando com Anthropic, OpenAI e Google para remediar o incidente. Detalhes sobre como as cobranças não autorizadas serão tratadas não foram divulgados no anúncio inicial.

A equipe notificou os usuários afetados por email e publicou o incidente no X (Twitter) no dia 17 de outubro. NetworkChuck, Matt Johansen e outros nomes da comunidade de segurança amplificaram o alerta.

O incidente ainda está sendo investigado. A recomendação oficial continua a mesma: revogue tudo, gere novos tokens, monitore.

Destilação como arma: o que vem por aí

Esse tipo de ataque vai se tornar mais comum. Com o custo de treinar modelos frontier ultrapassando centenas de milhões de dólares, roubar acesso computacional via API keys é dramaticamente mais eficiente do que alugar GPUs.

Pense: uma chave da Anthropic com acesso ao Claude Opus pode gerar datasets de treinamento de altíssima qualidade. O atacante não precisa de 10.000 H100s. Precisa de uma chave roubada e paciência.

A indústria vai precisar evoluir:

• Provedores precisam implementar detecção de padrões de destilação (queries repetitivas, volume anormal, padrões de prompt suspeitos)
• Ferramentas que armazenam chaves precisam tratar isso como infraestrutura crítica de segurança, não como feature de conveniência
• Devs precisam tratar API keys com o mesmo cuidado que tratam chaves SSH e certificados TLS

O OpenCode aprendeu essa lição da pior maneira possível. A pergunta é: você vai esperar acontecer com a sua ferramenta pra tomar providência?

Fonte de inspiração: OpenCode disclosure no X/Twitter e cobertura da Developer’s Digest