Existe uma pergunta simples que raramente aparece em demonstrações de ferramentas de segurança com Inteligência Artificial: o teste que embasa esse resultado usou dados que o modelo já poderia ter visto?
Parece detalhe técnico. Na prática, é uma decisão de orçamento e de confiança. Se um modelo foi treinado com informação sobre um ataque específico, encontrar aquela falha depois prova memória, não capacidade de análise. Quem contrata com base nesse número acaba comprando uma expectativa que talvez não resista ao primeiro código inédito.
Essa pergunta caiu no nosso colo antes de cair no de qualquer cliente. Por isso, antes de colocar o agente de segurança do Eagle Audit — nossa plataforma de análise e auditoria de Smart Contracts — à disposição de terceiros, decidimos testá-lo por conta própria. Este artigo documenta o que fizemos, o que encontramos e o que ficou de fora.
O que uma auditoria de Smart Contracts cobre (e o que fica fora)
Para entender o valor — e os limites — de qualquer ferramenta de segurança, é preciso primeiro mapear o território.
Os ataques a protocolos baseados em smart contracts se organizam em três grupos:
- Engenharia social: alguém se infiltra na equipe se passando por parceiro, colaborador ou investidor e obtém acesso privilegiado a chaves ou repositórios.
- Vazamento de chaves privadas: participantes com permissões elevadas seguem sendo pontos únicos de falha, mesmo quando as regras do protocolo estão corretamente escritas em código.
- Falha na lógica do próprio contrato: erros no código que permitem comportamentos não previstos, exploráveis por qualquer pessoa com acesso à blockchain.
Uma auditoria de código, seja humana ou automatizada, endereça exclusivamente o terceiro grupo. Os dois primeiros acontecem longe do repositório e ficam fora do alcance de qualquer revisão técnica.
Isso muda a conversa de governança. A pergunta deixa de ser "auditamos o código?" e passa a ser "qual classe de risco cada controle da nossa operação cobre, e o que sobra descoberto?" Muitas equipes respondem à primeira com confiança e travam na segunda.
O custo que define a frequência de revisão
Se o grupo das falhas de lógica é o auditável, por que tantos sistemas chegam a produção sem revisão contínua? A resposta é econômica antes de ser técnica.
Uma auditoria conduzida por especialistas humanos é cotada em dezenas de dólares por linha de código. Nesse patamar, revisão profunda vira evento: acontece antes de um lançamento, após um incidente ou quando um investidor exige como condição.
O problema é que sistemas em evolução contínua não param no evento. Eles mudam toda semana, por anos. Uma funcionalidade nova é barata de produzir, mas cara de revisar. E quando olhamos no longo prazo, essas duas curvas crescem sem parar.
Foi para fechar esse gap que construímos o agente de segurança dentro do Eagle Audit. Ele lê os contratos, executa testes, formula hipóteses sobre vetores de ataque e produz um relatório com causa raiz, impacto estimado, recomendação de correção e uma prova de conceito executável.
O custo por execução fica na faixa de centavos por linha e o ganho é de frequência: auditar passa a caber em cada ciclo de entrega.
Vale registrar o contexto de origem: o Eagle Audit nasceu no ecossistema do DREX, o que nos colocou cedo diante de exigências rigorosas de validação de infraestrutura financeira. Esse histórico moldou tanto a arquitetura da plataforma quanto os critérios que usamos para avaliá-la.
Como testamos o nosso próprio agente
Modelos de linguagem têm uma data de corte de conhecimento. Se um protocolo foi atacado antes dessa data, informação crítica sobre o evento pode estar embutida nos parâmetros do modelo.
Para evitar esse viés, estabelecemos uma regra metodológica: usaríamos apenas incidentes documentados após o corte de conhecimento do modelo que alimenta o agente. Sem exceções.
Vale notar que esse cuidado ainda é exceção no setor. Em março de 2026, OpenAI, Paradigm e OtterSec publicaram o EVMbench, uma avaliação abrangente de agentes em segurança de smart contracts. Poucos dias depois, um trabalho acadêmico apontou como limitação central do benchmark justamente a dependência de dados divulgados antes do lançamento dos modelos avaliados.
Com a metodologia definida, escolhemos três ataques reais, todos documentados publicamente por firmas de segurança independentes, e fizemos uma pergunta objetiva: se o agente tivesse sido apontado para esse código antes do ataque, a falha apareceria no relatório?
Os três ataques analisados
Uniswap V4 — março de 2026 Um roteador de swaps foi explorado, resultando em perda de aproximadamente US$ 42 mil de um usuário que havia autorizado o contrato. O vetor de ataque envolveu a manipulação de permissões concedidas previamente.
BitcoinReserveOffering (protocolo Solv) — março de 2026 Perda próxima de US$ 2,7 milhões. O incidente foi documentado por firmas independentes e envolveu falha na lógica de validação do contrato.
Caliber (Makina) — janeiro de 2026 Cerca de 1.299 ETH extraídos por manipulação de oráculo — um dos vetores de ataque mais recorrentes em DeFi, que explora a dependência de contratos em fontes externas de preço.
O que encontramos
Nos três casos, o agente identificou a falha explorada, apontou a causa raiz e escreveu um teste que reproduz o ataque em código executável, pronto para análise humana. Um dos relatórios ficou pronto em sete minutos.
Em execuções adicionais com casos aleatórios, observamos cerca de 50% de eficácia na identificação de falhas críticas, sem incidência expressiva de falsos positivos.
Esse número merece contexto em ambas as direções. Ele fica alinhado com o que benchmarks públicos recentes reportam para agentes nessa categoria de tarefa. E ao mesmo tempo, deixa metade das falhas críticas de fora — o que pesa mais do que qualquer comparação favorável.
A posição que guia o uso da ferramenta é direta:
"Um relatório limpo não é um atestado de segurança. Ele diz o que foi analisado, dentro do que foi analisado. A ferramenta amplia o alcance da revisão, mas a decisão final continua sendo humana — e é assim que deve ser. Preferimos um agente que ajuda a olhar mais vezes a um que promete olhar por você."
Há ainda um ponto que merece ser dito sem rodeios: o aumento recente de incidentes em protocolos on-chain levanta a hipótese de que fluxos com agentes já podem estar sendo usados do outro lado — por quem ataca, não apenas por quem defende. Isso segue como hipótese, mas é uma hipótese que muda o nível de urgência da discussão.
O que líderes de tecnologia levam disso
Smart contracts são um caso extremo: código publicado, difícil de corrigir depois, com valor financeiro em cima e adversários motivados o tempo todo. O que em software convencional é um inconveniente, ali costuma ser irreversível.
Por isso, esse território funciona como laboratório, mesmo para quem nunca vai tocar em blockchain. Três aprendizados se transferem diretamente:
- Mapeie a cobertura real dos seus controles. Saber que o sistema foi auditado não é suficiente. A pergunta relevante é qual classe de risco cada controle endereça — e o que sobra sem cobertura.
- Frequência vale mais do que profundidade pontual. Quando o código muda toda semana, uma revisão profunda por ano deixa meses de exposição intocados. Ferramentas que reduzem o custo por execução mudam essa equação.
- Exija prova de metodologia de qualquer ferramenta de IA. Antes de adotar qualquer solução baseada em modelos de linguagem para análise de segurança, pergunte: os testes foram conduzidos com dados posteriores ao corte de conhecimento do modelo? Se a resposta for vaga, o número de eficácia apresentado também é.
Conclusão
Qualidade de software é uma propriedade do processo que acompanha o código enquanto ele muda — não do evento único que acontece antes do lançamento. Agentes de IA para auditoria de smart contracts ampliam o alcance e reduzem o custo da revisão contínua, mas não substituem o julgamento humano nem eliminam classes inteiras de risco.
O que muda com ferramentas bem construídas e bem testadas é a frequência com que é possível olhar. E frequência, nesse contexto, é proteção.
Se a sua operação convive com código que evolui mais rápido do que a revisão consegue acompanhar, essa é a conversa que vale ter.
.avif)