Quando seu agente encontra uma vulnerabilidade

Nicholas Carlini, cientista de pesquisa na Anthropic, apontou o Claude Code para o código-fonte do kernel do Linux e pediu para encontrar vulnerabilidades. A configuração: um script bash de 10 linhas mais um container Docker com builds instrumentados por ASAN. Iterar pelos arquivos-fonte, pedir ao modelo para procurar bugs, passar para o próximo arquivo.¹³

O resultado, conforme detalhado no relato de Michael Lynch sobre a palestra:² um heap buffer overflow remotamente explorável no cache de replay LOCK do NFSv4, presente desde março de 2003 — anterior ao próprio Git. Dois clientes NFS cooperando podem ler memória sensível do kernel ao estourar um buffer de 112 bytes com um lock owner ID de 1.024 bytes. Carlini encontrou pelo menos mais quatro vulnerabilidades no kernel na mesma varredura. Separadamente, a mesma metodologia produziu 122 inputs causando crashes enviados à Mozilla, dos quais 22 receberam CVEs.³ Ele descreveu “várias centenas de crashes” que ainda não teve tempo de validar e reportar.²

São vulnerabilidades confirmadas, reportadas aos mantenedores, encontradas por um agente usando Opus 4.6 — a mesma classe de modelo que profissionais executam diariamente para code review, refatoração e desenvolvimento de funcionalidades. Carlini apresentou as descobertas na conferência de segurança de IA [un]prompted em abril de 2026.¹

Resumo

A metodologia de Carlini foi mínima: iterar pelos arquivos-fonte, pedir ao Claude para encontrar vulnerabilidades em cada um, verificar hits com asserções do ASAN. Opus 4.6 encontrou substancialmente mais vulnerabilidades que Opus 4.1 (8 meses mais antigo) ou Sonnet 4.5 (6 meses mais antigo), sugerindo que um limiar de capacidade foi cruzado recentemente.² O gargalo agora é a validação humana, não a descoberta por IA. Isso tem implicações diretas para como profissionais constroem hooks de segurança, conduzem code review e pensam sobre auditoria assistida por agentes.

Pontos principais

• Engenheiros de segurança: A capacidade é real e está melhorando rápido. Se você usa code review assistido por agentes, seus hooks de segurança PreToolUse são mais importantes do que nunca — não para bloquear o Claude, mas para controlar o que ele pode fazer com o que encontra.
• Construtores de harness: O gargalo de verificação (“várias centenas de crashes que não validei”) é um problema de harness. Triagem automatizada, deduplicação e classificação de severidade são a próxima camada de infraestrutura.
• Todos os demais: O mesmo modelo que introduz regressões de performance de 446x também encontra bugs que 23 anos de revisão humana não detectaram. Ambos são verdade simultaneamente.

A metodologia

A abordagem de Carlini não exigiu um framework de segurança customizado, um modelo fine-tuned ou prompts especializados. Ele descreveu como um “script bash de 10 linhas mais container Docker”:³

1. Compilar o alvo com instrumentação ASAN (AddressSanitizer)
2. Iterar pelos arquivos-fonte, usando o modelo para classificar relevância de segurança
3. Enviar ao Claude Code um prompt com enquadramento de capture-the-flag para arquivos de alta relevância
4. Executar múltiplas passadas por alvo (5-20 dependendo do codebase)
5. Usar agentes de crítica automatizados para verificar achados antes da divulgação

O enquadramento de capture-the-flag importa. Dizer ao modelo “este código tem um bug” ativa um modo diferente de “revise este código em busca de problemas”. Desenvolvedores perceberam o mesmo padrão no uso diário — o Claude encontra mais problemas quando você diz que um problema existe do que quando pergunta se um pode existir.²

O custo da varredura é medido em API tokens, não em pessoa-meses. Carlini encontrou cinco vulnerabilidades confirmadas no kernel do Linux e 22 CVEs do Firefox usando um CLI de agente comum.³ A mesma ferramenta que escreve seus testes unitários e formata seus imports.

O limiar de capacidade

A descoberta mais impressionante é a diferença entre gerações de modelos. Carlini tentou reproduzir seus resultados com modelos mais antigos:²

• Opus 4.6 (lançado ~2 meses antes da palestra): encontrou o heap overflow e múltiplas vulnerabilidades adicionais
• Opus 4.1 (8 meses antes): encontrou apenas uma pequena fração
• Sonnet 4.5 (6 meses antes): encontrou apenas uma pequena fração

Algo cruzou um limiar entre gerações de modelos. A capacidade de manter um codebase complexo em contexto, raciocinar sobre fluxo de dados através de fronteiras de funções e identificar incompatibilidades sutis de especificação parece ter emergido ao invés de melhorar gradualmente.

Carlini declarou diretamente: “Eu nunca encontrei uma dessas na minha vida. Isso é muito, muito, muito difícil de fazer. Com esses modelos de linguagem, eu tenho vários.”²

O paradoxo

