Suas Chaves De API De IA Estão Na Mira: Railway, LiteLLM E OpenCode Em Menos De Uma Semana

Existe um arquivo .env em algum lugar da sua máquina que você não abre há meses. Dentro dele há uma chave de um provedor de IA criada para um protótipo, e essa mesma chave, se você parar para contar, provavelmente vive em mais quatro lugares: no painel de variáveis de ambiente de uma plataforma de deploy, num segredo do CI, na configuração de um proxy de modelos e, quem sabe, num console de uma ferramenta de código que alguém do time configurou num sábado. Eu não sei quantas cópias a minha chave tem. Essa dúvida, que acho que é de muita gente, foi o que me incomodou ao ler as notícias das últimas semanas.

O que me fez parar foi a coincidência. Na segunda quinzena de outubro, três incidentes distintos, em três tipos de produto diferentes, giraram em torno da mesma coisa: chaves de API de provedores de IA. Um console de ferramenta de código com chaves guardadas, uma plataforma de hospedagem com variáveis de ambiente e um pacote Python muito usado como gateway de modelos. Cada um tem sua própria história, mas lidos em sequência eles desenham um alvo que dá para nomear.

Preciso ser claro sobre o que este texto é. Não fui afetado por nenhum desses incidentes, não analisei nenhum dos sistemas e não reproduzi nada. O que sei vem de relatos públicos: TechCrunch, BleepingComputer, o artigo técnico do Wiz e um recap do The Hacker News. O post é de 9 de novembro e os relatos são de 19 a 26 de outubro, então investigações podem ter evoluído desde então. Quando um número for da empresa, vou dizer que é da empresa; quando for da imprensa, vou dizer que é da imprensa.

O caminho é este. Primeiro, o que cada relato afirma e o que deixa em aberto, um incidente por vez. Depois, por que chave de IA é um alvo tão atraente do ponto de vista financeiro, separando fato de alegação. Por fim, um checklist de rotação, escopo e limites de gasto, que é a parte que serve para segunda-feira de manhã.

---

Três Incidentes, Um Alvo Em Comum

Em ordem cronológica dos relatos: o TechCrunch publicou em 19 de outubro a matéria sobre o OpenCode; o BleepingComputer publicou em 22 de outubro o aviso da Railway; e o Wiz descreveu o comprometimento do LiteLLM, cuja versão maliciosa foi publicada em 21 de outubro. O recap semanal do The Hacker News, da semana de 26 de outubro, junta as peças. Uma ressalva: o recap resume o episódio do LiteLLM citando "late May"; como o Wiz traz horários precisos, uso a data do Wiz e registro que há relatos com datas divergentes.

O que une os três é o alvo, não a técnica. No OpenCode, o relato fala de invasores num sistema antigo, chaves guardadas num console e cobranças não autorizadas em contas de provedores. Na Railway, fala-se de variáveis de ambiente criptografadas que podem ter sido lidas em texto claro. No LiteLLM, o código malicioso procurava credenciais no ambiente onde o pacote era instalado. Em todos os casos, o que importa para quem ataca é uma string que dá acesso a um provedor de modelos e cobra no cartão de outra pessoa.

Existe uma moldura maior, e vale tratá-la com cuidado. A Railway disse, segundo o BleepingComputer, que o incidente faz parte de uma série de ataques contra provedores de inferência de IA. O recap do The Hacker News descreve uma campanha "sustentada e direcionada" em 20 de outubro com o objetivo de obter chaves de API de provedores de IA para ataques de destilação. Já o OpenCode chamou o seu incidente de "ataque de destilação em larga escala", e o próprio TechCrunch nota que a empresa não explicou como o ataque ocorreu e que céticos questionaram a ligação com destilação. Ou seja, a motivação de destilação é uma alegação dos afetados, com evidência pública limitada, e vou tratá-la assim.

---

OpenCode: O Console Como Cofre

