Um novo estudo de segurança chama a atenção para uma camada menos visível dos agentes de programação: hooks de ciclo de vida capazes de executar ações no sistema sem passar diretamente pela escolha de ferramentas feita pelo modelo.
O artigo A Blind Trust, the Bloody Thrust foi submetido ao arXiv a 3 de setembro. O cenário começa com a instalação de um plugin benigno e continua com uma atualização cuja configuração de hooks foi alterada. No modelo de ameaça dos autores, o atacante não precisa de explorar uma falha nem de escapar de um ambiente isolado; a nova configuração pode associar comandos do sistema a eventos normais do ciclo de vida.
Os investigadores criaram o HookPry para automatizar esta classe de ataque. Em 1 000 execuções de ponta a ponta, envolvendo sete ambientes de agentes, cinco modelos e 25 combinações, reportam uma taxa média de sucesso de 77,0%. O melhor resultado por ambiente chegou a 92,5%.
Estes valores são os reportados pelos autores e não foram reproduzidos de forma independente. Os ensaios usam ambientes efémeros e recursos sintéticos, cobrem 40 casos e não esgotam sistemas operativos, shells, políticas empresariais, redes ou versões futuras. O estudo assume ainda adoção normal da instalação ou atualização e não mede a probabilidade de um utilizador real instalar um pacote malicioso.
A fronteira de segurança não termina nas ferramentas escolhidas pelo modelo
A principal conclusão é arquitetural. Muitas defesas concentram-se no percurso mediado pelo modelo: injeção de instruções, permissões de ferramentas, confirmações e regras aplicadas às ações escolhidas pelo LLM. Os hooks de ciclo de vida criam outro percurso. Quando ocorre o evento correspondente, o ambiente pode lançar um comando configurado sem pedir ao modelo uma nova decisão sobre esse comando.
A documentação oficial do Claude Code confirma de forma independente que esta é uma superfície privilegiada. A Anthropic descreve hooks de comando como comandos de shell definidos pelo utilizador que são executados automaticamente em determinados eventos e avisa que correm com todas as permissões da conta local. A mesma documentação descreve controlos de confiança da pasta de trabalho e o evento ConfigChange, que pode auditar ou bloquear algumas alterações de configuração numa sessão.
A documentação oficial do OpenCode também apresenta hooks associados a sessões, ferramentas e instalação. Os produtos não têm a mesma semântica, pelo que o HookPry não prova uma vulnerabilidade idêntica em todos os ambientes. Demonstra, porém, que a configuração de ciclo de vida pode transportar autoridade real de execução fora do ciclo de decisão imediato do modelo.
A análise estática não bastou neste ensaio
O artigo testa três defesas estáticas num conjunto de 40 artefactos maliciosos e 40 benignos. Segundo os autores, o Microsoft Defender detetou 0 dos 40 exemplos maliciosos, o HookPolicy detetou 20 e uma configuração de cinco regras do Semgrep detetou 19. Em conjunto, as três abordagens identificaram 21 e falharam 19, correspondendo a 47,5%.
O âmbito é importante. O Defender é generalista, enquanto HookPolicy e Semgrep foram configurados pelos investigadores. Os exemplos benignos são sintéticos e de baixo risco. O estudo não compara produtos comerciais especializados na segurança da cadeia de fornecimento nem deteção comportamental dinâmica. A conclusão mais sólida é que analisar o conteúdo de um pacote não basta para autorizar configuração executável.
Mais autoridade numa atualização deve exigir nova autorização
A contribuição da Aipolix é tratar uma atualização que acrescenta autoridade executável como uma mudança de permissão, não como uma simples nova versão.
Quatro controlos resultam daí. Primeiro, comparar semanticamente a configuração executável na instalação e em cada atualização, destacando novos eventos, comandos alterados, destinos de rede, caminhos de scripts e acesso adicional ao ambiente.
Segundo, exigir nova autorização sempre que aumenta o conjunto de ações permitido. A aprovação deve ficar ligada à configuração e às capacidades efetivas da versão, não apenas ao nome do pacote.
Terceiro, executar hooks com o mínimo privilégio necessário. Restrições ao sistema de ficheiros, rede, isolamento e credenciais de âmbito reduzido diminuem o impacto de um hook malicioso ou defeituoso.
Quarto, conservar proveniência de execução: versão do plugin, hash da configuração, evento que o ativou, handler executado e contexto de segurança. Se o hook transformar a saída de uma ferramenta antes de esta chegar ao modelo, devem ser guardados o resultado original e a proveniência da transformação.
A configuração executável pode ser sujeita a política
A mitigação não é apenas teórica. A documentação atual do Claude Code inclui o evento ConfigChange, destinado a auditar alterações de configuração e aplicar política de segurança. Para certas fontes, pode impedir que uma alteração seja aplicada à sessão em curso.
Isto não resolve toda a cadeia de fornecimento estudada e outros ambientes têm modelos diferentes. Ainda assim, aponta para uma regra útil: configuração que transporta autoridade executável deve ser observável, comparável e sujeita a decisão de política.
HookPry continua a ser um resultado de investigação, não prova de exploração generalizada no mundo real. O código está ligado através de um repositório anonimizado, os ensaios são sintéticos e os autores afirmam ter comunicado os resultados aos fornecedores afetados, aguardando respostas. Não foi encontrada reprodução independente dos valores de 77,0%, 92,5% ou 47,5%.
A regra operacional é clara: a governação de agentes não pode terminar nos prompts e nas ferramentas escolhidas pelo modelo. Todo o mecanismo capaz de produzir efeitos no sistema, incluindo configuração executável de hooks, deve ficar dentro do mesmo modelo de autorização, privilégio mínimo e auditoria.