Um agente de IA que atua em contas conectadas pode alterar dados ou acionar processos empresariais. Antes de escolher um fornecedor, o responsável pelo negócio e quem analisa a segurança podem comparar os controles de um fluxo de trabalho proposto com os requisitos escritos da organização. O resultado é um registro datado de evidências. Uma pergunta sem resposta permanece aberta; uma alegação do produto não demonstra, por si só, que uma ação será impedida. O método se baseia no NIST AI Risk Management Framework Playbook e no AI Agent Security Cheat Sheet da OWASP; nenhum deles avaliou o fornecedor candidato.
A grande mudança
- O que mudou: A compra de um agente pode incluir ações delegadas em sistemas empresariais. O comprador precisa saber quem pode fazer o agente agir, sobre o quê e mediante aprovação de quem.
- Por que importa: O comprador pode vincular cada ação proposta a um controle identificado e às suas evidências. Isso oferece ao responsável pelo negócio e a quem analisa a segurança uma base concreta para limitar o acesso ou suspender a compra.
- O que observar: A decisão depende de evidências para a versão exata do produto e o fluxo de trabalho. Um controle mostrado na documentação ainda pode exigir uma demonstração supervisionada antes de ser aceito para o uso pretendido.
Reúna quatro elementos
Use o perfil de risco escrito já existente e aprovado pela organização. Ele deve identificar o responsável pelo negócio, o resultado pretendido, os dados e destinos permitidos, as ações autorizadas, a autoridade de aprovação, as consequências inaceitáveis e as condições de parada. Se não existir, peça às pessoas responsáveis que o definam antes de avaliar o fornecedor. Este guia não pode definir a tolerância ao risco da organização por elas.
A orientação MANAGE 3.1 do NIST pede que se aplique a tolerância ao risco da organização aos sistemas de IA de terceiros e que seus controles sejam documentados. O Playbook oferece sugestões voluntárias, não uma lista universal de compras. As perguntas sobre controles de ação abaixo também se baseiam na orientação de segurança da OWASP para agentes. Esses referenciais apontam perguntas úteis; as evidências do próprio fornecedor devem respondê-las.
Nomeie um fornecedor candidato e o produto e a versão de implantação exatos em análise. Obtenha a documentação atual e as evidências que o fornecedor tem autorização para compartilhar. Dê acesso ao registro comparativo a quem analisa a segurança e ao responsável por compras. Mantenha arquivos sensíveis de arquitetura ou evidências em um local privado aprovado; a planilha pode conter links, sem copiar segredos.
1. Transforme o fluxo em requisitos
Liste cada ação proposta do agente, seu sistema de destino e os dados que precisa ler ou alterar. Separe leitura de escrita e de ações visíveis externamente ou irreversíveis. Para cada uma, copie o requisito relevante do perfil de risco escrito: identidade permitida, escopo de ferramenta e destino, aprovação, registro, tratamento de dados, interrupção e recuperação. Registre o responsável e a data do perfil.
Crie uma linha por requisito. Assim, o desconhecido fica visível em vez de enterrado em uma nota geral do fornecedor. A exigência de que o agente nunca acesse determinada conta precisa de uma linha tanto quanto uma ação permitida.
2. Rastreie quem age e o que pode ser executado
Pergunte qual pessoa, conta de serviço ou identidade de agente inicia cada ação, onde ficam as credenciais e se um agente pode passar uma solicitação a outro. Identifique o componente que verifica a permissão na execução. Compare as permissões reais de ferramentas do fornecedor com ferramentas, operações, contas e destinos permitidos pelo perfil. Solicite evidências de configuração ou arquitetura aplicáveis a esta versão; uma frase no prompt é uma evidência fraca de um limite imposto pelo sistema.
Para ações que exigem aprovação, pergunte o que a pessoa que revisa vê antes da execução e como a aprovação se vincula ao ator, à chamada exata da ferramenta, ao destino e aos parâmetros. Saiba o que acontece se ela expirar, for negada, usada duas vezes ou se a ação solicitada mudar. Registre como revogar o acesso e quem pode parar uma execução ativa. Uma tela de aprovação e uma verificação na execução respondem perguntas diferentes; peça evidências de ambas quando o perfil exigir ambas.
3. Acompanhe os dados e o registro da ação
Desenhe o caminho proposto da entrada até o modelo, ferramentas, destinatários externos, cópias armazenadas e registros. Pergunte quais dados cada componente recebe, quem pode recuperá-los e como funcionam retenção e exclusão. Inclua suboperadores ou transferências entre sistemas relevantes para o perfil. Marque uma pergunta sem resposta sobre destino ou retenção como desconhecida; não deduza proteção de privacidade de uma declaração ampla de política.
Solicite um registro de execução para a versão relevante. Quem analisa consegue ligar um ator e uma versão de política à chamada proposta da ferramenta, à aprovação ou recusa, ao destino exato e ao resultado? Confira se o registro mostra só uma decisão, uma execução real ou ambas. Uma captura de tela, uma exportação de configuração e uma trilha completa de eventos demonstram coisas diferentes. Anote ocultações que impeçam a comparação, mantendo credenciais e dados pessoais fora da planilha.
4. Solicite evidências de falhas
Peça evidências vinculadas à versão para uma ação permitida e os caminhos de falha exigidos pelo perfil: aprovação negada ou expirada, ferramenta ou destino fora do escopo, execução interrompida e, quando relevante, falha no registro ou na verificação de políticas. Registre o que foi testado, quando, sob quais políticas e ajustes de ferramenta, o resultado esperado e o observado. Um plano de teste é um pedido de evidência, não um resultado observado.
A pessoa responsável pela análise de segurança decide se é necessária uma demonstração supervisionada e autoriza seu escopo. Use entradas e contas permitidas fora de produção. Não conecte sistemas em operação só para preencher uma planilha de compras. Se o fornecedor não puder apresentar evidências, registre a lacuna e o próximo pedido, sem imaginar o resultado de um teste.
5. Registre a decisão e o trabalho pendente
Em cada linha, marque atende apenas quando as evidências apresentadas responderem ao requisito escrito para esta versão e fluxo. Marque lacuna quando houver conflito, ou desconhecido quando as evidências faltarem ou forem fracas demais. Anote registros conflitantes e quem deve resolvê-los. O responsável pelo negócio e a pessoa responsável pela segurança registram então a decisão real: pedir mais evidências, solicitar aprovação para um piloto restrito, adiar ou rejeitar. Uma entrada que atende é um julgamento das evidências, não garantia de segurança nem substituto do processo de compra da organização.
Mantenha o registro datado e reavalie as linhas afetadas quando mudarem o fluxo, a versão do produto, a política, as contas conectadas ou os destinos dos dados. Um piloto posterior precisa de autorização, limites e análise próprios.
Requisito do perfil escrito | Evidências do fornecedor, versão e data | Tipo de evidência e o que mostra | Atende, lacuna ou desconhecido | Responsável pela análise e próxima ação |
|---|---|---|---|---|
[Um requisito de ação ou controle] | [Link privado ou referência documental; versão; data] | [Alegação, configuração, registro de evento ou demonstração observada; limitação] | [Escolha uma opção e explique] | [Nome, pedido de evidência ou decisão] |
Cabeçalho do registro: fluxo e responsável; versão do perfil de risco e data de aprovação; produto candidato e versão de implantação; data da análise; responsável pela análise de segurança; responsável por compras; local das evidências restritas. Registro da decisão: decisão, linhas não resolvidas, limites aceitos ou controles compensatórios, responsável pela aprovação e gatilho da próxima análise. Deixe esses campos em branco até que as pessoas responsáveis realmente os analisem.
As orientações públicas usadas para formular essas perguntas estão disponíveis gratuitamente. Preparar a comparação exige tempo da equipe e dos responsáveis pela análise. Evidências do fornecedor, acesso confidencial e demonstrações autorizadas podem acrescentar custos ou limitar o que pode ser verificado; obtenha os termos reais com o candidato. Este exercício documental não testa um fornecedor nem estabelece conformidade jurídica ou um patamar universal de compra.
Fontes e leituras adicionais
- NIST AI RMF Playbook, Manage apoia aplicar a tolerância ao risco da própria organização aos recursos de IA de terceiros, documentar os controles e avaliá-los. A página informa que AI RMF 1.0 está sendo atualizado e o Playbook virá depois; não informa data de revisão da página. Não avalia este fornecedor.
- Introdução do NIST AI RMF Playbook descreve as sugestões como voluntárias e informa que o Playbook não é uma lista para seguir integralmente. A planilha aqui é uma síntese da BIG CHANGE para a tarefa indicada ao leitor.
- OWASP AI Agent Security Cheat Sheet trata de ferramentas com escopo limitado, autorização na execução, aprovações vinculadas a ações, registros, proteção de dados e evidências de validação vinculadas à versão. A página atual não informa versão nem data de publicação. São categorias de evidência, não prova de que um fornecedor as implementa.