A mesma arquitetura de agente que introduz regressões de performance — 118 funções com lentidões de 3x a 446x — também encontra vulnerabilidades de segurança que décadas de revisão humana especializada não detectaram. São aspectos complementares do mesmo perfil de capacidade. Pesquisa de vulnerabilidades é fundamentalmente reconhecimento de padrões contra classes conhecidas (buffer overflows, use-after-free, erros de sinalização de inteiros), o que é uma força de LLM.⁴ Otimização de performance exige o oposto: raciocinar sobre contextos específicos de execução, comportamento de cache e complexidade algorítmica. O modelo reconhece um buffer overflow em milhões de linhas de código, mas não consegue dizer que um hash map é mais lento que um array ordenado para seu padrão de acesso. Construa seu harness adequadamente — hooks de segurança que sinalizam achados, hooks de performance que medem antes de commitar.

O gargalo de verificação

A admissão mais reveladora de Carlini: “Eu tenho tantos bugs no kernel do Linux que não consigo reportar porque ainda não os validei.”²

O gargalo mudou da descoberta para a triagem. Encontrar vulnerabilidades potenciais agora é mais barato do que confirmar que são reais. Isso cria um novo problema de infraestrutura para equipes de segurança:

Descoberta é automatizada. Um agente pode varrer um codebase em horas.

Verificação é manual. Cada vulnerabilidade potencial precisa de uma prova de conceito, uma avaliação de impacto e um processo de divulgação responsável.

Triagem é a lacuna. Classificar centenas de achados gerados por agentes em vulnerabilidades reais, falsos positivos e ruído de baixa severidade é o trabalho que ainda não tem boas ferramentas.

É o mesmo padrão que vemos no code review assistido por agentes: o agente produz output bruto mais rápido do que humanos conseguem avaliar. O valor não está na geração — está na infraestrutura que processa, filtra e direciona o output.

Para construtores de harness, isso significa que o próximo hook de alto valor não é um scanner de segurança. É um sistema de triagem de segurança: deduplicação, classificação de severidade, filtragem de falsos positivos e geração automática de provas de conceito. Os hooks de governança que controlam o output do agente são mais importantes que as próprias capacidades de varredura.

O que isso significa para profissionais

Se você executa Claude Code em codebases de produção, já está rodando um sistema capaz de encontrar vulnerabilidades reais. A questão não é se a capacidade existe — é se seu harness foi projetado para lidar com o que o agente encontra.

Três movimentos práticos:

Adicione uma varredura de segurança ao seu pipeline de review. Um hook PostToolUse em Write/Edit pode disparar uma varredura de segurança direcionada nos arquivos alterados. O hook lê o caminho do arquivo do stdin (Claude Code passa o evento JSON no stdin para hooks):

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking — runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

Isso é um ponto de partida, não algo pronto para produção — você adicionaria deduplicação, filtragem de severidade e rate limiting. Porém, o padrão central corresponde à metodologia de Carlini: um loop pelos arquivos com um prompt direcionado.³

Construa infraestrutura de triagem. Achados brutos de vulnerabilidades sem classificação de severidade são ruído. Se seu agente produz 50 achados por varredura, você precisa de deduplicação automatizada e pontuação de prioridade antes que um humano veja a lista. Isso é um problema de harness, não um problema de modelo.

Aceite o paradoxo. O mesmo modelo que precisa de guardrails de performance é genuinamente excelente em reconhecimento de padrões de segurança. Projete seu harness para aproveitar a força e compensar a fraqueza. Hooks de segurança que varrem. Hooks de performance que medem. Hooks de qualidade que verificam. Cada um cobre o que os outros perdem.

A vulnerabilidade de 23 anos no Linux não estava escondida. Estava à vista, em um arquivo que milhares de engenheiros tinham lido. O modelo a encontrou porque reconhecimento de padrões em escala é o que esses sistemas fazem. A lição não é que agentes são melhores que humanos em segurança. A lição é que agentes cobrem uma superfície diferente — e o harness que orquestra ambos é o que torna a combinação confiável.

Fontes

Perguntas frequentes

Posso reproduzir a abordagem de Carlini com Claude Code?

A metodologia está documentada na entrevista do podcast.³ O loop central: compilar com ASAN, iterar pelos arquivos-fonte, enviar ao Claude um prompt com enquadramento de capture-the-flag, verificar hits. Carlini reportou que Opus 4.6 encontrou significativamente mais vulnerabilidades que modelos mais antigos — resultados com outras gerações de modelos podem variar.

Isso significa que agentes de IA são melhores que humanos para encontrar bugs de segurança?

Não. Significa que agentes cobrem uma superfície diferente. Agentes se destacam em reconhecimento de padrões contra classes de vulnerabilidades conhecidas em grandes codebases. Humanos se destacam em entender vetores de ataque inéditos, falhas de lógica de negócio e propriedades de segurança dependentes de contexto. A combinação é mais forte que qualquer um sozinho.

Devo me preocupar com atacantes usando essa capacidade?

Carlini alertou explicitamente sobre “uma grande onda vindo”. A mesma capacidade que ajuda defensores a encontrar vulnerabilidades está disponível para atacantes. A assimetria é que defensores podem automatizar triagem e correção, enquanto atacantes ainda precisam desenvolver exploits — mas a diferença na descoberta está diminuindo.