Revisão de permissões de agentes de IA: passo a passo

A revisão de permissões de agentes de IA é uma checagem recorrente do que cada agente pode ler, redigir e enviar, comparado com o que a função dele realmente exige. Você lista todos os acessos, descobre quais foram usados, remove o restante e registra quem aprovou o que ficou. Feita em ritmo constante, ela impede o crescimento silencioso de acessos antes que vire um risco para o negócio.

Principais pontos

• Revise três verbos separadamente para cada agente: ler, redigir e enviar. Eles carregam riscos diferentes e pedem aprovações diferentes.
• Parta da descrição da função do agente, não do que as ferramentas dele por acaso permitem. Acesso que a função não consegue justificar é candidato à remoção.
• Use evidência de atividade. O acesso que nunca foi exercido no período da revisão é o mais fácil de remover com segurança.
• Dê a cada permissão um responsável humano nomeado e uma data para a próxima revisão.
• Remova acessos de forma reversível, teste as tarefas normais do agente depois e guarde um registro escrito curto para a revisão seguinte.

Por que os agentes de IA acumulam acessos com o tempo?

Agentes raramente começam com acesso demais. Eles o ganham. Um piloto precisa de uma caixa de e-mail compartilhada, então ela é conectada. Alguém adiciona um link de agenda para uma demonstração. Um token de teste criado na configuração nunca é revogado. Cada decisão é razoável no dia em que é tomada, e a soma é um agente que alcança muito mais do que o trabalho dele exige.

As permissões também sobrevivem ao contexto que as justificou. A pessoa que aprovou uma conexão muda de função. Uma ferramenta altera o que seus escopos permitem. Uma pasta que era organizada passa a guardar contratos e anotações de folha de pagamento. Ninguém errou, mas o alcance do agente já não corresponde à imagem que as pessoas têm dele.

O OWASP Top 10 para aplicações com LLMs chama esse padrão de agência excessiva: um agente com mais funcionalidades, permissões ou autonomia do que a tarefa precisa. A revisão de permissões é a contramedida de rotina. Ela também fica bem mais simples quando o agente tem identidade própria, porque o acesso dele vira uma lista que você consegue ler, e não o login emprestado de uma pessoa. Tratamos essa base em por que o agente de IA da empresa precisa de identidade e contas próprias.

O que significam ler, redigir e enviar na prática?

Trate essas três ações como perguntas separadas para cada agente. Um único sim ou não para o agente inteiro esconde as decisões que importam.

• Ler: quais caixas de e-mail, unidades, pastas, objetos do CRM, canais e fontes de conhecimento o agente enxerga? Ele poderia ver registros de clientes ou colegas fora da função dele? Ele recebeu o sistema inteiro quando precisava de uma pasta?
• Redigir: o que ele consegue preparar sem que nada saia da empresa nem altere um sistema de registro? Exemplos são uma resposta salva na pasta de rascunhos, uma nota proposta no CRM ou um documento em área de preparação. Atenção: uma permissão de redigir que consegue editar documentos compartilhados está mais perto de enviar do que parece.
• Enviar: o que ele consegue fazer que sai da empresa ou muda um estado? Enviar um e-mail, publicar em um canal, atualizar um registro, criar uma reunião com convidados externos ou disparar uma etapa de pagamento pertencem a esta categoria.

Dois pontos de referência ajudam na checagem técnica. A documentação de OAuth 2.0 do Google explica os escopos como o mecanismo para solicitar acesso limitado, então compare cada escopo concedido com o mais restrito que ainda sustenta a tarefa. O Authorization Cheat Sheet do OWASP recomenda privilégio mínimo e negação por padrão, que é a postura que uma revisão deve reforçar: o acesso não existe até que uma tarefa o justifique.

Uma combinação merece atenção extra. Um agente que lê conteúdo não confiável, como e-mails recebidos ou páginas da web, e que também pode enviar fica exposto a instruções escondidas nesse conteúdo. Separar essas capacidades, ou colocar uma aprovação humana entre elas, elimina boa parte dessa exposição.

