Revisão de permissões de agentes de IA: passos e evidências

A revisão de permissões de agentes de IA é uma checagem curta e repetível de três pontos para cada agente: o que ele consegue acessar hoje, quem aprovou cada permissão e que evidência mostra que a permissão ainda é necessária. O que não tem dono atual, motivo registrado ou uso recente é reduzido ou removido, e o resultado fica por escrito. Feita em calendário fixo, a revisão leva horas, não dias, e impede que os agentes acumulem acessos que ninguém lembra de ter concedido.

Principais pontos

• Revise um agente por vez, conexão por conexão, e compare com o trimestre anterior em vez de começar do zero.
• Toda permissão precisa de um aprovador identificado, um motivo declarado e a data da última confirmação.
• Evidência vale mais que memória: use exportações de configuração, registros de aprovação e logs de uso, não lembranças.
• Comece pela remoção. Se ninguém consegue justificar uma permissão, retire e deixe o responsável pedir de volta.
• Feche o ciclo: registre as decisões, verifique se as remoções realmente funcionaram e defina a data da próxima revisão.

Por que agentes de IA precisam de uma revisão de permissões?

Agentes acumulam acesso como uma gaveta compartilhada acumula cabos. Alguém conecta uma caixa de e-mail para testar um rascunho, uma pasta compartilhada para uma tarefa pontual, um token de sistema de clientes numa semana corrida. O trabalho sai, a conexão fica e ninguém anota o motivo.

Quando uma pessoa muda de função, o RH ou a TI costuma disparar uma mudança de acesso. Com o agente não existe esse momento. A função dele pode continuar a mesma no papel enquanto o alcance cresce, e ele nunca vai reclamar de um acesso que não usa. É nessa lacuna que mora o risco desnecessário: um agente capaz de enviar, editar ou apagar coisas que nunca deveria tocar. O OWASP Top 10 for LLM Applications cita a autonomia excessiva (excessive agency) como categoria de risco, e as orientações de autorização do OWASP recomendam o menor privilégio e a negação de acesso por padrão. A revisão trimestral é o hábito prático que mantém esses princípios valendo depois do primeiro mês.

A revisão não é uma auditoria por si só. Ela responde a uma pergunta de negócio: se este agente errasse, ou fosse manipulado por uma mensagem maliciosa, quanto estrago poderia causar? Alcance menor significa consequências menores, e um registro claro significa decisões mais rápidas quando algo dá errado.

O que você precisa ter em mãos antes de começar?

Revisões dão errado quando a primeira hora é gasta procurando informação. Prepare um pacote para cada agente antes da reunião:

• Uma ficha no registro de agentes: a função que o agente exerce, o dono de negócio, o operador técnico e a data da última revisão.
• Uma lista de conexões: cada sistema, canal e ferramenta que o agente alcança, com o nível de acesso de cada um (leitura, rascunho, escrita, envio, exclusão).
• Credenciais e concessões: tokens, contas de serviço e autorizações OAuth, com seus escopos e datas de expiração.
• Fontes de conhecimento e memória: quais repositórios de documentos, pastas ou bancos de dados o agente pode consultar.
• Registros de aprovação: o chamado, a mensagem ou a solicitação de mudança que concedeu cada permissão.
• Logs de uso do trimestre: quais permissões o agente de fato exerceu e quando foi a última vez.

Uma observação sobre OAuth, já que muitas conexões de agentes dependem dele. A concessão é definida por escopos, e a documentação de OAuth 2.0 do Google descreve os escopos como a forma de um aplicativo pedir acesso limitado aos dados de um usuário. O que importa na revisão é a lista de escopos como ela existe hoje no provedor, não a que você lembra ter escolhido na configuração inicial.

Se esta for a primeira revisão, comece pelo levantamento de contas e credenciais (veja de quem devem ser as contas e chaves de API do agente de IA). Este artigo trata do ritmo trimestral que vem depois.

