Guardrails de Agente mapeados para o NIST AI RMF

Porque construí o AgentGuard

Comecei o AgentGuard após ver uma equipa enviar um agente alimentado por que podia ler uma base de dados, chamar uma API de pagamento e enviar um e-mail, tudo com um único pedido. O agente funcionou na demonstração, mas um simples erro de digitação na consulta do utilizador causou a transferência de dinheiro para a conta errada. Ninguém havia verificado o que o agente estava autorizado a fazer antes da chamada, e não havia forma de o parar uma vez que o erro ocorreu.

Percebi que o problema não era o modelo em si, mas as fronteiras ausentes em torno das suas ações. Queria uma forma repetível de listar cada ferramenta que um agente pode alcançar, decidir quem pode ativar cada ferramenta, testar o agente contra as permissões que pensamos que ele tem e reagir quando algo correr mal. O quadro de gestão de riscos de IA da NIST deu-me as quatro funções que se alinham exatamente com esses passos.

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

Filtros de entrada

Estes são verificações que são executadas na solicitação do utilizador ou na razão interna do agente antes de uma ferramenta ser invocada. Exemplos incluem:

- Detecção de padrões de injeção de solicitação que tentam ignorar instruções anteriores.

- Verificação de palavras-chave ou frases proibidas que sinalizam um pedido de acesso a um sistema restrito.

- Validação de que a solicitação 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 eliminar, e quais serviços externos pode contactar. Armazenamos cada permissão como uma tupla:

- Identificador de ferramenta

- Fontes de dados permitidas (por exemplo, acesso somente leitura à tabela de clientes, acesso de escrita ao registo de auditoria)

- Destinos de rede (por exemplo, api.paymentprovider.com na porta 443)

- Nível de aprovação necessário (nenhum, revisão de pares, assinatura de gerente)

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

Verificações de saída

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

- Garantir que uma consulta SQL retorne não mais de 100 linhas.

- Confirmar que a carga de um e-mail não contém URLs externas.

- Digitalizar para vazamentos de segredos, como chaves de API ou palavras-passe, 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 fornece uma estrutura clara para organizar o trabalho de guardrails. Abaixo está uma tabela que mostra a qual função pertence cada guardrail, o artifacto concreto que produzimos e um exemplo breve.

Função NIST | Tipo de guardrail | Artifacto | Exemplo Governar | Fluxo de aprovação | Registo de habilitação de ferramenta | Um documento assinado que lista quem aprovou a ferramenta send_email, a data e a autenticação multifator (MFA) necessária para o aprovador. Mapear | Inventário de ferramentas | Matriz de permissões | Uma folha de cálculo que enumera cada ferramenta, as tabelas que pode ler/escrever e os pontos finais externos que pode chamar. Medir | Conjunto de testes | Conjunto de prompts adversariais | Uma coleção de prompts projetados para desencadear escalada de privilégios, exfiltração de dados ou chamadas externas não autorizadas. Gerenciar | Resposta em tempo de execução | Registo de kill-switch | Uma entrada com carimbo de data e hora que registra quando o agente tentou excluir um registo 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 chamada de ferramenta

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

- Gravar 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 no motor de filtro de entrada.

Etapa 3: Verificar a sensibilidade dos dados

Examinamos as fontes de dados que a ferramenta pode acessar. Se alguma fonte contiver 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 isto não é

Quero deixar claro os limites das barreiras de segurança para que não as confunda com uma bala de prata.

- As barreiras de segurança 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 configurada ainda pode produzir efeitos indesejados dentro do limite permitido. - Elas não substituem as 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 injeção de SQL https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), a barreira de segurança não pode corrigir essa falha. - Elas não fornecem uma certificação de segurança de 100 %. Pense nelas como auxiliares de decisão que o ajudam a tomar 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 trabalho de revisão passo a passo

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

Exportar o texto exato que o agente recebe no início 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 finais externos e autenticação necessária - Qualquer token de aprovação ou papel necessário

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

Aplicar o processo de classificaçã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 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 adversariais

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 lista:

- Nome da ferramenta - Classificaçã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 mudam (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

As equipas por vezes pensam que adicionar um bloqueador de palavras-chave é suficiente. Contrariamos isto exigindo verificações de entrada e saída para qualquer ferramenta de risco médio ou alto, e registamos quando qualquer uma das verificações for disparada.

Armadilha 2: Esquecer-se 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 de o agente a poder utilizar. Exigimos que a matriz seja um ficheiro controlado por versões que o pipeline de CI valide em cada push.

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

Uma pesquisa de leitura apenas que devolve o endereço de e-mail de um utilizador pode tornar-se perigosa se o agente mais tarde utilizar esse endereço num fluxo de redefinição de palavra-passe. Tratamos a sensibilidade dos dados como um fator de classificação separado, por isso uma ferramenta de nível baixo que toca na informação pessoal é automaticamente atualizada.

Armadilha 4: Saltar o passo do humano-no-ciclo para ferramentas de alto risco

Para ferramentas que podem mover dinheiro ou apagar registos, exigimos um passo de aprovação explícito que não pode ser contornado pela automação. A aprovação é registada num registo imutável.

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

Incorporamos o fluxo de revisão na definição de pronto da equipa para qualquer funcionalidade 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 inadequada ainda podem causar danos dentro dos limites que foram permitidos.

O que precisamos para executar uma revisão?

O prompt do sistema do agente e sua lista de ferramentas. Isso é suficiente para avaliar as 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 o seu sistema e cumprir as obrigações ainda requer 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?

Isso revisa o prompt e a configuração da ferramenta. A monitorização em tempo de execução é uma camada separada que ainda é necessária.

E se uma ferramenta for genuinamente de alto risco?

Exija uma etapa de aprovação, restrinja seus parâmetros e registe 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 Modelos de Linguagem de Grande Escala

Experimente o produto: AgentGuard

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

Artigos relacionados

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