Roubo de chaves de API e ataques de destilação: como proteger as chaves das suas ferramentas de IA

Uma chave de API de um provedor de IA é uma credencial ao portador: quem a tem pode gastar seu dinheiro e usar sua cota, e o provedor não consegue distinguir quem a tem de você. Um ataque de destilação é um dos motivos pelos quais alguém quer muitas chaves assim. Ele treina um modelo mais barato com as respostas de um modelo mais forte e exige um número muito grande de requisições pagas. Se as requisições passam por chaves roubadas, outra pessoa paga por elas e o tráfego não parece o de um único cliente. A defesa prática é limitar o que cada chave pode fazer, observar o que ela faz e guardar as chaves no menor número possível de lugares.

Em 17 de outubro de 2026, a OpenCode relatou um incidente de segurança que ela associou a um ataque de destilação em larga escala. Este artigo parte do que a OpenCode disse, explica o que é destilação e por que as chaves são o alvo, lista os sinais de abuso e traz listas de verificação para quem usa ferramentas de IA e para quem as constrói. Ele também diz o que o zn-gate faz para esse problema e o que não faz.

O que a OpenCode disse que aconteceu?

Repetimos apenas o que a OpenCode disse publicamente. A publicação da OpenCode no X e o aviso aos usuários afetados são citados abaixo conforme relatados por Officechai e Blockonomi, com links. O que a OpenCode não disse publicamente é marcado como não confirmado.

Em 17 de outubro de 2026, a OpenCode escreveu no X: "We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users" (em português: 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). A mesma publicação, conforme citada pelo Blockonomi, diz que os usuários afetados foram avisados por e-mail naquela manhã e que "if you did not get an email you were not impacted" (se você não recebeu um e-mail, não foi afetado). A OpenCode acrescentou que "it was a subset of users who had external providers" (foi um subconjunto de usuários que tinham provedores externos).

O aviso enviado aos usuários afetados, conforme citado pelo Officechai, diz que a OpenCode "identified unauthorized access to a legacy system" (identificou um acesso não autorizado a um sistema legado) e que "third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed" (chaves de provedores terceiros, por exemplo OpenAI ou Anthropic, salvas no seu workspace podem ter sido expostas). Acrescenta que "the incident is ongoing so we cannot share more details at this point" (o incidente continua em andamento, então não podemos compartilhar mais detalhes neste momento).

Esse é todo o quadro confirmado. Algumas coisas decorrem dele e outras não:

• O 1,4% é uma parcela dos usuários do OpenCode Console, não de todos que usam o agente de código de código aberto OpenCode. A documentação da OpenCode descreve o Console como o lugar onde você adiciona os dados de cobrança e os créditos e copia sua chave de API, e diz que os proprietários e administradores do workspace podem conectar seus próprios provedores.
• Segundo o aviso, as chaves em risco são chaves de provedores terceiros salvas em um workspace.
• A OpenCode não publicou como os atacantes entraram, por quanto tempo tiveram acesso, quantas chaves foram usadas nem quais modelos foram chamados. Qualquer coisa sobre esses pontos que você leia em outro lugar é uma hipótese.

Usamos a OpenCode todos os dias, nas versões oficiais e em builds que adaptamos à nossa própria configuração, e confiamos no produto. Não temos nenhuma relação comercial com a equipe da OpenCode. Escrevemos sobre o incidente porque ele mostra um padrão que todo fornecedor de ferramentas de IA e todo usuário dessas ferramentas deve prever, e porque a equipe tem sido transparente enquanto a investigação ainda está em andamento. Não sabemos mais do que eles disseram e não especulamos sobre os sistemas deles.

O que é um ataque de destilação e o que é extração de modelo?

Destilação é "treinar um modelo menos capaz com as saídas de um modelo mais forte", nas palavras da publicação da Anthropic sobre ataques de destilação. A técnica é legítima e antiga. Hinton, Vinyals e Dean a descreveram em 2015 em Distilling the Knowledge in a Neural Network como uma forma de comprimir um conjunto de modelos em um modelo menor e mais barato de executar. Os provedores destilam seus próprios modelos para criar versões menores e mais baratas para os clientes.

