Cibersegurança é prova de trabalho

O UK AI Security Institute publicou uma avaliação independente do Claude Mythos Preview em tarefas de cibersegurança.¹ O número principal: Mythos completou uma simulação de ataque a rede corporativa de 32 etapas em 3 de 10 tentativas. Nenhum outro modelo resolveu a cadeia completa. No dia seguinte, Drew Breunig publicou o corolário econômico: cada uma dessas tentativas custou aproximadamente US$ 12.500 em tokens.² Juntas, essas duas análises reposicionam a cibersegurança de um problema de habilidade para um problema de computação.

A implicação é desconfortável. Defender um sistema agora exige gastar mais tokens descobrindo exploits do que os atacantes gastarão explorando-os.² Segurança sempre foi assimétrica — atacantes precisam de apenas um caminho, defensores precisam cobrir todos. Agentes de IA preservam essa assimetria, mas deslocam o eixo. O recurso escasso não é mais expertise. O recurso escasso é orçamento de computação.

O que o AISI realmente mediu

A avaliação usou duas abordagens de teste: desafios capture-the-flag (CTF) e simulações em cyber range.¹

O cyber range que importa — “The Last Ones” (TLO) — simula um ataque a rede corporativa de 32 etapas. Um humano precisaria de cerca de 20 horas para completá-lo.¹ Mythos completou a cadeia inteira em 3 de 10 tentativas. Considerando todas as 10 execuções, Mythos completou em média 22 das 32 etapas. Para comparação, o Claude Opus 4.6 completou em média 16 etapas no mesmo range.¹

Em tarefas CTF de nível especialista, Mythos teve sucesso em 73% das vezes.¹

Os orçamentos de tokens contam sua própria história. O AISI testou faixas de até 2,5 milhões de tokens para CTF não especialista, 50 milhões para CTF especialista e 100 milhões para as simulações em cyber range.¹ A avaliação nota explicitamente que “os modelos continuam progredindo com orçamentos de tokens maiores em todas as faixas testadas” e que o AISI espera que “melhorias de desempenho continuariam além” do teto de 100 milhões de tokens testado.¹

Mais tokens, mais progresso. Nenhum platô observado.

O AISI foi cuidadoso ao delimitar a descoberta. Os cyber ranges não tinham defensores ativos, ferramentas defensivas e penalidades por disparar alertas.¹ A avaliação se aplica a “sistemas empresariais fracamente defendidos e vulneráveis” — não ambientes de produção robustecidos com SOCs e IDS. Mythos também falhou no range “Cooling Tower”, que focava em tecnologia operacional.¹

Essas ressalvas importam. Porém, a trajetória importa mais. Modelos anteriores não conseguiam completar a cadeia inteira nesses ranges.¹ Agora um completa uma intrusão corporativa de 32 etapas em 3 de 10 tentativas, e a curva de desempenho se inclina para cima com mais computação. A questão não é se a IA consegue invadir redes corporativas. A questão é quando a taxa de sucesso cruza o limiar em que se torna economicamente racional automatizar.

A economia: US$ 12.500 por tentativa

A análise de Breunig converte as descobertas do AISI em dólares.² Com 100 milhões de tokens por tentativa, uma única execução do Mythos no TLO custa aproximadamente US$ 12.500. Dez tentativas no TLO custam US$ 125.000.²

Esses números parecem grandes isoladamente. Parecem pequenos em relação ao que um comprometimento de rede corporativa de 32 etapas custa ao defensor. O modelo alcança 30% de taxa de sucesso por uma fração do custo, roda sob demanda, e a taxa de sucesso melhora com o orçamento. Execute a mesma cadeia de ataque 100 vezes em vez de 10, e o número esperado de penetrações bem-sucedidas salta de 3 para 30 — um aumento de 10x a aproximadamente US$ 1,25 milhão em tokens. Caro para um pesquisador individual. Erro de arredondamento para um ator estatal.

A tese central de Breunig: “para fortalecer um sistema, você precisa gastar mais tokens descobrindo exploits do que os atacantes gastarão explorando-os.”² Segurança se torna uma corrida de orçamento de tokens. Na perspectiva de Breunig, defensores precisam gastar mais que atacantes em descoberta automatizada de exploits, ou perdem por padrão.

Ele propõe um modelo de três fases: Desenvolvimento, Revisão e Fortalecimento.² Desenvolvimento constrói o sistema. Revisão captura classes conhecidas de bugs. Fortalecimento é a nova fase — descoberta autônoma de exploits rodando continuamente até a equipe esgotar o orçamento. A segurança de um sistema se torna uma função de quantos tokens a equipe queima tentando quebrá-lo antes do deploy.

“Você não ganha pontos por ser esperto,” escreve Breunig. “Você vence gastando mais.”²

A Lei de Linus ganha uma dimensão de tokens

Breunig estende a Lei de Linus — “com olhos suficientes, todos os bugs são superficiais” — para incluir tokens.² Ciclos automatizados de revisão suficientes, com orçamento de computação suficiente, revelarão vulnerabilidades que a revisão humana deixou passar por décadas.

As evidências sustentam a extensão. O trabalho de Carlini no Anthropic, que cobri em When Your Agent Finds a Vulnerability, encontrou uma vulnerabilidade de 23 anos no kernel Linux usando um script bash de 10 linhas e Claude Code. O Project Glasswing escalou essa abordagem com Mythos para encontrar milhares de zero-days em todos os principais sistemas operacionais e navegadores. A avaliação do AISI agora fornece confirmação independente da capacidade.

Simon Willison acrescenta uma observação que vale destacar: a revisão de segurança orientada por IA aumenta o valor de bibliotecas open-source, porque os tokens gastos para protegê-las beneficiam todos os usuários coletivamente.³ Código proprietário arca com seus próprios custos de segurança. Código open-source amortiza esses custos por toda a base de usuários.

Breunig referencia o produto de revisão de código do Anthropic a US$ 15-20 por revisão como um ponto de dados sobre preços atuais.² Ele também cita os incidentes de supply chain do LiteLLM e Axios no contexto de segurança de dependências — exemplos do tipo de vulnerabilidade de supply chain que reforçam a necessidade de revisão automatizada.²

A fórmula se cristaliza: “Código continua barato, a menos que precise ser seguro.”² Cada linha de código em um sistema de produção carrega uma dívida de segurança implícita. Essa dívida anteriormente se escondia à vista de todos — enterrada nos salários de equipes de segurança e na esperança probabilística de que a revisão manual pegaria os bugs críticos. Segurança baseada em tokens torna o custo explícito e mensurável.

O que as ressalvas realmente significam

As ressalvas do AISI merecem leitura cuidadosa, não descarte.

A ausência de defensores ativos muda o cálculo significativamente. Uma cadeia de ataque de 32 etapas contra um sistema sem monitoramento, sem alertas e sem resposta a incidentes é um problema fundamentalmente diferente da mesma cadeia contra um SOC com equipe. Redes corporativas reais têm EDR, segmentação de rede, detecção de anomalias e analistas humanos. Cada alerta que um atacante automatizado dispara é uma chance de a defesa responder.

A ausência de penalidades por ruído significa que o modelo pode tentar abordagens de força bruta que um atacante humano evitaria. Um adversário real que dispara centenas de alertas IDS em uma hora é investigado. Os ranges do AISI não modelaram esse ciclo de feedback. Em uma rede real, ruído é caro — para o atacante. Furtividade restringe o espaço de busca. Remova essa restrição, e o problema se torna estritamente mais fácil.

A falha no Cooling Tower também é instrutiva. Mythos resolveu o range TLO focado em TI, mas falhou no range de tecnologia operacional.¹ Ambientes OT têm protocolos diferentes, restrições diferentes e modos de falha diferentes. O AISI observa que o modelo ficou preso em porções de TI daquele range, então a falha não necessariamente indica pouca capacidade específica em OT — mas as capacidades do modelo claramente não são uniformes entre domínios. Penetração de redes de TI e ataques a sistemas de controle industrial são problemas diferentes, e tirar conclusões sobre prontidão em OT a partir desta avaliação requer cautela.

Contudo, as ressalvas também têm data de validade. Orçamentos de tokens escalam. Capacidades dos modelos melhoram entre avaliações. A taxa de sucesso de 30% contra redes sem defesa é o piso, não o teto. O próprio AISI espera que o desempenho melhore além dos orçamentos testados.¹ Defensores que descartam as descobertas porque os ranges não tinham defesa ativa estão apostando contra a Lei de Moore para inferência.

Implicações operacionais para profissionais

Para qualquer pessoa rodando agentes de IA em produção — e eu rodo agentes autônomos durante a noite pelo Ralph Loop com 95 hooks como infraestrutura de segurança — a perspectiva de prova de trabalho muda a forma de pensar sobre defesa.

