Guardrails de agente mapeados para o NIST AI RMF

Por que eu criei o AgentGuard

Eu comecei o AgentGuard após assistir a uma equipe enviar um agente alimentado por que podia ler um banco de dados, chamar uma API de pagamento e enviar e-mail, tudo com um único prompt. O agente funcionou no demonstrativo, mas um simples erro de digitação na consulta do usuário fez com que ele transferisse dinheiro para a conta errada. Ninguém havia verificado o que o agente estava autorizado a fazer antes da chamada, e não havia como impedi-lo uma vez que o erro ocorreu., Eu percebi que o problema não era o modelo em si, mas as limitações ausentes em torno de suas ações. Eu queria uma maneira repetível de listar cada ferramenta que um agente pode alcançar, decidir quem pode habilitar cada ferramenta, testar o agente contra as permissões que achamos que ele tem e reagir quando algo dá errado. O quadro de gerenciamento de riscos de IA do NIST me deu as quatro funções que se alinham exatamente com essas etapas.

Conceitos principais: filtros de entrada, permissões de ferramentas, verificações de saída

Filtros de entrada

Essas são verificações que são executadas na prompt do usuário ou no raciocínio interno do agente antes que uma ferramenta seja invocada. Exemplos incluem:

- Detecção de padrões de injeção de prompt que tentam ignorar instruções anteriores. - Verificação de palavras-chave ou frases proibidas que sinalizam uma solicitação de acesso a um sistema restrito. - Validação de que o prompt contém um token de aprovação necessário quando uma ferramenta de alto risco é referenciada.

Implementamos filtros de entrada como motores de regex leves combinados com uma pequena lista de permitidos de padrões seguros. Eles adicionam menos de dois milissegundos de latência por chamada.

Permissões de ferramentas

As permissões de ferramentas definem quais dados uma ferramenta pode ler, escrever ou excluir, e quais serviços externos ela pode contatar. Armazenamos cada permissão como uma tupla:

- Identificador de ferramenta - Fontes de dados permitidas (por exemplo, acesso somente leitura à tabela de clientes, acesso de gravação ao log de auditoria) - Destinos de rede (por exemplo, api.paymentprovider.com na porta 443) - Nível de aprovação necessário (nenhum, revisão de peer, assinatura de gerente)

Quando o agente solicita usar uma ferramenta, o serviço de permissão verifica a tupla contra o contexto atual e permite a chamada, modifica os parâmetros ou bloqueia.

Verificações de saída

Depois que uma ferramenta retorna um resultado, as verificações de saída verificam se a resposta permanece dentro dos limites esperados. Exemplos:

- Garantir que uma consulta SQL retorne no máximo 100 linhas. - Confirmar que a carga de um e-mail não contém URLs externas. - Scaneamento de segredos vazados, como chaves de API ou senhas, na resposta.

Se uma verificação falhar, o sistema pode truncar o resultado, redigir partes sensíveis ou acionar um alerta.

Mapeamento de guardrails para funções do NIST AI RMF

A estrutura de quatro funções do framework fornece uma estrutura clara para organizar o trabalho de guardrails. Abaixo está uma tabela que mostra a qual função pertence cada guardrail, o artefato concreto que produzimos e um exemplo breve.

Função do NIST | Tipo de guardrail | Artefato | Exemplo Governar | Fluxo de aprovação | Registro de habilitação de ferramenta | Um documento assinado que lista quem aprovou a ferramenta send_email, a data e a autenticação de dois fatores necessária para o aprovador. Mapear | Inventário de ferramentas | Matriz de permissões | Uma planilha que enumera cada ferramenta, as tabelas que ela pode ler/gravar e os pontos de extremidade externos que ela pode chamar. Medir | Conjunto de testes | Conjunto de prompts adversários | Uma coleção de prompts projetados para disparar escalonamento de privilégios, exfiltração de dados ou chamadas externas não autorizadas. Gerenciar | Resposta em tempo de execução | Registro de kill-switch | Uma entrada com carimbo de data/hora que registra quando o agente tentou excluir um registro de produção, a ação que foi bloqueada e o operador que foi notificado.

Cada função se baseia na anterior. Governar decide quem pode adicionar uma nova ferramenta ao inventário. Mapear cria o inventário que Medir irá testar. Medir produz evidências que Gerenciar pode agir. O loop se repete sempre que a lista de ferramentas ou o prompt do agente muda.

Como avaliamos uma ferramenta de chamada

Etapa 1: Identificar a ferramenta e sua classe de permissão

Começamos procurando a ferramenta na matriz de permissões. A matriz atribui um nível de risco base:

- Consulta somente leitura (por exemplo, buscar um catálogo de produtos) → baixo

- Gravação em um log interno → médio

- Ação externa com efeitos colaterais (por exemplo, enviar dinheiro, excluir um registro) → alto

Se a ferramenta exigir um token de aprovação, adicionamos um nível ao risco base.

Etapa 2: Analisar o prompt para risco de injeção

Executamos o prompt do usuário pelo mecanismo de filtro de entrada.

Etapa 3: Verificar a sensibilidade dos dados

Examinamos as fontes de dados que a ferramenta pode acessar. Se alguma fonte contém informações de identificação pessoal (PII) ou dados financeiros, adicionamos outro nível.

Etapa 4: Produzir a classificação final e filtros sugeridos

A classificação final é a soma do nível base, do nível do prompt e do nível de dados. Com base na classificação, recomendamos:

- Baixo → nenhum filtro adicional, apenas registrar a chamada.

- Médio → adicionar um filtro de entrada que remova palavras-chave não permitidas e uma verificação de saída que limite a contagem de linhas.

- Alto → exigir aprovação humana, impor uma lista de permissões estrita de parâmetros e habilitar a redação completa de saída.

O que isso não é

Quero deixar claro os limites das guardrails para que você não as confunda com uma bala de prata.

- As guardrails não garantem que um agente nunca cause danos. Elas reduzem o raio de ação de um erro, mas um atacante determinado ou uma ferramenta mal projetada ainda pode produzir efeitos indesejados dentro do limite permitido. - Elas não substituem práticas de codificação seguras. Se a ferramenta subjacente tiver uma vulnerabilidade (por exemplo, uma falha de injeção de SQL descrita na folha de dicas de prevenção de injeção de SQL https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), a guardrail não pode corrigir essa falha. - Elas não fornecem uma certificação de segurança de 100 %. Pense nelas como auxiliares de tomada de decisão que ajudam a fazer escolhas informadas sobre o uso de ferramentas. - Elas não são uma configuração de definir e esquecer. Sempre que o prompt do agente, a lista de ferramentas ou os dados que uma ferramenta pode alcançar mudam, você deve reexecutar o processo de revisão.

Colocando em prática: um fluxo de revisão passo a passo

1. Coletar o prompt do sistema do agente e a lista de ferramentas

Exportar o texto exato que o agente recebe na inicialização e o arquivo JSON ou YAML que declara cada ferramenta que ele pode chamar.

2. Popular a matriz de permissões

Para cada ferramenta, registrar:

- Alvos de leitura permitidos - Alvos de escrita permitidos - Pontos de extremidade externos e autenticação necessária - Qualquer token de aprovação ou papel necessário

3. Executar a avaliação de risco de baseline

Aplicar o processo de avaliação de quatro etapas descrito anteriormente. Registrar o nível de risco inicial para cada ferramenta.

4. Gerar sugestões de filtros de entrada e saída

Com base no nível de risco, produzir regras de filtro concretas (padrões de regex, limites de contagem de linhas, regras de redação). Armazená-las ao lado da definição da ferramenta.

5. Executar o conjunto de testes adversários

Executar o agente contra o conjunto de prompts da coluna Medir da tabela. Verificar se os filtros bloqueiam ou mitigam os modos de falha esperados.

6. Documentar o resultado

Criar um relatório curto que liste:

- Nome da ferramenta - Avaliação de risco inicial - Filtros aplicados - Resultados dos testes (passar/falhar) - Qualquer etapa de aprovação manual necessária

7. Configurar o monitoramento e os alertas

Configurar o ambiente de execução do agente para registrar cada chamada de ferramenta, os filtros aplicados e os resultados da verificação de saída. Encaminhar anomalias para o canal de resposta a incidentes.

8. Agendar um gatilho de revisão

Marcar o fluxo de trabalho para repetir quando ocorrer qualquer uma das seguintes situações:

- Uma nova ferramenta é adicionada à lista - O prompt do sistema é editado - As permissões de uma ferramenta são alteradas (por exemplo, um banco de dados ganha uma nova coluna com PII)

Armadilhas comuns e como as evitamos

Armadilha 1: Dependência excessiva de um único tipo de filtro

Equipes às vezes pensam que adicionar um bloqueador de palavras-chave é suficiente. Contrariamos isso exigindo verificações de entrada e saída para qualquer ferramenta de risco médio ou alto, e registramos quando qualquer uma das verificações for acionada.

Armadilha 2: Esquecer de atualizar a matriz de permissões

Quando uma ferramenta ganha uma nova capacidade (por exemplo, uma API de pagamento agora suporta reembolsos), a matriz deve ser editada antes que o agente possa usá-la. Enforcemos isso tornando a matriz um arquivo controlado por versão que o pipeline de CI valida em cada push.

Armadilha 3: Ignorar ferramentas de baixo risco que se tornam de alto risco no contexto

Uma pesquisa de leitura apenas que retorna o endereço de e-mail de um usuário pode se tornar perigosa se o agente posteriormente usar esse endereço em um fluxo de redefinição de senha. Tratamos a sensibilidade dos dados como um fator de classificação separado, então uma ferramenta de nível baixo que toca informações de identificação pessoal é automaticamente atualizada.

Armadilha 4: Pulando a etapa de humanos na cadeia para ferramentas de alto risco

Para ferramentas que podem mover dinheiro ou excluir registros, exigimos uma etapa de aprovação explícita que não pode ser contornada pela automação. A aprovação é registrada em um log imutável.

Armadilha 5: Tratar a configuração da barreira de proteção como uma tarefa de uma vez

Incorporamos o fluxo de trabalho de revisão na definição de pronto da equipe para qualquer recurso que altere o comportamento do agente. Isso torna o processo repetível em vez de um item de lista de verificação esquecido.

Referências

- https://genai.owasp.org/llmrisk/-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Perguntas frequentes

Os guardrails tornam um agente seguro?

Não. Eles restringem o raio de ação de um erro. Um atacante determinado, uma ferramenta mal dimensionada ou uma solicitação ruim ainda podem causar danos dentro do limite que você permitiu.

O que precisamos para executar uma revisão?

O prompt do sistema do agente e sua lista de ferramentas. Isso é suficiente para avaliar chamadas e sugerir filtros.

O mapeamento do Regulamento de IA da UE é um conselho jurídico?

Não. É um mapeamento para ajudá-lo a encontrar as obrigações certas. Classificar seu sistema e atender às obrigações ainda precisa de um revisor qualificado.

Com que frequência devemos reexecutar?

Sempre que a lista de ferramentas, o prompt do sistema ou os dados que uma ferramenta pode alcançar mudam.

Isso testa o agente em tempo de execução?

Ele revisa o prompt e a configuração da ferramenta. A monitoração em tempo de execução é uma camada separada que você ainda precisa.

E se uma ferramenta for genuinamente de alto risco?

Exija uma etapa de aprovação, restrinja seus parâmetros e registre cada invocação. Ferramentas de alto risco geralmente precisam de um humano no loop, em vez de um filtro.

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

- Listas de permissão de ferramentas de agente de IA: por que deny-by-default vence - Explore a matriz completa de tópicos de micro-SaaS de IA →