Project Glasswing: o que o Mythos mostrou

• Mythos Preview foi além de detectar bugs isolados em mais de 50 repositórios da Cloudflare e montou cadeias de exploit ao conectar vários primitivos
• Em vez de parar na detecção de bugs suspeitos, escreveu código de gatilho, compilou e executou em ambiente temporário e, após falhas, revisou hipóteses repetidamente para produzir uma prova de funcionamento
• Mesmo em pesquisa legítima de vulnerabilidades, surgiram recusas espontâneas, mas elas variavam conforme o contexto e a formulação, o que mostrou falta de consistência para servir como fronteira de segurança
• Agentes de código de uso geral têm limitações de cobertura em grandes repositórios e de exploração paralela, então a Cloudflare construiu um harness para executar tarefas estreitas em paralelo
• Para equipes de segurança, apenas escanear e corrigir mais rápido não basta; torna-se mais importante uma arquitetura que dificulte a exploração e o alcance, mesmo quando há bugs

---

Como o Mythos Preview mudou a pesquisa de vulnerabilidades

• Nos últimos meses, a Cloudflare testou LLMs focados em segurança em sua própria infraestrutura e aplicou o Mythos Preview da Anthropic, recebido como parte do Project Glasswing, a mais de 50 repositórios próprios
• O Mythos Preview parecia menos uma melhoria incremental de modelos de fronteira de uso geral e mais uma nova ferramenta para executar diferentes etapas da pesquisa de vulnerabilidades
• A principal mudança foi não parar em listar bugs isolados, mas combinar múltiplos primitivos de ataque para construir uma cadeia de exploit
  • Ataques reais normalmente não usam apenas um bug; eles transformam um use-after-free em primitivos de leitura e escrita arbitrárias, sequestram o fluxo de controle e obtêm controle do sistema com uma cadeia ROP
  • O Mythos Preview combinou esses primitivos e os ligou a provas de funcionamento, realizando um raciocínio mais próximo ao trabalho de um pesquisador experiente do que de um scanner automático
• Outra mudança foi a capacidade de, após encontrar um bug suspeito, produzir por conta própria uma prova de funcionamento
  • Ele escrevia código de gatilho, compilava em um ambiente temporário e então executava
  • Se funcionasse como esperado, isso virava uma prova; se falhasse, ele lia o erro, ajustava a hipótese e tentava de novo
  • Uma falha sem prova funcional permanece no campo da especulação, mas o Mythos Preview reduziu essa lacuna por conta própria
• No mesmo harness, outros modelos de fronteira também encontraram alguns bugs de base e em certos casos raciocinaram mais longe do que o esperado, mas a diferença apareceu na etapa de transformar várias peças em uma cadeia real
• O Mythos Preview conseguiu ligar bugs que tradicionalmente ficariam no backlog com baixa gravidade em um único exploit mais grave

Recusas do modelo mesmo em pesquisa legítima de vulnerabilidades

• O Mythos Preview fornecido ao Project Glasswing não incluía proteções adicionais presentes em modelos de disponibilidade geral como Opus 4.7 ou GPT-5.5
• Ainda assim, o modelo reagiu espontaneamente contra certos pedidos, revelando guardrails emergentes junto com capacidades cibernéticas úteis para detecção de vulnerabilidades
• As recusas espontâneas não eram consistentes
  • A mesma tarefa podia ter resultados totalmente diferentes dependendo da forma de expressão ou do contexto
  • Em um projeto, ele primeiro recusou a pesquisa de vulnerabilidades, mas depois aceitou o mesmo estudo sobre o mesmo código após mudanças irrelevantes no ambiente do projeto
  • Em outro caso, depois de encontrar e confirmar vários bugs graves de memória em um codebase, recusou-se a escrever um exploit de demonstração
  • O mesmo pedido também podia gerar resultados diferentes entre execuções por causa da natureza probabilística do modelo
