Um agente de código com IA consegue encontrar vulnerabilidades de segurança?

Sim, principalmente falhas de lógica que scanners baseados em padrões não pegam, como uma rota de API sem verificação de propriedade. Ele também gera falsos positivos e deixa coisas passar, então trate a saída como pistas a verificar e continue rodando scanners determinísticos em paralelo.

O que o /security-review faz no Claude Code?

Ele analisa as mudanças da sua branch atual em busca de vulnerabilidades, comparando com a branch padrão do remote origin, e aponta riscos como injeção, problemas de autenticação e exposição de dados. Precisa de um remote origin. Revisa o diff, não o repositório inteiro.

Devo passar meu arquivo .env para o agente verificar meus segredos?

Não. Nunca cole segredos reais em um prompt. Use um scanner de segredos como o gitleaks para encontrá-los, deixe o .env fora do que o agente lê e, se uma chave real já foi commitada, rotacione-a primeiro e só depois limpe o histórico.

Como lidar com falsos positivos de uma revisão de segurança feita por IA?

Peça evidências para cada achado: arquivo e linha, de onde vem a entrada não confiável, o caminho até a chamada arriscada e por que a validação existente não cobre o caso. Faça uma sessão nova ou outro modelo verificar os achados de alta severidade antes de mudar o código.

Uma auditoria de segurança com IA substitui um teste de invasão?

Não. Ela lê o código-fonte do seu checkout e encontra falhas prováveis cedo e a baixo custo. Não testa o sistema em execução, a configuração nem a infraestrutura. Para qualquer coisa que lide com dinheiro, saúde ou dados pessoais, inclua uma revisão profissional.

Encontre vulnerabilidades de segurança no código com IA

Para encontrar vulnerabilidades de segurança no seu código com IA, rode primeiro os scanners determinísticos rápidos (segredos, dependências, regras estáticas) e depois dê a um agente de código uma classe de vulnerabilidade por vez, pedindo que ele rastreie como a entrada não confiável percorre o código. Trate cada achado como uma alegação a verificar, corrija com um teste de regressão e mantenha o agente longe de segredos reais o tempo todo.

Este guia trata de auditar o seu próprio código, de forma defensiva. Se você quer saber como impedir que o próprio agente cause estragos (prompt injection, comandos destrutivos, servidores MCP maliciosos), leia antes segurança de agentes de código com IA; este post parte do princípio de que essas proteções já estão no lugar. Os nomes de ferramentas e comandos abaixo seguem a documentação oficial de outubro de 2026.

No que uma auditoria com IA é boa, e no que não é

Scanners estáticos e agentes de código encontram bugs diferentes, e é por isso que você quer os dois.

	Scanners determinísticos	Agente de código
Ponto forte	Padrões conhecidos, versões de pacotes sabidamente vulneráveis, formatos de segredos	Lógica: quem pode chamar esta rota, de onde vem este valor, o que uma verificação esqueceu
Ponto fraco	Não enxergam regra de negócio; barulhentos em padrões seguros	Falsos positivos, problemas não detectados, respostas diferentes a cada execução
Custo	Segundos, repetível	Tokens, mais lento, não repetível
Melhor uso	Gate de CI em toda mudança	Auditoria focada em áreas de risco e código novo

Um agente brilha em casos como um endpoint que verifica se você está logado, mas nunca verifica se o pedido que você está lendo é seu. Nenhuma regex vê isso. Por outro lado, um agente não vai perceber com confiabilidade que o lodash do seu lockfile tem três anos; o npm audit vai.

O que nenhum dos dois faz: testar o sistema em execução. Um agente lê o código do seu checkout. Um storage na nuvem mal configurado, uma regra de firewall ou um token vazado num log de chat ficam fora do alcance dele.

Antes de começar: um ambiente seguro

Uma auditoria de segurança é uma tarefa de muita leitura, então monte o ambiente assim.

