A nova fronteira da cibersegurança com IA: a realidade após Mythos

• Depois que o Claude Mythos da Anthropic detectou automaticamente vulnerabilidades zero-day em larga escala, modelos abertos pequenos também conseguiram detectar as mesmas vulnerabilidades
• Modelos na faixa de 3,6B a 5,1B de parâmetros reproduziram bugs no FreeBSD e OpenBSD, e alguns apresentaram caminhos de exploit criativos diferentes dos do Mythos
• Os experimentos mostraram que tamanho do modelo e desempenho não são lineares e, em certas tarefas, modelos pequenos foram mais precisos que modelos grandes
• As capacidades de segurança de IA não escalam de forma suave, mas sim “irregular”, e a verdadeira competitividade está não no modelo, mas no projeto do sistema e no pipeline de validação
• Portanto, o fosso competitivo da segurança não é o modelo, mas o sistema, e uma estrutura de orquestração com conhecimento especializado embutido é o núcleo da segurança com IA

---

O fosso é o sistema, não o modelo

• Em 7 de abril de 2026, a Anthropic anunciou o Claude Mythos Preview e o Project Glasswing, formando um consórcio para detectar e corrigir automaticamente vulnerabilidades de segurança em softwares importantes usando o modelo Mythos
  • Prometeu US$ 100 milhões em créditos de uso e US$ 4 milhões em doações para organizações de segurança open source
  • O Mythos encontrou milhares de vulnerabilidades zero-day e detectou autonomamente bugs como um bug de 27 anos no OpenBSD, um bug de 16 anos no FFmpeg e uma vulnerabilidade de execução remota de código no FreeBSD, além de gerar exploits
• A AISLE reproduziu as mesmas vulnerabilidades com modelos pequenos, baratos e de pesos abertos
  • 8 de 8 modelos detectaram o exploit no FreeBSD
  • Até um modelo de 3,6B de parâmetros (US$ 0,11 por token) teve sucesso na detecção
  • Um modelo de 5,1B reconstruiu a cadeia central do bug do OpenBSD
  • Em algumas tarefas, modelos abertos pequenos foram superiores a modelos grandes
• Como resultado, as capacidades de segurança de IA são não lineares e irregulares (jagged)
  • Nenhum modelo é superior em todas as tarefas
  • O núcleo da competitividade em segurança não está no modelo, mas no sistema, com foco em uma estrutura de orquestração com conhecimento especializado embutido

Onde a segurança com IA está hoje

• Desde meados de 2025, a AISLE vem aplicando sistemas de detecção e correção de vulnerabilidades com IA a alvos reais
  • Encontrou 15 CVEs no OpenSSL, 5 no curl e mais de 180 CVEs validados externamente no total
  • O CTO do OpenSSL avaliou que “a qualidade dos relatórios e do processo de colaboração é excelente”
• Embora tenha usado vários modelos, os modelos da Anthropic nem sempre foram os melhores
  • Como o melhor modelo varia conforme a tarefa, a empresa adotou uma abordagem agnóstica em relação ao modelo

Decompondo o pipeline de segurança com IA

• Na prática, a segurança com IA não é um único modelo, mas um pipeline de múltiplas etapas
  • Varredura ampla, detecção de vulnerabilidades, validação e classificação, geração de patch e montagem de exploit têm características de escala diferentes em cada etapa
• A Anthropic maximiza o primeiro fator de entrada (inteligência do modelo), enquanto a AISLE trata com o mesmo peso diversos fatores como custo por token, velocidade e especialização em segurança

Conclusão: o fosso é o sistema

• Estruturas mencionadas no post técnico do Mythos, como execução em contêiner, varredura de arquivos, validação com ASan e avaliação de prioridade, são semelhantes ao sistema da AISLE
• O centro do valor não está no modelo, mas no processo de direcionamento, validação e construção de confiança
• A abordagem de implantar em paralelo um grande número de modelos pequenos para explorar amplamente todo o código garante ao mesmo tempo viabilidade econômica e eficiência de detecção
• O Mythos comprovou a categoria, mas escala operacional e confiabilidade continuam sendo desafios

Resultados do experimento: capacidades de segurança irregulares

