O governo acabou de banir um modelo de IA. A perspectiva de um engenheiro.

Passei a maior parte dos últimos três anos integrando IA à forma como minhas equipes desenvolvem e entregam software. Por isso, quando a notícia de que o governo dos EUA havia efetivamente desligado um modelo de IA se espalhou esta semana, fiquei realmente chocado. Não em um país. Não em uma empresa. Para todas as pessoas do planeta, de uma só vez.

Três dias. Foi esse o tempo que os modelos Fable 5 e Mythos 5, da Anthropic, ficaram disponíveis antes de o governo ordenar que fossem desligados para todos.

Não foram restritos. Não tiveram a exportação controlada para uma lista de países. Foram desativados. Por completo. Para todos os usuários. Tecnicamente, a ordem visava restringir o acesso de cidadãos estrangeiros, mas a Anthropic não tinha como distinguir cidadãos estrangeiros de pessoas dos EUA em tempo real. Para cumprir a ordem, retirou os dois modelos do ar para todos. Eles foram lançados em 9 de junho. Em 12 de junho, já tinham desaparecido.

Se você trabalha com segurança, isso deve receber toda a sua atenção. Não por causa da política, mas pelo que revela sobre o momento em que estamos e para onde estamos indo.

O que aconteceu

Aqui vai um resumo.

O Mythos 5 se mostrou excepcionalmente bom em encontrar vulnerabilidades de software. Tipo, muito bom. Com capacidade para encontrar bugs escondidos em bases de código há décadas. Então, um pesquisador descobriu um jailbreak que liberava esses recursos de detecção de vulnerabilidades de maneiras nunca pretendidas pela Anthropic. O governo avaliou a situação e concluiu que representava um risco à segurança nacional, temendo que adversários usassem o Mythos para descobrir e transformar vulnerabilidades zero-day em armas em grande escala.

Então, o governo emitiu uma diretriz de controle de exportação e, como a Anthropic não conseguia distinguir com segurança pessoas dos EUA de todas as outras, não teve escolha. Desativou o Fable 5 e o Mythos 5 para todos.

A Anthropic contesta a gravidade do caso. A empresa afirma que o jailbreak era restrito e que a resposta foi totalmente desproporcional. É possível argumentar sobre isso, e meu colega Stephen Thoemmes escreveu um relato detalhado do que aconteceu e de como o setor de segurança sempre lidou com recursos de uso duplo. Leia o texto dele para entender os detalhes. Este artigo trata do que isso significa.

Problema 1: seu fornecedor de IA agora é um risco na cadeia de suprimentos

Vamos falar sobre aquilo que ninguém quer discutir.

Se sua equipe de engenharia tivesse integrado o Fable 5 ou o Mythos 5 a algum fluxo de trabalho — revisão de código, triagem de vulnerabilidades, análise de segurança ou qualquer outro —, você teria acordado em 12 de junho e descoberto que esse recurso simplesmente... tinha desaparecido. Sem aviso de descontinuação. Sem prazo para migração. Sem um “vamos manter tudo funcionando por 90 dias enquanto você encontra uma alternativa”. Simplesmente desapareceu.

Isso é um evento na cadeia de suprimentos.

Há anos, nós, do setor, aprendemos — às vezes da maneira mais difícil — que nossas cadeias de suprimentos de software são frágeis. Vimos um único mantenedor apagar em massa pacotes do npm e derrubar metade da internet. Vimos o SolarWinds. Vimos o Log4Shell. Criamos SBOMs e ferramentas de análise de dependências, além de toda uma categoria de soluções para gerenciar o risco de código de terceiros desaparecer ou se tornar malicioso sem aviso.

Então, aqui vai minha pergunta: quantos de nós estão pensando no acesso a modelos de IA com o mesmo rigor?

A maioria das equipes trata o acesso a modelos de IA como um serviço básico. Você se cadastra, recebe uma chave de API, integra o modelo ao seu fluxo de trabalho e presume, sem pensar muito, que ele estará disponível amanhã. Esta semana abalou essa certeza. E, ao contrário de uma biblioteca que você pode fixar em uma versão e incluir no seu repositório, não dá para armazenar em cache um modelo que roda nos servidores de outra pessoa. Quando ele desaparece, desaparece de vez.

É nisso que minha equipe trabalha todos os dias na Snyk: fazer com que a segurança acompanhe seu código e seus agentes, em vez de ser algo que você, na prática, aluga de quem quer que forneça o primeiro modelo integrado. A conclusão prática é simples, mas importante: trate o acesso a modelos como qualquer outra dependência que você não controla. Mantenha uma alternativa. Coloque uma camada de abstração na frente. Tenha um plano para quando, numa manhã, o modelo tiver desaparecido.

Problema 2: banir recursos defensivos não impede os ataques

Agora, vamos à questão da cibersegurança, que torna tudo isso realmente desconfortável.

A preocupação do governo é simples: o Mythos 5 é tão bom em encontrar vulnerabilidades que, se adversários tivessem acesso a ele, poderiam descobrir e explorar vulnerabilidades zero-day mais rápido do que nunca. É uma preocupação legítima. Não vou fingir que não é.

Mas aqui vai uma pergunta que, na minha opinião, poucas pessoas estão fazendo: quem realmente sai prejudicado quando se proíbe uma ferramenta que encontra vulnerabilidades?

Quem quer encontrar e explorar vulnerabilidades não vai preencher a papelada e cumprir uma diretriz de controle de exportação. Nunca cumpriu. Isso é praticamente a definição de um atacante: não seguir as regras. Se um Mythos com jailbreak consegue encontrar vulnerabilidades zero-day, esse recurso já está por aí. O jailbreak foi publicado. Não dá para desfazer isso.

