Na madrugada de 17 de outubro, alguns programadores começaram a receber alertas de utilização invulgar. OpenAI, Anthropic e Google estavam a registar pedidos que não tinham feito. Em certos casos, as cobranças chegaram a centenas de dólares; num relato, ultrapassaram os 1.700 dólares.
A origem estava no OpenCode Console, uma plataforma online opcional onde algumas equipas guardavam as suas credenciais para usar modelos de inteligência artificial. Um intruso acedeu a um sistema legado da OpenCode, e 1,4% dos utilizadores do Console foram afetados.
O caso é pequeno em números, mas revela um problema maior: as credenciais de desenvolvimento tornaram-se um dos pontos mais frágeis da operação digital. E não é preciso partilhar a password errada nem fazer algo obviamente imprudente. Às vezes, basta colar uma chave numa ferramenta para ganhar conveniência.
O que aconteceu no breach do OpenCode
O OpenCode é um agente de programação open source, modelo-agnóstico e usado como alternativa a ferramentas como Claude Code e Cursor. Permite trabalhar com modelos de vários fornecedores, incluindo OpenAI, Anthropic e Google.
Na noite de 16 para 17 de outubro, um intruso alcançou um sistema antigo da OpenCode. A empresa notificou por email os utilizadores afetados na manhã de 17 de outubro, com o assunto “Action Required: Potential provider key breach”. Segundo a notificação, a exposição mais antiga possível foi às 00:30 UTC de 17 de outubro. Quem não recebeu esse email não fazia parte do grupo afetado.
É importante distinguir o Console da aplicação e da linha de comandos. A falha atingiu o Console, que é opcional e pode guardar keys para uma equipa usar modelos sem que cada pessoa veja a credencial. A aplicação open source e a linha de comandos não foram afetadas. O cofundador Dax Raad sublinhou que, quando as keys são usadas localmente, “essas keys nunca nos chegam”.
A OpenCode descreveu o incidente como relacionado com um “ataque de destilação em larga escala” e disse estar a trabalhar com Google, OpenAI e Anthropic. Destilação é uma técnica legítima de aprendizagem automática: treinar um modelo mais pequeno com respostas produzidas por um modelo maior. Torna-se um ataque quando é feita em larga escala através de consultas não autorizadas.
Mas há uma distinção a manter: a OpenCode não explicou como o intruso entrou, o que era o sistema legado, nem como a exposição das keys se relaciona exactamente com a destilação. Alguns observadores questionaram esse enquadramento e disseram que o uso das keys para treino não estava provado. O breach e o potencial comprometimento de credenciais foram confirmados; o método e o propósito exactos continuam por esclarecer. Também não parecia haver indicação de exposição de outros dados.
Porque apagar a key do painel não chega
Uma key de fornecedor — também chamada chave de API — é uma credencial que permite a uma aplicação pedir serviços a outro sistema. Neste caso, permite fazer pedidos a um modelo de IA. Muitas destas keys funcionam como credenciais portadoras: quem tiver uma cópia pode usá-la, e os pedidos podem ser faturados à conta associada até a key ser revogada.
Aqui está a armadilha: apagar a key do Console não revoga a key no fornecedor. Se alguém já tiver copiado a credencial, removê-la do painel onde estava guardada não impede essa pessoa de a usar. A revogação tem de ser feita no dashboard de quem emitiu a key — por exemplo, OpenAI, Anthropic ou Google.
O mesmo princípio aplica-se aos limites de utilização. Um budget configurado no Console só pode controlar pedidos que passam pelo gateway desse serviço. Uma key copiada pode ser usada directamente contra o fornecedor, fora desse percurso. Por isso, o controlo relevante tem de estar do lado do fornecedor.
Quando colas uma key numa ferramenta de terceiros, confias-lhe o acesso. Mas a autoridade para revogar essa key continua a ser do fornecedor que a emitiu.
As cobranças são reais; os totais não são um balanço final
Utilizadores reportaram cobranças que não reconheciam em várias plataformas ao mesmo tempo. Os casos partilhados publicamente incluíram cerca de 281 dólares na OpenAI e 168 dólares na Anthropic; outro utilizador relatou 400 dólares na Anthropic e aproximadamente 200 euros na Google, cujo projecto foi depois suspenso. Também foram relatadas perdas de 1.700 dólares e totais acima dos 1.000 dólares.
São relatos individuais, não um total oficial das perdas. A Google suspendeu projectos de alguns utilizadores por detectar actividade abusiva compatível com recursos sequestrados. Anthropic e Google bloquearam keys que consideraram expostas. A OpenAI disse ter trabalhado com a OpenCode para restaurar o acesso e reembolsar créditos usados no ataque; os reembolsos estavam em curso.
Um reembolso ajuda, mas não apaga o trabalho: identificar a key, revogá-la, actualizar scripts e aplicações, verificar a facturação e recuperar acessos suspensos. O impacto não se mede apenas pelo valor da cobrança.
A ironia: a IA também bloqueou parte da investigação
Durante a resposta ao incidente, os modelos usados pela OpenCode para analisar código malicioso começaram a recusar pedidos quando o conteúdo activava os seus filtros de segurança. A equipa só conseguiu melhorar a capacidade de investigação depois de receber acesso ao programa Daybreak Blue da OpenAI, que disponibiliza modelos menos propensos a recusar pedidos de trabalho defensivo de segurança.
Guardrails são salvaguardas concebidas para limitar utilizações perigosas de um modelo. A intenção é reduzir o risco de ajudar num ataque. O problema aparece quando o sistema não distingue um atacante de alguém que está a analisar o ataque para o travar.
Não foi um caso isolado. Em julho, a Hugging Face relatou uma dificuldade semelhante ao tentar analisar registos de uma intrusão envolvendo agentes de IA autónomos. A situação expõe uma assimetria: os atacantes podem tentar usar modelos para automatizar a ofensiva, enquanto quem responde pode encontrar restrições precisamente ao analisar código ou actividade maliciosa.
Nos 48 horas seguintes ao breach, segundo Raad, os atacantes continuaram a tentar entrar nos sistemas da OpenCode. A equipa manteve agentes de IA defensivos a trabalhar sem parar. A operação de segurança, portanto, não é um evento que termina quando se envia o email de notificação. É uma resposta contínua.
Como se perde o controlo das keys
Raramente começa com alguém a adivinhar uma credencial. Mais frequentemente, começa com acumulação:
- uma key partilhada pela equipa para simplificar o acesso;
- uma key guardada num painel de terceiros por conveniência;
- uma key deixada num script antigo para evitar alterações;
- uma credencial colada numa ferramenta “só para testar”;
- nenhuma revisão das keys activas ou dos limites definidos.
Nenhuma destas decisões tem de ser negligente. O problema é o efeito conjunto: cada integração acrescenta um sítio onde a credencial pode estar guardada, uma pessoa ou ferramenta que a pode usar e uma possível via de exposição.
Foi isso que tornou o caso instrutivo. O utilizador podia ter feito tudo de forma razoável do seu ponto de vista: guardar a key num painel para simplificar o acesso da equipa. Ainda assim, quando uma plataforma é comprometida, o nível de exposição depende do que lá foi guardado e dos controlos que já existiam no fornecedor.
O mínimo a fazer para proteger as tuas keys
Usa uma key diferente para cada ferramenta. Se uma for comprometida, sabes de onde veio e podes revogá-la sem interromper todas as outras integrações. Evita partilhar a mesma credencial entre pessoas, scripts e serviços.
Define limites e alertas no dashboard do fornecedor. Não te fiques pelo orçamento da ferramenta onde guardaste a key. Confirma que o limite ou alerta está activo do lado da OpenAI, Anthropic ou Google e percebe exactamente o que consegue travar.
Revê as keys pelo menos uma vez por trimestre. Identifica as que estão activas, onde são usadas e quem precisa delas. Revoga as que já não servem nenhum processo.
Pára antes de colar uma key “só para experimentar”. Procura uma ligação de conta, uma credencial dedicada ou uma alternativa que limite o acesso. Se não existir, decide conscientemente se a ferramenta merece receber essa key.
Prepara o plano de resposta antes de precisares dele. Se suspeitares de exposição: revoga a key no fornecedor, cria uma substituta, actualiza todos os scripts e aplicações que usavam a antiga e revê utilização e facturação desde pelo menos 16 de outubro.
Estas práticas complementam, mas não substituem, uma política de acessos mais ampla. No artigo “Passwords e agentes de IA: como dar as chaves sem perder a casa”, exploro a importância de limitar o que cada ferramenta pode fazer e de manter formas claras de cortar o acesso.
A key é dinheiro com asas
A destilação pode aumentar a procura por credenciais capazes de fazer grandes volumes de pedidos. Mas, neste caso, a ligação exacta entre essa prática e o breach ainda não foi explicada. Não precisas de assumir o pior para perceber o risco: uma key exposta pode ser usada para gerar custos, provocar bloqueios e obrigar-te a reconstruir acessos.
A regra é simples: uma key por ferramenta, limites no lado do fornecedor e revogação como rotina. A key não é apenas um segredo técnico. É uma autorização para gastar na tua conta.
Sabes quantas keys de IA estão activas no teu negócio, onde são usadas e que limites as protegem? Se não sabes, começa por inventariá-las. É muito melhor fazê-lo agora do que quando os alertas de utilização começarem a disparar.