- Início
- The Thinking Wire
- Uma Equipe de Agentes Caseira Venceu 10+ Scanners. A Arquitetura Explica.
Uma Equipe de Agentes Caseira Venceu 10+ Scanners. A Arquitetura Explica.
O engenheiro de segurança da Ramp, Eli Block, divulgou um número que deveria reformular como toda equipe de plataforma pensa o trabalho de vulnerabilidades. Uma equipe pequena construiu um sistema de agentes que encontrou, validou e corrigiu cerca de 100 falhas de segurança latentes no código em seis dias, sem nenhum humano envolvido até a revisão do pull request. O sistema foi montado em um hackathon de quatro horas e concluído em menos de uma semana, por um único integrante. As falhas que ele pegou já tinham sobrevivido a testes de penetração, a um programa de bug bounty, a análise estática e a mais de dez fornecedores comerciais de varredura de código.
Esse último detalhe é o que merece atenção. Os scanners não estavam ausentes. Estavam rodando. Mesmo assim deixaram as falhas passar, e uma equipe de agentes caseira as pegou. A razão não é um modelo mais esperto. A razão é contexto, e contexto é uma decisão de arquitetura.
Por Que Contexto Vence Cobertura
Um scanner comercial é construído para ser genérico. Ele precisa funcionar no código de todo cliente, o que significa que não consegue codificar o modelo de ameaça de nenhum cliente específico, suas convenções de nomenclatura, suas fronteiras internas de confiança nem quais endpoints de fato dão para a internet. Ele faz correspondência de padrões contra uma biblioteca de assinaturas conhecidas e reporta o que encaixa. Amplitude é o produto dele. Especificidade é o ponto cego.
Uma equipe de agentes construída dentro do código herda o trade-off oposto. Ela lê as convenções do próprio repositório, as prioridades do time, a documentação interna que diz qual serviço é privilegiado e qual é isolado. Quando avalia uma falha candidata, não está perguntando “isso bate com uma assinatura CWE”. Está perguntando “isso é explorável dado como este sistema está de fato conectado”. Essa segunda pergunta é a que separa uma falha real de uma teórica, e é a pergunta que ferramentas genéricas estruturalmente não conseguem fazer.
Esta é a parte que deveria mudar uma conversa de orçamento. A vantagem não foi os agentes serem espertos. A vantagem foi os agentes carregarem o mesmo contexto que um engenheiro sênior carrega, aplicado em um volume que nenhum engenheiro sênior tem tempo de cobrir. O scanner vende cobertura. A equipe construiu julgamento.
O Colapso do Custo de Trabalho
Equipes de segurança sempre souberam de mais falhas do que conseguiam corrigir. O gargalo nunca foi a detecção. Foi a cadeia de trabalho depois da detecção: validar a falha, confirmar que é real e não ruído, escrever a correção, escrever um teste que prova a correção, confirmar que nada quebrou. Cada etapa custa horas humanas, e horas humanas são racionadas. Então as equipes priorizam os críticos, e a longa cauda de falhas médias e baixas se acumula como risco latente que ninguém tem tempo de tocar.
Agentes colapsam essa cadeia. Quando encontrar, validar, corrigir e confirmar rodam todos a custo de máquina, a economia da triagem se inverte. Você deixa de precisar ignorar o conjunto amplo de falhas porque agir sobre ele ficou caro demais. Você pode agir sobre o conjunto inteiro. As cem falhas da Ramp não eram todas críticas; eram o backlog que uma estrutura de equipe convencional jamais teria justificado limpar. Os agentes tornaram a limpeza viável.
Essa é a virada estratégica escondida na manchete. Trabalho mais barato para o ciclo de vida completo significa que uma equipe de segurança finalmente opera sobre a distribuição que sempre enxergou, em vez da fatia fina que conseguia equipar.
A Arquitetura É a Lição
A autonomia aqui não é “soltar um modelo no código”. É um pipeline governado com papéis especializados e uma verificação adversarial embutida no meio. O formato, como a Ramp descreveu, funciona assim.
Um coordenador roteia o trabalho. Agentes detectores varrem em busca de falhas candidatas, cada um afinado para uma classe de problema. Então vem a peça que sustenta tudo: agentes gerentes atuam como juízes adversariais das propostas dos detectores. O trabalho deles é rejeitar, não aprovar. Agentes validadores escrevem testes que tentam provar que a falha é real. Um agente corretor trabalha em um loop guiado por testes, escrevendo o patch contra o teste que falha até ele passar. Só então um humano vê um pull request.
O número que prova que o desenho funciona é a taxa de rejeição. Os agentes gerentes adversariais descartaram 40% do que os detectores propuseram, e a revisão humana confirmou que toda rejeição era um falso positivo genuíno. É o jogo inteiro. Um detector otimizado para recall vai super-reportar; é o que detectores fazem. Colocar um agente cujo único incentivo é rejeitar diante do portão humano faz os falsos positivos morrerem a custo de máquina, antes de consumirem a atenção de um revisor ou corroerem a confiança no sistema.
Repare no que cada papel contribui para a governança. O coordenador dá um ponto único de orquestração para auditar. A separação entre detector e gerente isola “encontrar tudo plausível” de “manter só o que sobrevive ao desafio”, de modo que nenhum papel precisa fazer os dois trabalhos ao mesmo tempo. O validador transforma uma alegação em um teste reproduzível, a única prova honesta de que uma vulnerabilidade existe. O corretor guiado por testes garante que o patch está amarrado a esse teste, e não a uma intuição. E o portão humano do PR fica no final, revisando um conjunto pequeno, pré-filtrado e respaldado por testes, em vez de uma enxurrada de falhas cruas.
Este é o mesmo padrão que defendemos no problema da arquitetura de segurança de agentes: a autonomia é segura quando é estruturada e perigosa quando é monolítica. Também estende o argumento de pesquisa de segurança em IA e suas implicações de governança, onde a pergunta em aberto era “a IA consegue encontrar vulnerabilidades, e agora”. A Ramp responde o “e agora” com desenho organizacional. A resposta é um pipeline onde o portão humano está no final, o portão adversarial está no meio e cada etapa produz um artefato que você pode auditar.
Onde as Equipes Erram Nisso
A leitura tentadora é “comprar menos scanners e construir agentes no lugar”. Não é essa a lição. A lição é que detecção sem um pipeline de validação e rejeição produz ruído, e ruído é o que mata a automação de segurança. A maioria das equipes que conecta um LLM para varrer código pula o gerente adversarial e o validador que escreve testes, e então afoga os revisores em falsos positivos de aparência plausível. Em um mês os revisores param de confiar na saída, e o sistema é engavetado.
A taxa de rejeição de 40% não é uma nota de rodapé. É a funcionalidade. Um pipeline que não consegue rejeitar a si mesmo é um pipeline que exporta o próprio ruído para humanos. Construa o rejeitador antes de escalar o detector.
Faça Isto Agora
Mapeie seu fluxo atual de vulnerabilidades contra os cinco papéis. Onde a detecção acontece, quem valida que uma falha é real, quem escreve a prova, quem escreve a correção e onde o humano de fato olha. Se a detecção alimenta direto uma fila humana sem nenhum filtro adversarial no meio, você tem uma máquina de recall apontada para seus revisores, e ela vai queimar a confiança deles antes de conquistá-la.
Depois faça a pergunta de orçamento com honestidade. Você provavelmente paga por amplitude (vários scanners) enquanto subnutre a parte que converte falhas em correções seguras e validadas (a cadeia de trabalho). O resultado da Ramp sugere que a alavanca está no pipeline, não nos detectores. Construa o gerente adversarial e o validador guiado por testes primeiro. Coloque o humano no portão do PR, revisando um conjunto filtrado e respaldado por testes. Depois deixe a detecção rodar tão ampla quanto quiser, porque o rejeitador a jusante torna a amplitude barata em vez de perigosa.
Fontes
- Ramp. “We Proactively Fixed ~100 Security Issues in 6 Days With 0 Humans.” Fevereiro de 2026.
A Victorino ajuda equipes a desenhar arquiteturas de agentes governadas com humanos no portão certo: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa