Mythos achou falhas e BofA mobilizou 4 mil para corrigir

O scanner ficou bom demais para o próprio bem

Mythos da Anthropic passou pelos sistemas do Bank of America e encontrou tanta vulnerabilidade que o banco precisou mobilizar 4 mil pessoas só para corrigir. Não é teste pontual, não é piloto de laboratório. É operação real, com mil terceirizados contratados às pressas mais 3 mil funcionários internos trabalhando nisso desde o segundo trimestre. Quando a ferramenta de segurança funciona bem demais, ela não resolve o problema. Ela revela o tamanho do problema que você estava ignorando.

Quem já operou segurança em empresa grande conhece essa sensação. Você liga um scanner novo, mais agressivo, e de repente o backlog explode. A diferença agora é a escala e a qualidade do achado. Não estamos falando de alertas genéricos de linter ou de CVEs antigas que todo mundo já conhece. O Mythos, distribuído via Project Glasswing para parceiros selecionados, teria encontrado milhares de falhas sérias. E o Bank of America é só o primeiro grande a admitir publicamente quanta gente precisou para limpar a bagunça.

O fato sem enfeite

O CEO Brian Moynihan confirmou que o banco contratou mil prestadores externos para atuar ao lado de 3 mil funcionários internos na correção das falhas apontadas por modelos como o Mythos. O trabalho começou no segundo trimestre e segue em andamento. No terceiro trimestre, o banco gastou algumas centenas de milhões de dólares somando esse esforço de correção com exigências de combate à lavagem de dinheiro. Não houve abertura do custo isolado do patching, o que já diz muito sobre como esses números se misturam no balanço.

O contexto ajuda a entender o peso. A Anthropic liberou o Mythos em abril apenas para parceiros fechados, afirmando que ele havia descoberto milhares de vulnerabilidades graves. A OpenAI respondeu em maio com o programa Daybreak, focado em cibersegurança. No início, muita gente tratou os avisos dos laboratórios como marketing para vender medo. Depois de incidentes como o ataque à Hugging Face e de avaliações independentes que confirmaram a capacidade desses modelos em auditoria de código, o ceticismo caiu. Agora temos um banco americano gigante dizendo, na prática: sim, a IA acha falha de verdade, e dá trabalho consertar.

Como funciona na visão de quem opera

Pensa no Mythos e no Daybreak menos como antivírus e mais como um revisor de código incansável com contexto quase infinito. Em vez de buscar assinaturas conhecidas, esses modelos leem repositórios inteiros, cruzam fluxo de dados, entendem autenticação, sessão, serialização, injeção, condições de corrida. Provavelmente operam com acesso a código fonte e a histórico de commits via API, rodando em batches paralelos que nenhum time humano conseguiria acompanhar. A latência por achado cai drasticamente, o custo por vulnerabilidade encontrada vai a centavos comparado com pentest tradicional.

O gargalo muda de lugar. Antes, o custo estava em achar o bug. Você pagava consultoria cara, esperava semanas por um relatório, recebia 20 achados e corrigia 15. Agora, achar ficou barato e rápido. O modelo cospe centenas ou milhares de achados plausíveis em dias. Só que cada achado precisa de triagem, reprodução, avaliação de explorabilidade, escrita de patch, teste de regressão, deploy controlado em ambiente regulado como o de um banco. Isso não escala com GPU. Escala com gente, pipeline de CI, janela de mudança e aprovação de risco. É provável que o Bank of America tenha montado filas de priorização por severidade e por exposição, com times separados para validar se o alerta é verdadeiro positivo antes de mandar para correção.

O que isso muda na prática

Para quem constrói software, o recado é direto: seu backlog de segurança vai crescer, mesmo que seu código não tenha piorado. O que mudou foi a lente. Se um banco com orçamento quase ilimitado precisou de 4 mil pessoas para lidar com o resultado, imagina uma fintech de 200 engenheiros ou um SaaS em crescimento. Quem ganha agora é quem já tem higiene básica de engenharia, testes automatizados, ownership claro de serviços e capacidade de fazer deploy seguro rápido. Quem perde é quem acumulou dívida técnica por anos e tratava segurança como tarefa de fim de trimestre.

• Trazer a triagem para dentro: não deixe o modelo jogar vulnerabilidade direto no colo do dev. Crie uma camada de validação com engenheiros de segurança e agentes que reproduzem o problema e sugerem patch.
• Medir tempo de correção por severidade: separe falhas exploráveis remotamente de problemas teóricos. Sem isso, o time trava tentando corrigir tudo ao mesmo tempo.
• Ajustar contrato e orçamento: inclua verba recorrente para correção assistida por IA, porque varredura vai virar rotina trimestral, não evento anual.

Na prática, a ação mais urgente para times médios é simples: rode uma dessas ferramentas de auditoria em um repositório crítico em ambiente isolado e meça quantos achados reais aparecem em uma semana. Não para corrigir tudo, mas para calibrar sua capacidade de resposta. Se dez achados já travam sua sprint, você tem um problema de throughput, não de scanner. Melhor descobrir isso agora do que quando o auditor ou o regulador pedir o relatório.

Isso escala ou só move o gargalo?

Aqui está a tensão que ninguém quer admitir. Moynihan disse que espera que os custos de correção caiam com o tempo. Faz sentido em teoria, porque a base fica mais limpa. Mas na prática de operação, tenho dúvida. Modelos melhores vão achar classes novas de falhas, em código novo que você escreve todo dia. Você limpa mil vulnerabilidades hoje e o próximo deploy cria cinquenta. O custo não some, ele vira custo operacional contínuo, como infraestrutura em nuvem. E tem outro ponto: corrigir rápido em banco não é só commitar. Envolve compliance, trilha de auditoria, testes em mainframe legado, sistemas que ninguém quer tocar.

Também existe o risco de correção ruim feita às pressas. Com 4 mil pessoas, incluindo mil terceirizados que chegaram agora, como garantir qualidade consistente de patch? Um fix malfeito em autenticação ou em lógica de pagamento pode abrir uma falha pior que a original. A IA achou o buraco, mas fechar o buraco sem quebrar o prédio continua sendo trabalho artesanal, cheio de contexto de negócio. No fim, a automação barateou a descoberta e expôs o quanto a correção ainda é manual, lenta e cara. Isso resolve segurança ou só transfere a pressão para o time de engenharia?

Conclusão que importa

O Bank of America mostrou o novo normal: descobrir vulnerabilidade com IA é fácil, corrigir em escala continua sendo um esforço humano massivo. A pergunta que fica para o seu time é bem objetiva, quantos achados por semana você consegue corrigir sem parar a entrega?