Quais são os passos da revisão trimestral de acessos de um agente de IA?

Use a mesma sequência a cada trimestre para que os resultados sejam comparáveis. Analise um agente por vez, com o dono de negócio presente.

• Passo um, retrato: exporte a lista atual de permissões antes de mudar qualquer coisa, para ter um registro fixo do que existia no dia da revisão.
• Passo dois, comparação: coloque o retrato ao lado do trimestre anterior. Marque cada acréscimo, cada mudança de nível de acesso e cada item sem registro de aprovação correspondente.
• Passo três, teste contra o uso: para cada permissão, consulte os logs. Ela foi usada neste trimestre? A função do agente ainda a exige? Registre explicitamente as necessidades sazonais, como um processo de fim de ano.
• Passo quatro, confirmação do aprovador: o responsável indicado declara manter, reduzir ou remover. Se o aprovador saiu ou mudou de função, defina um responsável atual antes de decidir.
• Passo cinco, aplicar e verificar: faça a mudança e confira se o agente não consegue mais executar a ação removida e se o trabalho principal dele continua funcionando.
• Passo seis, registrar e agendar: arquive o pacote de evidências, liste as exceções com data de expiração e defina a data da próxima revisão.

Mantenha o grupo pequeno, mas sem autoavaliação. O dono de negócio da função do agente decide, o operador técnico prepara as evidências e aplica as mudanças, e alguém de TI ou segurança participa quando o agente toca sistemas compartilhados. Se só os operadores comparecem, a revisão vira alguém conferindo o próprio trabalho. Para um agente permanente, um patrocinador que leia o resumo de uma página depois costuma ser supervisão suficiente.

Que evidências guardar para cada permissão?

A evidência permite que um colega novo, uma seguradora ou um auditor entenda uma decisão sem precisar que alguém se lembre dela. Para cada permissão, guarde cinco itens:

• Prova de configuração: uma exportação ou leitura da permissão como ela existe no sistema conectado, incluindo os nomes de escopo ou perfil.
• Registro de aprovação: a referência à solicitação ou ao chamado, o nome do aprovador e a data.
• Motivo declarado: uma frase ligando a permissão a uma tarefa da função do agente.
• Prova de uso: o registro de log mais recente mostrando que a permissão foi exercida, ou uma nota de que não houve uso.
• Teste negativo: para tudo que foi removido ou reduzido, um registro de que a tentativa de executar a ação bloqueada falhou.

Duas regras práticas ajudam. Guarde a evidência onde o próximo revisor vai encontrá-la, não numa caixa de e-mail pessoal. E escreva as aprovações como decisões datadas, porque um aval verbal não pode ser conferido três meses depois. Quando a permissão foi concedida por uma solicitação de mudança documentada, boa parte dessa evidência já existe, e a revisão só confirma que ela continua verdadeira.

Os logs merecem uma palavra. Eles só sustentam a revisão se registrarem as ações do agente com detalhe suficiente para saber qual conexão foi usada, e se forem mantidos pelo menos pelo tempo do ciclo de revisão. Confira a retenção antes da reunião, não durante ela.

Como decidir o que remover, reduzir ou manter?

Decida com as mesmas regras todas as vezes, para que a revisão não vire negociação. Use este guia:

• Remover quando ninguém consegue dizer o motivo, quando o aprovador saiu e ninguém assumiu a permissão, ou quando não houve uso no trimestre nem necessidade sazonal conhecida.
• Reduzir quando o agente usa só parte do acesso: leitura em vez de escrita, uma pasta em vez do drive inteiro, um canal em vez de todos.
• Limitar no tempo quando o acesso atende a um projeto, um teste ou um terceiro, definindo uma data de expiração.
• Escalar quando a permissão deixa o agente executar uma ação irreversível, como enviar mensagens externas, apagar registros ou movimentar dinheiro, sem uma etapa de aprovação humana. Inclua o limite de aprovação antes de manter.
• Manter quando motivo, aprovador, uso e teste conferem. Registre a data da confirmação para que a próxima revisão tenha um ponto de partida.

