Code review de segurança com agente de IA: o limite

A equipe roda o agente na base de código pela primeira vez e recebe 340 apontamentos em vinte minutos. O time de quatro pessoas olha a lista, escolhe os doze primeiros, confirma três e desiste no dia seguinte. Seis meses depois ninguém lembra que a lista existe.

Esse é o desfecho mais comum de um code review de segurança assistido por agente quando a saída da ferramenta é tratada como resultado final. O problema não está na quantidade de achados. Está em quem assinou embaixo.

Vale começar pela parte boa: um code review de segurança automatizado realmente encontra coisa que passaria despercebida, e encontra barato. O que ela não faz é decidir se o que encontrou importa.

Um agente de IA lê mais código em uma hora do que um revisor humano lê em uma semana, e é exatamente por isso que ele serve para triagem. O veredito continua humano, porque provar que um achado é explorável exige conhecer a regra de negócio, o dado que trafega e o caminho real da requisição, e nada disso está escrito no arquivo que o agente leu.

O que a varredura automatizada pega bem

Quatro famílias de problema aparecem com consistência num code review de segurança feito por agente sobre uma base inteira, e as quatro têm a mesma característica: o defeito cabe num trecho de arquivo, sem depender do resto do sistema.

A primeira é segredo escrito no código. Chave de API, senha de banco, token de serviço. É o achado mais barato de todos, porque o padrão é reconhecível e a correção é óbvia. A segunda é dependência com versão vulnerável conhecida, que a ferramenta cruza com uma base pública de CVE. A OWASP colocou falhas de cadeia de suprimentos de software em terceiro lugar no Top 10 de 2025, e esse é justamente o tipo de risco que você herda de quem você instalou.

A terceira é entrada de usuário que chega a uma consulta, a um comando ou a um caminho de arquivo sem passar por validação. A quarta é permissão concedida mais larga que a necessidade: um bucket público, um papel de banco com direito de escrita onde só se lê, um token com escopo aberto.

Nenhuma dessas quatro exige entender o negócio. É leitura de padrão em volume, e máquina faz isso melhor que gente cansada na sexta à tarde.

Onde o code review de segurança com agente erra

O erro não é aleatório, o que ajuda: ele tem três formas previsíveis.

Lógica de autorização. O agente vê que existe uma verificação de permissão antes da função. Ele não tem como saber que, naquela empresa, o gerente de filial não pode ver o cadastro de cliente de outra filial, porque essa regra existe num contrato e na cabeça de três pessoas, não no código. A OWASP mantém controle de acesso quebrado em primeiro lugar na lista de 2025, com o maior número de ocorrências entre os dados contribuídos, e é a categoria em que ferramenta automatizada menos ajuda.

Encadeamento de falhas. Um endpoint devolve o identificador interno do usuário. Outro aceita esse identificador sem checar sessão. Separados, os dois passam em qualquer varredura. Juntos, são um caminho de acesso a conta alheia. O agente analisa unidade por unidade e raramente monta a cadeia sozinho.

Definição de dado sensível. Um campo chamado codigo_interno pode ser o número de prontuário. Um campo chamado observacao pode guardar dado de saúde digitado à mão pelo atendente. A máquina classifica pelo nome e pelo formato. Quem sabe o que aquilo é de verdade é quem opera o processo.

Some a isso o falso positivo em volume. Uma consulta montada por concatenação parece injeção, mas pode estar protegida por uma validação três camadas acima ou rodar num script que só recebe entrada de um arquivo interno. A Semgrep chega a marcar achados como ignorados provisoriamente quando a própria triagem automática os considera prováveis falsos positivos, segundo a documentação de triagem. O GitHub, por sua vez, pede que quem descarta um alerta do CodeQL como falso positivo escolha o motivo com cuidado, porque a escolha afeta se aquela consulta continua na análise futura. As duas ferramentas partem do mesmo pressuposto: quem decide é uma pessoa.

