GuardAgent: Execução Determinística de Políticas de Segurança para Agentes LLM via Execução de Código

O problema central de segurança para qualquer agente com capacidade de escrita (write-back) é: como impedi-lo de tomar uma ação que nunca deveria ter sido tomada? O GuardAgent (Xiang et al., ICML 2025) propõe um agente de salvaguarda dedicado — um agente LLM separado que verifica cada ação do agente de destino em relação a um conjunto de políticas de segurança antes da execução. Para o Bean Labs, onde a questão "o agente pode escrever no livro-razão sem violar as regras contábeis?" é inegociável, este artigo está exatamente no cerne da nossa agenda de pesquisa.

O artigo

GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning, de Zhen Xiang e colegas da UIUC, Emory e UC Berkeley, introduz o que os autores afirmam ser o primeiro agente de salvaguarda de propósito geral para sistemas LLM. A ideia central é direta: em vez de incorporar restrições de segurança diretamente no prompt do agente de destino (onde podem ser ignoradas ou esquecidas), o GuardAgent opera como um agente independente que intercepta as ações do agente de destino e as verifica em relação às políticas estabelecidas.

O mecanismo possui dois estágios. Primeiro, o LLM lê a política de segurança e a entrada ou saída proposta pelo agente de destino, e então escreve um plano de ação passo a passo descrevendo o que verificar. Segundo, ele converte esse plano em código Python executável usando uma caixa de ferramentas predefinida de funções chamáveis. Um intérprete Python externo executa o código, produzindo um veredicto sim/não determinístico. Um módulo de memória armazena tuplas de tarefas passadas (política, plano, código) e recupera exemplos anteriores semelhantes usando a distância de Levenshtein, permitindo o aprendizado em contexto de poucas tentativas (few-shot) sem qualquer ajuste fino adicional. O artigo avalia a abordagem em dois novos benchmarks introduzidos pelos autores.

Ideias principais

• A execução de código supera veredictos em linguagem natural. Quando as decisões de segurança são renderizadas como código em vez de texto de LLM, a saída é determinística: o mecanismo Python permite ou bloqueia a ação, sem risco de alucinação na etapa final de decisão. O LLM só precisa gerar o código correto, não a resposta final correta.
• Dois benchmarks personalizados. O EICU-AC (316 exemplos) testa o controle de acesso para o EHRAgent em um banco de dados de saúde com três funções de usuário e dez bancos de dados. O Mind2Web-SC (200 exemplos) testa seis políticas de segurança para o agente web SeeAct. Ambos foram criados pelos autores especificamente para este artigo.
• 98,7% e 90,0% de precisão de rótulo (GPT-4) no EICU-AC e Mind2Web-SC, respectivamente. Crucialmente, a precisão da resposta final — se o agente de destino ainda conclui sua tarefa quando deveria ser permitido — permanece em 100% em ambos os cenários.
• Regras de segurança codificadas (hardcoded) falham drasticamente. Incorporar políticas diretamente no prompt do sistema do agente de destino alcança apenas 81,0% / 77,5% de precisão nos dois benchmarks e faz com que o agente de destino falhe em 29,2% / 71,0% de suas tarefas legítimas — um tradeoff utilidade-segurança inaceitável.
• LlamaGuard não é a ferramenta certa aqui. A linha de base de moderação de conteúdo atinge aproximadamente 50% de precisão — próximo ao acaso — porque foi projetada para texto prejudicial, não para raciocinar se a ação de um agente viola uma regra específica de controle de acesso.
• Remover a caixa de ferramentas custa cerca de 8 pontos. Sem a biblioteca de funções chamáveis, o GuardAgent cai de 98,7% para 90,8% no EICU-AC, embora compense parcialmente definindo autonomamente as funções necessárias (68% das saídas geram código mesmo sem instrução explícita, o que os autores tratam como evidência de suporte para o design de geração de código).

O que se sustenta — e o que não se sustenta

