Listas de permissão de ferramentas de agentes de IA: por que o padrão de negação vence

Porque o deny-by-default funciona melhor do que tentar bloquear cada chamada ruim

Quando você começa com uma postura de deny-by-default, só precisa pensar no que o agente realmente precisa. Todas as outras chamadas são interrompidas automaticamente, sem ter que prever cada possível mau uso. Isso reduz a carga mental no revisor e diminui a chance de que um esquecimento perigoso passe despercebido.

Considere um agente que escreve relatórios. Ele precisa ler um arquivo de modelo, extrair dados de um banco de dados e enviar o PDF finalizado para uma caixa de correio interna. Se você lista apenas essas três chamadas, qualquer tentativa de executar um comando de shell, consultar uma API externa ou excluir uma tabela é negada instantaneamente. Você nunca precisa escrever uma regra que diga "bloquear rm -rf", "bloquear curl para evil.com" ou "bloquear DROP TABLE". A regra deny-by-default cobre todos eles.

Na prática, eu vi equipes gastarem semanas construindo listas de bloqueio longas que ainda perdem um novo vetor de ataque, enquanto uma lista de permissões curta de cinco itens parou os mesmos ataques no primeiro dia. O esforço economizado na manutenção é real: você revisa a lista de permissões quando uma ferramenta muda, não quando uma nova ameaça aparece.

Como construo uma lista de permissões para um novo agente

Sigo uma lista de verificação repetível que mantém a lista compacta e revisável.

- Registo as tarefas exatas que o agente deve realizar hoje. Ignoro ideias de “pode ser útil mais tarde”.

- Para cada tarefa, encontro a ferramenta única que faz o trabalho com os parâmetros mais estreitos possíveis. Se uma ferramenta oferece uma flag que alarga o âmbito, não a ativo a menos que a tarefa explicitamente a necessite.

- Registo o nome da ferramenta, o comando exato ou endpoint de API e os valores de parâmetros permitidos num ficheiro YAML simples. Este ficheiro vive ao lado do código do agente para que os revisores possam vê-lo de relance.

- Executo o agente num sandbox e verifico que cada chamada listada tem sucesso e que qualquer chamada não no ficheiro devolve um erro.

- Peço a um colega que revise a lista. O trabalho do revisor é confirmar que cada entrada corresponde a uma tarefa real e que nenhuma capacidade extra está escondida atrás de valores predefinidos.

- Armazeno o ficheiro no controlo de versão. Etiqueto cada commit com a versão do agente para que possa rastrear qual lista de permissões foi enviada com qual lançamento.

- Configuro um passo de CI que falha a compilação se o ficheiro YAML estiver em falta ou se contiver uma ferramenta não aprovada no registo de ferramentas do projeto.

Este processo leva-me cerca de uma hora para um agente simples e produz um documento que qualquer pessoa pode auditar.

Classificar ferramentas pelo que elas podem alterar

Nem todas as ferramentas apresentam o mesmo risco. Eu dividi as ferramentas permitidas em três classes de impacto para saber onde adicionar verificações extras.

Classe de impacto | O que significa | Exemplo de ferramenta | Salvaguarda típica Somente leitura | Pode buscar dados, mas não pode alterar o estado | Leitura de arquivo, SELECT de banco de dados, GET de API pública | Registar a chamada, sem aprovação extra necessária Escrita ou mutável | Pode criar, atualizar ou excluir dados | Escrita de arquivo, INSERT/UPDATE/DELETE de banco de dados, publicação de mensagem interna | Exigir um segundo aprovador para o primeiro uso, registrar com ID de usuário Efeito externo irreversível | Pode afetar sistemas fora do limite de confiança | Enviar e-mail, publicar em mídia social, iniciar pagamento, chamar webhook externo | Aprovação manual obrigatória, rastreamento de auditoria detalhado, tempo limite na chamada

Quando eu revejo uma nova ferramenta, pergunto: “Se esta chamada for executada, qual é a pior coisa que poderia acontecer?” A resposta me diz qual linha da tabela se aplica. Para ferramentas somente leitura, eu adiciono apenas uma linha de registro. Para ferramentas de escrita, eu adiciono um fluxo de trabalho de aprovação leve. Para efeitos irreversíveis, eu impeço um portão manual e mantenho a janela de chamada curta.

Associar listas de permissões com filtros de entrada e saída

Uma lista de permissões remove capacidades desnecessárias. Os filtros capturam dados ruins que escapam às chamadas permitidas. Trato-os como camadas complementares, não como substitutos.

No lado de entrada, executo um verificador de injeção de prompt que procura por padrões de jailbreak conhecidos. Utilizo a folha de dicas de prevenção de injeção de prompt LLM da OWASP (link) como referência para as regras que habilito. Se o verificador sinalizar um prompt, eu o rejeito ou saneio o segmento ofensivo antes que o agente o veja.

No lado de saída, escaneio o texto gerado pelo agente para segredos, tentativas de injeção de SQL ou URLs não permitidas. A folha de dicas de gerenciamento de segredos (link) ajuda-me a construir padrões de regex para chaves de API, senhas e tokens. A folha de dicas de prevenção de injeção de SQL (link) orienta os padrões que uso para capturar strings de consulta perigosas que possam ser ecoadas de volta em uma resposta.

