Quando um governo retira um modelo de IA do ar: o que a suspensão do Fable 5 e do Mythos 5 significa para as equipes de segurança

Na noite de 12 de junho de 2026, a Anthropic desativou o acesso a dois de seus modelos mais recentes, Claude Fable 5 e Claude Mythos 5, para todos os clientes no mundo todo. A empresa não fez isso por causa de uma interrupção no serviço ou de uma falha que tivesse descoberto por conta própria. Fez isso para cumprir uma diretriz de controle de exportações do governo dos EUA, recebida às 17h21, no horário do leste dos EUA, naquele dia, com base em prerrogativas de segurança nacional.

Para quem trabalha com segurança, os detalhes importam mais do que a política: qual teria sido o gatilho, como a medida se desenrolou e o que ela revela sobre depender do modelo de outra empresa. São questões sobre as quais as equipes de segurança podem agir, independentemente de sua posição no debate sobre políticas públicas.

O que realmente aconteceu com o Fable 5 e o Mythos 5 da Anthropic

É importante ser preciso, porque a versão resumida que circula online ("o governo proibiu o modelo para todo mundo") não corresponde exatamente ao que consta nos registros.

Segundo o comunicado da Anthropic, a diretriz ordenou que a empresa "suspendesse todo o acesso ao Fable 5 e ao Mythos 5 por qualquer pessoa de nacionalidade estrangeira, dentro ou fora dos Estados Unidos, incluindo funcionários da Anthropic de nacionalidade estrangeira". Em seus termos, a restrição visava o acesso por pessoas de nacionalidade estrangeira, não todos os usuários.

A suspensão global foi a consequência prática. Como explicou a Anthropic, "o efeito líquido dessa ordem é que precisamos desativar abruptamente o Fable 5 e o Mythos 5 para todos os nossos clientes para garantir o cumprimento". Não há como separar com segurança, em tempo real, pessoas de nacionalidade estrangeira de cidadãos dos EUA em uma base de usuários com centenas de milhões de pessoas — especialmente com aviso no mesmo dia. Por isso, a empresa desligou os modelos para todo mundo. Essa distinção importa: a ordem visava o acesso por pessoas de nacionalidade estrangeira, mas, na prática, a única maneira de cumpri-la com tão pouco aviso era suspender o acesso de todos.

O motivo alegado foi um suposto "jailbreak de IA". Veja como a Anthropic descreveu as evidências que recebeu: "o governo só nos apresentou evidências verbais de um possível jailbreak restrito e não universal, que consiste basicamente em pedir ao modelo que leia uma base de código específica e corrija eventuais falhas de software". A empresa acrescentou que "o nível de capacidade demonstrado está amplamente disponível em outros modelos (incluindo o GPT-5.5 da OpenAI) e é usado todos os dias pelas equipes de defesa que mantêm os sistemas seguros".

O governo não publicou a diretriz, e a carta não apresentou uma justificativa técnica específica. Por isso, as informações públicas se baseiam em grande parte no relato da Anthropic. Os recursos cibernéticos de modelos de fronteira são, legitimamente, uma questão de segurança nacional, e reportagens indicam que a diretriz foi motivada pela alegação de jailbreak feita por terceiros. O que se pode analisar aqui é a natureza da medida e como ela se compara às práticas de segurança consolidadas, não os detalhes sigilosos que a motivaram.

O gatilho relatado: análise e correção de código

Pedir a um modelo que leia uma base de código e corrija suas falhas não é um ataque extraordinário. É revisão automatizada de código e correção de vulnerabilidades — o mesmo trabalho feito por análise estática, fuzzers, revisão de código com IA e qualquer profissional de segurança que executa uma verificação antes de uma versão ser lançada. É um recurso usado rotineiramente pelas equipes de defesa e, como a maioria dos recursos de segurança, tem natureza de uso duplo.