• Foram realizados experimentos com modelos pequenos e baratos tendo como alvo vulnerabilidades emblemáticas do anúncio do Mythos

  • Bug NFS do FreeBSD, bug SACK do OpenBSD e teste de falso positivo da OWASP

    • Os resultados mostraram que tamanho, geração e preço do modelo têm relação não linear com o desempenho
    • Todos os modelos tiveram sucesso na detecção do FreeBSD, apenas alguns tiveram sucesso no OpenBSD, e no teste da OWASP os modelos pequenos foram mais precisos que os grandes
    • Detecção no FreeBSD: todos os 8 modelos detectaram o buffer overflow
    • Até o modelo de 3,6B calculou corretamente e avaliou a possibilidade de RCE
    • O DeepSeek R1 realizou cálculos compatíveis com a estrutura real da stack
    • Na lógica do exploit, todos os modelos propuseram uma estratégia de cadeia ROP
    • Alguns modelos apresentaram soluções criativas diferentes das do Mythos (por exemplo, elevação para root em modo usuário em vez de modo kernel)
    • Bug SACK do OpenBSD: um modelo de 5,1B reconstruiu toda a cadeia e sugeriu o patch correto
    • O Qwen3 32B foi perfeito no FreeBSD, mas aqui julgou erroneamente que “é seguro”
    • O ranking de desempenho por modelo se inverteu completamente de uma tarefa para outra

• Teste de falso positivo da OWASP: em código Java simples, modelos pequenos foram mais precisos que os grandes

  • GPT-OSS-20b, DeepSeek R1 e OpenAI o3 julgaram corretamente como “atualmente seguro, mas com possibilidade de vulnerabilidade”
  • Muitos modelos das linhas Anthropic e GPT-4.x fizeram detecção incorreta de SQL injection

Teste de reconhecimento de patch (atualização de 9 de abril de 2026)

• Foi comparada a capacidade de detectar o bug e reconhecer a correção em código da versão com patch do FreeBSD
  • Todos os modelos detectaram o bug sem patch, mas houve muitos falsos positivos no código após o patch
  • Apenas o GPT-OSS-120b foi preciso nos dois sentidos
  • A maioria dos modelos fez alegações erradas de vulnerabilidade devido a erro na interpretação do sinal de oa_length
• Isso mostra alta sensibilidade (capacidade de detecção), mas baixa especificidade (precisão),
  enfatizando que um sistema externo ao modelo para validação e triagem é essencial

Os limites da montagem de exploits

• Os casos do Mythos, como escape de sandbox de navegador em múltiplas etapas e cadeia ROP de kernel, são exemplos muito avançados
• Modelos abertos explicam de forma lógica a possibilidade de exploit, técnicas e estratégias de bypass, mas
  ainda faltam mecanismos de entrega criativos em ambientes restritos
• Porém, em workflows defensivos, a confiabilidade da detecção e do patch é mais importante do que um exploit completo

Perspectiva macro

• O anúncio do Mythos demonstrou a viabilidade real e a importância industrial da segurança com IA
  • Houve ampliação de financiamento e interesse em segurança open source
• Porém, é exagerado dizer que “essa capacidade existe apenas em um modelo fechado específico”
  • Na prática, as etapas de detecção e análise já são amplamente acessíveis
  • Especialização em segurança, projeto de sistema e construção de confiança são os verdadeiros gargalos

• O que é necessário agora não é um modelo, mas a construção de sistemas

  • Scaffolds, pipelines, estruturas de colaboração e integração com workflows de desenvolvimento
  • Os modelos já estão suficientemente prontos

Limitações e pontos de atenção

• Escopo de teste limitado: as funções vulneráveis e dicas foram fornecidas diretamente aos modelos; não se trata de exploração totalmente autônoma
• Sem acesso a ferramentas: não foram usados execução de código, loops ou ambiente sandbox
• Atualizações dos modelos refletidas: alguns modelos mais recentes da Anthropic foram melhorados depois
• Esclarecimento do escopo da afirmação: não nega a capacidade do Mythos,
  mas aponta que a exclusividade da capacidade de detecção foi exagerada

Resumo do apêndice

• Citações sobre a detecção no FreeBSD

  • Kimi K2: “oa_length é copiado sem validação, podendo causar overflow”
  • Gemma 4: “Pode exceder o buffer de stack de 128 bytes”

• Tabela comparativa de desempenho por tarefa

  • Todos os modelos tiveram sucesso na detecção no FreeBSD, apenas alguns no OpenBSD, e os modelos pequenos se saíram melhor na OWASP

• Teste com código corrigido por patch

  • A maioria dos modelos gerou falsos positivos por erro de sinal em oa_length
  • Apenas o GPT-OSS-120b foi totalmente preciso
  • Conclusão:
  • A principal vantagem competitiva da segurança com IA não está no tamanho ou na exclusividade do modelo, mas
  • em um projeto sistêmico com conhecimento especializado embutido e uma estrutura operacional confiável.
  • Modelos pequenos também são suficientemente poderosos, e já estamos em um estágio em que é possível construir sistemas de defesa automatizados em larga escala com eles.