Como executar a revisão, passo a passo?

Este plano serve para um agente ou para vários. Mantenha-o como checklist permanente e repita a cada ciclo.

• Passo 1, confirme a função e o responsável. Reúna a descrição de uma página da função do agente e o nome da pessoa responsável por ele. Se nenhum dos dois existir, escreva-os antes de revisar qualquer outra coisa. Os exemplos de funções para agentes de IA em empresas ajudam a montar esse parâmetro.
• Passo 2, faça o inventário de todos os acessos. Liste contas, chaves de API, concessões OAuth, participações em caixas compartilhadas, pastas compartilhadas, participações em canais, conexões com ferramentas, webhooks e tarefas agendadas. Inclua memórias e fontes de conhecimento, pois elas também são coisas que o agente lê.
• Passo 3, classifique cada item. Marque como ler, redigir ou enviar, anote quais dados ele cobre e se a credencial pertence à empresa ou a uma pessoa.
• Passo 4, reúna evidência de atividade. Consulte os logs para ver o que foi de fato usado no período da revisão e quando foi o último uso. Acesso sem rastro de uso forma a sua primeira lista de remoção.
• Passo 5, compare com a função. Ao lado de cada acesso, escreva a tarefa que ele sustenta. Se não conseguir nomear uma, marque para remoção.
• Passo 6, reduza ou remova. Diminua o escopo antes de apagar quando houver dúvida. Converta o envio em rascunho com aprovação humana onde o custo de um erro for alto.
• Passo 7, teste, registre e agende. Execute as tarefas padrão do agente, confirme que nada quebrou, anote o que mudou e quem aprovou, e defina a data da próxima revisão.

Quem faz o quê neste plano deve ser combinado antes. Um modelo de responsabilidade compartilhada em agentes de IA deixa claro quem cuida do inventário, quem aprova as remoções e quem precisa ser avisado.

Como decidir qual acesso remover?

Use um guia de decisão simples para que as revisões sejam consistentes e não dependam de quem estiver mais cauteloso no dia.

• Nenhuma tarefa da descrição da função usa o acesso: remova.
• Não foi usado no período, mas uma tarefa depende de um evento raro, como fechamento do mês ou auditoria: mantenha, marque como raro e dê a ele uma data de revisão mais curta.
• É usado, mas é mais amplo do que a tarefa exige, por exemplo uma unidade inteira quando uma pasta basta: reduza.
• Permite enviar a clientes, parceiros ou órgãos reguladores, ou toca em dinheiro ou compromissos jurídicos: exija aprovação humana antes do envio ou converta em rascunho.
• Roda com uma credencial ligada a uma pessoa que saiu ou mudou de função: substitua pela credencial própria do agente e depois revogue a antiga.
• Ninguém sabe dizer quem concedeu nem por quê: suspenda, observe se surgem reclamações e remova se nenhuma aparecer.

A remoção deve ser reversível. Registre a configuração anterior, faça as mudanças em um período calmo e avise as pessoas que trabalham com o agente sobre o que vai mudar. Vale a mesma disciplina de qualquer atualização em produção: planejar, testar e ter como voltar atrás. Se uma tarefa falhar depois, restaure o acesso, documente por que ele é necessário e anexe esse motivo à permissão, para que o próximo revisor não repita a pergunta.

Como é uma revisão na prática? Um cenário ilustrativo

Este cenário é ilustrativo, não um caso real. Uma distribuidora tem um agente que prepara respostas a dúvidas de compras vindas de fornecedores e de colegas internos. A descrição da função diz que ele redige respostas e propõe anotações para a equipe de compras.

O inventário mostra acesso de leitura a todo o drive compartilhado, acesso de leitura à caixa de compras e a uma caixa de vendas, permissão para enviar a partir de um endereço compartilhado, acesso de escrita para anotações no ERP e um token de teste antigo de uma ferramenta de planilhas. Os logs de atividade mostram que a caixa de vendas nunca foi aberta, que o drive foi usado apenas para uma pasta de tabelas de preços e que as respostas externas sempre eram editadas por uma pessoa antes do envio. O token de teste nunca foi usado depois da configuração.

