por AgentPolicy (LX AI)

Pacotes de política de agente de IA e NIST AI RMF

Um pacote de política é um conjunto reutilizável de regras sobre o que um agente pode fazer: quais ferramentas ele pode chamar, quais classes de dados ele pode tocar e quando ele deve escalar para um humano. Mapear essas regras para as quatro funções do NIST AI Risk Management Framework - Govern, Map, Measure e Manage - mantém o pacote fundamentado em uma estrutura que os auditores já reconhecem. O pacote é um rascunho que você aprova, não um certificado de conformidade.

Governar: propriedade e responsabilidade

Definindo proprietários de regras

Eu começo cada pacote nomeando uma pessoa ou equipe responsável por cada regra. O proprietário assina a regra de texto, revisa trimestralmente e aprova qualquer alteração. Sem um proprietário claro, uma regra que bloqueia uma ferramenta perigosa hoje pode ser esquecida quando uma nova integração aparece, deixando o agente com acesso não intencional.

Processo de controle de alterações

Eu trato o pacote como um arquivo controlado por versão. Cada edição cria um novo commit, inclui uma breve justificativa e passa por uma lista de verificação de revisão que aborda: (1) impacto em ferramentas permitidas, (2) efeito em tags de classe de dados, (3) caminhos de escalonamento e (4) compatibilidade com evidências de auditoria existentes. A lista de verificação vive no mesmo repositório que o pacote, para que os revisores possam ver a diferença e a discussão em um só lugar.

Link para a função Govern do NIST

O NIST AI RMF descreve Govern como a base que define papéis, responsabilidades e políticas. Meu pacote espelha isso tornando a propriedade explícita e incorporando um fluxo de trabalho de controle de alterações leve que os auditores podem inspecionar. Quando um auditor pergunta “quem é responsável por essa regra?”, eu posso apontar para o campo de proprietário e o histórico de commits.

Mapa: contexto e fluxos de dados

Inventário de ferramentas e classes de dados

Eu listo cada ferramenta externa que o agente pode chamar, então etiqueto cada ferramenta com as classes de dados que ela pode ler ou escrever. Por exemplo, uma ferramenta de resumo recebe a etiqueta "tickets de cliente" porque pode ingerir o texto do ticket, enquanto uma ferramenta de cálculo matemático recebe a etiqueta "nenhum" porque apenas retorna números. Essa visão em duas camadas evita o erro comum de permitir que uma ferramenta acesse dados sem entender quais dados ela toca.

Avaliação de risco por ferramenta

Para cada par ferramenta-dados, eu atribuo uma pontuação de risco simples: baixo, médio ou alto. A pontuação vem de três perguntas: (1) A ferramenta lida com informações de identificação pessoal? (2) A ferramenta pode invocar outros serviços? (3) A ferramenta foi mencionada em bases de dados de vulnerabilidades públicas? Eu registro a pontuação no pacote para que os revisores vejam por que uma ferramenta é restrita ou permitida.

Link para a função de mapeamento da NIST

O mapeamento no AI RMF é sobre entender o contexto e o impacto potencial. Meu inventário e folha de pontuação fornecem um artefato concreto que mostra quais sistemas o agente alcança, quais dados fluem por meio dele e qual seria o custo de uma falha. Isso atende ao requisito de mapeamento para "identificar e categorizar riscos" antes que quaisquer controles sejam aplicados.

Medida: telemetria e evidências

Registro de acertos de regras

Eu configuro o agente para emitir uma entrada de log estruturada cada vez que uma regra é avaliada. A entrada contém: carimbo de data e hora, ID do agente, ID da regra, nome da ferramenta, classe de dados, decisão (permitir/negar/escalonar) e a pontuação de risco da etapa Map. Esses logs fluem para um repositório central onde posso executar consultas simples, como “mostrar todas as negações para a ferramenta de resumo na última semana.”

Rastreamento de escalonamento

Sempre que o pacote dispara uma escalonamento, eu registro o motivo e o humano que respondeu. Com o tempo, calculo duas métricas: (1) taxa de escalonamento por ferramenta e (2) tempo médio de resolução humana. Esses números se tornam as evidências que mostro durante uma revisão para provar que os limites não são apenas escritos, mas realmente aplicados.

Link para a função de Medida do NIST

A função de Medida exige indicadores quantitativos que mostrem se os controles estão funcionando. Minhas métricas baseadas em logs dão aos auditores uma maneira repetível de ver a eficácia da regra, frequência de escalonamento e latência de resposta. Se as métricas mostram um aumento repentino de negações para uma ferramenta, eu sei que o pacote precisa de uma atualização do Map.

Gerenciar: resposta e iteração

Atualizações impulsionadas por incidentes

Quando uma entrada de log revela uma violação de política — digamos, o agente chamou uma ferramenta proibida — eu abro um ticket que faz referência à linha de log exata. O ticket impulsiona um fluxo de trabalho curto: (1) verificar a violação, (2) decidir se deve ser feita uma restrição na definição da ferramenta, adicionar uma lista de permissões de saída ou exigir confirmação, (3) editar o pacote, (4) aumentar a versão e (5) fechar o ticket com um link para o novo commit.