[GN⁺]

Comentários do Hacker News

• Pelo texto Mythos Preview da Anthropic, eles teriam encontrado a vulnerabilidade mais crítica no OpenBSD
  O custo total de mil execuções teria ficado abaixo de US$ 20 mil, e em uma delas o bug foi encontrado por menos de US$ 50
  Mas foi enfatizado que esse número só faz sentido em retrospecto, já que na prática não dá para saber qual execução vai ter sucesso
  Usando a metáfora de que o Mythos vasculhou um continente inteiro como se fosse uma mina de ouro, preveem que, se o mesmo experimento fosse feito em toda a base de código do FreeBSD, o ruído seria grande demais

  • O scaffolding do Mythos, na prática, era um loop em bash percorrendo todos os arquivos e pedindo ao modelo para encontrar vulnerabilidades
    Fica a dúvida se a Anthropic divulgou a taxa de false positives
    No Xitter, viram relatos de pessoas testando com outros modelos abertos e reproduzindo apenas parte do que o Mythos encontrou
    O Mythos parece ter mostrado uma melhoria incremental, mas grande em relação aos modelos anteriores, ao mesmo tempo em que aumentou a complexidade
    O marketing do tipo “forte demais para ser divulgado” parece, na verdade, uma forma de embalar a realidade de que “rodar na base inteira custa US$ 20 mil”
    Na apresentação de Nicholas Carlini também usaram o Opus, e segurança já é uma área em que a Anthropic se concentra há muito tempo
  • O Mythos também gerou muitas vulnerabilidades alucinadas, mas algumas foram de fato validadas por testes
    O ponto central é saber se modelos menores também conseguem executar essa etapa de validação, e se conseguem fazer isso de forma mais barata
  • Em contrapartida, acham que outras pesquisas foram longe demais no extremo oposto
    Separaram apenas as funções vulneráveis e as deram ao modelo para avaliação, o que seria como “mostrar diretamente a sala onde o ouro está escondido”
    Na prática, a parte mais difícil é encontrar essa sala no continente inteiro
  • Gastar US$ 20 mil para encontrar uma única vulnerabilidade de DoS no OpenBSD parece ineficiente
    Há um clima de tratar o Mythos como troféu, mas acham que seria melhor doar esse dinheiro para a fundação OpenBSD
  • Se o mesmo tipo de vulnerabilidade pode ser encontrado com modelos pequenos, fica a dúvida de por que a empresa ainda não tinha encontrado isso antes

• Houve um estudo dizendo que pequenos modelos abertos detectaram todas as 8 de 8 vulnerabilidades do FreeBSD encontradas pelo Mythos
  Mas, como o teste foi feito separando apenas o código relevante, isso parece diferente de um caso de uso real
  O valor real estaria em conseguir jogar a base inteira e escanear tudo

  • A própria equipe de pesquisa reconheceu essa limitação
    Como deram ao modelo diretamente a função vulnerável e dicas, isso representa apenas um limite superior da exploração totalmente autônoma
    Ainda assim, um scaffolding bem projetado consegue criar esse contexto automaticamente, então o essencial é o sistema (moat), não o modelo
  • Segundo o post técnico da Anthropic, a estrutura sobe contêineres, o modelo escaneia arquivos, levanta hipóteses e valida com ASan
    Ou seja, a alegação é que o framework (harness) faz a maior parte do trabalho, e o modelo é substituível
  • Mesmo com modelos pequenos, dá para construir um harness automático que fique repetindo prompts por arquivo ou por função
    Depois bastaria revalidar com um modelo maior apenas os pontos consistentemente apontados como vulneráveis
    No fim, o importante não é o modelo, e sim o harness
  • No fim das contas, a diferença é só o harness. Eu também consigo montar um harness que divide o código por função e o joga em um agente de análise

• Como no exemplo do Heartbleed, se você mostrar só o código vulnerável, qualquer um encontra o bug
  O difícil de verdade é localizar essa parte dentro de um código grande
  Surpreende que a Aisle tenha escrito um texto assim

  • É um texto com cara de publicidade, mas o fato de ter ido para o topo do HN talvez tenha sido por mexer com o sentimento de “esse modelo novo também não é tudo isso”
  • Em projetos grandes, é comum que, ao parar um pouco e voltar depois, o próprio código que você escreveu pareça uma bagunça
    A dificuldade de manter contexto é uma das causas fundamentais de bugs
  • Humanos são fracos em tarefas repetitivas e minuciosas
    Já as máquinas conseguem continuar vasculhando código sem ficar entediadas
    A frase “com olhos suficientes, todos os bugs são rasos” não bate com a realidade
  • Então basta automatizar esse processo de “olhar de perto”
    Dá para criar uma ferramenta que percorre a base de código e repete para o LLM: “se houver uma vulnerabilidade neste código, encontre-a”
    Ou seja, a ferramenta (harness) é a chave para tornar o LLM mais inteligente
  • Isso seria como confundir resolução de problema com verificação
    Algo como a analogia “se alguém te disser a fatoração, quebrar PKI fica fácil”