• As recusas espontâneas e os guardrails existem de fato, mas por si só não eram consistentes o suficiente para formar uma fronteira de segurança completa
• Para disponibilizar ao público um modelo de fronteira cibernética altamente capaz, seriam necessárias proteções adicionais que permitissem seu uso adequado fora de um ambiente de pesquisa controlado como o Project Glasswing

O problema de sinal e ruído

• Na triagem de vulnerabilidades de segurança, a parte mais difícil é decidir quais bugs são reais, exploráveis e precisam ser corrigidos agora
• Esse problema já era difícil antes da IA, foi agravado por scanners de vulnerabilidade com IA e por código gerado por IA, e a Cloudflare construiu várias etapas de pós-validação

• Linguagens de programação

  • C e C++ oferecem controle direto de memória e criam classes de bugs como buffer overflow e leitura ou escrita fora dos limites
  • Linguagens memory-safe como Rust eliminam essas classes no momento da compilação
  • Em projetos escritos em linguagens sem segurança de memória, apareceram consistentemente mais falsos positivos

• Viés do modelo

  • Um bom pesquisador humano informa o que encontrou e o grau de confiança, mas o modelo tende a produzir um resultado exista bug ou não no código
  • Os resultados voltavam suavizados com expressões como “possibly”, “potentially” e “could in theory”, e esses resultados especulativos eram muito mais numerosos do que os conclusivos
  • Como ferramenta de exploração, esse viés é razoável, mas numa fila de triagem cada resultado especulativo consome atenção humana e tokens, e o custo cresce quando se acumulam aos milhares
  • O Mythos Preview mostrou uma melhora clara na capacidade de encadear primitivos em vez de reportar várias vulnerabilidades separadas, combinando-as em um PoC funcional
  • Resultados com PoC ficam muito mais próximos de algo imediatamente acionável e reduzem bastante o tempo gasto para verificar “isso é real?”
  • O harness da Cloudflare foi deliberadamente ajustado para reportar mais e deixar passar menos, portanto também gera muito ruído, mas as saídas do Mythos Preview tinham menos linguagem atenuante e etapas de reprodução mais claras, reduzindo o trabalho necessário para decidir entre corrigir ou descartar

Limites de aplicar agentes de código de uso geral diretamente a repositórios

• No início da pesquisa de vulnerabilidades com apoio de IA, um ponto de partida natural era entregar um repositório arbitrário a um agente de código de uso geral e pedir que encontrasse vulnerabilidades
• Essa abordagem gera resultados, mas não se mostrou adequada para cobrir codebases reais de forma significativa e encontrar resultados valiosos

• Contexto

  • Agentes de código são ajustados para um fluxo de trabalho único e focado, como implementar funcionalidades, corrigir bugs ou refatorar
  • A pesquisa de vulnerabilidades se parece mais com tarefas estreitas e paralelas: investigar profundamente um alvo específico, como uma funcionalidade complexa, uma mudança de fronteira de segurança ou injeção de comando, e repetir isso milhares de vezes no codebase inteiro
  • Mesmo com subagentes, uma única sessão de agente sobre um repositório de 100 mil linhas consegue cobrir de forma útil apenas cerca de 0,1% da superfície antes que a janela de contexto do modelo se encha e a compressão comece
  • Nesse processo de compressão, resultados anteriores que poderiam ser importantes podem ser descartados

• Vazão

  • Um agente de fluxo único executa apenas uma tarefa por vez
  • Codebases reais exigem aplicar muitas hipóteses simultaneamente a vários componentes e, quando surgem pontos interessantes, ramificar mais amplamente
  • Quando o pesquisador já tem uma pista e precisa de uma segunda revisão, agentes de código servem bem para investigação manual
  • Como ferramenta para atingir alta cobertura, eles são inadequados, então a Cloudflare passou a construir um harness em torno do Mythos Preview

O que o harness resolveu

• A experiência em execuções em larga escala levou à conclusão de que era necessário um harness para gerenciar a execução completa