Trabalhe numa branch ou num git worktree. A auditoria e as correções devem ser fáceis de revisar e fáceis de descartar.
Comece somente leitura. No Claude Code, use o plan mode (Shift+Tab ou /plan) para a auditoria em si; no Codex, /permissions → Read Only ou --sandbox read-only. Só libere edições na hora de corrigir.
Mantenha os segredos fora de alcance. Nunca cole chaves, tokens ou o conteúdo do .env num prompt. Se o agente precisa saber que uma variável existe, o nome basta. Um .env.example com valores falsos é o que ele deve ler.
Use credenciais de desenvolvimento. Se o agente roda seus testes, esses testes devem falar com um banco local ou de staging com chaves descartáveis, nunca com produção.

Passo 1: rode os scanners determinísticos

Eles levam segundos e dão ao agente pistas concretas. Todos podem ser rodados localmente de graça.

# Secrets in git history and in the working tree (gitleaks v8.19+)
gitleaks git -v .
gitleaks dir -v .

# Known-vulnerable dependencies
npm audit --audit-level=high
pip-audit -r requirements.txt

# Static analysis rules for your languages
semgrep scan --config auto

Algumas observações da documentação oficial:

O gitleaks dividiu o antigo comando detect em git (varre commits) e dir (varre arquivos) na v8.19.0; os comandos antigos ainda funcionam, mas não aparecem na ajuda.
No npm audit, --audit-level só muda o código de saída, não o relatório. npm audit fix faz uma instalação de verdade; npm audit fix --force pode instalar atualizações SemVer-major, então não rode às cegas.
O pip-audit sem argumentos audita o ambiente Python atual; -r audita um arquivo de requirements.
O Semgrep com --config auto busca regras adequadas ao seu projeto no Semgrep Registry, então precisa de acesso à rede. Adicione --error para sair com 1 quando houver achados, que é o que você quer no CI.

Salve a saída num arquivo. No passo 3 você vai entregá-la ao agente em vez de redigitar tudo.

Passo 2: audite uma classe de vulnerabilidade por vez

“Encontre bugs de segurança neste repositório” rende uma lista rasa. Um prompt focado por classe rende análise de verdade. O OWASP Top 10:2025 é um bom mapa; estas são as classes que vale auditar primeiro numa aplicação web típica:

Classe	O que pedir para o agente rastrear	Sinal típico
Controle de acesso quebrado	Toda rota que lê ou altera um registro: ela verifica se o registro pertence a quem chama?	`findById(req.params.id)` sem filtro de dono ou tenant
Injeção (SQL, shell, XSS)	Todo lugar onde a entrada do usuário chega a uma query, a um comando de shell ou a HTML	Concatenação de strings em SQL, `exec` com entrada, renderização de HTML cru
Falhas de autenticação	Login, sessão, redefinição de senha e tratamento de tokens	Tokens de redefinição que nunca expiram, falta de rate limit no login
SSRF	Toda requisição do lado do servidor cuja URL vem do usuário	`fetch(req.body.url)` sem allow list
Segredos no repositório	Chaves hardcoded, tokens em config, credenciais em testes	Strings com cara de chave; o gitleaks será mais confiável
Cadeia de suprimentos	Dependências, scripts de instalação, permissões de workflows de CI	Actions sem versão fixada, `permissions:` amplas nos workflows

Um prompt que funciona, em plan mode:

Audit this repository for broken access control. Do not edit files.

1. List every HTTP route that reads, updates or deletes a record by ID.
2. For each one, find where the caller's identity comes from and whether
   the query is limited to records the caller owns (user or tenant).
3. Report only routes where you can show the missing check.

For each finding give: file:line, the route, where the ID comes from,
why the existing middleware does not cover it, and a severity
(high/medium/low). If you are unsure, say so instead of guessing.

Repita o mesmo formato para injeção, autenticação e SSRF. Uma classe por conversa mantém a janela de contexto focada, e você pode rodá-las em paralelo em sessões separadas.

Para injeção, ajuda dizer ao agente como é o “seguro” na sua stack, para ele não marcar toda query:

We use parameterized queries through db.query(sql, params) everywhere.
Find any place that builds SQL, shell commands or HTML from request
data without going through db.query params, execFile with an argument
array, or the template engine's escaping. Ignore code under tests/.

Passo 3: use as revisões de segurança integradas

Vários agentes já trazem uma revisão de segurança que você não precisa escrever.