• Acham que a metodologia deste texto é uma comparação completamente errada
  Dar diretamente a função vulnerável e dicas é uma tarefa totalmente diferente
  Na prática, mesmo dividindo trechos de código e jogando em modelos pequenos, é difícil obter resultados no nível de modelos grandes
  Já encontraram muitos bugs no Redis com um pipeline simples de shell script
  Com modelos fracos não funcionou. Testando na prática, a diferença aparece
  Além disso, mesmo que modelos pequenos encontrem 80%, ainda é preciso um modelo mais forte para achar os 20% restantes

  • A Anthropic disse que divulgou menos de 1% das vulnerabilidades que encontrou
    Seria interessante dar a modelos abertos um ambiente Linux antigo e testar quantas eles conseguem achar
  • Mas outra pessoa considera essa abordagem razoável
    Modelos pequenos filtraram bem os false positives e, com um harness adequado, podem chegar a resultados parecidos com os de modelos grandes
    Como são rápidos e baratos, nas mãos de um usuário experiente podem ser muito mais eficientes
    Acham que essa combinação de modelo leve + harness vai virar tendência
  • Também houve quem reagisse com sarcasmo: “Thanks Dario, very cool!”

• Muitos comentários dizem “como separaram o código, isso é inválido”, mas a Anthropic também rodou o modelo de forma parecida, por arquivo
  O harness do Mythos atribuía uma pontuação de importância a cada arquivo e criava uma instância do Claude Code para focar nele
  Portanto, a simples separação do código não invalida o resultado

• A mesma técnica também aparece no vídeo da apresentação de Nicholas Carlini
  Fazer o LLM revisar intensamente um arquivo por vez parece ser eficaz
  A “inovação” do Mythos, na prática, foi essa simples automação de prompts por arquivo
  É bem possível que esse método tenha sido o motivo de o custo subir até US$ 20 mil
  Também testaram o mesmo método com Opus 4.6 e GPT 5.4, e a revisão foi muito mais minuciosa
  Ou seja, quando uma sessão fica focada em um único arquivo, o modelo analisa com muito mais profundidade

  • Mas assim podem passar despercebidas vulnerabilidades geradas por interações entre arquivos

• A expressão “modelos pequenos reconstruíram a mesma análise” é difícil de confiar porque não foi quantificada
  Validação de vulnerabilidades pode ser medida com clareza por PoC, então seria preciso esse tipo de evidência
  Além disso, “fornecer de antemão apenas o código relevante” não é uma comparação justa

• Sem divulgar a taxa de false positives, a análise perde sentido
  Se alguém disser que toda linha tem bug, a taxa de detecção é 100%, mas isso não serve para nada
  Como Anthropic e OpenAI não divulgam esses números, fica difícil confiar

  • Mas também houve o contraponto de que, se existir um oracle verificável, false positives podem ser ignorados
  • Na prática, modelos pequenos acertaram no teste de false positives, e o Opus errou
    Só que eles não chegaram ao nível de validação de exploit do Mythos
    O resultado do Deepseek R1 foi bastante convincente, mas não ficou claro se realmente funcionou
  • No mínimo, seria preciso atingir a mesma cobertura obtida pela Anthropic para isso ter significado

• O ponto central é que eles separaram o código relevante
  Zerodays complexos surgem da interação entre vários arquivos, então essa abordagem tem limitações

  • Mas alguns afirmam que o próprio Mythos também acabou fazendo análise por arquivo do mesmo jeito
  • Não está claro se o Mythos realmente encontrou vulnerabilidades entre arquivos

• O Mythos avaliou a base de código inteira, mas este estudo testou apenas o código vulnerável separado
  É a diferença entre “um cachorro que encontrou a bola na floresta” e “um cachorro ao qual disseram em que área a bola estava”

  • Chegaram até a comparar com passar cheiro na bola, deixar o cachorro sentir esse cheiro e soltá-lo numa área pequena
  • Como o Mythos não consegue enfiar o código inteiro de uma vez, é provável que vários subagentes tenham dividido o trabalho
    No fim, o importante não é o modelo, e sim o harness (sistema de ferramentas)