Por que o agente não prova exploração

Num code review de segurança, existe uma diferença de natureza entre dizer "este trecho tem a forma de uma falha" e dizer "consegui sair daqui com o dado do cliente".

O agente lê texto. Ele não sobe o ambiente, não manda requisição, não observa resposta e não tenta contornar a validação que ele mesmo apontou. Mesmo quando a ferramenta roda o código, o alcance é limitado ao que o teste cobre.

Isso muda o que se pode fazer com a saída dele. Um achado não validado é uma hipótese sobre o sistema. Colocar hipótese no backlog junto com defeito confirmado é a forma mais rápida de perder a confiança do time de desenvolvimento, e a partir daí qualquer alerta de segurança vira ruído. Esse é o mesmo raciocínio que sustenta uma gestão de vulnerabilidades que funciona: a fila só é útil se cada item dela for verdadeiro.

O risco cresce quando muito do código foi escrito rápido, com assistência de modelo e pouca revisão. Aí você tem volume grande de código pouco conhecido sendo lido por outro agente que também não o conhece, e ninguém no meio com o contexto inteiro.

O desenho em fases de um code review de segurança que funciona

A Cloudflare publicou uma skill de auditoria de segurança para agentes de código que organiza o trabalho em seis fases, e o desenho dela explica bem o ponto. Reconhecimento primeiro, para mapear arquitetura, fronteiras de confiança e superfícies de entrada. Depois a caça guiada por cobertura. Depois a validação, e aqui está a regra que importa: segundo o repositório oficial da skill, o agente que verifica um achado nunca é o agente que o encontrou, e o verificador trabalha tentando derrubar a hipótese.

A saída também é separada por confiança. Os registros saem classificados como confirmados, pendentes de validação ou rejeitados, e o confirmado precisa de rastro completo da origem até o resultado observado. Pendente de validação guarda o fato exato que ficou em aberto e não recebe severidade nenhuma.

Esse é um exemplo concreto de como um procedimento embalado como skill muda o resultado de um agente de IA sem trocar o modelo. O que muda é a exigência de prova.

Achado bruto contra achado validado

A tabela mostra por que misturar as duas colunas na mesma fila de code review de segurança destrói as duas. O achado bruto perde o prazo e o validado perde a prioridade.

O papel do humano em cada fase

1. Escopo. A pessoa define o que entra no code review de segurança e o que fica de fora, e escreve quais dados a aplicação trata. Sem isso o agente classifica sensibilidade pelo nome do campo.
2. Varredura. Aqui o humano só configura e sai. É a única fase em que a máquina trabalha sozinha, e é onde o ganho de tempo aparece.
3. Triagem. Alguém agrupa achados repetidos, descarta os que o contexto neutraliza e separa o que merece investigação. Metade do volume costuma morrer nesta fase.
4. Validação. Um revisor tenta reproduzir o caminho: entrada, trajeto, efeito. Se não conseguir descrever os três, o achado volta para a lista de candidatos, não para o backlog.
5. Correção. Só agora vira tarefa, com responsável, prazo e um teste que falhe antes da correção e passe depois.

Duas regras seguram o desenho. A primeira: quem valida não pode ser quem escreveu o código, pelo mesmo motivo que a Cloudflare separa quem acha de quem verifica. A segunda: a lista de candidatos tem data de validade. Achado que ninguém revisou em trinta dias é descartado com registro, porque lista infinita e lista vazia informam a mesma coisa.

O ponto que fica

Num code review de segurança, o agente é um bom leitor e um mau juiz. Ele lê a base inteira, aponta onde olhar e derruba o custo da primeira passada, que é a parte cara do trabalho quando feita por gente.

A conta só fecha quando a fase de validação existe de verdade, com nome de quem assinou cada achado confirmado. No desenho da Cloudflare, o achado que não passou pelo verificador sai sem severidade nenhuma, e essa ausência é o dado mais honesto do relatório.