Revisão de acessos de agentes de IA: auditoria trimestral de permissões

Uma revisão de acessos de agentes de IA é uma verificação periódica que compara o que cada agente consegue alcançar (suas ferramentas, seus escopos de dados e seus aprovadores) com o que a função dele exige hoje. Faça a revisão a cada trimestre, registre cada decisão e remova qualquer permissão que a função já não justifique. O objetivo não é ter uma lista de permissões perfeita no primeiro dia, e sim criar um hábito repetível que identifique acessos concedidos para um piloto e nunca retirados.

Principais pontos

• Revise as ferramentas, os escopos de dados e os aprovadores de cada agente em relação ao trabalho atual, não à configuração que ele tinha no lançamento.
• Use o texto escrito da função como padrão. Tudo o que a função não precisa é candidato à remoção.
• Trate os aprovadores como parte do modelo de acesso. Um aprovador que saiu da empresa ou mudou de função é um controle quebrado.
• Mantenha um registro datado de cada decisão, para que a próxima revisão parta de evidências e não da memória.
• Revogue primeiro os acessos sem justificativa e discuta depois. Uma permissão mais restrita pode ser restaurada por meio de um pedido registrado, mas dados que já foram expostos não podem ser recolhidos.

Por que as permissões dos agentes se desviam

Agentes costumam ser conectados com pressa. Um piloto precisa de leitura pasta compartilhada, uma integração precisa de um token de escrita no sistema de clientes, e um aprovador é indicado porque alguém estava disponível naquela semana. Ninguém decide manter essas concessões. Elas simplesmente continuam depois que o projeto muda de forma, que a equipe ao redor do agente muda e que o motivo original se perde.

Guias de autorização, como a OWASP Authorization Cheat Sheet, tratam o acesso como uma decisão que precisa ser aplicada e revisitada ao longo do tempo, e não como uma configuração feita uma vez e esquecida. No caso dos agentes, o desvio é mais rápido do que em contas comuns de software, porque um agente pode atuar em vários sistemas ao mesmo tempo e seu escopo costuma crescer por conveniência: mais uma pasta, mais um canal, mais uma ferramenta que foi útil durante os testes.

O que inspecionar em cada agente

A revisão de acessos cobre três camadas. Cada camada exige uma pergunta diferente.

• Ferramentas: toda ação que o agente pode executar, incluindo leituras, escritas, envios, exclusões e qualquer coisa que toque em dinheiro ou em registros de clientes. A pergunta é se a função realiza cada ação.
• Escopos de dados: as pastas, tabelas, caixas de e-mail, canais e memórias que o agente pode ler ou escrever. A pergunta é se a tarefa usa esses dados ou apenas os tem por perto.
• Aprovadores: as pessoas que precisam confirmar ações específicas. A pergunta é se cada aprovador ainda ocupa o cargo, pode ser contatado e recebe contexto suficiente para decidir.

A memória merece um item próprio na revisão. Se um agente guarda anotações sobre clientes, funcionários ou decisões anteriores, esse armazenamento é um escopo de dados como qualquer banco de dados. O conteúdo deve corresponder à função, e o prazo de retenção deve estar documentado.

Auditoria trimestral em seis etapas

O método abaixo trata um agente por vez. Para um número pequeno de agentes, um responsável e um revisor de operações conseguem concluí-lo em uma sessão focada. Conjuntos maiores se beneficiam de uma lista de verificação compartilhada e de um calendário único de revisões.