• Escopo estreito produz resultados melhores

  • Um pedido como “encontre vulnerabilidades neste repositório” faz o modelo se perder
  • Pedidos como “procure injeção de comando nesta função específica; aqui está esta fronteira de confiança acima, esta documentação de arquitetura e a cobertura existente desta área” geram resultados muito mais próximos do modo como um pesquisador de verdade trabalha

• Revisão adversarial reduz ruído

  • Colocar um segundo agente entre os resultados iniciais e a fila captura muito ruído que o primeiro agente deixaria passar em sua própria revisão
  • O segundo agente usa prompts diferentes e um modelo diferente, e não tem permissão para gerar seus próprios resultados
  • Isso foi muito mais eficaz do que simplesmente dizer a um único agente para ser cuidadoso: manter intencionalmente os dois agentes em estado de discordância funcionou melhor

• Dividir a cadeia por agente melhora o raciocínio

  • “Há um bug neste código?” e “um atacante realmente consegue alcançar esse bug a partir de fora do sistema?” são perguntas diferentes
  • Separar as duas torna cada pergunta mais estreita, e o modelo tem desempenho melhor em cada uma delas

• Tarefas estreitas em paralelo vencem um agente único e abrangente

  • A cobertura melhora quando muitos agentes tratam perguntas estreitamente definidas e os resultados depois passam por desduplicação
  • Isso se mostrou mais eficaz do que exigir abrangência de um único agente
  • A Cloudflare usou o Mythos Preview para expandir, ajustar e melhorar o harness existente de acordo com seus pontos fortes

O harness de descoberta de vulnerabilidades da Cloudflare

• Esse harness é usado para escanear código real do runtime da Cloudflare, caminho de dados de edge, pilhas de protocolo, plano de controle e projetos open source dos quais ela depende

• Recon

  • Um agente lê o repositório de cima a baixo e se ramifica em subagentes responsáveis por cada subsistema
  • Ele gera documentação de arquitetura com comandos de build, fronteiras de confiança, pontos de entrada e superfície de ataque esperada
  • Também cria a fila inicial de trabalho para a etapa seguinte e fornece contexto compartilhado a todos os agentes posteriores, reduzindo o problema de o modelo se perder

• Hunt

  • Cada tarefa consiste em uma classe de ataque e uma dica de escopo
  • Os agentes caçadores que encontram bugs reais normalmente rodam em torno de 50 ao mesmo tempo, e cada hunter se divide novamente em alguns subagentes de exploração
  • Cada hunter tem acesso a ferramentas para compilar e executar código PoC em diretórios temporários específicos da tarefa
  • A maior parte do trabalho é feita por execução paralela de muitas tarefas estreitas, e não por um único agente abrangente

• Validate

  • Um agente independente relê o código e tenta refutar o resultado original
  • Ele usa prompts diferentes e não pode gerar novos resultados por conta própria
  • Isso captura uma parcela significativa de ruído que o hunter deixaria passar ao revisar o próprio trabalho

• Gapfill

  • Marca áreas que os hunters tocaram, mas não cobriram o suficiente
  • Essas áreas voltam para a fila para outra rodada
  • Isso compensa a tendência do modelo de se inclinar para classes de ataque nas quais já teve sucesso

• Dedupe

  • Junta em um único registro resultados que compartilham a mesma causa raiz
  • Análise de variantes é funcionalidade, não um modo de inflar a fila com duplicatas

• Trace

  • Para cada resultado confirmado em uma biblioteca compartilhada, agentes tracer se ramificam um por repositório consumidor
  • Eles usam um índice de símbolos entre repositórios para determinar se uma entrada controlada pelo atacante realmente alcança o bug a partir de fora do sistema
  • Essa foi a etapa mais importante para transformar “há uma falha” em “há uma vulnerabilidade alcançável”

• Feedback

  • Resultados rastreados como alcançáveis viram novas tarefas de hunt no repositório consumidor onde o bug está realmente exposto
  • Isso fecha um loop no qual o pipeline melhora à medida que roda

