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

Por que negar-por-padrão funciona melhor do que tentar bloquear cada chamada ruim

Quando você começa com uma postura de negar-por-padrão, você só precisa pensar sobre o que o agente realmente precisa. Todas as outras chamadas são interrompidas automaticamente, sem precisar prever cada possível mau uso. Isso reduz a carga mental do 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 de negar-por-padrão cobre todos eles.

Na prática, eu já vi equipes gastarem semanas construindo listas de bloqueio longas que ainda perdem um novo vetor de ataque, enquanto uma lista de permissão 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ão quando uma ferramenta muda, não quando uma nova ameaça aparece.

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

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

- Escrevo 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 realiza o trabalho com os parâmetros mais estreitos possíveis. Se uma ferramenta oferece uma flag que amplia o escopo, não a habilito a menos que a tarefa explicitamente precise disso. - Registro o nome da ferramenta, o comando exato ou endpoint de API e os valores de parâmetro permitidos em um arquivo YAML simples. Este arquivo fica ao lado do código do agente para que os revisores possam vê-lo de relance. - Executo o agente em um sandbox e verifico que cada chamada listada seja bem-sucedida e que qualquer chamada não no arquivo retorne um erro. - Peço a um peer para revisar a lista. O trabalho do revisor é confirmar que cada entrada mapeia para uma tarefa real e que nenhuma capacidade extra está escondida atrás de padrões. - Armazeno o arquivo em controle de versão. Marco cada commit com a versão do agente para que eu possa rastrear qual lista de permissões foi enviada com qual lançamento. - Configuro uma etapa de CI que falha na compilação se o arquivo YAML estiver faltando ou se contiver uma ferramenta não aprovada no registro de ferramentas do projeto.

Esse processo leva cerca de uma hora para um agente simples e produz um documento que qualquer um pode auditar.

Classificando ferramentas pelo que elas podem alterar

Não todas as ferramentas carregam 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 | Registrar a chamada, sem aprovação extra necessária Gravação ou mutável | Pode criar, atualizar ou excluir dados | Gravação 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, postar em mídia social, iniciar pagamento, chamar webhook externo | Aprovação manual obrigatória, rastreamento de auditoria detalhado, tempo limite na chamada

Quando eu reviso uma nova ferramenta, pergunto: “Se essa 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 gravação, 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.

Combinando listas de permissão com filtros de entrada e saída

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

No lado de entrada, executo um verificador de injeção de prompts que procura por padrões de jailbreak conhecidos. Utilizo a OWASP LLM Prompt Injection Prevention Cheat Sheet como referência para as regras que habilito. Se o verificador sinalizar um prompt, eu o rejeito ou sanitizo 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 Secrets Management Cheat Sheet me ajuda a criar padrões de regex para chaves de API, senhas e tokens. A SQL Injection Prevention Cheat Sheet orienta os padrões que uso para capturar strings de consulta perigosas que podem 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 impedem muitos ataques de baixo esforço antes que eles atinjam a camada de ferramentas. Como a lista de permissão 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 isso não é

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

- Não é uma garantia de que o agente nunca se comportará mal. Um atacante determinado que encontra uma maneira de invocar uma ferramenta permitida com parâmetros maliciosos ainda pode causar danos. - Não substitui práticas de codificação seguras. Se o próprio código do agente contém uma vulnerabilidade, a lista de permissões não pode impedir a exploração dessa falha. - Não é um substituto para gerenciamento adequado de segredos. Mesmo que o agente não possa chamar uma ferramenta de extração de segredos, segredos vazados em logs ou saída ainda representam um risco. - Não impede a injeção indireta de prompts que manipula o agente para usar uma ferramenta permitida de uma maneira 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 solução mágica para 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.

Entender esses limites ajuda a alocar esforço onde ele adiciona valor de segurança real.

Armadilhas comuns que eu vejo e como eu as evito

Mesmo com um processo claro, as equipes às vezes caem em hábitos que enfraquecem a lista de permissões. Abaixo estão os padrões que eu observo e as etapas concretas que eu tomo para manter a lista honesta.

- Parâmetros muito amplos – Alguém adiciona uma ferramenta com uma flag como "--recursive" ou "--all" porque parece conveniente. Eu contraponto isso perguntando: "Qual é o menor conjunto de opções que satisfaz a tarefa?" Se a resposta for um subconjunto, eu travo a flag para esse subconjunto no YAML. - Atualizações de ferramentas esquecidas** – Uma biblioteca é atualizada e adiciona um novo comando que é exposto automaticamente. Eu mitigo isso fixando a versão exata da ferramenta no arquivo de dependência do AgentGuard e adicionando uma etapa de CI que falha se uma nova versão introduzir comandos não documentados. - Misturando política com prompt** – Um desenvolvedor tenta impor limites adicionando instruções como "não chame delete" dentro do prompt. Eu lembro a equipe de que os controles de nível de prompt podem ser contornados por meio de reescrita astuta; a verdadeira proteção deve estar no registro de ferramentas ou na camada de execução. - Logs ausentes** – A lista de permissões bloqueia uma chamada, mas ninguém sabe que isso aconteceu. Eu garanto que cada tentativa bloqueada escreva uma entrada de log estruturada com carimbo de data/hora, ID do agente e nome da ferramenta rejeitada. Esse log é alimentado em nosso sistema de alertas para que possamos detectar a varredura de…

Referências

- Folha de Dicas de Prevenção de Injeção de Prompt LLM do OWASP - Folha de Dicas de Prevenção de Injeção de SQL do OWASP - Folha de Dicas de Gerenciamento de Segredos do OWASP - AgentGuard - Guia de Arquivos de Configuração

Perguntas frequentes

Um prompt de instrução é suficiente para restringir ferramentas?

Não. Restrições de nível de prompt podem ser contornadas. Imponha 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, excluir registros, publicar conteúdo — qualquer coisa que você não possa desfazer.

Quantas ferramentas são muitas?

Não há um número. O teste é se você pode 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. Filtros capturam conteúdo ruim; listas de permissões removem capacidade desnecessária. Use ambos.

Isso cobre a injeção indireta de prompt?

Isso limita o dano que um pode fazer. Detectar e bloquear a injeção em si é um controle de lado de entrada separado.

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

Não. É um suporte de decisão que avalia chamadas e sugere filtros.

Referências

- OWASP — Top 10 para Aplicações de Modelo de Linguagem Grande - — Framework de Gerenciamento de Risco de IA

Experimente o produto: AgentGuard

2026-09-20 · fontes primárias apenas · sem métricas de tráfego fabricadas · suporte à decisão apenas.

Artigos relacionados

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