Hooks de segurança são um gasto mínimo, não suficiente. Meus 95 hooks controlam o que os agentes podem fazer: bloqueando force pushes, validando credenciais, impondo sandboxes. Esses hooks impedem meus próprios agentes de causar danos. Eles não fazem nada contra um atacante externo que gasta 100 milhões de tokens sondando os sistemas com os quais esses agentes interagem. Infraestrutura de hooks é necessária, mas não suficiente.

Testes ofensivos automatizados se tornam obrigatórios. O modelo de três fases de Breunig — Desenvolvimento, Revisão, Fortalecimento — implica que todo pipeline de deploy precisa de uma fase adversarial onde agentes de IA tentam quebrar o sistema antes do lançamento. Não um pentest de checkbox. Um exercício de esgotamento de orçamento de tokens. Rode descoberta automatizada de exploits até o orçamento acabar, corrija o que surgir, repita.

O Ralph Loop agora tem um corolário de segurança. Escrevi sobre degradação iterativa de segurança no contexto de desempenho — agentes que passam em todos os testes enquanto introduzem lentidões de 446x. O mesmo padrão se aplica à segurança. Um agente que escreve código correto, funcional e bem testado ainda pode introduzir vulnerabilidades sutis que só aparecem sob revisão adversarial automatizada. A solução é a mesma: adicionar o gate que falta. Benchmarks de desempenho capturam regressões de desempenho. Red-teaming automatizado captura regressões de segurança.

Dependências open-source merecem orçamentos de tokens. A observação de Willison sobre benefício coletivo se aplica diretamente ao gerenciamento de dependências. Toda biblioteca open-source em uma stack de produção está recebendo revisão automatizada de segurança de alguém, ou não está. Breunig cita os incidentes de supply chain do LiteLLM e Axios no contexto de segurança de dependências — casos em que vulnerabilidades persistiram em bibliotecas amplamente utilizadas.² Profissionais devem avaliar suas árvores de dependências com uma nova pergunta: quem está gastando tokens na segurança desta biblioteca?

A matemática desconfortável

A perspectiva de prova de trabalho torna a economia de segurança explícita de uma forma que modelos baseados em expertise nunca conseguiram. No modelo antigo, a qualidade da segurança era uma função de quem você contratava e quão habilidosos eram. No novo modelo, a qualidade da segurança é uma função de quantos tokens você gasta tentando quebrar seus próprios sistemas.

Talento ainda importa — alguém precisa interpretar resultados, priorizar correções e tomar decisões arquiteturais. Porém, a fase de descoberta, a parte em que vulnerabilidades são encontradas, é cada vez mais um problema de computação. E problemas de computação têm uma propriedade conhecida: a entidade com o maior orçamento vence.

O paralelo com a prova de trabalho de criptomoedas é instrutivo, mesmo que imperfeito. Mineradores de Bitcoin queimam eletricidade para proteger a cadeia. Defensores queimam tokens para proteger o sistema. Em ambos os casos, a garantia de segurança é proporcional à computação gasta. Em ambos os casos, um atacante com orçamento maior pode sobrepujar a defesa. A diferença: a dificuldade de mineração do Bitcoin se ajusta automaticamente. Orçamentos de tokens de segurança exigem julgamento humano sobre quanto é suficiente.

Para organizações bem financiadas, o caminho é claro. Adicione descoberta autônoma de exploits ao pipeline de deploy. Defina um orçamento de tokens proporcional ao perfil de risco do sistema. Esgote o orçamento. Corrija o que surgir. Lance.

Para todos os outros, o caminho é menos confortável. Se você não pode gastar mais tokens defendendo do que atacantes gastarão atacando, precisa contar com infraestrutura compartilhada — revisão de segurança open-source, varredura fornecida por vendors, defesa coletiva. O equivalente em segurança da imunidade de rebanho. E como a imunidade de rebanho, só funciona se participantes suficientes contribuírem. Pegar carona na revisão de segurança open-source sem contribuir tokens de volta é uma estratégia que funciona até parar de funcionar.

A avaliação do AISI mostrou que agentes de IA conseguem completar ataques a redes corporativas. Breunig argumenta que defesa é um problema de gasto. Willison identificou a única vantagem estrutural dos defensores: infraestrutura compartilhada amortiza custos entre todos que a utilizam.

A pergunta para todo profissional é a mesma que sistemas de prova de trabalho sempre fizeram: quanta computação você está disposto a queimar?

Citações