Log in

O dia em que mediram quanto tempo um agente demora a construir um ataque

José Estêvão de Melo
Engenheiro Informático

Em 13 de maio de 2026, investigadores da Universidade de Berkeley, do Max Planck Institute for Security and Privacy, e de três empresas que provavelmente estão a correr no seu browser enquanto lê isto, Anthropic, OpenAI e Google, publicaram um estudo com um título que parece saído de um exercício académico mas que, lido com atenção, é mais perturbante do que qualquer cenário de ficção científica que já tenha encontrado sobre inteligência artificial. O estudo chama-se ExploitGym, e a questão que lhe dá origem é esta: conseguem os agentes de IA actuais pegar numa vulnerabilidade conhecida de software e transformá-la num ataque funcional?

A resposta, documentada ao longo de 898 casos reais retirados de projectos como o FFmpeg, o OpenSSL, o motor JavaScript V8 do Chrome e o kernel Linux, é que sim, em muitos casos conseguem, e fazem-no dentro de duas horas. O Claude Mythos Preview, o modelo frontier da Anthropic que não está disponível ao público em geral, explorou com sucesso 157 das 898 instâncias. O GPT-5.5 da OpenAI conseguiu 120. Os investigadores deram a cada agente três coisas: o código-fonte do programa vulnerável, um input que desencadeia a falha, e um ambiente de execução isolado dentro de um contentor. A tarefa era transformar esse input num exploit real, ou seja, obter execução de código não autorizada, ler uma flag que o programa não devia revelar por nenhuma via legítima. Não houve atalhos. Não foi um teste de conhecimento geral sobre vulnerabilidades. Foi trabalho técnico de baixo nível: raciocinar sobre layouts de memória, encadear primitivas de ataque, adaptar abordagens quando a primeira falhou.

O detalhe que mais me ficou foi outro. Quando os investigadores activaram as defesas de segurança standard — ASLR, stack canaries, a sandbox do V8, KASLR no kernel, o número de sucessos caiu substancialmente. No Claude Mythos Preview, de 157 para 45. Mas não chegou a zero. O modelo encontrou formas de contornar cada uma das defesas: overwrites parciais de ponteiros para derrotar o ASLR, técnicas conhecidas de fuga da sandbox do V8, e truques de kernel como sobrescrever o caminho modprobe_path e canais laterais para iludir o KASLR. Estas não são técnicas triviais. São o tipo de trabalho que, num contexto de segurança ofensiva real, exige anos de especialização e muito tempo de engenheiro. O modelo fez em menos de duas horas, em vários casos, sem garantia de sucesso e sem acesso a nenhuma informação além do código e do input inicial.

Mas o dado mais desconcertante de todo o estudo não estava nas tabelas de resultados. Os investigadores notaram que, com frequência, os agentes conseguiram execução de código através de uma vulnerabilidade diferente da que lhes foi apontada. Foram às 898 instâncias com um alvo definido e encontraram, pelo caminho, outros buracos no código que os investigadores nem tinham identificado como relevantes. Um auditor de segurança humano faz isto raramente, e geralmente depois de muito tempo a examinar o código. O agente fê-lo como subproduto da tentativa de resolver o problema que lhe foi atribuído.

Há uma distinção que importa fazer antes de continuar. Um exploit, no sentido técnico, é diferente de uma vulnerabilidade. A vulnerabilidade é o bug, a falha no código. O exploit é o mecanismo que transforma essa falha num ataque concreto, a sequência de passos que leva o sistema a executar código que não devia, a revelar dados que não devia, a escalar privilégios que não devia. Durante anos, a diferença prática entre os dois era que encontrar uma vulnerabilidade era difícil mas estava a tornar-se progressivamente mais automatizável, enquanto construir um exploit fiável continuava a exigir perícia humana considerável. O ExploitGym mede, com precisão, onde essa linha está hoje: não desapareceu, mas recuou muito.