• Inventário: liste todos os agentes ativos, o responsável de negócio de cada um, o texto escrito da sua função e a data da última revisão.
• Exportação: extraia as concessões atuais diretamente dos sistemas, incluindo permissões de ferramentas, escopos de pastas e tabelas, tokens de integração e atribuições de aprovadores. Não confie apenas nas anotações de configuração.
• Comparação: confronte cada concessão com o texto da função e classifique-a como necessária, indefinida ou não utilizada.
• Leitura dos logs: no período revisado, verifique quais ferramentas foram chamadas, com que frequência, e quais pedidos de aprovação foram enviados e respondidos. Os logs são a evidência que separa uma concessão usada de uma que apenas existe.
• Revogação e restrição: remova primeiro as concessões não utilizadas e as sem justificativa, depois reduza os escopos restantes ao menor conjunto que ainda completa a tarefa.
• Registro e teste: anote cada decisão, o revisor e a próxima data de revisão. Execute uma tarefa de teste para confirmar que o agente continua funcionando dentro dos novos limites.

A etapa de logs depende de instrumentação. A introdução do OpenTelemetry sobre observabilidade explica como traços, métricas e logs permitem reconstruir o que um sistema fez e por quê. Uma revisão de acessos usa o mesmo tipo de evidência: qual ação aconteceu, por meio de qual ferramenta, sob a aprovação de quem.

Como decidir o que a função ainda precisa

A maior parte das divergências em uma revisão surge de concessões que parecem inofensivas. Um guia de decisão simples ajuda o responsável e o revisor a chegarem à mesma resposta.

• Se a ação está nomeada no texto da função e aparece nos logs, mantenha-a e registre com que frequência ela é usada.
• Se a ação está nomeada no texto da função, mas não aparece nos logs, pergunte ao responsável se a tarefa ainda existe antes de remover. A remoção pode esperar um ciclo se a tarefa for sazonal ou rara, mas a pergunta precisa ser registrada.
• Se a ação não está no texto da função, remova-a, mesmo que possa ser útil no futuro. Necessidades futuras passam por um novo pedido.
• Se a ação escreve, envia ou exclui algo, confirme que o aprovador nomeado está atualizado, pode ser contatado e tem contexto para decidir.
• Se ninguém consegue explicar uma concessão, trate-a como um incidente a investigar, e não como um detalhe de configuração a arrumar depois.

A mesma lógica sustenta a confiança em etapas. Autoridade mais ampla só deve ser concedida quando a versão mais restrita já tiver um histórico comprovado. O artigo sobre autorização de agentes de IA por níveis de permissão descreve como subir um agente um nível por vez, o que combina bem com uma revisão trimestral que também pode rebaixá-lo.

Aprovadores fazem parte do modelo de acesso

Uma etapa de aprovação que é sempre concedida em segundos não é um controle. Na revisão, observe como as aprovações realmente acontecem. Quem responde aos pedidos, quanto tempo leva, se alguma vez recusa e se o aprovador vê a ação proposta com detalhes suficientes para julgá-la. Um aprovador que confirma todos os pedidos sem olhar é, na prática, uma concessão com uma etapa a mais.

Para cada ação que exige aprovação, a revisão deve nomear um aprovador principal e um substituto, e ambos devem ser pessoas que tenham autoridade para aquela decisão hoje. Quando alguém deixa a função, suas aprovações devem migrar junto com a responsabilidade, e não continuar vinculadas a uma conta antiga. Como definir o ponto em que um agente deve parar e perguntar é tratado com mais profundidade em aprovação humana em fluxos de IA.

Uma revisão ilustrativa de um agente de atendimento

Cenário ilustrativo, não um caso de cliente: um agente de atendimento redige respostas para e-mails de clientes e pode ler uma pasta compartilhada com pedidos recentes. O texto da função diz que ele prepara rascunhos para uma pessoa enviar e propõe reembolsos para um gerente aprovar.

Durante a revisão, a equipe encontra três problemas. O agente pode enviar respostas diretamente, o que a função não exige. Ele pode ler o arquivo completo de pedidos, enquanto a tarefa de redação só precisa dos últimos meses. E o aprovador de reembolsos é um gerente que mudou de departamento meses antes, de modo que os pedidos de reembolso estavam esperando por alguém sem o contexto necessário para decidir.

