Não é preciso tratar o Mythos como se fosse o maior e o mais temível de todos.
Não me interpretem mal. Dependendo do critério de comparação que se utilize, o Mythos está entre os melhores modelos disponíveis atualmente e, em geral, é o melhor em termos de raciocínio. Mas não está muito à frente dos demais.
E, no que diz respeito a casos de utilização práticos, aplicar um modelo genérico — mesmo que seja um modelo de ponta — a um problema não produz os melhores resultados. Além disso, não é escalável nem rentável. Quando se trata de identificar vulnerabilidades, o conjunto de testes utilizado para um modelo é mais importante do que os próprios modelos.
Vamos começar por analisar por que razão o Mythos não é o modelo ideal para resolver todos os problemas e, em seguida, como é que um bom conjunto de ferramentas produz resultados de alta qualidade em grande escala.
O Mythos é um pouco exagerado
Primeiro, vamos analisar alguns factos. O Mythos é excelente, um dos melhores modelos de IA até à data, e continua a apresentar um desempenho de alto nível nos testes de desempenho. O Mythos destaca-se na construção de cadeias de exploração e na geração de provas de conceito, pelo que, desde o seu lançamento, acumulou um extenso historial na descoberta de vulnerabilidades de dia zero.
No entanto, embora algum receio e entusiasmo fossem justificados, a reação do mundo foi desproporcionalmente exagerada em relação às melhorias introduzidas em relação aos modelos anteriores. Cada novo modelo de ponta lançado no mercado é sempre melhor do que o anterior, mas apenas numa pequena medida.
E, neste momento, outros modelos de ponta também se encontram, em grande parte, ao mesmo nível, especialmente desde que o GPT-5.5 foi lançado em abril. O AI Security Institute do Reino Unido classificou-o aproximadamente no mesmo nível de capacidade cibernética que o Mythos. Na categoria mais difícil do seu conjunto de avaliações, o GPT-5.5 atingiu 71,4%, enquanto o Mythos atingiu 68,6%. Entre o Mythos e o GPT 5.5, um supera o outro dependendo da tarefa.
O Mythos não é perfeito e, por si só, ainda não é uma solução milagrosa para detetar todas as vulnerabilidades de segurança. Por exemplo, alguém executou o Mythos na base de código da biblioteca cURL e enviou os resultados por e-mail ao seu fundador e mantenedor, Daniel Stenberg. O Mythos identificou cinco «vulnerabilidades de segurança confirmadas». Mas, depois de a equipa de Stenberg as ter analisado, descobriu que três eram falsos positivos, uma era um bug não relacionado com segurança e apenas uma era uma vulnerabilidade real. Alguns dias depois, Steinberg recebeu 17 vulnerabilidades de pessoas que utilizaram outras ferramentas de IA. Ele afirmou no LinkedIn: «O Mythos está longe de ter chegado ao fim desta corrida», e no seu blogue sobre a experiência escreveu que considera que o entusiasmo em torno do Mythos é «principalmente marketing».
O arnês é mais importante do que o modelo
Com os diferentes modelos a destacarem-se agora em diversas tarefas e os modelos de topo a aproximarem-se em termos de capacidades, a principal variável na otimização da deteção de vulnerabilidades é o conjunto de ferramentas.
Um harness é a camada de orquestração que envolve um modelo (ou vários modelos). Isso inclui a lógica que determina qual agente é executado e quando, que contexto recebe, como os resultados são validados e quando se deve recorrer a um modelo mais avançado. Trata-se de código, conceção de fluxos de trabalho e arquitetura de prompts a funcionar em conjunto, sendo o modelo apenas mais um desses componentes.
Os harnesses direcionam os LLMs, fazendo com que passem de um modelo geral para um modelo altamente adequado a um determinado domínio e tarefas. Além disso, tiram partido do não determinismo dos LLMs, o que faz com que estes apresentem resultados ligeiramente diferentes de cada vez. Com um harness, vários agentes analisam uma base de código, partindo do princípio de que nenhum agente irá detetar 100% das vulnerabilidades (incluindo os agentes que funcionam no Mythos).
No contexto da investigação sobre vulnerabilidades, o estudoCloudflare apresenta um exemplo de como é, frequentemente, uma configuração sólida de um harness:
- Uma fase de reconhecimento que analisa o repositório e cria uma fila de tarefas para todos os processos a jusante
- Uma fase de detecção em que vários agentes operam em paralelo, cada um à procura de vulnerabilidades
- Uma fase de validação em que um agente independente, utilizando um prompt diferente e sem capacidade para gerar as suas próprias conclusões, tenta refutar o que o agente de pesquisa descobriu
- Uma fase de rastreio que analisa os resultados confirmados em todo o repositório para determinar se os dados introduzidos pelo atacante conseguem efetivamente atingir a vulnerabilidade a partir do exterior do sistema
- Lógica de deduplicação para consolidar resultados que tenham a mesma causa principal
O design do harness tem um impacto tão grande que, muitas vezes, é mais importante do que a própria escolha do modelo. Investigadores da UCSB executaram o mesmo Claude Opus 4.6 nas mesmas tarefas com diferentes harnesses e descobriram que o melhor harness passou quatro vezes mais testes do que o pior. A título de comparação, a diferença entre modelos de ponta como o Opus 4.6 e o GPT-5.4 em benchmarks de codificação padrão é de apenas cerca de um ponto percentual. Isso significa que as equipas obcecadas com a escolha do modelo estão a otimizar em excesso a variável errada.
Niels Provos demonstrou o mesmo conceito a partir de uma perspetiva diferente. Ele criou um conjunto de testes que identificou uma vulnerabilidade com 18 anos numa biblioteca popular e, em seguida, substituiu-a pelo GLM 5.1 de código aberto, obtendo resultados comparáveis. Ele demonstrou que um conjunto de testes robusto pode transformar o modelo num componente substituível, em vez de ser o principal fator determinante.
A investigação da equipa de segurança da Mozilla explica por que razão investir no desenvolvimento de harnesses compensa a longo prazo. Assim que o seu fluxo de trabalho de harnesses ficou consolidado, cada novo modelo que integravam melhorava imediatamente a deteção de falhas, a geração de provas de conceito e a análise de impacto, sem necessidade de qualquer reestruturação. Quando o Mythos ficou disponível, conseguiram integrá-lo e tirar partido dele de imediato. Se o harness for bem construído, o avanço dos modelos passa a ser algo que se aproveita naturalmente, em vez de ter de se esforçar para o adotar.
O dinheiro fala mais alto
Outro problema em utilizar o Mythos para tudo é de natureza económica. Os modelos de maior dimensão têm sempre um melhor desempenho, mas também são muito mais caros.
Executar o Mythos uma vez custa dinheiro real, cerca de dezenas de milhares de dólares, para realizar uma única análise exaustiva de um repositório em busca do que poderão ser algumas vulnerabilidades. Se executar o Opus 4.6, ou mesmo o GPT-5.4 nano, dez vezes pelo mesmo custo de executar o Mythos uma vez, geralmente encontrará mais vulnerabilidades. O custo não varia proporcionalmente à capacidade. Por exemplo, tanto as entradas como as saídas do GPT 5.4 custam metade das do GPT 5.5, mas o primeiro não tem metade da capacidade de raciocínio do segundo. Internamente, descobrimos que oito agentes GPT-5.4-mini superam um agente GPT-5.5 em alguns casos, e têm aproximadamente o mesmo custo. Modelos mais baratos permitem-lhe transformar o número de agentes numa vantagem.
O modelo mais pequeno produzirá, em geral, mais falsos positivos do que um modelo de fronteira, uma vez que é, de facto, menos preciso. Mas, neste caso específico, a quantidade é tão importante quanto a qualidade, pois o objetivo é garantir a deteção do maior número possível de vulnerabilidades. É aqui que os harnesses podem ajudar a filtrar o ruído supérfluo, permitindo que outros agentes verifiquem as cadeias de exploração e façam a limpeza, sendo esta abordagem muito mais económica do que executar o Mythos e modelos de fronteira para detetar tudo.
No que diz respeito aos autores de ameaças, o que é que eles vão realmente utilizar? Não é o Mythos. Em primeiro lugar, eles não o têm. Mas vão querer utilizar o que for mais barato, repetidamente e em grande escala, e não vão ficar à espera na fila. Os modelos de código aberto com interfaces decentes funcionam bem, e é provavelmente isso que estão a fazer neste momento.
E, para as organizações, o que é sustentável? Executar um modelo de ponta em cada alteração de código certamente não o é. Executar uma orquestração em várias camadas que utilize modelos económicos regularmente e modelos dispendiosos de forma precisa… isso sim, é.
Não prestem atenção à modelo atrás da cortina
O Mythos foi um momento fascinante na nossa história. Chamou a atenção de todos para o que os modelos são capazes de fazer atualmente. No entanto, é possível obter uma deteção autónoma de vulnerabilidades de alta qualidade e eficaz através de meios alternativos e mais económicos, em vez de se limitar ao Mythos ou ao Project Glasswing.
Os fornecedores limitados a um único modelo têm de aperfeiçoar esse modelo. As plataformas independentes de fornecedores podem escolher a ferramenta certa para cada tarefa. Um modelo mais simples pode abranger uma área mais ampla e identificar candidatos, enquanto um modelo mais robusto pode aprofundar-se nos que parecem interessantes e exigem capacidades de raciocínio mais elevadas. Para obter os melhores resultados em AppSec pentest de IA, deve dar prioridade a sistemas com infraestruturas sofisticadas que utilizem os modelos certos, em vez de se preocupar demasiado em ter o modelo mais sofisticado envolvido.
Na Aikido, percebemos desde cedo que a quantidade, a orquestração e a liberdade de escolher a ferramenta certa para cada tarefa são mais importantes do que correr atrás do que quer que esteja, neste momento, por trás do paywall mais caro. Como AppSec , consideramos que a nossa responsabilidade é criar a orquestração que permite que a camada de modelos continue a evoluir em segundo plano. Se quiser saber mais sobre como os nossos testes de penetração podem ajudá-lo a proteger a sua aplicação, fale connosco hoje mesmo.
P.S. Também elaborámos uma lista de verificação compatível com o Mythos para ajudar as equipas a prepararem-se para as ameaças da IA autônoma (seja ela alimentada pelo Mythos ou por vários GPT 5.4 minis).