Então, quem é prejudicado? Os defensores. Os pesquisadores de segurança. As equipes de empresas como a sua, que tentam encontrar e corrigir vulnerabilidades antes que os criminosos cheguem a elas.

A cibersegurança sempre foi uma corrida armamentista. Desde que o setor existe. A premissa da segurança moderna de aplicações é que os defensores precisam ter pelo menos os mesmos recursos que os atacantes — e, idealmente, recursos melhores. Você analisa seu próprio código antes que outra pessoa o faça. Testa seus próprios sistemas. Executa exatamente as ferramentas que um atacante usaria, direcionadas à sua própria infraestrutura, para encontrar as brechas primeiro.

Tire esse recurso de todos que seguem as regras e você não vai desacelerar os atacantes. Só vai deixar os defensores em situação pior do que ontem. E quase tudo que vale a pena em segurança pode ser usado para o bem ou para o mal; o uso duplo está no cerne da área. O artigo de Stephen explica como o setor sempre lidou com essa tensão, desde a divulgação coordenada até os controles em camadas. Minha versão é mais curta: sempre que um recurso puder ser usado de forma indevida, desligue-o, e o botão de desligar acabará voltado contra quem está realmente na defensiva.

Isso abre um precedente perigoso

Quero deixar algo claro: entendo por que o governo agiu. A segurança nacional é coisa séria, e é realmente assustador imaginar Estados-nação hostis usando uma IA capaz de gerar vulnerabilidades zero-day em série. Essas preocupações não são levianas.

Mas o precedente me preocupa mais do que o incidente.

Agora ficou estabelecido que um modelo de IA pode ser desligado para todos, no mundo todo e sem aviso, por causa de um cenário de uso indevido potencial. Não um ataque real. Não uma violação confirmada. Um jailbreak que poderia, em teoria, ser usado para fazer coisas ruins.

Agora, leve essa lógica adiante. O que acontece quando o próximo modelo for incrível em detectar anomalias no tráfego de rede e esse mesmo recurso puder ser usado para vigilância? O que acontece quando um modelo for excelente em gerar correções de segurança, mas também puder, em teoria, ser induzido a gerar código de exploração? Quase todo recurso realmente útil em segurança é, por natureza, de uso duplo. Isso não é um defeito. É a própria área.

Reaja assim todas as vezes, e os defensores acabarão lutando em desvantagem, enquanto os atacantes — que nunca cumpririam um controle de exportação — continuam com liberdade total.

Ninguém fica mais seguro com isso. Só temos a sensação de que fizemos alguma coisa.

O que o setor de segurança precisa acertar

Então, para onde vamos daqui? Não tenho todas as respostas, mas acho que vale dizer algumas coisas em voz alta.

Precisamos de uma estrutura real para lidar com recursos de IA de uso duplo. “Banir tudo porque não conseguimos definir controles de acesso” é uma medida grosseira. Há décadas lidamos com essa tensão por meio da divulgação responsável, de licenças, de estruturas legais e de normas da comunidade — não banindo as ferramentas. Precisamos levar a mesma nuance para a IA, em vez de recorrer ao botão de desligar.

A comunidade de segurança precisa participar das decisões. A decisão foi tomada por autoridades de comércio, não pelas pessoas que passam os dias pensando em como proteger software de verdade. Não é uma crítica ao Departamento de Comércio. Controles de exportação são responsabilidade deles. Mas os efeitos para a segurança defensiva são enormes, e quem entende esses efeitos precisa ter voz antes da próxima decisão, não depois.

As empresas precisam tornar suas estratégias de IA resilientes agora. Não espere o próximo modelo ser retirado do ar. Se você está criando fluxos de trabalho críticos com uma IA que não controla, precisa de planos de contingência hoje: estratégias com vários fornecedores, camadas de abstração e alternativas. Trate isso como o risco de cadeia de suprimentos que realmente é.

E veja, na Snyk, nossa filosofia é que colocar ferramentas de segurança nas mãos de desenvolvedores — e agora de agentes de IA — torna o software mais seguro, não menos. Quanto mais pessoas puderem encontrar e corrigir vulnerabilidades, mais seguros todos ficarão. Isso sempre foi verdade para a análise estática, para os bancos de dados de vulnerabilidades de código aberto e para todos os recursos de segurança que conseguimos democratizar. Tenho certeza de que também será verdade para a segurança baseada em IA.

A resposta para “essa ferramenta é poderosa” deveria ser “vamos garantir que as pessoas certas possam usá-la com responsabilidade”. Não “vamos garantir que ninguém possa usá-la”.

O tempo está se esgotando

Estamos em um momento decisivo. Os recursos de IA para segurança estão avançando rápido, e as estruturas de políticas públicas estão correndo para acompanhar esse ritmo. É nessa lacuna entre o que a tecnologia pode fazer e o que as regras permitem que mora o risco real.

A proibição do Fable 5 e do Mythos 5 nesta semana é uma prévia de uma conversa muito maior, que teremos por anos. A forma como lidamos com a IA de uso duplo na cibersegurança vai determinar se os defensores conseguirão acompanhar os atacantes ou ficarão permanentemente para trás.

Prefiro que acertemos, em vez de simplesmente agirmos rápido. Mas precisamos começar essa conversa agora, porque as decisões que tomarmos hoje vão moldar o cenário de segurança por muito tempo.

E enquanto isso? Confira suas dependências de IA. Sério. Agora mesmo. Porque, se esta semana nos ensinou alguma coisa, é que o modelo de que você depende hoje talvez não esteja disponível amanhã.