Ir para o conteúdo principal
Voltar aos artigos

Anthropic vaza 500 mil linhas de código do Claude Code: anatomia de um erro que qualquer dev pode cometer

·7 min de leitura·37 visualizações

No dia 31 de março de 2026, a Anthropic cometeu um erro que toda empresa de tecnologia teme. Vazou o código fonte completo de um dos seus produtos mais importantes: 500 mil linhas de código do Claude Code, publicamente disponíveis no NPM para qualquer pessoa baixar e analisar.

Não foi ataque hacker. Não foi vulnerabilidade zero-day. Foi erro humano. Alguém publicou o pacote errado. E é o segundo vazamento grave da empresa em menos de uma semana.

Se você trabalha com desenvolvimento, precisa entender o que aconteceu. Porque o mesmo pode acontecer com você.

O que é Claude Code e por que isso importa

Claude Code é uma ferramenta de programação assistida por IA da Anthropic (a mesma empresa que faz o chatbot Claude). Pense no GitHub Copilot, mas com capacidades mais avançadas. A ferramenta não apenas sugere código, ela pode:

  • Navegar por projetos inteiros
  • Executar comandos no terminal
  • Criar e modificar múltiplos arquivos
  • Debugar problemas complexos
  • Seguir instruções de alto nível ("adicione autenticação JWT neste projeto")

Grandes empresas adotaram Claude Code justamente porque ele é muito bom. Mas o segredo não está só no modelo de IA que a Anthropic usa. Está também no agentic harness.

O que é "agentic harness" (e por que ele vale tanto)

Aqui vai uma analogia: o modelo de IA (GPT-4, Claude, Gemini) é como o motor de um carro. Poderoso, mas sozinho não faz muita coisa. Você precisa de volante, freios, câmbio. A estrutura que permite controlar o motor.

O agentic harness é essa estrutura. É o código que:

  • Diz para a IA COMO usar ferramentas (terminal, editor de texto, navegador)
  • Aplica regras de segurança (não pode deletar tudo, não pode executar código malicioso)
  • Formata as respostas de forma útil
  • Gerencia contexto e memória
  • Define o "comportamento" da ferramenta

É a receita secreta. E foi exatamente isso que vazou.

Como o vazamento aconteceu

O NPM (Node Package Manager) é uma plataforma onde desenvolvedores JavaScript publicam pacotes de código para outras pessoas usarem. Tipo uma biblioteca pública de código.

Quando você desenvolve um pacote NPM, normalmente você:

  1. Escreve o código fonte (legível, com comentários, estrutura clara)
  2. Compila/minifica esse código (transforma em versão otimizada, difícil de ler)
  3. Publica APENAS a versão compilada no NPM

A Anthropic pulou a etapa 2. Alguém rodou o comando de publicação direto no código fonte. Resultado: 1.900 arquivos, 500 mil linhas de código, tudo exposto.

Foi o equivalente a enviar o projeto inteiro do Google Drive para o cliente ao invés de enviar só o PDF final.

Por que isso é grave

1. Concorrentes podem copiar funcionalidades

Com o código fonte na mão, qualquer empresa competidora pode ver:

  • Como o Claude Code decide qual ferramenta usar em cada situação
  • Quais prompts internos fazem a IA funcionar melhor
  • Como eles resolvem problemas de contexto longo
  • Truques de engenharia de prompt que levaram meses para descobrir

É tipo a Coca-Cola vazar a receita completa.

2. Revela arquitetura interna

O código expõe:

  • APIs internas não documentadas
  • Como o sistema se comunica com os servidores da Anthropic
  • Estrutura de autenticação
  • Endpoints que não deveriam ser públicos

Isso facilita MUITO a vida de quem quer atacar ou burlar o sistema.

3. Confirma produtos não anunciados

O código vazado contém referências ao Capybara, um novo modelo de IA que a Anthropic ainda não anunciou oficialmente. Pesquisadores de segurança que analisaram o código descobriram que:

  • Vai ser mais poderoso que o Claude Opus (modelo atual mais forte)
  • Provavelmente terá versão "fast" e "slow"
  • Terá contexto ainda maior
  • Será mais caro

Empresas ODEIAM quando produtos não anunciados vazam. Estraga planejamento de marketing, dá vantagem para concorrentes se prepararem.

4. Pode facilitar ataques sofisticados

Se você conhece exatamente quais regras de segurança a IA segue, fica mais fácil criar prompts que burlam essas regras. É tipo saber exatamente onde estão as câmeras de segurança de um banco.