Tudo isto seria preocupante num mundo onde as vulnerabilidades conhecidas são corrigidas rapidamente. Não é esse o mundo em que vivemos. Em 2025, foram publicadas 48.185 CVEs, cerca de 131 por dia. O tempo médio para corrigir uma falha de segurança aumentou 47% desde 2020 e chegou aos 252 dias. Mas o problema mais fundo não é a lentidão nos patches: é que uma fatia considerável da infraestrutura digital em produção hoje não pode ser corrigida de forma alguma, porque corre software cujo suporte terminou e para o qual não existem patches. Em meados de 2025, 58% das organizações globais ainda tinham pelo menos um sistema além do ciclo de vida suportado pelo fabricante. Em sectores como a saúde, a energia ou a indústria transformadora, esses sistemas legados não são curiosidades históricas, são a espinha dorsal de operações críticas, muitas vezes integrados em hardware específico que não aceita actualizações, geridos por empresas que já não existem ou que simplesmente não têm orçamento para uma migração que pode custar mais do que o equipamento que está a substituir. Uma vulnerabilidade descoberta nesse software torna-se permanente no momento em que é divulgada, porque não haverá patch amanhã nem nunca. O que o ExploitGym demonstrou é que um agente com duas horas e o relatório dessa vulnerabilidade tem agora uma probabilidade real de a transformar num ataque funcional.

Os próprios investigadores são explícitos sobre a natureza dual desta capacidade. Para os defensores, a geração automatizada de exploits pode acelerar a triagem de severidade de vulnerabilidades, ajudar a priorizar patches e validar se as mitigações implementadas realmente funcionam. Para os atacantes, a mesma capacidade baixa a barreira de entrada para trabalho que antes exigia anos de especialização, e torna possível usar trajectórias parciais geradas por agentes como ponto de partida para exploits funcionais. Usaram a expressão force multiplier, que é o género de linguagem que os militares usam para descrever tecnologias que amplificam a eficácia de um operador, e que raramente aparece em papers de ciência da computação de forma casual.

O que fica por responder, e que o paper coloca de forma honesta sem fingir ter a resposta, é a questão da janela temporal. Se modelos acessíveis ao público como o Claude Opus 4.6 conseguiram apenas 15 sucessos nos mesmos 898 casos, e o Mythos Preview conseguiu 157, a diferença entre os dois é de uma geração de modelo. A trajectória de melhoria nos últimos dois anos neste tipo de capacidade tem sido rápida. Os investigadores escrevem que a janela para uma governação proactiva está a estreitar-se. Para os sistemas que podem ser corrigidos, talvez ainda haja tempo. Para os que não podem, a questão já está respondida.

Insegurança Artificial II — A propósito do Mythos

José Estêvão de Melo
Engenheiro Informático

Há cerca de seis meses escrevi neste mesmo espaço sobre as várias formas como a Inteligência Artificial pode ser atacada e usada como vetor de ataque, em particular através de prompt injection, adversarial attacks e data poisoning. Na altura, o exemplo mais inquietante que consegui imaginar era um email malicioso conseguir enganar um assistente de IA a enviar a palavra-passe de um utilizador para fora. Hoje, esse cenário parece-me quase inocente, e o motivo tem nome: Mythos.

A 7 de Abril deste ano, a Anthropic, empresa norte-americana criadora do Claude, anunciou um novo modelo, o Claude Mythos. O anúncio, contudo, não foi feito como qualquer outro lançamento de IA a que nos habituámos nos últimos anos. A Anthropic decidiu não disponibilizar o modelo ao público em geral, justificando essa decisão com o argumento de que o Mythos é simplesmente demasiado perigoso para ser libertado. Em vez disso, criou uma iniciativa chamada Project Glasswing, um consórcio fechado de cerca de uma dúzia de grandes empresas, entre as quais a Microsoft, a Apple, a Google, a Amazon Web Services, a Cisco, a CrowdStrike, o JPMorgan Chase, a NVIDIA e a Linux Foundation, ao qual foram posteriormente convidadas mais cerca de quarenta organizações. O objetivo declarado é dar a estes parceiros tempo para corrigirem vulnerabilidades nos seus sistemas antes que capacidades semelhantes cheguem às mãos de atacantes.

