Sandbox ZTAC reduz drasticamente o número de exploits bem-sucedidos contra agentes de codificação comprometidos
O Zero-Trust Agent Cells (ZTAC) ataca uma classe inteira de exploits contra agentes de codificação de IA que exploram a confusão entre o nome de um recurso (um caminho, um argumento) e o objeto real a que ele se refere no momento do uso, como symlinks e opções de comando com comportamento inesperado. Em testes contra 74 ataques, incluindo réplicas de 10 incidentes reais já divulgados, um allowlist de ferramentas sozinho falhou em 66 deles e um allowlist combinado com sandbox de comando falhou em 56, enquanto o ZTAC falhou em apenas 2.
Agentes de codificação de IA leem repositórios e páginas web escritas por qualquer pessoa, e depois agem com a autoridade do usuário que os invocou — uma combinação que os torna um alvo natural para ataques via conteúdo malicioso injetado no ambiente que o agente processa. Defesas contra prompt injection reduzem a chance de o modelo ser manipulado, mas não a eliminam, então os autores partem da premissa de que o sistema precisa assumir que o agente já pode estar comprometido e conter o dano a partir daí, em vez de depender só de impedir a manipulação em primeiro lugar.
O diagnóstico técnico central do artigo é que muitos exploits reais contra agentes de codificação em produção compartilham uma causa raiz comum: uma verificação de segurança aprova um nome — um caminho de arquivo, um vetor de argumentos, um diretório — mas uma etapa posterior do processamento resolve esse nome para um objeto diferente do que foi verificado. Exemplos citados incluem o arquivo real atrás de um symlink, o comportamento que uma opção de linha de comando efetivamente seleciona, ou um repositório Git que o próprio Git descobre de forma autônoma durante a execução. A verificação e o uso, nesse padrão, não apontam necessariamente para o mesmo objeto.
A arquitetura proposta, ZTAC, executa o agente dentro de uma sandbox de kernel cuja única rota de acesso a arquivos, programas e rede é um socket para um "broker" externo. Esse broker resolve cada requisição para o objeto concreto sobre o qual ela vai efetivamente atuar, autoriza a ação com base nesse objeto resolvido (não no nome original da requisição), e no momento do uso verifica novamente que a ação está de fato incidindo sobre o objeto que foi autorizado. Programas que o broker inicia correm em sandboxes derivadas da mesma política, e cada aprovação concedida é vinculada a um objeto específico e só pode ser usada uma vez.
Na avaliação, que incluiu réplicas de 10 incidentes reais já documentados publicamente, um allowlist de ferramentas isolado falhou (ou seja, deixou o ataque passar) em 66 dos 74 casos testados, e a combinação de allowlist com sandbox de comando — a defesa típica usada por agentes de codificação hoje em produção — ainda falhou em 56. O ZTAC falhou em apenas 2, ambos envolvendo a codificação de um segredo dentro do tráfego para um endpoint já permitido, uma categoria de ataque conceitualmente diferente da confusão nome-objeto que o sistema foi desenhado para resolver. O protótipo, com apenas 3,2 mil linhas de Rust confiável, ainda completou 43 de 46 operações legítimas com apenas 8 pedidos de aprovação e latência mediana de 4 milissegundos por requisição — evidência de que essa contenção rigorosa é viável sem destruir a usabilidade do agente em tarefas do dia a dia.