Ambos os conjuntos de filtros são executados como middleware leve. Eles adicionam alguns milissegundos de latência, mas param muitos ataques de baixo esforço antes que eles atinjam a camada de ferramentas. Como a lista de permissões já removeu classes inteiras de chamadas, os filtros têm uma superfície menor para inspecionar, o que mantém os falsos positivos baixos.

O que isto não é

Quero ser claro sobre os limites de uma lista de permissões para que você não espere que ela resolva problemas que nunca foi projetada para resolver.

- Não é uma garantia de que o agente nunca se comportará mal. Um atacante determinado que encontra uma forma de invocar uma ferramenta permitida com parâmetros maliciosos ainda pode causar danos. - Não substitui práticas de codificação seguras. Se o código do próprio agente contém uma vulnerabilidade, a lista de permissões não pode impedir a exploração dessa falha. - Não é um substituto para um gerenciamento de segredos adequado. Mesmo que o agente não possa chamar uma ferramenta de extração de segredos, segredos vazados em logs ou saídas ainda representam um risco. - Não impede a injeção indireta de prompts que manipula o agente para usar uma ferramenta permitida de uma forma inesperada. Você ainda precisa de validação de entrada e filtragem de saída. - Não é uma tarefa única. Sempre que uma ferramenta é adicionada, seus parâmetros mudam ou o propósito do agente muda, você deve revisitar a lista. - Não é uma bala de prata para a conformidade. Regulamentações como o EU AI Act exigem documentação, avaliações de risco e supervisão humana que vão além de uma simples lista de permissões.

Armadilhas comuns que eu vi e como as evito

Mesmo com um processo claro, as equipas por vezes caem em hábitos que enfraquecem a lista de permissões. Abaixo estão os padrões que eu vigio e as medidas concretas que eu tomo para manter a lista honesta.

- Parâmetros excessivamente amplos – Alguém adiciona uma ferramenta com uma flag como "--recursive" ou "--all" porque parece conveniente. Eu contraponto isto perguntando: "Qual é o conjunto mais pequeno de opções que satisfaz a tarefa?" Se a resposta for um subconjunto, eu tranco a flag para esse subconjunto no YAML. - Atualizações de ferramentas esquecidas** – Uma biblioteca é atualizada e adiciona um novo comando que é automaticamente exposto. Eu mitigo isto fixando a versão exata da ferramenta no ficheiro de dependências do AgentGuard e adicionando uma etapa de CI que falha se uma nova versão introduzir comandos não documentados. - Mistura de política com prompt** – Um desenvolvedor tenta impor limites adicionando instruções como "não chamar delete" dentro do prompt. Eu lembro a equipa que os controles de nível de prompt podem ser contornados através de reescrita astuta; a verdadeira guarda deve estar no registo de ferramentas ou na camada de execução. - Registo em falta** – A lista de permissões bloqueia uma chamada, mas ninguém sabe que isso aconteceu. Eu asseguro que cada tentativa bloqueada escreva uma entrada de registo estruturada com carimbo de data/hora, ID do agente e nome da ferramenta rejeitada.

Referências

- Folha de Dicas de Prevenção de Injeção de Prompt LLM da OWASP - Folha de Dicas de Prevenção de Injeção de SQL da OWASP - Folha de Dicas de Gestão de Segredos da OWASP - AgentGuard - Guia de Ficheiros de Configuração

Perguntas frequentes

Um comando de prompt é suficiente para restringir as ferramentas?

Não. Restrições ao nível do prompt podem ser contornadas. Implemente a lista de permissões no registro de ferramentas ou na camada de execução.

O que conta como um efeito externo irreversível?

Enviar e-mails ou mensagens, mover dinheiro, apagar registos, publicar conteúdo — qualquer coisa que não possa ser desfeita.

Quantas ferramentas são demasiadas?

Não há um número específico. O teste é se consegue explicar, para cada ferramenta na lista, qual tarefa a requer e o que ela pode destruir.

Os filtros substituem a lista de permissões?

Não. Os filtros capturam conteúdo ruim; as listas de permissões removem capacidades desnecessárias. Use ambos.

Isto cobre a injeção indireta de prompts?

Limita os danos que se pode causar. Detectar e bloquear a injeção em si é um controlo de entrada separado.

A revisão é uma auditoria de segurança?

Não. É um suporte de decisão que avalia chamadas e sugere filtros. Uma avaliação completa da implementação ainda precisa de uma revisão de segurança.

Referências

- OWASP — Top 10 para Aplicações de Modelos de Linguagem Grande - NIST — Quadro de Gestão de Risco de IA

Experimente o produto: AgentGuard

2026-09-20 · apenas fontes primárias · nenhum tráfego métrico fabricado · apenas suporte à decisão

Artigos relacionados

- Barreiras de agente mapeadas para o NIST AI RMF - Explore a matriz completa de tópicos de micro-SaaS de IA →