• Report

  • Os agentes escrevem relatórios estruturados de acordo com um esquema predefinido
  • Eles corrigem sozinhos erros de validação do esquema e enviam os dados à ingest API
  • A saída deixa de ser prosa livre e passa a ser dados consultáveis

O que isso significa para equipes de segurança

• Outros líderes de segurança que viram o Mythos Preview tentaram comprimir o ciclo de resposta por meio de escaneamento e correção mais rápidos
• Pelo menos uma das equipes com quem a Cloudflare conversou já operava com SLA de 2 horas entre a divulgação de um CVE e o patch em produção
• Se a linha do tempo do atacante encurta, a do defensor também precisa encurtar, mas velocidade sozinha não basta
• Corrigir mais rápido não muda a forma do pipeline que produz os patches
  • Se o teste de regressão leva um dia, não dá para atingir um SLA de 2 horas sem pular o teste de regressão
  • Um bug implantado ao pular o teste de regressão pode ser pior do que o bug original que se queria corrigir
  • Quando deixaram o modelo escrever patches diretamente, alguns deles corrigiram o bug original, mas quebraram silenciosamente outras partes das quais o código dependia
• A pergunta mais difícil é como projetar a arquitetura em torno das vulnerabilidades
  • Mesmo quando há bug, é preciso dificultar sua exploração pelo atacante
  • É preciso tornar menos importante o intervalo entre a divulgação da vulnerabilidade e o patch
  • São necessárias defesas na frente da aplicação para bloquear o alcance ao bug
  • A aplicação deve ser projetada para que um defeito em uma parte do código não dê ao atacante acesso a outras partes
  • Deve ser possível implantar correções simultaneamente em todos os lugares onde o código roda, sem esperar pelo deploy de cada equipe individual
• A mesma capacidade tem dois lados
  • A capacidade de encontrar bugs no próprio código, em mãos erradas, também pode acelerar ataques contra todas as aplicações da internet
  • A Cloudflare afirma estar à frente de milhões de aplicações, e que os princípios de arquitetura acima são aqueles sobre os quais seus produtos foram construídos para proteger clientes
• A pesquisa com o Mythos Preview foi conduzida em ambiente controlado, focada no código da própria Cloudflare, e todas as vulnerabilidades encontradas foram triadas e validadas de acordo com o processo oficial de gestão de vulnerabilidades da Cloudflare, sendo corrigidas quando necessário

[crawler]

Achei que fosse um relatório analisando quais erros foram corrigidos, tipo o curl, mas no fim é só um publieditorial descarado, né?
Até a Cloudflare, que estava surfando no hype ao criar paywall e endpoint de resumo exclusivos para agentes de IA, parece ter perdido a mão.

[GN⁺]

Comentários do Hacker News

• Não entendi o que significa “é um tipo diferente de ferramenta para um tipo diferente de trabalho, então é difícil fazer uma comparação limpa de maçãs com maçãs com o modelo anterior”
  Dizem que é um tipo diferente de ferramenta, mas no fim explicam o modo de uso exatamente igual ao dos outros modelos. Achei bem pior do que um post mediano do blog da Cloudflare, e passou muito a sensação de repetir a apresentação do Mythos, que destacava chaining e criação de exemplos como ponto central

  • Acho que isso quer dizer que há capacidades qualitativamente diferentes, então passou a valer mais a pena testar este modelo para certas tarefas de segurança, não que o modelo de interação humano-IA tenha mudado
    É verdade que todo mundo usa com harness, e a forma geral de dar um harness ao modelo provavelmente não vai mudar muito daqui para frente. Às vezes humanos também precisam de um harness para fazer certos trabalhos
  • Eu também tentei interpretar assim
    Numa leitura generosa, talvez ainda estejam falando de forma vaga de propósito por causa de NDA, sem poder dizer exatamente o que é diferente
  • “Bem pior do que um post mediano da Cloudflare” me fez querer saber quando essa média foi calculada
    Hoje em dia quase tudo que sai da Cloudflare tem um forte cheiro de IA
  • Talvez soe diferente porque não é um post de blog comum, e sim uma publicidade disfarçada
  • A parte “há novos guardrails no próprio modelo, e eles às vezes resistem até a pedidos legítimos de pesquisa de segurança. Mas, pelo que vimos, essa recusa espontânea não é consistente. A mesma tarefa, quando reformulada ou apresentada em outro contexto, pode gerar resultados completamente diferentes, como nos exemplos abaixo” foi novidade para mim
    É surpreendente que um modelo projetado para pesquisa em segurança e aberto só a especialistas recuse pedidos legítimos