Controle de versão como código

Eu armazeno o pacote em um repositório Git. Cada lançamento recebe uma versão semântica (por exemplo, 1.2.0). A mensagem de commit inclui a regra alterada, o motivo e o número do ticket associado. Isso torna fácil mostrar a um auditor a diferença exata entre a versão revisada no mês passado e a versão em produção hoje.

Link para a função Gerenciar do NIST

Gerenciar no AI RMF é sobre responder a problemas detectados e melhorar os controles. Meu fluxo de ticket impulsionado por incidentes e meu pacote controlado por versão fornecem um mecanismo concreto para detectar, responder e verificar a melhoria — exatamente o que o Gerenciar espera.

Construindo um pacote de políticas passo a passo

Comece com uma lista de permissões de ferramentas

Eu começo coletando cada API, CLI ou webhook que o agente possa precisar. Eu escrevo cada entrada em uma lista YAML simples, anotando o fornecedor da ferramenta, a versão e o propósito. Nesta etapa, não me preocupo com classes de dados; eu apenas quero um inventário completo.

Adicione tags de classes de dados

Em seguida, eu percorro a lista de permissões e pergunto: quais dados essa ferramenta lê ou grava? Eu adiciono uma tag como "registros financeiros", "informações de saúde" ou "web pública". Se uma ferramenta toca em várias classes, eu adiciono várias tags. Esta etapa transforma uma lista simples em um mapa que pode ser pontuado para risco.

Defina limiares de escalonamento

Para cada par de ferramenta e dados, eu decido quando o agente deve passar para um humano. Eu uso a pontuação de risco da etapa de mapeamento: pontuações baixas obtêm permissão automática, pontuações médias obtêm permissão com registro de auditoria e pontuações altas forçam uma escalonamento. Eu codifico esses limiares como uma tabela de decisão no pacote.

Valide com cenários de teste

Antes de chamar o pacote de "pronto", eu executo um conjunto de interações scriptadas que tentam acionar cada regra. Eu verifico se os registros capturam a decisão esperada, se os escalonamentos disparam quando devem e se nenhuma regra falha silenciosamente. Se um teste mostrar uma discordância, eu retorno à etapa de mapeamento ou gerenciamento para corrigir o pacote.

O que isso não é

Quero deixar claro os limites de um pacote de políticas. Ele não é uma garantia de que o agente nunca violará uma regra. Não é um escudo de 100 % contra vetores de ataque novos que eram desconhecidos quando o pacote foi escrito. Ele não substitui uma revisão legal formal, uma avaliação de um órgão notificado ou sua própria aceitação de risco. O pacote é uma ferramenta de apoio à decisão que torna as regras visíveis, testáveis e alteráveis, mas a responsabilidade final ainda recai sobre os humanos que possuem o sistema.

Lista de verificação do operador para pacotes de política de agente de IA por meio de uma lente de NIST AI RMF

Mantenho uma lista de verificação escrita ao lado de cada lançamento que toca nesse tópico. A lista é propositadamente monótona: nomear o proprietário, nomear o artefato de evidência e nomear o rollback. Se uma etapa não puder produzir um arquivo, um ticket ou uma linha de log, não é uma etapa — é um desejo.

Antes de alterar a produção

- Congele o branch ou a revisão de configuração que você medirá. - Registre o modo de falha atual com uma entrada concreta e uma saída concreta. - Confirme qual identidade o trabalho é executado e se essa identidade pode alcançar dados que não deve. - Abra as referências principais que você citará: https://genai.owasp.org/llmrisk/llm01-prompt-injection, https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene.

Enquanto você executa a verificação

- Prefira um caminho reprodutível em vez de dez capturas de tela anedóticas. - Escreva o resultado seguro esperado antes de acionar a ferramenta ou consulta. - Capture o comando exato, prompt, schema ou regex em teste — não uma paráfrase. - Se o sistema puder agir (enviar, escrever, excluir, transferir), exija um limite de confirmação no mesmo passe.

Depois de terminar

- Arquive o risco residual com um proprietário e uma data, mesmo quando a varredura estiver limpa. - Não converta um sinal de verificação verde em linguagem de vendas que afirme a completude. - Execute a mesma lista de verificação quando o modelo, o schema da ferramenta ou as regras de validação mudarem.

AgentPolicy ajuda com a primeira passagem mensurável. Escolhas de arquitetura, assinatura legal e afirmações voltadas para o cliente ainda precisam de um proprietário humano. Trate cada linha da lista de verificação como suporte à decisão, não como um certificado.

Como explico limites para compradores

Quando um prospect pergunta se o produto "cobrir tudo", respondo com o limite: verificações automatizadas capturam padrões conhecidos; cadeias novas e julgamento de política ainda precisam de revisão. Essa honestidade mantém a carga de suporte baixa e mantém o blog alinhado com o que o produto realmente faz.

Se você precisa de uma segunda opinião, combine este texto com as referências abaixo e com sua própria reprodução de teste. Não pule a etapa de reprodução apenas porque um modelo escreveu um resumo confiante.

Referências

- https://genai.owasp.org/llmrisk/llm01-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