Remover é barato de reverter. Se alguém precisar do acesso de volta, pede, declara o motivo e obtém nova aprovação. Deixar um acesso sem justificativa não tem rede de segurança equivalente. Para ações que afetam pessoas de fora da empresa ou alteram registros, confirme na mesma reunião quem supervisiona o agente e o que o dono de negócio deve controlar, para que os limites de aprovação correspondam às permissões que permanecerem.

Como uma revisão funciona na prática?

Cenário ilustrativo: uma empresa de serviços usa um agente que redige respostas a e-mails de clientes. Na revisão trimestral, o registro mostra quatro conexões: uma caixa de suporte compartilhada (leitura e rascunho), o sistema de pedidos (leitura), uma pasta do financeiro (leitura) e a agenda da equipe (escrita).

A comparação com o trimestre anterior mostra que a pasta do financeiro não tem registro de aprovação. O operador explica que ela foi conectada na configuração inicial para testar uma pergunta sobre faturas. Os logs mostram que o agente nunca recuperou nada dela. A escrita na agenda foi aprovada para um projeto de agendamento que já terminou, e os logs não mostram atividade na agenda desde então.

O dono de negócio decide: remover a pasta do financeiro, remover a escrita na agenda e manter a caixa de e-mail e o sistema de pedidos como estão. O operador aplica as mudanças e depois faz ao agente uma pergunta que exigiria um documento financeiro, confirmando que ele não consegue recuperar nenhum. O pacote de evidências registra o retrato, as duas remoções, o teste negativo e a data da próxima revisão. Tudo cabe numa reunião curta porque a preparação foi feita antes.

Como a Be Human trata isso na operação gerenciada?

A Be Human mantém um registro de cada agente que opera: identidade, canais, ferramentas, permissões e limites de aprovação. A revisão de permissões faz parte do trabalho recorrente da operação gerenciada. O operador prepara o retrato, a comparação com o trimestre anterior e as evidências de uso, e o dono de negócio do cliente decide entre manter, reduzir ou remover. As mudanças seguem um caminho de aprovação, as remoções são verificadas e o registro fica com o cliente, para que o controle permaneça com as pessoas responsáveis pelo agente.

Perguntas frequentes

Com que frequência revisar os acessos de agentes de IA? A cada trimestre é uma base sensata para agentes em uso regular. Revise também quando algo mudar: sai uma pessoa com poder de aprovação, uma nova ferramenta é conectada, a função do agente se amplia ou ocorre um incidente. Uma checagem curta disparada por esses eventos entre os trimestres evita que a revisão do calendário vire um acúmulo de pendências.

Quem deve aprovar as permissões de um agente? O dono de negócio da função que o agente exerce, porque ele entende o que o trabalho exige e quanto custaria um erro. O operador técnico confirma o que é viável e aplica a mudança, mas não deve ser o único aprovador. Quando o agente toca sistemas compartilhados, o responsável por esses sistemas também deve concordar.

E se ninguém souber quem aprovou uma permissão? Trate como não aprovada. Reduza ou remova, e peça uma nova aprovação pelo processo normal de mudança, com motivo declarado e data. Registre a lacuna no pacote de evidências, já que aprovações ausentes costumam apontar uma fraqueza de processo a corrigir, como conexões feitas de modo informal durante a configuração.

A revisão precisa cobrir também provedores de modelos e fluxos de dados? Sim, em um nível mais leve. Anote quais provedores recebem o contexto do agente, quais configurações de retenção se aplicam e se algo mudou desde o último trimestre. Referenciais como o NIST AI Risk Management Framework enfatizam responsabilização e governança documentadas, e um registro de revisão datado é uma forma simples de demonstrar isso nas decisões de acesso.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.