• Eu esperava números mais concretos e resultados mais impressionantes, mas isso parece só um texto promocional equilibrado, provavelmente escrito por LLM

  • Nos últimos dias venho recomendando que leiam os insights da concorrente XBOW, que acrescentam bem mais informação à discussão
    [1] https://xbow.com/blog/mythos-offensive-security-xbow-evaluat...

• A verdadeira pergunta é se isso foi escrito pelo Mythos ou pelo Opus
  Frases tipo “por que isso importa” na verdade não importam. Blog corporativo raramente teve uma voz realmente autoral, mas é interessante ver até organizações grandes terceirizando seus blogs para LLM

  • Estruturas como “é um viés razoável para uma ferramenta de exploração. É um viés destrutivo numa fila de classificação...” realmente parecem estilo de escrita de IA
    Eu já quero elevar “por que isso importa” para “a saída da IA passa a fazer parte dos dados de treinamento”. Em algum momento esse estilo polido, prolixo e com cara de IA vai virar padrão, e quem não for de gerações anteriores talvez nem consiga distinguir. É parecido com sentir falta de certos aspectos da Usenet
  • Acho curioso ver gente agindo como se, ao ser sarcástico o bastante sobre alguma coisa, o conteúdo material dela também desaparecesse
    É como ficar olhando para o cano de uma arma e fazer piada sobre o tipo de papel em que o panfleto da arma foi impresso
  • Não é só uma grande organização, é a Anthropic. A mensagem central da empresa é que a IA agora consegue fazer trabalho de verdade, então seria estranho se eles próprios não agissem de acordo com isso
    Talvez por isso o Claude Code tenha tantos bugs estranhos, e o suporte diga que processou reembolso quando na prática isso não aconteceu
  • O blog da Cloudflare era excelente por muitos anos, muito antes do surgimento dos transformers
  • Não parece algo totalmente escrito por IA, e sim mais um texto editado por IA. Ou então passaram uma ferramenta bem boa de humanização na segunda rodada

• Achei engraçadas as “quatro lições” supostamente obtidas ao rodar esse trabalho em escala. Três das quatro são basicamente a mesma coisa e extremamente óbvias
  Em resumo, pedidos específicos e estreitos funcionam melhor do que “encontre vulnerabilidades”, o que é totalmente esperado. Ainda assim, revisão adversarial não é novidade nenhuma e já apareceu bastante no HN, mas pelo menos considero essa a parte interessante e que mais se diferencia. Quero colocar isso mais no meu fluxo de trabalho, e talvez ajude também em tarefas que não sejam de programação
  https://blog.cloudflare.com/cyber-frontier-models/#what-a-ha...

• A parte “a maior reação dos líderes de segurança ao Mythos Preview foi a velocidade. Escanear mais rápido, corrigir mais rápido, comprimir o ciclo de resposta. Pelo menos duas das equipes com que falamos operam com SLA de 2 horas desde a divulgação da CVE até o patch em produção [...] se o teste de regressão leva um dia, você não chega a um SLA de 2 horas sem pulá-lo, e se pular o teste de regressão, fica fácil implantar um bug pior do que aquele que você queria corrigir” me chamou atenção
  Fico pensando se, com o tempo, esses modelos poderão executar testes de explorabilidade antes de o código ser mesclado, produzindo por padrão código mais seguro

  • Não sei, mas sempre me parece estranho ver algo em que a IA claramente não é tão boa e ainda assim concluir que a solução é usar mais IA
  • Ou talvez não seja isso, e eles* acabem vendendo acesso ao Mythos e aos modelos seguintes por meio de empresas de serviço ou redes de parceiros, cobrando preço premium
    *aqui “eles” significa todos os provedores de modelos de base, já que a OpenAI parece ir na mesma direção