Contexto: não foi a primeira vez

  • Fevereiro 2025: Primeiro vazamento similar do Claude Code
  • 26 de março 2026: Vazaram 3.000 arquivos internos, incluindo rascunho de blog post sobre o modelo Mythos (aparentemente outro nome para Capybara)
  • 31 de março 2026: Este vazamento (código fonte completo)

Três vazamentos em 13 meses. Isso não é azar. É falha de processo.

O que a Anthropic disse

Segundo porta-voz da empresa:

"Nenhum dado sensível de clientes ou credenciais foram expostos. Foi um problema de empacotamento de release causado por erro humano, não uma brecha de segurança. Estamos implementando medidas para prevenir que isso aconteça novamente."

Tecnicamente correto: não vazaram senhas de usuários nem conversas privadas. Mas minimizar como "problema de empacotamento" ignora a gravidade de expor arquitetura interna.

Como evitar isso no SEU projeto

Aqui vai o checklist prático:

1. Use .npmignore (ou equivalente)

Crie um arquivo .npmignore no seu projeto NPM listando o que NÃO deve ser publicado:

src/
tests/
.env
.env.*
*.md
docs/
scripts/
.git/

2. Configure o package.json corretamente

Use a propriedade files para listar APENAS o que deve ser publicado:

{
  "files": [
    "dist/",
    "README.md",
    "LICENSE"
  ]
}

Se files estiver definido, apenas esses arquivos vão. Tudo resto fica de fora.

3. Teste ANTES de publicar

# Simula o que seria publicado (não publica de verdade)
npm pack

# Descompacta o arquivo .tgz gerado
tar -xzf seu-pacote-1.0.0.tgz

# OLHE O QUE TEM DENTRO
ls -la package/

Se você ver pasta src/ com código fonte, PARE. Não publique.

4. Automatize o processo

Crie um script de release que OBRIGA você a passar por checklist:

#!/bin/bash
# release.sh

echo "🔍 Verificando o que será publicado..."
npm pack --dry-run

echo "⚠️  Confira a lista acima. Pressione ENTER para continuar ou Ctrl+C para abortar"
read

npm publish

5. Use ferramentas de análise

  • npm-packlist: mostra exatamente o que vai ser publicado
  • publint: analisa seu package.json e avisa problemas
  • snyk: detecta se você tá publicando credenciais ou segredos

6. Revisar releases em dupla

Antes de publicar qualquer versão importante:

  • Pessoa A prepara o release
  • Pessoa B revisa o que vai ser publicado
  • Ambas precisam aprovar

Parece burocrático? A Anthropic perdeu vantagem competitiva de milhões de dólares por não fazer isso.

7. Monitore o que já foi publicado

Configure alertas para:

  • Novos downloads do seu pacote (pico suspeito pode indicar vazamento)
  • Issues abertas no GitHub mencionando "código fonte" ou "security"
  • Menções no Twitter sobre seu pacote

Lições aprendidas

  1. Processos existem por algum motivo

    • A Anthropic provavelmente TINHA processo de release
    • Alguém deu um jeito de pular (urgência? pressa? "só dessa vez"?)
    • "Só dessa vez" sempre dá errado
  2. Automação > confiança

    • Não confie que a pessoa vai lembrar de compilar antes de publicar
    • Automatize para que seja IMPOSSÍVEL publicar código fonte
  3. Empresas grandes erram igual às pequenas

    • Se a Anthropic (avaliada em bilhões) faz isso, você também pode
    • A diferença é que eles têm mais a perder
  4. Vazamento de código != vazamento de dados de usuários

    • Imprensa mistura tudo ("data leak")
    • São problemas diferentes com gravidades diferentes
    • Ambos são ruins, mas o impacto é distinto

Conclusão

O vazamento da Anthropic não foi causado por hacker genial ou vulnerabilidade zero-day. Foi alguém apertando "publish" sem verificar o que estava enviando.

A boa notícia: é evitável. Com processos simples, automação básica e cultura de revisão, você elimina 99% do risco.

A má notícia: processos só funcionam se você seguir eles. Sempre. Sem exceções. Sem "só dessa vez".

Se você mantém pacotes NPM (ou PyPI, RubyGems, qualquer registro público), reserve 30 minutos hoje para:

  1. Verificar o que está publicado (npm pack)
  2. Adicionar .npmignore ou configurar files no package.json
  3. Criar script de release com revisão obrigatória

30 minutos hoje podem evitar manchete embaraçosa amanhã.


Fontes:

Continue lendo

KYAML torna manifestos Kubernetes mais previsíveis

KYAML define uma forma mais rígida e consistente de escrever YAML para Kubernetes, mantendo compatibilidade com as ferramentas existentes.

·18 visualizações