O abuso é destilar o modelo de outra pessoa sem permissão. A publicação da Anthropic diz que concorrentes a usam para adquirir capacidades "in a fraction of the time, and at a fraction of the cost" (em uma fração do tempo e do custo) de desenvolvê-las, e que os modelos criados assim dificilmente mantêm as salvaguardas originais. Nessa publicação, a Anthropic relata três campanhas que juntas geraram mais de 16 milhões de interações com o Claude por meio de cerca de 24.000 contas fraudulentas, e diz que as campanhas ilícitas são reconhecidas pelo padrão: "massive volume concentrated in a few areas, highly repetitive structures" (volume massivo concentrado em poucas áreas, estruturas muito repetitivas).

Uma ideia relacionada é a extração de modelo. Em Stealing Machine Learning Models via Prediction APIs (USENIX Security 2016), Tramèr e coautores mostram que quem tem apenas acesso de consulta a um modelo consegue copiar de perto o comportamento dele, e que remover os valores de confiança das saídas não impede totalmente isso. O artigo trata de modelos clássicos, não de modelos de linguagem grandes, mas a lição vale também aqui: se você consegue consultar um modelo o bastante, o comportamento dele pode ser copiado a partir das respostas.

Nenhuma das duas técnicas precisa de acesso aos pesos. Precisam de volume. É aí que entram as chaves.

Por que os atacantes usam chaves de API roubadas para isso?

Há dois motivos, e ambos têm a ver com custo e visibilidade.

A vítima paga. Uma execução de destilação exige muitas requisições, e cada uma é cobrada pelo provedor. Com uma chave roubada, a conta vai para o dono da chave. O custo do atacante se reduz ao esforço de juntar chaves.

O rastro se espalha. Um provedor que vê uma conta enviando milhões de requisições repetitivas consegue detectá-la, como a Anthropic descreve, usando classificadores, identificação de padrões de comportamento e ferramentas que detectam atividade coordenada entre muitas contas. Se o mesmo volume é dividido entre centenas de chaves de clientes diferentes, cada chave envia uma pequena quantidade de tráfego de aparência comum. A visão do provedor sobre qualquer conta isolada parece normal, e o padrão só aparece quando muitas contas são vistas em conjunto. A detecção do lado do provedor é difícil por esse motivo, e o dono da chave pode ser a primeira pessoa capaz de perceber que algo está errado, porque só ele sabe qual é o seu uso normal.

O resultado é que o dono da chave tem um interesse em observá-la que mais ninguém tem.

De onde vêm as chaves roubadas?

As chaves vazam dos lugares em que são guardadas. Na prática, estes são os mais comuns:

A última linha é a que este incidente aponta. Quando você salva uma chave de provedor no console de outra empresa, soma a segurança dessa empresa à segurança da chave. Isso pode ser uma boa troca, porque um serviço com uma equipe por trás pode proteger uma chave melhor do que um notebook. Também significa que uma falha nesse serviço pode expor chaves de clientes que fizeram tudo certo nas próprias máquinas.

Este artigo não descreve como nenhum desses vazamentos é explorado, e não vamos fazê-lo. As defesas não dependem disso.

Como saber se uma chave está sendo usada indevidamente?

Os sinais aparecem do lado do provedor, então o painel de cada provedor é o lugar para olhar. Procure por:

• Gasto que sobe sem mudança no seu trabalho. Um salto entre dois dias, ou um aumento constante em um horário em que ninguém está trabalhando.
• Modelos que você não usa. Se você só chama um modelo e a página de uso mostra outro, a chave está sendo usada por outra pessoa.
• Uso em horários estranhos ou em volume estranho, como uma taxa alta e constante a noite toda.
• Uso por chave que não combina com a finalidade da chave. Uma chave criada para uma ferramenta que mostra tráfego quando essa ferramenta está fechada.
• Cobranças inesperadas ou chegada a um limite que você não esperava alcançar.
• Avisos do provedor. Os provedores também detectam abuso e podem escrever para você ou desativar uma chave.