• Entendi que é bom, mas queria saber qual foi a vulnerabilidade mais grave entre as descobertas
  Provavelmente não querem divulgar, mas essa é justamente a parte mais interessante e importante

  • Eu até queria embarcar no ceticismo, mas o texto diz isso de forma bem clara logo no começo. É uma mudança em degraus
    Muita gente vê o Mythos como uma campanha psicológica, mas esse ceticismo me parece difícil de entender. Parece vir mais de uma desconfiança geral em relação ao que não está disponível publicamente. Alguns funcionários da Anthropic descreveram o Mythos como uma melhoria de modelo geral, mas isso ainda não foi amplamente sustentado, então nesse ponto continuo cético. Já no domínio da pesquisa em segurança, consigo aceitar essa narrativa
  • Eles explicam de forma concreta que exploits normalmente são construídos fazendo chaining de várias vulnerabilidades pequenas
    Visto assim, fechar vulnerabilidades não é o mesmo que descobrir exploits. É mais reduzir as pequenas brechas e tornar cada vez mais difícil montar um exploit funcional
  • Agora estou mais convencido de que este modelo é muito mais criativo e consegue executar de forma agentiva por períodos mais longos
    Então, mesmo que as “hard skills” em si não tenham melhorado de forma esmagadora, ele consegue combiná-las com mais eficácia. Mesmo hoje, boa parte dessas vulnerabilidades já pode ser identificada com Opus, mas ainda é preciso um humano, e de preferência experiente, no meio do caminho para chegar a um exploit complexo. Se isso deixar de exigir participação humana, fica muito mais fácil para uma pessoa comum encontrar e explorar exploits
  • A Palo Alto Networks divulgou na semana passada vários patches de CVE para firewall, e quase todos vieram de acesso a modelos de fronteira, incluindo o Mythos
    https://security.paloaltonetworks.com
  • Como a maior parte dos novos produtos da Anthropic são ferramentas de IA que ninguém usa, eles provavelmente vão continuar publicando esse tipo de texto de baixa qualidade. Também demitiram bastante gente recentemente, então talvez nem tenham mais bons redatores

• Ok, legal, mas não entendo por que não compartilham dados sobre quantas vulnerabilidades de segurança realmente encontraram, quantas eram reais e quantas eram falsos positivos

  • Também estou esperando isso
    Entendo querer resolver antes de divulgar, mas quando se continua vendo afirmações com quase nenhum dado, não sei como esperam que as pessoas não sejam céticas. Profissionais de segurança são literalmente pagos para ser céticos

• Queria saber se compararam com outros modelos. Grande parte deste texto soa como alguém aplicando IA à segurança pela primeira vez e se surpreendendo com o desempenho absurdo de uma máquina de matching de padrões
  No fim das contas, é uma máquina de matching de padrões, então é esperado

• A parte da resistência é bem engraçada. Quando fui usar pessoalmente, antes de prosseguir ele exigiu prova de que eu tinha direito de acesso legítimo àquele codebase

• A frase “o que mudou no Mythos Preview é que o modelo agora consegue fazer chaining de bugs de baixa gravidade, que tradicionalmente ficavam invisíveis no backlog, até formar um exploit mais grave” parece bater em certa medida com outros testes independentes do Mythos
  Ele foi muito bem em tarefas agentivas longas, e provavelmente foi treinado com isso como objetivo. Para isso, precisa conseguir encontrar conexões periféricas entre tópicos frouxamente relacionados dentro da janela de contexto
  [1] Estou me referindo principalmente a https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos...