"Approval laundering": pesquisa mostra que aprovar um comando em agentes de codificação não cobre os efeitos que esse comando dispara
O estudo identifica uma falha de cobertura em interfaces de aprovação de agentes de codificação: o registro de auditoria associa a decisão humana apenas ao comando ou chamada de ferramenta aprovado, mas não aos efeitos transitivos que esse comando executa — como um hook de instalação de pacote que grava arquivos ou uma chamada MCP que exerce autoridade de rede. Em um benchmark de 111 pares de objetos de aprovação e rastro real, vincular metadados no momento da decisão reduziu os registros com efeito não coberto de 40 para 3, e os autores integraram a defesa como hook PreToolUse do Claude Code.
Interfaces de aprovação em agentes de codificação (o prompt que pede "permitir esta ação?" antes de rodar um comando) vinculam a decisão humana à invocação de entrada — o comando digitado, a chamada de ferramenta específica. O problema é que ferramentas de desenvolvedor frequentemente executam um fluxo de trabalho inteiro a partir dessa única invocação: instalar um pacote pode disparar scripts de lifecycle (`postinstall` e similares) que escrevem arquivos fora do escopo aparente do comando, e uma chamada MCP aparentemente inócua pode exercer autoridade de rede completa. Os autores chamam essa lacuna de "approval laundering": o registro durável nomeia a invocação de entrada, mas omite os efeitos que o workflow disparado de fato exerce — então uma auditoria posterior, baseada apenas no registro de aprovação, subestima sistematicamente o que realmente aconteceu.
O artigo formaliza essa relação entre o registro (o que foi aprovado) e o "fechamento" (tudo que a invocação de fato ativa) sobre seis classes de efeito, e prova um limite de informação: dado que campos de política visíveis no momento da aprovação podem ser idênticos para dois workflows com efeitos completamente diferentes, nenhuma política baseada só no registro de entrada consegue garantir cobertura de efeito — é matematicamente impossível inferir com segurança o efeito real só olhando a assinatura da invocação aprovada.
O benchmark construído, Approval-to-Action Security Benchmark, testa isso empiricamente contra 111 pares fixos de objeto de aprovação e rastro de execução: usando apenas campos explícitos do objeto de aprovação, 40 dos 111 casos ficam com registro residual (efeito não coberto); adicionando semântica do comando esse número cai para 17, e adicionando metadados capturados no momento da decisão, para 13. Em 11 execuções com hash fixo (SHA), a cadeia de refinamento chega a zero registros residuais, e os autores encontram dois mapeamentos exatos que se repetem em três frontends de produto diferentes — sugerindo que o padrão de "aprovação que não cobre o efeito real" não é um caso isolado de uma ferramenta específica.
A contribuição prática mais concreta é prospectiva: os autores propõem vincular cada invocação, antes da autorização, a uma previsão do efeito transitivo do seu workflow baseada em fonte (source-backed), e testam isso em 17 workflows de holdout não vistos, com 0,926 de recall macro e 0,941 de precisão macro — cortando efeitos residuais de 10 para 3. Eles chegam a implementar essa amarração como um hook PreToolUse no Claude Code, carregando o registro congelado através do caminho de permissão sem aprovar automaticamente nada, o que torna este um dos poucos papers da leva com uma mitigação testada em um agente de codificação real e amplamente usado, não apenas em simulação.