A equipe remove o envio direto e mantém a redação de rascunhos. Restringe o acesso à pasta à janela recente, transfere a aprovação de reembolsos para o gerente atual com um substituto nomeado e registra a decisão no registro. Uma execução de teste confirma que os rascunhos ainda chegam à fila de envio e que as propostas de reembolso chegam à pessoa certa. A revisão do trimestre seguinte verifica se a janela mais estreita chegou a bloquear alguma tarefa legítima.

Como a Be Human trata revisões de acesso em operações gerenciadas

A Be Human desenha a função, a memória, as ferramentas, as permissões e os limites de aprovação de cada agente durante o primeiro projeto, para que a revisão tenha uma linha de base escrita para comparar. A operação gerenciada pode incluir revisão recorrente de permissões como parte do serviço, com mudanças feitas por meio de melhorias controladas, registradas e testadas antes de entrar em produção. Se uma revisão encontrar uma concessão que ninguém consegue explicar, o mesmo processo usado na resposta a incidentes se aplica, e o responsável de negócio é chamado a decidir. O objetivo é que o acesso sempre reflita uma função atual e que cada mudança deixe um rastro que alguém consiga ler depois.

Mantendo a revisão útil depois do primeiro trimestre

O ciclo trimestral é um padrão sensato, mas não é o único gatilho. Faça uma revisão extra sempre que um agente receber uma nova ferramenta, uma nova fonte de dados, um novo canal ou um novo aprovador, e sempre que uma pessoa que era responsável ou aprovadora de um agente deixar a empresa. Um incidente também justifica a revisão de todas as concessões que o agente afetado possui, e não apenas daquela envolvida.

O NIST AI Risk Management Framework trata isso como governança contínua: mapear o contexto, medir o risco, responder e atribuir responsabilidades. Os achados de acesso devem estar no mesmo registro dos demais riscos de IA, com responsável, status e data. A abordagem descrita em modelo de registro de riscos de IA funciona bem para esse fim. Ao longo de vários ciclos, a revisão deve ficar mais curta, porque a linha de base se torna precisa e as mudanças passam a ser menores.

Se você não tem certeza de qual agente ou tarefa deve ser revisado primeiro, faça o diagnóstico gratuito de IA da Be Human para encontrar a primeira tarefa que vale a pena entregar a um agente.

Perguntas frequentes

Quanto tempo leva a primeira revisão de acessos de um agente de IA? O tempo depende de quantos agentes existem e de quão bem seus logs são mantidos. Para um único agente, com um responsável e logs utilizáveis, uma sessão de trabalho focada costuma bastar para concluir as seis etapas e registrar as decisões. Conjuntos com muitos agentes devem planejar o primeiro ciclo como um projeto, com lista de verificação compartilhada.

Quem deve conduzir a revisão? O responsável de negócio de cada agente deve decidir o que a função precisa, porque conhece o trabalho. Um revisor de operações ou de segurança deve conferir as concessões com os sistemas e com os logs. O agente nunca deve aprovar mudanças nas próprias permissões, e ninguém deve ser a única pessoa capaz de pedir e aprovar a mesma concessão.

Devemos remover uma permissão que o agente pode precisar no futuro? Se a função não precisa dela hoje e os logs não mostram uso recente, remova-a e registre o motivo. Restaurar uma permissão mais restrita por meio de um pedido documentado é algo normal e leva pouco tempo. Manter acessos não usados por conveniência deixa a empresa exposta sem nenhum benefício correspondente.

E se nossos sistemas não guardam logs das chamadas de ferramentas e das aprovações? Nesse caso, a primeira ação é ativar o registro de chamadas de ferramentas, de acesso a dados e de decisões de aprovação antes da próxima revisão. Sem logs, a revisão consegue comparar as concessões com a função escrita, mas não consegue mostrar o que o agente realmente fez. Os logs devem ser mantidos por um período compatível com as exigências de auditoria e com as obrigações de privacidade da sua empresa.

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