O perigo da "camada de controle" para agentes de LLM
Os modelos de linguagem modernos raramente trabalham sozinhos. Com mais frequência, são implantados dentro de um harness de agente — uma camada intermediária que dá ao modelo acesso a ferramentas, extensões, memória de longo prazo, permissões e ações externas. É essa camada que decide o que o modelo pode fazer e o que não pode.
O problema é que os benchmarks de segurança existentes geralmente testam apenas cenários de ataque isolados ou um conjunto limitado de condições operacionais. Por isso, é difícil entender em qual etapa exata do funcionamento do harness ocorre a falha: na configuração, no momento da chamada de ferramenta ou na recuperação após um incidente. Os pesquisadores propuseram o HarnessRisk — um benchmark que analisa a segurança do harness de agente como um todo, em todas as etapas do seu ciclo de vida.
Seis fases do ciclo de vida do harness
Os autores do trabalho dividiram a segurança do harness em seis fases operacionais:
- Harness Configuration — configuração de parâmetros e permissões de acesso;
- Capability Extension — conexão de novas capacidades e extensões;
- Runtime Operation — execução de tarefas em tempo real;
- State Persistence — salvamento e restauração de estado;
- Action Control — controle sobre ações e ferramentas;
- Incident Recovery — reação a falhas e recuperação após incidentes.
Cada fase é responsável pela sua própria área de atuação, e vulnerabilidades podem se manifestar em qualquer uma delas. É exatamente essa divisão que permite comparar como diferentes harnesses lidam com ataques nas mesmas condições.
O que há dentro do HarnessRisk: cenários e métricas
O benchmark reúne 128 cenários isolados. Cada cenário é estruturado de forma engenhosa: o modelo recebe uma tarefa de usuário segura, mas dentro de um artefato não confiável do fluxo de trabalho está escondida uma instrução hostil. O modelo deve executar o objetivo legítimo sem ceder ao ataque embutido no artefato.
Cada trajetória é avaliada por quatro métricas:
- Utility — quão bem a tarefa original foi executada;
- Attack Success Rate — proporção de ataques bem-sucedidos;
- Persistence — por quanto tempo o efeito do ataque persiste;
- Detection — quão eficazmente o sistema percebe riscos.
Essa abordagem permite ver não apenas "foi invadido ou não", mas também o custo da segurança para a utilidade do modelo.
O que os testes mostraram
Os experimentos foram conduzidos em três harnesses, seis modelos de linguagem e 14 combinações de modelos e harnesses. Os resultados foram heterogêneos: a taxa de sucesso dos ataques variou de 12,6% a 80,9%, enquanto a Utility permaneceu na faixa de 75,0% a 97,6%. Em outras palavras, o mesmo modelo pode ser quase invulnerável em uma configuração e francamente fraco em outra.
A fase mais vulnerável em todos os três harnesses é a Harness Configuration. Os ataques geralmente funcionam não por exploits complexos, mas porque, dentro do fluxo de trabalho "permitido", é possível alterar parâmetros que afetam a segurança. Isso é um sinal de alerta: até um harness de aparência correta pode permitir que um invasor mude as regras do jogo.
Um resultado curioso também está relacionado ao reconhecimento de riscos. Algumas configurações detectam ataques em mais de 90% das execuções, mas ainda assim permitem uma parcela significativa de ataques bem-sucedidos. Ou seja, o modelo "entende" que algo perigoso está acontecendo, mas não converte esse entendimento em comportamento seguro. A consciência da ameaça, por si só, não protege o sistema.
Conclusões: a segurança não pode ser medida "na média"
A principal lição do HarnessRisk é que a segurança de sistemas de agentes depende fortemente da combinação específica de modelo e harness. Avaliações médias como "o modelo é seguro" ou "o harness é seguro" dizem pouco se não considerarmos em qual configuração eles operam.
É preciso avaliar os agentes em várias áreas de responsabilidade do harness ao mesmo tempo — da configuração inicial à recuperação após incidentes. E verificar separadamente como o modelo se comporta diante de um ataque embutido em um artefato de trabalho comum. Só assim é possível notar pontos fracos que, em benchmarks clássicos, ficam fora do campo de visão.
