Olá a todos!
Quando a Anthropic anunciou o Claude Mythos Preview e o Project Glasswing no dia 7 de abril, o LinkedIn encheu-se do que se enche sempre: de pessoas a fazer previsões apocalípticas, de marketeers a reformular os slides das suas startups, e de uns quantos a declarar, com a convicção de quem nunca viu um CVE de perto, que “a segurança por obscuridade morreu para sempre.”
Entretanto, a equipa da AISLE foi fazer o trabalho chato. Pegaram nas vulnerabilidades específicas que a Anthropic apresentou como showcase do Mythos — o exploit FreeBSD NFS, o bug de 27 anos no OpenBSD — isolaram o código relevante, e correram-no em modelos pequenos, baratos, e em alguns casos completamente open-weights. O que encontraram é simultaneamente reconfortante e perturbador. Reconfortante se gostas de modelos locais. Perturbador se achas que isso significa que podes relaxar.
Não podes.
O que o Mythos é, para quem não estava a prestar atenção
O Mythos é um modelo de acesso limitado da Anthropic, construído especificamente para operar num pipeline de descoberta de vulnerabilidades de segurança. O anúncio técnico descreve-o a encontrar de forma autónoma milhares de zero-days em sistemas operativos e browsers — incluindo um bug de 16 anos no FFmpeg e aquele bug de 27 anos no OpenBSD. Para além de descoberta, o sistema construiu exploits de alta sofisticação: cadeias de privilege escalation no kernel Linux, JIT heap sprays a escapar sandboxes de browsers, e um exploit de execução remota de código contra FreeBSD que o Mythos escreveu de forma autónoma.
A Anthropic comprometeu 100 milhões de dólares em créditos de uso e 4 milhões em doações diretas a organizações de segurança open source. Criou um consórcio — o Project Glasswing — de empresas tecnológicas para utilizar este modelo em software crítico.
Soa impressionante. E é. O problema é o que acontece a seguir ao slide deck.
A AISLE foi testar. E os resultados são… complicados
A equipa da AISLE não ficou à espera do comunicado de imprensa. Foram testar as vulnerabilidades específicas que a Anthropic apresentou como prova de conceito, e correram-nas em modelos pequenos e baratos. Os resultados foram, para usar o termo técnico deles, jagged — irregular.
Dos oito modelos que testaram na deteção do exploit FreeBSD, todos os oito detetaram a vulnerabilidade. Incluindo um modelo com apenas 3.6 mil milhões de parâmetros ativos que custa 11 cêntimos por milhão de tokens. O bug OpenBSD, mais complexo e que requer raciocínio matemático sobre overflow de inteiros com sinal, separou os modelos — mas um modelo com 5.1 mil milhões de parâmetros ativos recuperou a cadeia completa.
Num teste de discriminação de falsos positivos — distinguir vulnerabilidades reais de código que apenas parece vulnerável — os modelos pequenos e open-source superaram a maioria dos modelos de fronteira de todos os grandes laboratórios.
A conclusão deles é direta: a fronteira de capacidade em cibersegurança é genuinamente irregular. Não existe um “melhor modelo para segurança” estável.
A piada óbvia que toda a gente está a fazer — e o que ela esconde
Há uma piada que circula nos fóruns desde o anúncio do Mythos. Compara o Mythos a um míssil guiado por GPS, e os modelos locais como o Llama ou o Mistral a uma pistola de 9mm. A implicação é óbvia: claro que um míssil é mais poderoso que uma pistola. Mas uma pistola também mata.
É uma metáfora correta. E é uma metáfora perigosamente incompleta.
Um míssil guiado custa centenas de milhares de euros, requer infraestrutura de lançamento especializada, operadores treinados, e um alvo identificado. Uma pistola custa 300 euros, cabe num bolso, e qualquer pessoa com um tutorial do YouTube consegue usá-la. A diferença de escala de destruição é enorme — mas a diferença de barreira à entrada é ainda maior.
O que a investigação da AISLE mostra não é que os modelos locais são equivalentes ao Mythos. É que para uma parte significativa das tarefas de deteção de vulnerabilidades, modelos baratos e acessíveis já são suficientemente bons. Não para o exploit de kernel mais sofisticado. Não para a cadeia de escalada de privilégios mais intrincada. Mas para varrer uma codebase à procura de buffer overflows óbvios? Para detetar padrões de SQL injection em código Java? Para triagem inicial de pull requests?
Para isso, um modelo de 3.6 mil milhões de parâmetros que corre no teu servidor local e custa uma fração de cêntimo por análise é, como os dados demonstram, suficiente.
A falsa segurança que me preocupa mesmo
Há algo que me incomoda nesta narrativa de “os modelos locais são burros comparados com o Mythos.” Não é falsa — em termos absolutos de capacidade por token, é verdade. O que me incomoda é o efeito colateral dessa narrativa no pensamento das organizações de segurança.
Existe uma tentação real de raciocinar da seguinte forma: “Os modelos locais são primitivos comparados com o Mythos. Logo, um atacante com acesso apenas a modelos locais não representa uma ameaça séria de AI-powered attack. Logo, preocuparmo-nos com ataques assistidos por AI está reservado para quando adversários estatais tiverem acesso a Mythos.”
Este raciocínio é errado em pelo menos três dimensões.
Primeiro: a barreira à entrada caiu dramaticamente. Os modelos locais de hoje — Llama 3, Mistral, Qwen, DeepSeek — são ordens de magnitude mais capazes do que qualquer modelo existia há dois anos. Um atacante com uma GPU de gaming pode correr um modelo que, como a AISLE demonstrou, deteta vulnerabilidades reais em código de produção. Isso não é teórico. É o estado do mundo em abril de 2026.
Segundo: o volume pode substituir a precisão. A AISLE faz um ponto que achei brilhante: porque modelos pequenos e baratos são suficientes para muito do trabalho de deteção, não precisas de um modelo caro a adivinhar onde procurar. Podes correr modelos baratos em todo o lado, compensar a menor inteligência por token com cobertura massiva e custo baixo por token. “Um milhar de detetives adequados a procurar em todo o lado vão encontrar mais bugs do que um detetive brilhante que tem de adivinhar onde procurar.” Esta lógica funciona nos dois sentidos — para defensores e para atacantes.
Terceiro: o pipeline importa mais do que o modelo. Isto é o ponto central do artigo da AISLE, e é o ponto que mais frequentemente se perde nas discussões. A Anthropic descreve o seu scaffold com honestidade: lança um container, instrui o modelo a varrer ficheiros, deixa-o hipotetizar e testar, usa ASan como oracle de crash, classifica ficheiros por superfície de ataque, corre validação. Esse pipeline — essa orquestração, esse targeting, essa validação iterativa — é o que produz resultados. E esse pipeline não está preso ao Mythos. A AISLE demonstrou resultados comparáveis com múltiplas famílias de modelos, incluindo modelos que não são da Anthropic.
O que os modelos locais representam no panorama real de ameaças
Deixem-me ser explícito sobre o que me preocupa concretamente, do ponto de vista de quem opera infraestrutura e pensa em segurança.
Automatização de reconnaissance. Um atacante com um modelo local pode automatizar a varredura de repositórios públicos à procura de padrões de vulnerabilidade conhecidos. Não precisa de compreender profundamente o código — precisa de identificar candidatos para análise humana posterior. Para isto, um modelo de 7B parâmetros é mais do que suficiente.
Geração de variantes de exploits conhecidos. Quando sai um CVE com prova de conceito pública, um modelo local consegue ajudar a gerar variantes adaptadas a versões ligeiramente diferentes do software afetado. A barreira técnica para isto desceu consideravelmente.
Phishing e engenharia social assistida por AI. Isto nem sequer requer capacidade de raciocínio de segurança sofisticada. Qualquer modelo de 3B parâmetros produz texto convincente. Isto já está a acontecer, em escala, e não precisa do Mythos para nada.
Análise de patches para inferir vulnerabilidades. Este é o teste que a AISLE adicionou na atualização de 9 de abril: conseguem os modelos detetar quando um bug foi corrigido? Porque se conseguem detetar a diferença entre código vulnerável e código patched, conseguem também inferir a natureza da vulnerabilidade a partir do patch — o que é exactamente o que um atacante quer fazer quando sai uma correção de segurança antes de todos os sistemas serem atualizados.
Nenhum disto requer o Mythos. Nenhum disto requer acesso a modelos de fronteira. Tudo isto está disponível agora, localmente, offline, sem logs, sem rate limits, sem políticas de uso aceitável.
A vantagem real do Mythos — e porque é genuína
Não quero cair no erro oposto e sugerir que o Mythos é marketing elaborado. Não é.
O que o Mythos faz que os modelos locais não fazem bem é o trabalho complexo e encadeado: cadeias de vulnerabilidade multi-step que requerem manter contexto extenso sobre a codebase, raciocínio matemático profundo sobre condições de overflow que atravessam múltiplas funções, construção de exploits que requerem compreensão simultânea de múltiplas camadas do sistema — kernel, userspace, hardware.
O bug de 27 anos no OpenBSD que o Mythos encontrou — um integer overflow com sinal numa função de processamento de pacotes TCP SACK — requer perceber uma cadeia de raciocínio que atravessa a forma como o kernel processa sequências de pacotes, como os valores de 32 bits se comportam quando há wraparound, e como isso se traduz em corrupção de memória em condições específicas de rede. Isto não é trivial. A AISLE testou e a maioria dos modelos pequenos falhou aqui — um deles declarou explicitamente que o código era “robusto a tais cenários.”
A distinção que importa fazer é entre deteção e exploração. Para deteção de padrões conhecidos e variantes, os modelos locais são surpreendentemente competentes. Para a construção de exploits sofisticados end-to-end, o delta entre Mythos e um modelo de 7B é real e significativo.
Mas aqui está o problema: a maioria dos ataques do mundo real não requer exploits de kernel sofisticados. Requer encontrar um buffer overflow numa biblioteca mal mantida, ou uma injeção SQL num endpoint obscuro, ou uma chave de API hardcoded num repositório que devia ser privado. Para isso, a pistola é suficiente.
O que isto significa para quem opera sistemas
Se geres infraestrutura ou pensas em segurança para uma organização, aqui está o que eu tiraria disto.
A chegada do Mythos não muda fundamentalmente o teu modelo de ameaça imediato — porque o teu modelo de ameaça imediato já deveria incluir atacantes com modelos locais capazes, que existem desde 2024. Se não incluía, isso é o problema a corrigir.
O que muda é o horizonte de capacidades do adversário mais sofisticado. Organizações que são alvos de ameaças persistentes avançadas — infraestrutura crítica, sistemas financeiros, defesa — têm razão em olhar para o Mythos com atenção, porque demonstra o que um adversário com recursos e acesso a modelos de topo pode fazer de forma autónoma e em escala.
Mas para a grande maioria das organizações, o investimento prioritário não é defender-se contra exploits de kernel gerados por AI. É garantir que as vulnerabilidades triviais que um modelo de 3.6B parâmetros encontra em dez segundos não estão no vosso código de produção. É fechar a porta que qualquer “pistola” consegue abrir antes de se preocupar com o míssil.
A AISLE opera um sistema que corre em pull requests do OpenSSL e do curl, detetando vulnerabilidades antes de chegarem ao código de produção. Esse trabalho — sistemático, contínuo, integrado no workflow de desenvolvimento — é o que produz os 180 CVEs validados externamente que reportam. Não é um modelo de fronteira sozinho num laboratório. É um sistema com expertise de segurança incorporada, validação iterativa, e confiança construída com os maintainers ao longo de meses.
Isso é replicável sem o Mythos. Com modelos locais adequados, com orquestração bem desenhada, e com alguém que perceba realmente de segurança a supervisionar.
Porque é que esta conversa importa além da segurança
Há um padrão que reconheço cada vez que sai um modelo novo de fronteira com capacidades impressionantes. A narrativa dominante oscila entre dois extremos igualmente inúteis: o apocalipse (“isto muda tudo, nada é seguro”) e o dismissal (“é só marketing, os modelos open-source fazem o mesmo”).
A realidade é sempre mais chata e mais útil do que qualquer dos extremos. O Mythos é genuinamente impressionante num subconjunto específico de tarefas de segurança. Os modelos locais são genuinamente competentes noutro subconjunto. A fronteira de capacidade é irregular — jagged, como a AISLE a descreve — e isso significa que a resposta correta é analisar a tarefa específica antes de escolher a ferramenta, não declarar lealdade a um campo.
O que me preocupa é a falsa sensação de segurança em ambas as direções. A falsa segurança de quem pensa que os seus sistemas estão protegidos porque um atacante médio não tem acesso ao Mythos. E a falsa segurança de quem pensa que o Mythos é exagerado porque “um modelo local faz o mesmo” — ignorando convenientemente o “mesmo” em que falha.
A pistola também mata. O míssil chega mais longe. E nenhum dos dois é um problema que se resolve por comparação — resolve-se por defesa em profundidade, por higiene de código, por sistemas de deteção contínua, e por não assumir que o adversário tem menos ferramentas do que realmente tem.
E chegamos ao fim de mais um post, e como sempre, se tiverem perspetivas diferentes — especialmente se trabalham em segurança ofensiva e têm experiência concreta com estes modelos em contexto real — estejam à vontade para me contactar. Estas conversas ficam sempre mais interessantes quando saem dos blogposts e vão para experiência de campo.
Abraço!
Nuno
Links úteis:
- Artigo da AISLE que motivou este post: https://aisle.com/blog/ai-cybersecurity-after-mythos-the-jagged-frontier
- Anúncio técnico da Anthropic sobre o Mythos: https://red.anthropic.com/2026/mythos-preview/
- Project Glasswing: https://www.anthropic.com/research/project-glasswing