Segundo o TechCrunch, em 19 de outubro, invasores entraram num sistema antigo do OpenCode durante a noite. A empresa disse que a violação afetou 1,4% dos usuários do OpenCode Console, uma plataforma online onde alguns usuários guardam chaves de API de serviços de IA. O anúncio saiu num sábado, e desenvolvedores relataram alertas de gasto durante a noite. Os usuários afetados foram avisados por e-mail, e a regra que a empresa passou foi simples: quem não recebeu e-mail não foi afetado.

O que ficou sem resposta é bastante. A matéria diz que não foi informado como os invasores entraram, nem como as chaves estavam armazenadas, nem a extensão total do uso indevido. Para quem guarda segredos, a segunda pergunta é a que mais pesa: criptografadas ou em texto claro, com que chave, onde? Sem essa resposta, quem estava no Console só consegue tratar as chaves como expostas, que é o que o conselho final da empresa também sugere.

As cobranças apareceram em contas da OpenAI, da Anthropic e do Google. O TechCrunch descreve valores na casa das centenas de dólares em alguns casos e poucos acima de US$ 1.000. Anthropic e Google bloquearam as chaves que julgaram expostas; a OpenAI trabalhou com o OpenCode para restaurar acesso e reembolsar créditos, e o OpenCode disse que os reembolsos estavam em andamento.

O cofundador Dax Raad afirmou que o app open source e a CLI não foram afetados e que as chaves expostas ficaram restritas ao Console. É uma distinção importante e a registro como declaração da empresa. Ela separa o produto que roda na sua máquina do serviço hospedado que guarda segredos. A pergunta de arquitetura que fica: por que uma chave de produção está num console de terceiros? Muitas vezes é só conveniência, e conveniência é o que um incidente cobra depois.

Raad também contou o lado defensivo, e é a parte mais incomum do relato. Segundo a matéria, os invasores tentaram entrar nos sistemas sem parar por 48 horas, e a equipe rodou agentes defensivos de IA 24 horas por dia. Modelos comerciais ajudaram na análise inicial, mas depois se recusaram a examinar o código malicioso quando os filtros de segurança foram ativados; só então a equipe ganhou acesso ao programa Daybreak Blue da OpenAI, com modelos menos propensos a recusar trabalho defensivo. É relato da empresa, não fato verificado por terceiros, mas levanta uma questão real: filtros de recusa podem atrapalhar a análise de malware, e quem faz resposta a incidente precisa saber disso antes da crise. O conselho final de Raad foi revogar e substituir as chaves diretamente com cada provedor, e o incidente seguia "ainda em andamento" na data da matéria.

---

Railway: Variáveis De Ambiente E Deploys Pausados

O relato da Railway vem do BleepingComputer, em 22 de outubro. A empresa detectou atividade suspeita no começo daquela semana e avisou que um terceiro não autorizado pode ter acessado variáveis de ambiente criptografadas. Para algumas delas, o conteúdo decifrado foi obtido. Essas variáveis podem incluir chaves de API, credenciais de banco de dados e credenciais de registry. A matéria diz que provavelmente só um subconjunto de usuários foi afetado, mas nenhum número foi publicado. A Railway reporta cerca de 4,8 milhões de usuários e mais de 16 milhões de serviços, o que dá a escala do universo em que esse subconjunto existe, sem dizer nada sobre o tamanho dele.

O ponto que me parece mais relevante para quem usa plataforma de deploy é o que "criptografadas" significa na prática. Variáveis de ambiente em plataformas assim são lidas pelo runtime do serviço para injetar o valor no processo, então em algum ponto da cadeia existe um componente capaz de decifrá-las. Quando o relato diz que o conteúdo decifrado foi obtido, ele sugere que o acesso foi a esse ponto, e não que alguém quebrou a criptografia. Isso é inferência minha; a matéria não detalha o mecanismo. Mas lembra que criptografia em repouso não protege contra um atacante que alcança quem tem a chave.