Nenhum desses sinais prova roubo por si só. Cada um é um motivo para verificar. A forma mais barata de torná-los visíveis é configurar alertas antes de precisar deles.

Como proteger suas chaves como usuário?

O objetivo é que uma chave roubada cause pouco dano, por pouco tempo, e que você perceba rápido. Estas medidas funcionam em conjunto:

1. Use uma chave por ferramenta e por finalidade. Quando uma chave vaza, você sabe de onde veio, pode revogá-la sem quebrar todo o resto, e a página de uso dela conta uma história clara. Os provedores agrupam as chaves em projetos ou workspaces, e essa é uma boa forma de separar ambientes. As boas práticas de produção da OpenAI recomendam projetos separados para homologação e produção, o que também permite limites de taxa e de gasto separados para cada um.
2. Defina limites de gasto e alertas. A documentação da OpenAI descreve alertas que avisam quando o uso passa de um valor em dólares e limites rígidos que interrompem o tráfego quando o gasto atinge o limite. Um limite rígido é o controle que transforma uma perda ilimitada em uma perda limitada. Defina-o abaixo do que você acha necessário e aumente quando chegar nele.
3. Dê validade às chaves e rotacione-as. A OpenAI recomenda definir uma data de expiração ao criar uma chave de projeto e ter um processo regular de rotação: criar uma substituta, atualizar seus aplicativos, verificar se funciona e então revogar a chave antiga. A documentação do Google recomenda rotacionar as chaves periodicamente, diz que chaves de API sem restrições são inseguras e recomenda restringir cada chave às APIs de que ela precisa.
4. Revogue, não apenas substitua, diante de qualquer dúvida. Se uma ferramenta que você usa relata um incidente e você não tem certeza de que sua chave foi envolvida, revogue a chave. Criar uma chave nova leva um minuto. Depois, analise o uso da chave antiga nos dias anteriores à revogação.
5. Mantenha as chaves fora do código, dos repositórios e dos logs. Use variáveis de ambiente ou um gerenciador de segredos, como a OpenAI recomenda, e mantenha o .env fora do controle de versão.
6. Não guarde uma chave no console de um terceiro, a menos que o serviço precise dela. Se a ferramenta roda na sua máquina, a chave pode ficar na sua máquina. Se o serviço precisa chamar o provedor por você, use uma chave criada só para isso, com projeto próprio, limite de gasto e validade.
7. Revise a lista de chaves de vez em quando. Exclua as chaves de ferramentas que você não usa mais. Os consoles dos provedores mostram quando cada chave foi criada, e alguns mostram quando foi usada pela última vez. A Admin API da Anthropic, por exemplo, expõe o status, a data de criação e a expiração de cada chave e nunca devolve o segredo em si.

O que devem fazer as pessoas que constroem ferramentas de IA?

Se o seu produto guarda chaves que pertencem aos seus clientes, você assumiu um dever que o notebook de um usuário não carrega, e o projeto deve refletir isso.

• Criptografe as chaves guardadas com um serviço de chaves gerenciado, como um KMS na nuvem, com controles de acesso que separem as pessoas e os serviços que podem descriptografar daqueles que apenas executam o produto. Guarde só o que você precisa para chamar o provedor.
• Use o menor privilégio entre os seus componentes. A parte do sistema que chama um provedor deve poder ler as chaves de que precisa para a requisição em questão, não o repositório inteiro.
• Não mostre uma chave de novo depois de salva. Exiba uma dica, como os últimos caracteres, e deixe o usuário substituí-la. Os objetos de chave da Admin API da Anthropic funcionam assim, com uma dica parcial e sem o segredo.
• Aplique cotas por chave e verificações de anomalia do seu lado. Você vê o tráfego de todos os seus clientes antes de qualquer um deles. Uma chave que de repente faz milhares de requisições do mesmo formato merece ser pausada e investigada.
• Retire sistemas antigos. Código e armazenamentos de dados que continuam acessíveis, mas não estão mais em uso ativo, costumam receber a menor revisão. Exclua-os ou mantenha-os sob os mesmos controles do sistema em produção.
• Facilite a rotação. Se revogar e substituir uma chave é um procedimento longo, os usuários não o fazem.
• Avise os clientes cedo e com clareza, dizendo o que fazer em seguida. Uma mensagem curta que diga quais usuários foram afetados e o que rotacionar permite que as pessoas ajam antes de a investigação terminar.

O que o zn-gate faz sobre isso e o que ele não faz?

O zn-gate é uma camada de segurança de código aberto que roda na sua máquina, entre o seu agente de código e as ferramentas e conteúdos que ele toca. Ele ajuda com a parte do problema que fica na sua máquina. Não ajuda com a parte que fica na nuvem de outra pessoa. Dizemos as duas coisas para que você não conte com ele para algo que ele não faz.

O que ele faz. Estas afirmações estão no README do zn-gate e na documentação do Scrubber e cofre de segredos:

• Com o plugin do Claude Code, ou os hooks do zn para Codex CLI, Cursor e OpenCode, o agente de código é impedido de ler arquivos .env que contêm valores reais e arquivos de credenciais como ~/.aws/credentials. É uma proteção de apoio, não um sandbox.
• Os segredos no que as ferramentas do agente devolvem, como leituras de arquivos e saída de comandos, são substituídos por marcadores antes que o modelo os veja, e um segredo colado em um prompt é bloqueado. No Cursor, apenas a saída das ferramentas MCP é limpa.
• zn env shadow .env move seus valores para um cofre criptografado na sua máquina e deixa marcadores como __ZN_STRIPE_KEY__ no arquivo. O cofre é local e não é sincronizado.
• Uma chave pode ser usada sem que o modelo a veja. Um comando que você permitiu recebe o valor por meio de zn run, e a saída dele é mascarada. Para APIs HTTP, o servidor MCP secrets envia o valor apenas aos hosts que você permitiu e devolve a resposta com os segredos substituídos por marcadores. Nenhuma ferramenta devolve um valor ao agente.

O que ele não faz.

• Ele não protege uma chave guardada na nuvem de um terceiro. No caso acima, as chaves em risco eram as salvas em um workspace em um console hospedado. O zn-gate não está no caminho entre esse serviço e o provedor, então não consegue reduzir essa exposição. Só o serviço e você, limitando e rotacionando essa chave, conseguem.
• Ele não substitui limites de gasto, alertas nem rotação. São os seus controles no provedor.
• Ele não impede um processo que você mesmo inicia, nem um malware executando como o seu usuário. O modelo de ameaças dele diz que qualquer programa executando como o seu usuário do sistema pode pedir um segredo pelo nome a um cofre desbloqueado, e recomenda bloquear o cofre com zn lock quando você não o estiver usando.
• Um comando que você permitiu ainda guarda o valor enquanto executa. O zn controla para onde uma credencial vai, não o que um programa permitido faz com ela.
• Ele não detecta um ataque de destilação. O tráfego do lado do provedor está fora do que ele enxerga.

O que o zn-gate remove é uma fonte comum de vazamentos: a chave em texto simples em um arquivo .env, onde um agente ou uma injeção de prompt pode encontrá-la. Uma dependência comprometida executando como o seu usuário é um caso diferente: veja o modelo de ameaças acima. Manter uma chave fora do alcance do agente na sua máquina é útil e é uma medida entre as listadas acima.

Qual é uma lista de verificação que você pode usar hoje?

Para usuários:

• Cada ferramenta tem a própria chave, no próprio projeto ou workspace.
• Cada chave tem um limite de gasto e um alerta em um valor menor.
• Cada chave tem uma data de validade, e você sabe quando vai rotacioná-la.
• Você sabe onde cada chave está salva: ambiente local, cofre, segredo de CI ou console de um terceiro.
• As chaves em consoles de terceiros são apenas as que o serviço precisa, com um limite.
• Os arquivos .env não estão no controle de versão, e o agente de código não consegue lê-los (npx -y zn-gate check).
• Você olha o uso por chave pelo menos uma vez por semana, e após qualquer aviso de incidente de um fornecedor de ferramenta.
• As chaves sem uso são excluídas.
• Se um fornecedor relata um incidente que pode envolver você: crie uma chave nova, atualize a ferramenta, revogue a chave antiga, analise o uso da chave antiga.