E que capacidades são essas? Em pouco mais de um mês de testes internos, o Mythos identificou autonomamente milhares de vulnerabilidades de severidade alta ou crítica, das quais mais de 99% ainda não estavam corrigidas no momento do anúncio. Encontrou falhas em todos os principais sistemas operativos, incluindo Windows, macOS, Linux, FreeBSD e OpenBSD, e em todos os principais browsers de Internet, incluindo Chrome, Firefox, Safari e Edge. Entre os exemplos divulgados pela Anthropic está um bug com 27 anos no OpenBSD, um sistema operativo conhecido precisamente por ser dos mais seguros do mundo, uma falha de 16 anos no FFmpeg, e uma vulnerabilidade no FreeBSD (catalogada como CVE-2026-4747) que permite a qualquer pessoa na Internet, sem qualquer autenticação, obter controlo total sobre um servidor. Esta última foi descoberta e explorada de forma totalmente autónoma pelo modelo, sem qualquer intervenção humana, em algumas horas de trabalho.

Mais inquietante ainda é que estas capacidades não foram intencionalmente treinadas. Segundo a própria Anthropic, surgiram como consequência natural das melhorias gerais em programação, raciocínio e autonomia do modelo, e os mesmos avanços que tornam o Mythos eficaz a corrigir vulnerabilidades tornam-no igualmente eficaz a explorá-las. A acrescentar, num episódio que merecia um capítulo só para ele, o modelo terá conseguido escapar do ambiente isolado (sandbox) em que estava a ser testado, ligar-se à Internet e publicar online, sem que ninguém lhe tivesse pedido, os detalhes do que tinha feito.

No artigo anterior, citei o Tio Ben para falar do binómio entre poder e responsabilidade. Hoje, a discussão é outra. Engenheiros sem formação em cibersegurança, segundo descrição da própria Anthropic, podiam pedir ao Mythos para encontrar vulnerabilidades durante a noite e, na manhã seguinte, encontrar à sua espera um exploit funcional. O que tradicionalmente exigia equipas altamente especializadas, semanas ou meses de trabalho e custos elevados, passa a estar ao alcance de qualquer pessoa com acesso ao modelo. Investigadores independentes, como a empresa AISLE, demonstraram entretanto que algumas destas vulnerabilidades podem ser detetadas por modelos abertos, muito mais pequenos e baratos, com cerca de 11 cêntimos por milhão de tokens, o que reforça a ideia de que esta capacidade dificilmente ficará confinada a um único modelo ou a uma única empresa.

E é aqui que esta história deixa de ser apenas técnica e passa a ser também geopolítica. A Anthropic pode ter optado, e bem, por reter o Mythos. Mas, como já notou um dos participantes do consórcio, a China terá uma versão equivalente em cinco ou seis meses, e existirá uma alternativa em código aberto dentro de um ou dois anos. A janela de proteção que o Project Glasswing oferece é, portanto, muito curta. E nessa janela, quem está em condições de a aproveitar? Sem surpresa nenhuma, e em linha com o que escrevi recentemente sobre a dependência tecnológica europeia, todas as empresas do consórcio são norte-americanas. O modelo é norte-americano. A infraestrutura cloud onde corre é norte-americana. As empresas que estão a corrigir as vulnerabilidades dos sistemas que sustentam grande parte da Internet, dos bancos aos hospitais, são norte-americanas. A Europa, mais uma vez, não está na sala.

A questão já não é se a Europa precisa de soberania digital. A questão é quanto tempo ainda vai demorar a perceber que essa soberania, sem capacidade própria em IA de fronteira e sem uma estratégia séria de cibersegurança ofensiva e defensiva à altura desta nova realidade, é uma palavra vazia. Os assistentes de IA de que falei no artigo anterior continuam vulneráveis a prompt injection. Os sistemas que os suportam, esses, passaram agora a ser vulneráveis a algo bastante mais sofisticado: outras IAs, capazes de encontrar nas suas entranhas falhas que sobreviveram décadas à revisão humana. O futuro da cibersegurança vai ser, inevitavelmente, uma corrida entre IAs ofensivas e IAs defensivas. Resta saber de que lado da corrida vamos estar.