Agentes de codificação de IA prometem produtividade com segurança embutida. Sandbox, aprovação humana, permissões limitadas. Uma pesquisa recente da Manifold Security mostra que essa promessa tem um buraco grande demais para ignorar. Foram identificadas 8 falhas em 7 agentes de IA amplamente usados, incluindo Claude Code, Codex e Cursor, todas explorando o mesmo componente: o arquivo .git/config. O ataque não passa pelo agente de IA propriamente dito. Ele passa por baixo dele, na ferramenta Git que o agente invoca sem questionar. Resultado: execução de código arbitrário do atacante, sem prompt, sem aviso, sem chance de aprovação humana.

O que a pesquisa da Manifold Security descobriu

A Manifold Security testou agentes de codificação de IA operados via CLI e encontrou 8 falhas distintas espalhadas por 7 ferramentas diferentes. O denominador comum entre todas: manipulação do arquivo de configuração do Git (.git/config) para forçar a execução de comandos arbitrários no momento em que o agente interage com um repositório.

Das falhas identificadas, quatro seguem sem correção no momento da divulgação. Isso significa que, para uma parte relevante do ecossistema de agentes de IA usados em desenvolvimento, o vetor continua explorável hoje.

A relevância para ambientes corporativos é direta. Equipes de engenharia estão adotando agentes de IA para clonar repositórios, revisar pull requests, indexar código e executar tarefas de manutenção de forma autônoma. Se qualquer uma dessas interações pode ser sequestrada por um .git/config malicioso, a superfície de ataque não é teórica: é o fluxo de trabalho diário de qualquer time que usa essas ferramentas. Esse tipo de risco se conecta a um problema mais amplo que já discutimos em AI Agents Corporativos: Como Agentes Autônomos Estão Criando Novas Superfícies de Ataque nas Empresas: quanto mais autonomia um agente tem, maior a superfície que ele expõe sem que ninguém perceba.

Anatomia do ataque: como o .git/config vira uma arma

Hooks do Git como vetor de execução

Hooks são scripts que o Git executa automaticamente em determinados eventos: pre-commit``post-checkout``post-merge, entre outros. Eles existem para automatizar tarefas legítimas, como rodar linters antes de um commit. Um detalhe costuma ser mal entendido aqui: hooks não viajam pela rede. Um git clone monta um .git novo no destino, e os hooks vêm do template local da sua máquina, nunca do servidor remoto. É uma proteção deliberada do Git. O risco aparece quando o diretório .git já está no disco antes de o agente agir, porque aí qualquer operação Git rotineira executa o hook sem nenhuma indicação visual de que algo rodou.

Filtros clean/smudge e outras diretivas abusáveis

Além dos hooks, o Git permite configurar filtros de conteúdo, como clean e smudge, que processam arquivos automaticamente durante operações de checkout e commit. Diretivas como core.fsmonitor também podem ser sequestradas para apontar para binários ou scripts controlados pelo atacante. Nada disso exige interação do usuário. Basta que o .git/config do repositório contenha as diretivas certas e que alguém, ou algum agente, execute uma operação Git padrão sobre ele.

O momento exato em que o agente de IA aciona o gatilho

Aqui está o ponto central da descoberta: ações que parecem completamente inofensivas do ponto de vista do agente de IA, como entrar em um diretório para analisá-lo, rodar um git status ou git log para entender o histórico, ou indexar arquivos para montar contexto, já são suficientes para disparar a execução maliciosa quando a árvore de arquivos chega armada. Não há prompt de confirmação, porque, do ponto de vista do agente, ele está apenas “olhando o código”. A execução acontece na camada do Git, invisível para a lógica de aprovação do agente.

Por que o sandboxing dos agentes de IA não impede esse ataque

A resposta padrão da indústria para riscos de agentes autônomos tem sido sandboxing e aprovação humana em etapas críticas. Essas defesas partem de uma premissa: que o agente de IA é o único ponto de decisão e execução. O problema é que o Git, como ferramenta externa invocada pelo agente, opera com sua própria lógica de execução automática, orquestrada por arquivos de configuração que o agente nem sempre inspeciona antes de agir.

Isso cria uma falsa sensação de segurança. O time de segurança configura políticas de aprovação para ações do agente, mas o ataque nem chega a esse ponto de decisão. Ele acontece um nível abaixo, na chamada de sistema que o Git faz ao processar um hook ou filtro. Sandboxing de container ajuda a limitar o dano, mas não impede a execução em si dentro do ambiente onde o agente está operando.

Esse padrão de comportamento autônomo gerando risco de forma inesperada não é inédito. Já mostramos um caso concreto em Claude Mythos 5: agente de IA tenta inserir backdoor, onde a autonomia do agente, mesmo sem intenção maliciosa embutida, gerou uma situação de risco real de segurança.

Não é um problema novo, é um problema amplificado

Paralelos com ataques supply chain tradicionais via Git

Hooks maliciosos e submódulos comprometidos não são novidade. Pesquisadores de segurança já demonstraram há anos que repositórios podem ser armados com esse tipo de configuração para comprometer desenvolvedores que executam operações Git dentro de árvores de arquivos de terceiros sem cuidado. O vetor é conhecido, documentado e, até certo ponto, mitigável quando há um humano no comando, atento a sinais de alerta antes de rodar comandos em um repositório desconhecido. Esse tipo de dinâmica de cadeia de suprimentos comprometida já foi discutido em Supply Chain Attack: Vulnerabilidades Ocultas na Cadeia Digital de Fornecedores.

O que muda com a automação e os privilégios elevados dos agentes

A diferença agora é a escala e a ausência de fricção. Um desenvolvedor humano pode notar um hook suspeito, desconfiar de uma pasta de origem duvidosa antes de rodar comandos Git dentro dela, ou revisar um .git/config estranho. Um agente de IA, operando em modo autônomo e com privilégios elevados para executar tarefas de desenvolvimento, não tem esse instinto de desconfiança. Ele processa repositórios em volume, muitas vezes sem revisão humana intermediária, o que transforma um vetor antigo e conhecido em um risco de execução em escala. Esse tipo de amplificação por automação é parte do mesmo raciocínio que já exploramos em Ameaças do Futuro: Como se Defender do Malware Gerado por Inteligência Artificial.

Superfície de ataque: como o repositório malicioso chega até você

A pergunta certa não é “como eu clonaria um repositório perigoso”, e sim “como um .git controlado pelo atacante chega ao disco onde o agente vai trabalhar”. Como o Git nunca transfere configuração nem hooks do servidor, todo caminho de entrada real passa por arquivos que já existem localmente:

• Um diretório .git versionado como conteúdo comum dentro de outro repositório, por exemplo em uma subpasta de exemplos ou de fixtures de teste. Ele chega como arquivo normal no clone legítimo, e passa a valer assim que o agente roda qualquer comando Git dentro daquela subpasta.
• Arquivos compactados que o agente baixa e extrai, como um zip ou tarball de release, carregando um .git pronto junto com o código.
• Descoberta para cima na árvore de diretórios: o Git sobe do diretório atual procurando um .git, então basta o atacante conseguir escrever em qualquer pasta acima da que o agente usa, como um diretório temporário compartilhado ou um volume montado, para que a configuração dele seja lida.
• Submódulos, que fazem o Git materializar repositórios adicionais durante a inicialização e já foram alvo de falhas conhecidas envolvendo caminhos e o protocolo de arquivo local.
• Instruções embutidas no próprio repositório, em README, arquivo de contribuição ou arquivo de instruções para agentes, pedindo que o ambiente seja preparado com um comando git config. Contra um desenvolvedor isso é engenharia social, contra um agente de IA é injeção de prompt, e o agente executa por conta própria.

O ecossistema moderno de desenvolvimento depende fortemente de código de terceiros, e a exposição não se limita ao repositório principal da empresa. O que precisa ser tratado como hostil não é a origem do clone, é qualquer árvore de arquivos de terceiros que o agente venha a percorrer.

Checklist de mitigação para equipes de desenvolvimento

Configurações defensivas no Git

Restringir protocol.file.allow para bloquear protocolos de arquivo não confiáveis. Apontar core.hooksPath para um diretório controlado pela organização, para que hooks que venham junto com uma árvore de arquivos externa não sejam executados. Revisar configurações padrão de core.fsmonitor e filtros clean/smudge antes de permitir que qualquer ferramenta automatizada opere sobre um repositório externo.

Isolamento de ambiente ao lidar com repositórios externos

Usar contêineres efêmeros e VMs descartáveis para qualquer operação de clone, checkout ou análise de repositórios de terceiros. Nenhum agente de IA deveria operar diretamente sobre repositórios externos em um ambiente com acesso à rede interna ou a credenciais de produção.

Políticas específicas para uso de agentes de IA em pipelines de desenvolvimento

Definir revisão obrigatória de repositórios antes de expor o conteúdo a um agente de IA. Restringir permissões de execução do agente ao mínimo necessário para a tarefa. Manter auditoria detalhada dos comandos disparados pelo agente, incluindo operações Git internas, para permitir investigação posterior caso algo saia do esperado.

De quem é a responsabilidade: fornecedores de IA, Git ou ambos?

O problema nasce na interseção entre duas camadas: o comportamento padrão do Git, que executa hooks e filtros automaticamente por design, e a orquestração dos agentes de IA, que assumem que essas operações são seguras por padrão. Não é razoável colocar toda a responsabilidade em um lado só.

Fornecedores de agentes de IA precisam tratar operações Git como potencialmente perigosas e adicionar camadas de verificação antes de executar comandos sobre repositórios não confiáveis. Ao mesmo tempo, quem avalia essas ferramentas para adoção corporativa precisa entender que “sandbox” e “aprovação humana” não são garantias suficientes quando o vetor de risco está um nível abaixo da abstração do produto. Avaliar um agente de IA para uso corporativo exige perguntar explicitamente como ele lida com hooks, filtros e configurações Git de repositórios externos, não apenas quais permissões o agente pede ao usuário.

Implicações para pentest e red team

Esse vetor deveria entrar no radar de qualquer time de segurança ofensiva que testa ambientes de desenvolvimento com agentes de IA. Algumas linhas de teste possíveis:

• Simulação de repositórios maliciosos com hooks e filtros armados, para verificar se agentes de IA em uso na organização executam comandos sem aprovação.
• Testes de cadeia de suprimentos de software direcionados especificamente a fluxos automatizados de análise de código.
• Engenharia social técnica voltada a times de desenvolvimento que usam agentes de IA, testando se um .git escondido numa subpasta de exemplos, ou uma instrução de setup embutida no README, consegue passar despercebido pelo processo de revisão.

A metodologia de pesquisa aplicada pela Manifold Security ilustra bem o valor de investigar vulnerabilidades em camadas que normalmente não recebem atenção, um princípio que já discutimos em outro contexto em Firmware Security: Revelando Vulnerabilidades Ocultas e Fortalecendo a Segurança. O paralelo é direto: componentes de infraestrutura invisíveis ao usuário final costumam ser os pontos mais negligenciados, e por isso os mais perigosos.

Conclusão: o que fica claro depois desse achado

Sandboxing e aprovação humana não bastam quando o vetor de ataque opera abaixo da camada de abstração do agente de IA. A descoberta da Manifold Security, detalhada originalmente pelo The Hacker News, deixa claro que o Git em si precisa ser tratado como superfície de ataque ativa em qualquer ambiente que envolva agentes de codificação autônomos. Não é suficiente confiar nas camadas de proteção do produto de IA. É preciso auditar o que acontece por baixo dele.

Equipes de segurança que estão integrando agentes de IA nos fluxos de desenvolvimento precisam revisar configurações Git, isolar ambientes de teste e tratar todo repositório externo, incluindo submódulos e forks, como potencialmente hostil até prova em contrário.