A comunidade técnica apontou isso rapidamente. No Hacker News, um comentarista colocou a questão assim: "Se entendi direito, o 'jailbreak' é pedir ao modelo para corrigir a base de código e, então, ele expõe as falhas? Parece uma lacuna quase impossível de corrigir sem reduzir muito a capacidade. Afinal, você quer que ele consiga corrigir sua base de código." Não existe um modelo de programação capaz de corrigir vulnerabilidades que também não consiga descrevê-las.

Nos dias que antecederam a suspensão, alguns pesquisadores de segurança reclamaram justamente do contrário: as proteções do Fable 5 eram rígidas demais para trabalhos legítimos de defesa. Valentina Palmiotti, da IBM X-Force, disse ao TechCrunch que o modelo "rejeita qualquer solicitação que possa ter alguma relação com segurança cibernética". Na mesma semana, o modelo foi criticado por ser restritivo demais para as equipes de defesa e retirado do ar por causa de um recurso usado na defesa.

O uso duplo de recursos é algo comum em segurança. Um scanner de portas, um analisador de pacotes, um fuzzer, um mecanismo SAST, um depurador e uma prova de conceito de corrupção de memória são ferramentas "ofensivas" ou "defensivas" dependendo de quem as usa e com que objetivo. Não proibimos o nmap nem classificamos o Wireshark como arma. Em geral, a área de segurança concluiu que não dá para melhorar a defesa proibindo as ferramentas de que ela precisa.

Como a área de segurança lida com os riscos de uso duplo

O problema geral é antigo: existe um recurso poderoso que pode ser usado de forma indevida. Há décadas, a área de segurança vem desenvolvendo uma resposta para isso, e essa resposta é um contexto útil, independentemente da conclusão a que se chegue sobre essa medida específica. Ela se baseia em algumas práticas.

Divulgação coordenada. Quando alguém encontra uma falha grave, a prática estabelecida é comunicá-la em particular a quem pode corrigi-la, combinar um prazo e publicá-la depois que houver uma correção. O objetivo da divulgação responsável é reduzir os danos e, ao mesmo tempo, fazer o ecossistema avançar. Segundo a Anthropic, ela recebeu apenas evidências verbais de um possível jailbreak, sem que a descoberta específica fosse apresentada por escrito. O governo não descreveu publicamente seu próprio processo.

Defesa em profundidade. Não se espera que um único controle seja perfeito. Por isso, as equipes combinam controles e partem do princípio de que alguns vão falhar. A Anthropic afirma que desenvolveu o Fable 5 exatamente com base nesse princípio e declarou isso no lançamento: "acreditamos que, atualmente, nenhum provedor de modelos consegue impedir todos os jailbreaks". A estratégia era torná-los "restritos [...] ou muito caros de executar" e "combinar isso com monitoramento rigoroso para detectar e interromper rapidamente qualquer ataque bem-sucedido". A lógica é a mesma da segurança de aplicações em camadas: verificações na IDE, na pull request e no CI, além de monitoramento em produção. A expectativa não é impedir que qualquer coisa passe. É contar com as camadas para detectar e conter o que passar.

Priorização baseada em risco. Programas de segurança maduros não tratam toda descoberta como uma emergência máxima, pois isso é impossível e contraproducente. Quando surge uma CVE crítica em um pacote npm popular, o ecossistema não tira todo o npm do ar. Ele faz a triagem com base na possibilidade de exploração e na alcançabilidade, prioriza os casos que realmente importam, aplica correções e verifica os resultados. Toda a abordagem da Snyk para proteger código gerado por IA e para segurança de aplicações em geral parte dessa ideia: a gravidade é importante, mas não basta. A pergunta útil é sempre: "quais desses riscos são reais, alcançáveis e mais importantes de resolver primeiro?" Raramente as equipes de segurança têm de escolher entre tudo ou nada. A prática é encontrar uma resposta gradual que corresponda ao risco real.

É difícil avaliar, com base nas informações públicas, como essa medida específica se alinha a essas práticas, já que o governo não descreveu seu processo. As práticas oferecem um referencial comum para o debate que se seguiu.

As diferentes reações à suspensão do Fable 5

