Friendly Fire prova que um agente da IA pode executar código e abrir a porta para seu host

Uma equipe do AI Now Institute publicou esta semana um teste de conceito que abre um buraco inquietante na forma como muitas organizações já delegam tarefas de segurança a agentes da IA: em vez de identificar código malicioso dentro de um repositório, o agente pode executar esse mesmo código na sua máquina e se tornar a via de entrada. O estudo, batizado como "Friendly Fire" e assinado por Boyan Milanov e Heidy Khlaaf, demonstra o risco quando agentes com capacidade de executar comandos funcionam em modos autônomos que aprovam ações sem intervenção humana.

Na experiência os pesquisadores trabalharam sobre implementações “de estoque” de Claude Code (com builds de CLI indicadas e modelos Sonnet/Opus) e a versão do Codex de OpenAI, em configurações concretas com a opção de execução automática ativada. O vector é simples e subtil: adicionar ao repositório ficheiros aparentemente benignos e um programa de verificação (por exemplo, security.sh num README) que, ao ser considerado parte do trabalho pelo agente, é executado sem aviso e lança um binário escondido com a carga útil. Para evitar a detecção, os atacantes podem acompanhar esse binário com um arquivo fonte inocuo e copiar cadeias de texto do código- fonte para que as verificações de desensamblado pareçam concordantes. Nada no código do projeto invoca esse binário, então desde a visão superficial do agente tudo parece normal.

A conclusão técnica mais preocupante não é um bug isolado em uma versão concreta, mas uma falha de design: entregar texto não confiável a um agente que pode executar comandos equivale a dar a chave do seu host. Os modelos utilizados na PoC falharam em separar corretamente "instruções que fazem parte do código que examinam" de "ordens que devem executar", e essa falha persiste entre diferentes fornecedores e modelos. A AI Now argumenta que isso não é corrigido com um simples adesivo de modelo; exige mudanças no fluxo de trabalho e nas políticas de uso.

As implicações operacionais são amplas. Equipamentos que adotaram agentes automatizados para acelerar revisões de dependências ou auditorias de código de terceiros confiam agora em uma ferramenta que, em certos modos, pode executar sem supervisão código que veio de fora. Dentro de uma pipeline CI/CD isso pode transformar uma revisão rotineira em uma execução de um binário malicioso em infraestrutura que contém chaves, credenciais e acesso a segredos. Embora a PoC não tenha mostrado escalada de privilégios ou movimento lateral na rede dos pesquisadores, o primeiro passo – ejecutar código alheio no host – já é suficiente para comprometer segredos e processos.

Isto não invalida completamente o uso de agentes, mas exige um replanteamento: não entregue código não confiável a um agente com capacidade de executar comandos e acesso às suas chaves. Essa regra é a mais direta e a mais segura. Para os equipamentos que ainda querem beneficiar de agentes automatizados existem atalhos práticos e controlos de mitigação que reduzem o risco: desativar os modos autónomos, forçar um “human-in-the-loop” antes de qualquer execução, ou executar as verificações em ambientes herméticos e efêmeros que não contenham credenciais persistentes ou acesso à rede, além de auditar todo comportamento de execução.

É preciso advertir que os mecanismos de contenção não são infalívels. Sandboxes e máquinas virtuais acrescentam barreiras, mas mostraram vazamentos e vazamentos no passado: por exemplo, houve uma falha na sandbox de Claude Code (referido no relatório como CVE-2026-39861) que ilustra que confiar exclusivamente em contentores ou sandboxes pode dar uma falsa sensação de segurança. Por isso, as proteções devem ser em camadas: separação de privilégios, uso de tokens efêmeros e rotação automática, segmentação de rede, e políticas rigorosas de mínimos privilégios para qualquer ferramenta automatizada.

Do ponto de vista da cadeia de fornecimento de software, a recomendação aponta práticas já promovidas por iniciativas de segurança moderna: assinar artefatos, exigir rastreabilidade e reprodutibilidade, e aplicar marcos como SLSA para a integridade dos builds. Estas medidas ajudam a reduzir a probabilidade de um arquivo R E A D M E ou outro documento de texto se tornar um vetor de execução inadvertida. Para aprofundar essas práticas, organizações e responsáveis técnicos podem rever documentação de boas práticas na integridade da cadeia de fornecimento em projetos como a SLSA em https://slsa.dev/, e material de análise crítica sobre riscos e políticas no trabalho de think tanks como o AI Now Institute https://ainowinstitute.org/.

Recomendações operacionais específicas que qualquer equipamento pode aplicar imediatamente: desactivar os modos automáticos de execução em agentes que analisem código não confiável; exigir confirmação humana e um registro claro de ações antes de permitir execuções; tratar arquivos de documentação (README, scripts de exemplo) como não confiáveis por defeito; não expor credenciais nos ambientes onde correm revisões automatizadas e, quando for imprescindível executar código, fazê-lo em máquinas descartáveis sem segredos e com imagem revertible. Além disso, implantar monitoramento e alertas para detectar execuções inesperadas e rotar qualquer segredo que tenha estado presente em um ambiente comprometido.

Finalmente, isto é um lembrete de que a adoção acelerada de agentes para tarefas defensivas deve ser acompanhada de governança e controles. O teste de conceito é laboratório, não exploração massiva documentada em produção, mas o padrão já apareceu com variantes anteriores (TrustFall, Agentjacking) e a superfície de ataque é real porque os repositórios públicos e artefatos de terceiros são um objetivo frequente. A cobertura técnica deve ser completada com políticas organizacionais que limitem a autonomia operacional dos agentes até que as garantias de isolamento, rastreabilidade e controle humano sejam robustas.