A percepção arquitetural central — de que a execução de código oferece um ponto de aplicação determinístico — é genuinamente útil, e as ablações são honestas. A comparação com regras de segurança codificadas é particularmente convincente: mostra que designs ingênuos de "apenas adicionar regras ao prompt" degradam a utilidade do alvo enquanto ainda falham em aplicar a segurança de forma confiável.

No entanto, a avaliação possui limites reais. Os dois benchmarks são pequenos (316 e 200 exemplos), e os próprios autores construíram ambos, o que cria um risco óbvio de sobreajuste (overfitting). O EICU-AC é essencialmente uma matriz de controle de acesso (função × banco de dados), que é um problema estruturado e enumerável — o tipo de coisa em que o código é naturalmente bom. O Mind2Web-SC é mais complexo, e o número de 90,0% ali é consideravelmente menos impressionante do que parece à primeira vista: os autores admitem que a regra 5 (que abrange "filmes, músicas e vídeos") causa a maioria das falhas porque exige um raciocínio amplo de mundo aberto. Esse é o tipo de regra que um agente financeiro real enfrentaria constantemente.

O módulo de memória recupera demonstrações por similaridade de string, o que funciona bem para tipos de políticas repetitivas, mas degradará em políticas genuinamente novas. Além disso, todo o framework assume um "contexto confiável" — as próprias políticas de segurança devem ser fornecidas por um administrador confiável. Se um invasor puder modificar as políticas, ou se a caixa de ferramentas contiver funções inseguras, o GuardAgent não oferece proteção. O artigo não modela a manipulação adversária de políticas. Trabalhos subsequentes (ShieldAgent, arXiv:2503.22738; AGrail, arXiv:2502.11448) já destacaram essas lacunas, com o ShieldAgent relatando uma melhoria média de 11,3% sobre o GuardAgent em benchmarks mais amplos.

Por que isso importa para a IA financeira

O agente de gravação do Beancount precisa de mais do que um prompt de segurança — ele precisa de um mecanismo para aplicar as regras contábeis que seja estruturalmente separado do agente que executa o trabalho. A arquitetura do GuardAgent mapeia diretamente para isso: um agente de proteção que verifica cada lançamento contábil proposto em relação às regras contábeis (débito == crédito, nenhuma postagem em períodos bloqueados, nenhuma modificação de transações conciliadas) antes que a gravação seja executada. A camada de aplicação por execução de código é especialmente atraente aqui porque a aritmética de partidas dobradas é exatamente o tipo de verificação estruturada e enumerável que o código lida de forma confiável e o texto de LLM não.

A limitação honesta é que o GuardAgent assume que você pode enumerar suas políticas de segurança antecipadamente e codificá-las em uma caixa de ferramentas. Em implantações de produção do Beancount, algumas restrições são implícitas (seguindo as convenções do livro-razão que o usuário construiu ao longo de anos) e outras são dinâmicas (orçamentos mudam, estruturas de contas são refatoradas). O GuardAgent não diz como lidar com restrições que não podem ser pré-especificadas. Esse é o problema mais difícil e permanece em aberto.

O que ler a seguir

• ShieldAgent (arXiv:2503.22738, ICML 2025) — baseia-se no GuardAgent com raciocínio verificável de política de segurança e o ShieldAgent-Bench (2 mil exemplos em seis ambientes web); relata melhoria de 11,3% sobre o GuardAgent e redução de 64,7% nas chamadas de API.
• AGrail (arXiv:2502.11448) — propõe verificações de segurança adaptativas que se transferem entre as tarefas do agente, em vez de exigir demonstrações por tarefa; aborda diretamente a limitação de escalabilidade do GuardAgent.
• ToolSafe (arXiv:2601.10156) — salvaguardas proativas em nível de etapa com feedback para agentes de chamada de ferramentas; mais granular do que o modelo de interceptação de entrada/saída do GuardAgent.