Para quem constrói:

• As chaves dos clientes são criptografadas com um serviço de chaves gerenciado, com permissões de descriptografia restritas.
• Uma chave nunca é exibida de novo depois de salva.
• Há cotas por chave e alertas de anomalia do seu lado.
• Sistemas e armazenamentos antigos são retirados ou cobertos pelos mesmos controles.
• Existe um procedimento testado para avisar os clientes e rotacionar todas as chaves guardadas.

O que este artigo não cobre?

• Ele não descreve como o incidente da OpenCode aconteceu além do que a OpenCode disse, porque isso não é público.
• Ele não traz nenhum método para roubar chaves nem para executar uma campanha de destilação.
• Ele não cobre a detecção do lado do provedor além do que os provedores publicaram.
• Ele não cobre chaves de serviços que não são provedores de IA, embora a maior parte do conselho se aplique a elas.

Perguntas frequentes

O que é um ataque de destilação?

Treinar um modelo menos capaz com as saídas de um modelo mais forte. A Anthropic descreve a destilação ilícita como o uso por concorrentes para adquirir capacidades em uma fração do tempo e do custo de construí-las. Ela exige um número muito grande de requisições ao modelo mais forte.

Por que um atacante roubaria chaves de API para um ataque de destilação?

Porque as requisições precisam ser pagas e partir de algum lugar. Com uma chave roubada, quem paga a conta é o dono da chave, e o tráfego se espalha por muitas contas em vez de uma só conta que um provedor consiga identificar e bloquear.

Como sei se a chave do meu provedor de IA está sendo usada indevidamente?

Procure por gasto que sobe sem mudança no seu trabalho, requisições a modelos que você nunca usa, uso em horários em que ninguém está trabalhando ou tráfego de ferramentas que você não reconhece. Alertas de gasto e telas de uso por chave são os primeiros sinais.

O que devo fazer se uma ferramenta que eu uso teve um vazamento de chaves?

Crie uma chave nova, atualize a ferramenta que precisa dela, revogue a chave antiga e depois analise o uso da chave antiga no período anterior à revogação. Faça isso mesmo que você não tenha certeza de que a chave foi afetada.

O zn-gate protege uma chave que guardei no console na nuvem de um terceiro?

Não. O zn-gate roda na sua máquina e impede que o agente de código leia seus arquivos .env e de credenciais, mantém os valores secretos fora do que o modelo vê e pode usar uma chave de um cofre local sem mostrá-la ao modelo. Uma chave que você colou no serviço de um terceiro está fora do alcance dele.

Devo guardar as chaves do meu provedor no console na nuvem de uma ferramenta?

Só se a ferramenta precisar delas para executar um serviço para você. Se ela puder rodar na sua máquina com a chave no seu próprio ambiente ou em um cofre local, é um lugar a menos para proteger. Se você guardar uma chave lá, defina um limite de gasto e use uma chave exclusiva para essa finalidade.

Com que frequência devo rotacionar as chaves de API?

A orientação da OpenAI recomenda definir uma data de expiração ao criar uma chave de projeto e ter um processo regular de rotação. A frequência depende do dano que uma chave pode causar: uma chave com limite de gasto baixo pode ser rotacionada com menos frequência do que uma sem limite.

---

Para o básico de manter um .env longe de um agente, veja como impedir que Claude Code, Codex CLI, Cursor e OpenCode leiam seu .env com um único comando. Para ver como um hook de agente pode ser contornado e como isso foi corrigido, leia como um agente de código podia ler seu arquivo .env de forma indireta. O zn-gate tem licença MIT, roda localmente e não exige conta: GitHub e Instalação.