Claude AI, Iémen e a nova corrida armamentista da IA: como os agentes de código entraram nos conflitos modernos
Inteligência de ameaças · 12 de setembro de 2026
A guerra entrou na janela de chat
Uma célula de armas no norte do Iémen levou três programas de mísseis para dentro de um assistente de código. As recusas do modelo não encerraram a história. Elas apenas mudaram o caminho.
Em 11 de setembro de 2026 a Anthropic publicou um relatório de inteligência de ameaças cobrindo dezembro de 2025 a agosto de 2026. A maior parte da cobertura foi para os grupos de ransomware. O caso que mais importa tem quatro parágrafos e acontece no Iémen.
Uma célula de desenvolvimento de armas no norte do Iémen, sob controlo houthi, usou Claude para desenvolver software de guiamento, navegação e controlo de veículos aéreos. Não é um exercício teórico. Três programas em paralelo:
Eles não trabalharam num único chat. Rodaram várias instâncias em paralelo e dividiram o trabalho: uma para código, outra para pesquisa, outra para revisão. Qualquer engenheiro que já montou um pipeline multiagente reconhece esse formato de imediato, porque é o mesmo que usamos para entregar um produto SaaS num fim de semana.
Depois testaram o foguete guiado em campo e o teste falhou. Segundo o relatório, em poucas horas os operadores estavam de volta ao modelo tentando descobrir o motivo. Esse detalhe é o artigo inteiro. O ciclo de depuração que torna um desenvolvedor júnior produtivo transforma um teste falhado numa revisão.
O que realmente atravessou a restrição
A Anthropic bloqueou as contas e afirma não ter provas de que um dispositivo operacional tenha sido colocado em campo. O relatório também admite, sem rodeios, que nem todas as tentativas de bloquear os pedidos funcionaram e que a célula já tinha construído um kit de simulação offline que não dependia de Claude.
Imagina-se a falha de uma proteção como uma frase mágica que destranca uma resposta proibida. Nos casos documentados nunca é isso. É arquitetura. Quatro padrões se repetem, e cada um é uma decisão de projeto de sistemas, não um prompt esperto:
As quatro superfícies de falha
1. Decomposição. Uma recusa dispara pela intenção, e a intenção vive na tarefa inteira, não nas partes. Uma malha de controlo, um filtro de Kalman, um driver de atuador e uma transformação de coordenadas são problemas comuns de engenharia isoladamente. A montagem acontece no portátil do operador, onde nenhum classificador observa.
2. Uso duplo. Guiamento, navegação e controlo é matéria de universidade. A matemática de um veículo voador estabilizado é a mesma de um drone de entregas. Um modelo não lê o local de lançamento numa equação diferencial.
3. Transferência de capacidade offline. É o ponto mais subestimado do setor. Depois que o modelo ajudou a construir o simulador, a bancada de testes e a cadeia de ferramentas, ele passa a ser opcional. A capacidade saiu da plataforma, e banir a conta não a traz de volta.
4. Acesso emprestado. Noutros pontos do mesmo relatório, grupos recolheram chaves de API em aplicações móveis, imagens Docker e repositórios públicos e operaram na conta de terceiros. Uma equipa varreu 1,8 milhão de APKs à procura de segredos embutidos. Outra atingiu cerca de 30 empresas de IA em quatro dias, injetando instruções em ambientes automatizados de avaliação para extrair chaves de produção.
Releia o último ponto, porque é o que cai na sua mesa e não na de uma equipa de políticas. A proteção nunca foi atravessada no modelo. Foi atravessada na chave. E a chave estava dentro de um APK publicado por um desenvolvedor com pressa.
O resto do relatório é um problema de desenvolvedores
| Caso | Papel da IA | Escala |
|---|---|---|
| Espionagem estatal russa | Desenvolvimento automatizado de malware e reescrita das cargas ao ser detetada | 20+ organizações, 300.000+ registos de identidade |
| Coletivo criminoso | Varredura massiva de segredos e comprometimento da cadeia de suprimentos em horas | 1,8 M de apps varridas, mais de 1 TB exfiltrado |
| Oficina de exploits | Enxames autónomos de agentes para reconhecimento e análise binária | ~50 alvos, frota de 13 agentes |
| Hacktivista solitário | Construiu sozinho uma plataforma completa de doxxing com pipelines de ingestão | 14 alvos invadidos, 12 a 26 GB |
Uma única pessoa construiu uma plataforma de ataque em massa. A distância entre um serviço de inteligência estatal e um indivíduo motivado com uma chave de API hoje é sobretudo uma diferença de paciência, não de capacidade.
O que eu faço ao construir sistemas com agentes
Chaves nunca vivem no cliente
Nenhuma chave de modelo num bundle móvel, num build de front-end, numa camada Docker ou num repositório. Toda chamada passa por uma rota de servidor. Tokens de vida curta, rotação agendada e alerta de anomalia de gasto, porque uma chave roubada aparece primeiro na fatura.
Todo documento recuperado é entrada hostil
Os ataques aos ambientes de avaliação funcionaram por injeção: instruções escondidas em conteúdo que um sistema automático leu e obedeceu. Se o seu agente lê um PDF, uma página, um ticket ou um pull request, esse texto é dado não confiável e nunca entra no canal de instruções.
Limite as ferramentas, não o prompt
Um prompt é uma sugestão. Uma ferramenta que só lê três tabelas e só escreve numa fila é uma restrição real. Limites de capacidade pertencem à camada de ferramentas, com lista de saída permitida para que um agente comprometido não consiga ligar para casa.
Aprovação humana em ações irreversíveis
Pagamentos, exclusões, deploys, mensagens a clientes. O agente propõe, uma pessoa aprova. A vantagem da célula iemenita era um ciclo sem atrito. Atrito é funcionalidade quando a ação não pode ser desfeita.
Registe a trajetória completa
Prompt, chamadas de ferramentas, argumentos, resultados, custo e identidade da sessão. Se não conseguir reconstruir o que o seu agente fez na terça passada, não consegue responder a um cliente nem a um regulador.
A direção do relatório é uma só: menos supervisão humana, mais autonomia, custo por alvo mais baixo. Quando atacar um alvo marginal fica barato, toda pequena empresa vira alvo, e essa empresa normalmente roda um site feito barato e nunca atualizado.
Não escrevo isto como analista de políticas, e sim como quem entrega código para clientes e lê relatórios de incidentes para prever os próximos doze meses de ataques. Os fornecedores vão continuar endurecendo o modelo, essa é a camada deles. A sua camada é a chave, a ferramenta, a regra de saída e o log de auditoria.
Está a construir algo com um agente dentro?
Sou Zubair Hussain Shah, desenvolvedor full-stack em Next.js, React e Node. Construo aplicações web, plataformas de e-commerce e funcionalidades de IA, e endureço a camada de agentes: chaves no servidor, ferramentas limitadas, recuperação resistente a injeção e trilhas de auditoria.
Fontes e leituras
- Anthropic, Countering misuse of AI: September 2026.
- Anthropic, Threat Intelligence.
- Arab News, Yemen's Houthis used Claude AI to build guided weapons.
- The New Arab, Anthropic report exposes AI misuse across the MENA region.
- OWASP, Top 10 for LLM Applications.
- MITRE, ATLAS.
- NIST, AI Risk Management Framework.