O BleepingComputer registra que o incidente faz parte de uma série de ataques contra provedores de inferência de IA e que esses provedores foram notificados e orientados a revogar todas as suas chaves por precaução. A matéria não diz se chaves de provedores de IA de clientes da Railway foram de fato expostas, e eu também não afirmo isso. O recap do The Hacker News pede para revogar e reaplicar variáveis sensíveis que estavam armazenadas antes de 21 de outubro. Um resultado de busca adicional indica que revogações de chaves em 24 de outubro foram descritas pela Railway como precaucionais, e não vou ler nada além disso nessa frase.

O conselho prático da Railway foi rotacionar todas as variáveis de ambiente e segredos, incluindo credenciais de registry privado, e verificar os logs de serviço. Deploys foram pausados, e os builds foram restaurados primeiro para os planos Pro e Enterprise, depois para Hobby, Free e Trial. A empresa disse que entraria em contato direto com usuários com comprometimento confirmado. Esse último ponto tem uma armadilha: quem não foi contatado não pode concluir que está seguro, porque "comprometimento confirmado" é uma condição estreita.

Dá para extrair um cenário a partir disso, e rotulo como hipotético. Imagine um time com dez serviços numa plataforma de deploy, cada um com a chave de IA, a URL do banco e o token do registry nas variáveis de ambiente. Num incidente como o descrito, o raio de impacto não é uma chave: é tudo o que estava naquele painel. Rotacionar só a chave do provedor de IA e esquecer a senha do banco, que está ao lado, é um erro fácil de cometer quando a pressa e o foco da notícia apontam para a IA. O próprio aviso da Railway lista as três categorias.

---

LiteLLM: Um .pth Que Roda Sem Ser Importado

O caso do LiteLLM é o mais técnico dos três e o que mais interessa a quem escreve Python. Segundo o Wiz, em 21 de outubro de 2026 a versão 1.107.0 foi publicada no PyPI às 11:39 UTC e colocada em quarentena até 13:20 UTC; as imagens Docker foram removidas por volta de 13:53 UTC. Foram afetadas a 1.107.0 e as tags Docker v1.107.0, latest, main-latest e main-stable. A versão segura mais recente informada é a 1.106.2. O artigo fala em cerca de 49 mil downloads, número que é da fonte e não deve ser confundido com o número de ambientes realmente comprometidos.

O mecanismo é o que torna o caso instrutivo. O pacote malicioso colocava três arquivos na raiz de site-packages. O primeiro, cook.pth, é um arquivo .pth, e o interpretador Python processa esses arquivos na inicialização; neste caso, ele importava o módulo cook a cada start do interpretador. O segundo, cook.py, rodava o coletor de credenciais e gravava um marcador em /tmp, e falhava no Windows. O terceiro, sitecustomize.py, só rodava em Linux e macOS, buscava um domínio num arquivo do GitHub e, se houvesse resposta, baixava e executava um script de segundo estágio, que segundo o artigo nunca foi observado ativo. O resultado é que o código roda mesmo que a aplicação nunca importe o LiteLLM. Segundo o artigo do Wiz, o uso de .pth junto com sitecustomize.py seria o primeiro caso documentado em campo.

O que o coletor procurava é uma lista longa. Credenciais e cookies de navegadores; credenciais da AWS, tanto de variáveis de ambiente quanto do serviço de metadados da instância; chaves de conta de serviço e credenciais padrão do GCP; tokens do Azure do cache da CLI; chaves de API de provedores de IA, como OpenAI, Anthropic e Cohere; chaves SSH e GPG e histórico de shell; e credenciais de provedores do banco PostgreSQL do LiteLLM Proxy. Os dados saíam criptografados, por HTTP, para um domínio parecido com o do projeto, no caminho /healthcheck. O artigo registra que credenciais AWS de role de instância roubadas foram validadas cerca de 4,5 horas depois, o que é compatível com LLMjacking, o uso de credenciais roubadas para consumir modelos por conta alheia.