A reação pública se dividiu rapidamente. Uma linha de argumentação apontou que a Anthropic havia defendido publicamente a autoridade do governo sobre a implantação de IA e agora protestava quando essa autoridade foi exercida. Em seu comunicado, a Anthropic concordou que os governos devem poder bloquear implantações inseguras, mas apenas "por meio de um processo legal transparente, justo, claro e fundamentado em fatos técnicos". A empresa afirmou que "essa medida não respeita esses princípios". O governo declarou que a medida se baseava na segurança nacional, uma preocupação reconhecida quando se trata dos recursos cibernéticos de modelos de fronteira. Reportagens indicam que a diretriz foi emitida após uma alegação de jailbreak feita por terceiros. As evidências específicas não foram divulgadas.

Outras reações não tinham muito a ver com nenhuma das partes. Desenvolvedores que haviam criado soluções com o Fable 5 se preocuparam com a confiabilidade, e muitos viram o episódio como argumento a favor de modelos com pesos abertos ou hospedados por conta própria, que não podem ser desligados remotamente. Alguns interpretaram o caso, com ceticismo, como publicidade antes de um IPO. Simon Willison registrou o momento em que o acesso foi interrompido.

Também há precedentes. Nos anos 1990, os EUA trataram a criptografia forte como material bélico controlado e restringiram sua exportação. Por fim, tribunais americanos decidiram que publicar código de segurança é uma forma de expressão protegida. Essas restrições limitavam a exportação, mas não obrigavam a retirar do ar um produto já implantado para usuários domésticos — uma das diferenças entre aquele caso e este.

A questão da confiabilidade que as equipes de segurança não podem ignorar

Deixe de lado as questões jurídicas: há uma lição operacional que continua válida, independentemente do desfecho do debate sobre políticas públicas.

Uma única diretriz tirou do ar, em poucas horas, um produto amplamente disponível para toda a sua base global de usuários. Para quem havia integrado o Fable 5 a um fluxo de trabalho, a disponibilidade do modelo podia ser revogada por fatores fora do seu controle e do controle do fornecedor. Quem desenvolvia com o modelo e acompanhava o episódio em tempo real chegou a uma conclusão óbvia: contar com modelos alternativos agora é um requisito de resiliência, não apenas uma questão de custo ou desempenho. Tratar um único modelo hospedado como dependência essencial cria um ponto único de falha. E pontos únicos de falha são um problema de segurança, quer a causa seja uma interrupção no serviço, uma cobrança, uma mudança de política ou uma carta do governo.

Essa é a mesma disciplina que a Snyk aplica ao restante da cadeia de suprimentos de software. Você não pode gerenciar o que não consegue ver. Por isso, conhecer o raio de impacto da sua IA, inventariar onde os componentes e as dependências de IA estão nos seus sistemas por meio da descoberta de ativos e planejar para a falha de qualquer um deles está se tornando indispensável. A suspensão do Fable 5 mostra isso na prática.

Juntos, somos mais fortes: o papel das ferramentas de segurança

Qualquer que seja o desfecho do debate sobre políticas públicas, as equipes de segurança precisam continuar trabalhando. A questão prática é como gerenciar no dia a dia os recursos de IA de uso duplo, e a área de segurança já tem práticas consolidadas para isso. Na Snyk, já vemos esse cenário se desenrolar nas próprias ferramentas de IA: nossa pesquisa ToxicSkills auditou quase 4.000 habilidades de agentes de IA e descobriu que mais de um terço tinha pelo menos uma falha de segurança, desde injeção de prompts e segredos expostos até malware propriamente dito.

Divulgação coordenada, controles em camadas, monitoramento contínuo e priorização baseada em risco não são conceitos abstratos. São práticas diárias que permitem continuar desenvolvendo e lançando software, mesmo com a descoberta constante de vulnerabilidades. Elas se aplicam diretamente ao desenvolvimento e à operação com IA:

• Proteja continuamente o código gerado por esses modelos. A IA escreve mais código e mais rápido, mas nem todo código é seguro. Verificar o código gerado por IA no momento em que é criado e na pull request, com correções automatizadas sempre que possível, ajuda a conciliar velocidade e segurança. Esse é o foco das orientações da Snyk sobre desenvolvimento seguro com IA e sobre abordagens no nível de tipo para gerar código seguro com IA.

