Como fazer uma revisão de segurança do código que seu agente de codificação com IA escreve

Agentes de codificação com IA são rápidos, e essa velocidade é uma faca de dois gumes. Eles vão gerar de bom grado uma funcionalidade que funciona em minutos — e com a mesma disposição vão montar uma consulta SQL por concatenação de strings, registrar um segredo nos logs ou pular uma verificação de autorização. O código roda, os testes passam e a vulnerabilidade vai para produção. A revisão de segurança não é opcional quando quem digita é um agente; é a parte pela qual você continua responsável.

Aqui está um fluxo de trabalho prático e independente de ferramenta para revisar código gerado por IA antes que ele chegue à produção.

Saiba o que procurar

A maioria das vulnerabilidades do mundo real se agrupa em um punhado de padrões. Quando você (ou uma ferramenta) revisar a saída do agente, procure primeiro por estes:

• Injeção (Injection) — entradas de SQL, shell ou template construídas concatenando strings em vez de usar consultas parametrizadas.
• Cross-site scripting (XSS) — entrada do usuário renderizada em HTML sem escaping.
• Autenticação/autorização quebrada — endpoints que verificam quem você é mas não se você tem permissão; ausência de verificações de propriedade sobre os registros.
• Tratamento inseguro de dados — segredos no código, credenciais nos logs, dados sensíveis em mensagens de erro.
• Dependências vulneráveis — um pacote que o agente adicionou e que tem CVEs conhecidos.

Esses se mapeiam de perto ao OWASP Top 10, e são exatamente as categorias que, segundo a Anthropic, sua revisão de segurança automatizada procura. Manter essa lista curta em mente torna a revisão manual muito mais eficaz.

Use o agente para revisar a si mesmo — em um contexto novo

O mesmo modelo que escreveu o código pode revisá-lo, mas não no mesmo fôlego. Um agente que acabou de passar 20 turnos fazendo uma funcionalidade funcionar está predisposto a defendê-la. Inicie uma nova sessão e dê a ele uma única tarefa: encontrar as falhas.

Um prompt que funciona bem:

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

A cláusula "concrete exploit scenario" é a parte importante. Ela força o modelo a provar que o problema é real em vez de listar clichês vagos do tipo "considere validar a entrada".

Recorra às ferramentas integradas

Se você usa o Claude Code, há um comando dedicado /security-review que analisa suas mudanças em busca de padrões comuns de vulnerabilidade e, quando você aprova, aplica as correções diretamente. Ele está disponível nos planos pagos Pro e Max e em contas de API pré-pagas por uso.

Para cobertura contínua, a Anthropic também disponibiliza uma GitHub Action de código aberto que roda a cada pull request e posta comentários inline exatamente nas linhas que a preocupam. Colocá-la em um repositório fica mais ou menos assim:

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

Agora cada PR — seja aberta por um humano ou por um agente — passa por uma verificação de segurança antes de alguém clicar em merge. Cursor, Copilot e outros assistentes oferecem integrações de revisão comparáveis; o princípio é o mesmo independentemente da ferramenta.

Não pule as verificações determinísticas

A revisão por IA é uma poderosa adição, não um substituto para o ferramental chato que nunca se cansa:

• Varredura de dependências — npm audit, pip-audit ou Dependabot pegam pacotes com vulnerabilidades conhecidas que um LLM não reconheceria pelo nome.
• Varredura de segredos — ferramentas como o gitleaks ou a push protection do GitHub impedem que uma chave vazada chegue sequer ao histórico.
• Análise estática (SAST) — linters e ferramentas como o Semgrep aplicam regras de forma consistente por toda a base de código.

Use a IA para raciocinar sobre lógica e contexto — "um usuário autenticado consegue ler aqui os registros de outro usuário?" — e use os scanners determinísticos para o que é mecânico e detectável por padrão. Eles cobrem os pontos cegos um do outro.

Um exemplo concreto

Suponha que seu agente gere este endpoint:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

Uma verificação de segurança deveria sinalizar dois problemas: a consulta é uma injeção de SQL esperando para acontecer (invoice_id interpolado), e não há verificação de que a fatura realmente pertence ao user — qualquer conta logada pode ler qualquer fatura adivinhando IDs. A correção é uma consulta parametrizada mais um filtro de propriedade:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

A injeção é o tipo de coisa que um scanner pega. A verificação de autorização que falta é o tipo de coisa que precisa de alguém — ou de um revisor de IA com o prompt certo — que entenda para que o código serve. Essa é a divisão a ter em mente.

A conclusão

Trate cada diff que seu agente produz como não confiável até que tenha sido revisado — o mesmo padrão que você aplicaria à primeira pull request de um novo colega de equipe. Combine uma revisão por IA em contexto novo, uma verificação automatizada de PR e scanners determinísticos, e você obtém a maior parte da velocidade do desenvolvimento assistido por IA sem herdar seus piores hábitos.