Outra parte do relato fala de como o invasor publicou. Segundo a LiteLLM, ele usou tokens OAuth da GitHub CLI roubados de três engenheiros: uma conta disparou o workflow de release e outra aprovou. A empresa suspeita que os tokens vieram de logs de um deploy interno exposto, e os commits maliciosos foram para um repositório parecido com Berri-AI/litellm, não visível no GitHub. A LiteLLM diz ter revogado todos os tokens envolvidos. O desenho do ataque, porém, é familiar: não se quebrou o PyPI, quebrou-se a cadeia de quem publica. Já escrevi sobre esse risco geral em um post sobre supply chain de IA no pipeline de desenvolvimento, e este caso é uma ilustração concreta de por que o pipeline de release merece o mesmo cuidado que o de produção.

Uma coisa que o artigo do Wiz sugere, e que eu extraio como inferência, é que varrer ambientes Python por arquivos .pth suspeitos passa a ser uma verificação razoável. Não é uma solução, é um ponto de inspeção barato. A lição geral: instalar uma dependência é executar código, e isso num ambiente com credenciais é entregá-las.

---

Por Que Chave De IA É Dinheiro

Uma chave de provedor de modelos tem uma propriedade que poucas credenciais têm: ela é monetizável sem passos intermediários. Uma credencial de banco de dados exige que o atacante tenha acesso à rede e saiba o que fazer com os dados. Uma chave de IA exige apenas uma chamada HTTP, e cada chamada gera uma cobrança. Os relatos do OpenCode mostram isso de forma direta: gastos que apareceram como alertas durante a noite, cobranças de centenas de dólares e algumas acima de US$ 1.000, em contas de três provedores diferentes.

É nesse ponto que o assunto deixa de ser só segurança e entra em FinOps. Já escrevi sobre como os preços de cache e as promoções de LLM têm calendário e expiram, e a lógica complementar vale aqui: o custo de uma chave exposta não é só o que o atacante gasta, é o que você demora a perceber. Um teto de gasto e um alerta de pico transformam uma noite de abuso em um incômodo limitado, e a ausência deles transforma a mesma noite em uma fatura. Esses controles não bloqueiam ataque; apenas dão ao prejuízo um limite conhecido.

Separo agora fato, relato e alegação. Fato, segundo a imprensa: houve cobranças não autorizadas em contas de provedores de IA depois do incidente do OpenCode, e credenciais AWS roubadas no caso do LiteLLM foram validadas horas depois. Relato da empresa: o OpenCode diz que foi um ataque de destilação em larga escala, e a Railway e o recap do The Hacker News associam o conjunto a ataques de destilação. Alegação com evidência limitada: que a motivação seja, de fato, extrair capacidade de modelos por destilação. O TechCrunch mesmo registra que céticos questionaram essa ligação. Para quem precisa decidir o que fazer, a motivação importa menos do que parece: a chave exposta vale dinheiro e vale acesso, seja qual for o plano de quem a roubou.

Há ainda um ponto de identidade. Uma chave de API de IA é uma credencial de uma identidade não humana, e costuma ser a mais permissiva possível: um único segredo, sem expiração, sem escopo por projeto, reutilizado em vários lugares. Discuti esse problema mais amplo em um post sobre identidades não humanas e agentes, e os incidentes de outubro são um exemplo de por que o modelo "uma chave para tudo" é frágil. Quando uma chave está em cinco lugares, o incidente em qualquer um deles obriga a rotacionar os cinco.

---

Checklist De Rotação, Escopo E Limites

Tudo o que segue são boas práticas gerais, extraídas dos próprios avisos da Railway, do OpenCode e do Wiz e de extensões minhas que rotulo como tal. Nenhuma delas é garantia de proteção, e nenhuma foi testada por mim contra esses ataques. O primeiro princípio vem direto dos relatos: rotacione na origem. Se a chave é da Anthropic, da OpenAI ou do Google, a revogação e a criação da nova acontecem no painel do provedor, não só na plataforma onde você a guarda. Apagar a variável no painel de deploy não invalida a chave que já foi copiada.

