PulseFlow Tecnologia
← Insights
·7 min de leitura·guia-tecnico·guardrails·tool-use·autorizacao
PulseFlow Tecnologia

Como criar guardrails para tool use em agentes

Uma pesquisa acadêmica recente encontrou algo desconfortável em três dos frameworks de agente mais usados do mercado - LangChain, LlamaIndex e Stripe Agent Toolkit: todos "conflate tool exposure with authorization". Ou seja, expor uma ferramenta ao modelo não significa, por padrão, que cada chamada individual seja autorizada com valores específicos antes de executar. Na prática, os pesquisadores demonstraram uma chamada de pagamento não autorizada executando sob o dispatch padrão do LangChain - o clássico problema do "confused deputy", agora em agentes de IA.

Lista de ferramentas permitidas não é o mesmo que autorização por chamada

O erro comum é confundir "a ferramenta está na lista de tools disponíveis" com "esta chamada específica está autorizada". Os três frameworks auditados oferecem capability gating por padrão - decidir quais ferramentas existem —, mas nenhum oferece, por padrão, um gate determinístico de autorização por valor e por chamada, fail-closed.

Risco por tool: nem toda ferramenta pede o mesmo guardrail

Uma ferramenta de leitura tem perfil de risco completamente diferente de uma que move dinheiro, deleta registro, ou envia comunicação externa. Guardrails proporcionais ao risco de cada ferramenta - não um guardrail genérico aplicado igualmente a tudo - é o que evita tanto excesso de fricção em ferramentas de baixo risco quanto excesso de exposição em ferramentas críticas.

ScopeGate: o mecanismo de cinco etapas que zerou os bypasses

A resposta que os próprios pesquisadores propõem, ScopeGate, estrutura o guardrail em cinco etapas: escopo (o que a ferramenta pode fazer), autorização (quem/o que aprovou esta chamada específica), limite monetário (valor máximo por chamada), idempotência (a mesma chamada não executa duas vezes por engano), e negação padrão (fail-closed quando algo não está explicitamente permitido). Testado contra 48 tentativas estáticas de bypass e 29 tentativas adaptativas ao longo de 40 iterações, o resultado foi zero sucessos em ambos os casos - com contenção de 10 em 10 num agente de pagamentos, e zero falsos positivos em casos legítimos.

Validação de argumentos como parte do gate, não etapa separada

Autorizar a ferramenta certa com o argumento errado ainda é uma falha. O gate de autorização por chamada precisa validar não só se a ferramenta pode ser chamada, mas se os valores específicos daquela chamada (quantia, destinatário, escopo do dado) estão dentro do permitido.

Ambientes isolados, logs, alertas e revogação

Cada chamada de ferramenta deveria rodar num ambiente isolado o suficiente para conter o dano se algo passar pelo gate. Logs de cada tool call - não só de erros, de todas as chamadas - permitem auditoria depois do fato. Alertas para padrões fora do esperado (volume anormal, valores fora da faixa comum) complementam o gate determinístico com detecção de anomalia. E revogação de acesso - a capacidade de desligar uma ferramenta ou credencial imediatamente quando um incidente é identificado - fecha o ciclo.

Checklist de guardrails

  1. Lista de tools permitidas - capability gating, o ponto de partida, não o fim
  2. Risco por tool - guardrail proporcional, não genérico
  3. Validação de argumentos - parte do gate de autorização, não etapa separada
  4. Política de aprovação - quem/o que autoriza cada chamada
  5. Default deny - fail-closed quando não explicitamente permitido
  6. Limites financeiros - valor máximo por chamada, não só por dia
  7. Ambientes isolados - conter o dano se o gate falhar
  8. Logs de tool calls - toda chamada, não só erros
  9. Alertas - anomalias de volume ou valor
  10. Revogação de acesso - desligar rápido quando necessário

Fontes