/security-review do Claude Code. A referência oficial de comandos o descreve como uma análise das mudanças da sua branch atual em busca de vulnerabilidades: ele revisa o diff entre a sua branch e a branch padrão do origin e procura riscos como injeção, problemas de autenticação e exposição de dados. Precisa de um remote origin. Cobre apenas as mudanças da sua branch, então rode antes de abrir um pull request. O repositório claude-code-security-review da Anthropic explica como personalizá-lo: copie o security-review.md dele para .claude/commands/ e acrescente suas próprias regras, por exemplo quais padrões são seguros na sua base de código.

Plugin security-guidance do Claude Code. Instalado com /plugin install security-guidance@claude-plugins-official, ele revisa o código enquanto o Claude escreve: uma checagem de padrões a cada edição (coisas como eval(, child_process.exec, .innerHTML =), uma revisão de segurança em segundo plano do diff de cada turno e uma revisão mais profunda quando o Claude faz commit. Você pode adicionar regras do projeto em .claude/claude-security-guidance.md. A documentação deixa claro que ele não bloqueia escritas e pode deixar problemas passar; é uma camada.

/review do Codex. O comando de revisão do Codex (e codex review --uncommitted ou --base main a partir do shell) é um code review geral. Peça explicitamente o foco em segurança se é isso que você quer.

Extensão de segurança do Gemini CLI. Instalada com gemini extensions install https://github.com/gemini-cli-extensions/security, ela adiciona /security:analyze para as mudanças da sua branch e /security:scan-deps, que verifica dependências com o OSV-Scanner.

Para código que já existe, e não para as mudanças de uma branch, use os prompts por classe do passo 2. Você também pode passar a saída dos scanners:

Here is the output of semgrep and npm audit in scan-results.txt.
For each finding, check whether it is reachable from user input in
this codebase. Mark each as confirmed, likely false positive or
needs a human, with a one-line reason. Do not edit files.

Passo 4: separe achados reais de falsos positivos

Revisões de segurança com IA soam confiantes estejam certas ou não. Peça evidências, não veredictos:

Origem: por onde entra o valor não confiável? Corpo da requisição, query string, upload de arquivo, webhook?
Caminho: por quais funções ele passa até chegar à chamada arriscada? Peça a cadeia com file:line de cada salto.
Proteção: que validação, escape ou autorização existe nesse caminho, e por que não cobre este caso?
Alcançabilidade: a rota está exposta? Um achado num script de admin morto não é o mesmo que um numa API pública.

Depois, peça uma segunda opinião. Uma sessão nova, ou melhor, outro modelo, deve checar os achados de alta severidade antes de alguém escrever uma correção. Entregue o achado e o código, não o raciocínio do primeiro agente, para que ele não simplesmente concorde. Code review com IA descreve como pesar os achados e manter esse ciclo sob controle.

Falsos positivos comuns: SQL montado só com constantes, HTML que passa pelo escape automático de um framework, fixtures de teste com chaves falsas e requisições do servidor para uma URL interna fixa. Escreva os padrões seguros no CLAUDE.md ou AGENTS.md para que as próximas auditorias parem de marcá-los.

Passo 5: corrija com um teste de regressão

Uma correção de segurança sem teste tende a voltar. Peça o teste primeiro:

Fix the missing ownership check in GET /api/orders/:id (finding #2).

1. First write a test where user A requests user B's order and expect
   a 404. Run it and show me that it fails.
2. Then add the check in the smallest way that fits our existing
   middleware. Don't change unrelated code.
3. Run the full test suite and show me the diff.

O teste que falha e depois passa prova que o bug existia e que a correção o cobre. Mantenha cada correção em seu próprio commit com uma mensagem clara, para que o histórico explique o que estava errado. Para o hábito geral de corrigir com teste primeiro, veja depurar código com IA.

A mesma disciplina vale para achados de dependências: atualize um pacote por vez, rode os testes, leia o changelog procurando mudanças incompatíveis. Um npm audit fix --force em massa é o jeito de uma auditoria virar uma queda do sistema.

Se você encontrar um segredo real no repositório

Este é o único caso em que a ordem dos passos importa:

Rotacione o segredo primeiro. Revogue a chave no provedor e emita uma nova. Depois que um segredo foi enviado com push, considere-o comprometido; apagar o arquivo não desfaz o vazamento.
Coloque o novo segredo no seu gerenciador de segredos ou no ambiente, não de volta no código.
Depois limpe: remova-o do código e decida com a equipe se vale reescrever o histórico. Reescrever o histórico não adianta se a chave não foi rotacionada.
Evite o próximo com um hook de pre-commit. O gitleaks documenta esta entrada no .pre-commit-config.yaml:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Deixe o agente ajudar nos passos 2 a 4, mas nunca colando o segredo na conversa. “A chave do Stripe em src/config.ts precisa ir para uma variável de ambiente chamada STRIPE_SECRET_KEY” é tudo de que ele precisa.

Torne isso contínuo

Uma auditoria pontual envelhece assim que chega código novo. Coloque as checagens determinísticas no CI e deixe a revisão por IA para os pull requests:

# .github/workflows/security.yml (excerpt)
- run: npm audit --audit-level=high
- run: semgrep scan --config auto --error

Para uma passada de IA em cada pull request, a GitHub Action anthropics/claude-code-security-review da Anthropic comenta os achados no PR. A entrada obrigatória é claude-api-key; as opcionais incluem comment-pr, exclude-directories e false-positive-filtering-instructions. Se você já roda o Claude no GitHub Actions, Claude Code GitHub Actions cobre a configuração e o tratamento de segredos.

Fazendo isso com o AgentVera

O AgentVera é um app desktop para macOS, Windows e Linux que roda Claude Code, Codex, Gemini CLI e outros agentes de CLI lado a lado em terminais reais. Para auditorias de segurança, isso facilita algumas configurações:

Workspace: coloque um auditor somente leitura (permissão em Ask) ao lado de um corretor trabalhando num worktree, e um terceiro painel com outra CLI como segunda opinião. Cada agente mantém o próprio nível de permissão.
Code review: ative a revisão ao fim de cada turno nas configurações do projeto, e um modelo Claude à sua escolha revisa as mudanças do corretor; os achados vêm com severidade e um link file:line e podem voltar para o agente, no máximo duas rodadas seguidas.
Review inbox: o trabalho concluído espera em cartões, e mudanças arriscadas são sinalizadas: código de autenticação e segurança, arquivos de dependências, arquivos de CI e infraestrutura, .env e mudanças sem testes.
Verify (Pro e Team): um verificador separado, somente leitura, confere o resultado contra os critérios do seu pedido, como “existe um teste de regressão e ele falha sem a correção”.
Agentes no Docker: rode o Claude Code ou o Codex num contêiner que só enxerga a pasta do projeto, para que arquivos e chaves SSH de outros lugares da sua máquina fiquem fora de alcance durante a auditoria.
Checkpoints: cada turno vira um snapshot, então uma correção que deu errado se desfaz com um clique.

A grade, os worktrees, o code review e os agentes no Docker estão no plano gratuito. Baixe o AgentVera e faça sua primeira auditoria numa branch.

Erros comuns

Pedir “todos os problemas de segurança” de uma vez. Você recebe um checklist genérico. Audite uma classe por vez.
Corrigir antes de verificar. Um falso positivo “corrigido” acrescenta código que ninguém entende. Consiga a evidência primeiro.
Colar segredos para “ver se são válidos”. Nunca. Rotacione.
Rodar npm audit fix --force num loop de agente. Atualizações major quebram coisas de formas que parecem não ter relação.
Tratar uma revisão de IA limpa como garantia. Significa só que o agente não achou nada desta vez. Mantenha os scanners no CI.
Deixar o auditor editar. Mantenha a auditoria somente leitura e as correções numa etapa separada e revisada.

Concluindo

Comece com o gitleaks, o auditor de dependências e o Semgrep. Depois audite uma classe OWASP por vez com um agente somente leitura, pedindo evidência com file:line e um caminho alcançável. Rode o /security-review (ou o equivalente do seu agente) antes de cada pull request, peça para uma segunda sessão checar os achados graves e corrija cada um com um teste de regressão que falhe primeiro. Se um segredo vazar, rotacione-o antes de qualquer outra coisa. Quando estiver pronto para colocar agentes trabalhando nas correções, pair programming com IA mostra como você continua no lugar do navegador. Se tudo isso é novo para você, aprender a programar com IA é um ponto de partida mais tranquilo.