O segundo é reduzir o que cada chave pode causar. Quando o provedor permite, prefira chaves com escopo e orçamento por projeto, em vez de uma chave de conta para tudo. Configure limites de gasto e alertas de pico, e confira se o alerta chega a alguém que vai agir, e não a uma caixa de e-mail esquecida. O terceiro é segregar por ambiente: desenvolvimento, homologação e produção com chaves diferentes, de modo que um ambiente comprometido não entregue o de produção. Sobre como pensar custo e controle de tokens em produção, escrevi em um post sobre gestão de tokens em produção, que complementa este ponto.

O quarto é onde as chaves moram. Não guarde chaves de produção em consoles de terceiros sem necessidade; o caso do OpenCode mostra o que um console comprometido significa. O quinto é a cadeia de dependências: fixe versões, verifique integridade e desconfie de atualização automática em ambiente que tem credenciais. Num ambiente Python, inclua na rotina uma varredura de arquivos .pth e de sitecustomize.py inesperados em site-packages, que é uma inferência minha a partir do artigo do Wiz. O sexto é observação: monitore picos de gasto e revise logs de serviço, como a Railway pediu. Já escrevi sobre um vetor parecido em outro contexto, o de arquivos de instrução maliciosos que viram canal de ataque; a moral é a mesma, tudo o que um agente ou um pipeline lê e executa é superfície de ataque.

Um cenário hipotético ajuda a ver o tamanho do trabalho. Imagine um time com 30 chaves de IA espalhadas por quatro lugares: painel de deploy, CI, um proxy de modelos e arquivos .env de máquinas pessoais. O primeiro passo é um inventário, que é a parte mais chata e mais valiosa: para cada chave, quem criou, de qual provedor, em que ambiente, em que lugares existe. O segundo é ordenar por risco, com as de produção e as sem teto de gasto na frente. O terceiro é rotacionar na origem, uma por vez, atualizando todos os lugares onde ela existia e anotando a data. Só depois vêm os limites e os escopos, para que a próxima rotação seja mais barata.

---

Conclusão

O que mais me chamou a atenção nesses três relatos não foi a sofisticação técnica, embora o truque do .pth seja engenhoso, mas o quão banal é o alvo. Uma string em um console, em um painel de variáveis, em um ambiente Python. A defesa que as próprias empresas recomendam também é banal, e justamente por isso fácil de adiar: revogar, substituir, limitar, inventariar. O risco de adiar é que o custo aparece como fatura, num fim de semana.

Preciso repetir os limites do que li. Descrevo relatos públicos de 19 a 26 de outubro, não uma investigação própria, e investigações podem ter avançado desde então. Não sei como o OpenCode foi invadido, não sei se chaves de IA de clientes da Railway foram de fato expostas, e não sei se há ligação entre os três incidentes além da coincidência de alvo e de datas. A motivação de destilação é alegação dos afetados com evidência pública limitada.

No fim, minha posição é de incômodo prático, não de alarme. Se a pergunta for quantas cópias a sua chave tem e onde, e a resposta for "não sei", esse já é o primeiro item do checklist, e vale resolver antes do próximo aviso chegar no e-mail. Não tenho certeza de que a próxima vez será parecida com esta. Tenho certeza de que quem souber onde estão as suas chaves vai gastar menos tempo na próxima.

Fontes:

• TechCrunch — Hackers hit AI coding tool OpenCode, running up charges on users' AI accounts
• BleepingComputer — Railway warns devs to rotate secrets after potential breach
• Wiz — LiteLLM Compromised, Steals Credentials
• Endor Labs — LiteLLM 1.107.0 compromised (conhecido só por resultado de busca; nenhum fato atribuído)
• The Hacker News — Weekly Recap
• GridinSoft — Railway explains why new API keys were revoked (conhecido só por resultado de busca; nenhum fato atribuído)