• Estabeleça proteções para o comportamento da IA. Em geral, o controle mais útil é sobre a ação, não sobre o modelo inteiro. O trabalho da Snyk sobre proteções para assistentes de programação com IA e sobre o futuro da segurança de agentes de IA reflete essa abordagem: limite o que um agente pode fazer, monitore-o e intervenha de forma específica.

• Trate os sistemas de IA como parte da superfície de ataque que você já gerencia. Injeção de prompt, exposição de informações confidenciais e os demais itens do OWASP Top 10 for LLMs são riscos de aplicações e devem ser tratados com práticas de segurança de aplicações. Os resultados do ToxicSkills descritos acima representam exatamente esse tipo de risco: real, mensurável e administrável com as ferramentas e os processos que as equipes de defesa já usam.

Proteger o código gerado por IA é o ponto de partida para a maioria das equipes. Este breve tutorial da Snyk mostra como fazer isso na prática:

Play Video: The Secret to Secure AI Code

O segredo para proteger código gerado por IA (Como manter seguro o código escrito por IA à medida que o volume e a velocidade aumentam)

Nada disso exige escolher entre “a IA é segura” e “a IA é perigosa”. É a mesma abordagem que o setor de segurança adota diante de toda tecnologia poderosa: presumir que há riscos, criar camadas para gerenciá-los, divulgar e corrigir problemas de forma coordenada e manter as equipes de defesa bem preparadas.

O que as equipes de segurança e quem desenvolve devem levar em conta

1. Não deixe que um único modelo hospedado se torne uma dependência crítica. Crie redundância entre modelos e mecanismos de contingência para tudo o que for importante. Se você não controla a disponibilidade, precisa se planejar para esse risco.

2. Faça um inventário de onde a IA está presente na sua stack. Não é possível avaliar o raio de impacto sem descobrir quais ativos existem. Saiba de quais modelos e componentes de IA dependem seus serviços, pipelines e produtos.

3. Faça da análise do código gerado por IA uma prática padrão, não uma etapa esquecida. Com o volume e a velocidade do código escrito por IA, analisar desde a criação e nas solicitações de pull, com correção automatizada, é a maneira prática de acompanhar o ritmo.

4. Prefira barreiras de proteção e monitoramento a botões de desligamento. Limite as ações, monitore o comportamento e intervenha de forma pontual. Reserve a remoção completa para situações que realmente justifiquem essa medida e defina com antecedência quais são elas.

5. Pratique a divulgação coordenada de vulnerabilidades e espere o mesmo dos outros. Você não consegue corrigir uma vulnerabilidade que não conhece. Exija evidências e um plano de correção, e ofereça o mesmo aos outros.

Conclusão

A suspensão do Fable 5 e do Mythos 5 ainda será debatida por algum tempo sob os aspectos jurídicos e políticos, e pessoas razoáveis podem ter opiniões diferentes sobre se os governos devem poder tirar do ar um modelo em produção. Para as equipes de segurança, as lições mais duradouras não dependem de quem tem razão. O recurso no centro da controvérsia é usado rotineiramente por equipes de defesa. E o resultado prático — a remoção, em poucas horas, de uma dependência disponível no mundo todo — é um argumento concreto a favor da redundância e da visibilidade.

Recursos poderosos e de uso duplo não são um problema novo, e o setor de segurança já sabe como lidar com eles: mantenha redundância suficiente entre modelos para que nenhum provedor seja uma dependência crítica, saiba onde a IA está presente na sua stack, analise o código gerado por IA assim que ele chega, crie barreiras de proteção para limitar o que a IA pode fazer em vez de recorrer a botões de desligamento e pratique a divulgação coordenada nos dois sentidos. Aplicada continuamente, essa abordagem permite que as equipes continuem entregando software diante dos riscos de uso duplo — e é aí que as ferramentas de segurança, incluindo a Snyk, entram em cena. Esse é o caminho para fazer mais em conjunto.