O resultado é rápido. A conexão com a caixa de vendas é removida. O acesso ao drive é reduzido à pasta de tabelas de preços. O token de teste é revogado. As respostas internas continuam com envio direto, enquanto as externas passam a ser rascunho com aprovação, o que corresponde ao jeito como a equipe já trabalha. A permissão de anotação no ERP permanece, porque a descrição da função a cita. A revisão termina com um registro escrito curto e uma data para a próxima.

Com que frequência revisar e quem aprova?

Um ritmo regular no calendário é o ponto de partida. Trimestral é um começo sensato para a maioria das empresas, e a frequência ideal aumenta conforme o alcance do agente. Um agente que apenas lê uma base de conhecimento pode ser revisado com menos frequência do que um que envia mensagens a clientes. Para encaixar a revisão de permissões na rotina maior, veja também a revisão trimestral de IA na empresa.

Acrescente gatilhos por evento além do calendário. Antecipe a revisão quando ocorrer qualquer um destes casos:

• Uma nova ferramenta, canal ou fonte de dados é conectada.
• A função do agente muda ou se amplia.
• Uma pessoa com direitos administrativos sai ou muda de cargo.
• Acontece um incidente ou quase incidente.
• O modelo ou o fornecedor por trás do agente muda.

A aprovação precisa de duas perspectivas. Um responsável de negócio confirma que o acesso restante corresponde ao trabalho. Um revisor técnico confirma que a configuração real corresponde ao que foi relatado. Quem construiu ou opera o agente não deve ser o único aprovador do próprio acesso. Se você está montando a estrutura de supervisão mais ampla, o modelo operacional de IA para empresas descreve uma forma leve de começar. Para uma visão de framework de gestão de riscos, o NIST AI Risk Management Framework é uma boa referência.

Como a Be Human conduz a revisão de permissões?

A Be Human define os limites de aprovação no início do projeto: para cada função de agente, o que ele pode ler, redigir e enviar, e quais ações exigem aprovação de uma pessoa. O agente roda com identidade e contas próprias, sob controle da empresa. Dentro da operação gerenciada, a Be Human faz revisões recorrentes de permissões junto com o monitoramento e a manutenção das integrações, entrega uma lista escrita de mudanças propostas e só aplica remoções depois que o responsável da empresa aprova. O que esperar dessa rotina ao longo do tempo está em primeiros meses com um agente de IA gerenciado.

Perguntas frequentes

Com que frequência devemos revisar as permissões dos agentes de IA? Comece com um ritmo fixo no calendário, como a cada trimestre, e adicione uma revisão sempre que uma nova ferramenta for conectada, uma função mudar ou houver um incidente. Agentes que enviam mensagens para fora merecem um intervalo menor do que agentes que apenas leem uma fonte restrita.

Quem deve ser o dono da revisão? Um responsável de negócio que entenda o trabalho do agente deve responder por ela, com um revisor técnico verificando a configuração real. Evite que a mesma pessoa que constrói ou opera o agente seja a única aprovadora do acesso dele.

Um agente deve ter acesso para enviar? Sim, quando a tarefa exige e o custo de um erro é baixo ou uma pessoa aprova antes da liberação. Muitas equipes permitem envio direto para mensagens internas e exigem aprovação para tudo que vai a clientes, parceiros ou autoridades. Reveja essa linha a cada revisão, conforme a confiança e as evidências se acumulam.

E se remover um acesso quebrar alguma coisa? Faça remoções reversíveis, guarde a configuração anterior e teste as tarefas padrão do agente logo depois da mudança. Se algo falhar, restaure o acesso, anote qual tarefa depende dele e anexe essa nota à permissão, para que o motivo fique claro da próxima vez.

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