Por que o agente de IA da empresa precisa de identidade e contas próprias

Um agente de IA precisa de identidade própria porque cada ação dele deve poder ser rastreada até o agente, limitada ao que o papel exige e removida sem mexer na conta de uma pessoa. Na prática, isso significa uma conta dedicada ou identidade de serviço para cada agente, com permissões delimitadas, credenciais próprias, um responsável humano nomeado e um registro do que ele fez. Usar o login de um funcionário é mais rápido no primeiro dia, mas esconde quem agiu, concede mais acesso do que a tarefa pede e quebra quando essa pessoa muda de função ou sai da empresa.

Principais pontos

• Dê a cada agente uma identidade dedicada, separada de qualquer funcionário, para que cada ação seja atribuída ao agente e ao responsável humano por ele.
• Delimite o acesso ao papel. Comece com leitura, depois acrescente a criação de rascunhos, e permita enviar ou gravar apenas onde existir um limite de aprovação.
• Guarde as credenciais em um cofre de segredos gerenciado, troque-as periodicamente e nomeie um responsável humano e um substituto para cada identidade de agente.
• Registre qual identidade fez o quê, a pedido de quem e com qual aprovação, para que revisões e investigações se apoiem em evidência.
• Planeje a revogação. Você deve conseguir desligar um agente sem tocar na conta de uma pessoa nem em outro agente.

O que significa um agente de IA ter identidade própria?

Identidade é a resposta à pergunta que todo sistema faz antes de qualquer coisa: quem está pedindo? Quando uma pessoa abre o CRM, o CRM enxerga um usuário com um perfil de acesso. Quando um agente atualiza esse mesmo CRM, o sistema deve enxergar uma conta que pertence ao agente, com um perfil desenhado para o trabalho dele.

Uma identidade dedicada costuma ter cinco partes. Primeiro, um nome que torne o agente reconhecível nos registros e nas caixas de entrada de outras pessoas. Segundo, credenciais que pertencem só a ele. Terceiro, permissões em cada ferramenta que ele toca, definidas para o papel e nada além. Quarto, uma pessoa nomeada que responde por ele. Quinto, um ciclo de vida: criação, revisão periódica, troca de credenciais e desativação.

A forma varia conforme a ferramenta. Alguns produtos oferecem contas de serviço ou credenciais de aplicação. Outros só entendem licenças de usuário, então o agente recebe uma licença própria, identificada claramente como agente. Alguns permitem acesso delegado via OAuth, em que o agente age em nome de uma pessoa específica, com consentimento limitado a escopos nomeados. Os três caminhos são legítimos, e todos são diferentes de digitar a senha de um funcionário em um sistema e torcer para ninguém perceber.

Por que usar o login de um funcionário é um problema?

Parece inofensivo porque funciona na hora. Os custos aparecem depois, e costumam aparecer juntos.

• A atribuição desaparece. O registro diz que o funcionário enviou a mensagem ou alterou o cadastro, e ninguém sabe se foi a pessoa ou o agente. Quando algo dá errado, a primeira hora é gasta para descobrir quem agiu.
• O acesso é amplo demais. A conta de um funcionário reflete tudo o que aquela pessoa pode precisar no trabalho, não o que uma tarefa do agente exige. O agente herda tudo isso, inclusive sistemas que nunca deveria ver.
• O agente herda a vida da pessoa. Troca de senha, pedidos de autenticação em dois fatores, mudança de cargo, afastamento ou desligamento afetam o agente. Ou ele para de funcionar em hora ruim, ou continua funcionando com um acesso que deveria ter sido removido.
• Os controles de segurança são enfraquecidos. Para tornar um login utilizável por software, as equipes costumam dispensá-lo de verificações que protegem contas humanas, como o segundo fator. Essa exceção passa a morar em uma conta poderosa.
• A resposta a incidentes fica mais difícil. Para parar o agente, é preciso bloquear uma pessoa. Para manter a pessoa trabalhando, é preciso deixar o agente rodando.
• As revisões de acesso perdem o sentido. Uma revisão que não separa a atividade humana da atividade do agente não consegue responder se o acesso ainda é adequado.

O ponto em comum é que um login compartilhado apaga uma distinção que você vai acabar precisando: o que uma pessoa decidiu versus o que um agente fez em nome dela. Referências de autorização, como o OWASP Authorization Cheat Sheet, tratam permissões claras e aplicadas por cada entidade como o mínimo esperado. Um agente também é uma entidade.

Como deve ser a identidade dedicada do agente em cada ferramenta?

A forma certa depende do que cada ferramenta suporta. Use este guia de decisão, ferramenta por ferramenta.

• Use uma conta de serviço ou credencial de aplicação quando a ferramenta oferecer e o agente trabalhar em horários programados ou em resposta a eventos, como ler uma pasta compartilhada ou publicar em uma fila de chamados.
• Use OAuth delegado com escopos estreitos quando o agente precisar agir por uma pessoa específica, por exemplo preparando um rascunho na agenda dela, e ela puder ver e revogar o consentimento a qualquer momento.
• Use uma licença de usuário dedicada, nomeada como agente, quando a ferramenta não tiver o conceito de conta de serviço. Trate-a como conta de serviço: nada de senha compartilhada em chat da equipe, nem celular pessoal como segundo fator.
• Use uma pessoa em vez de uma conta quando a ação for rara, de alto impacto ou difícil de desfazer. O agente prepara o trabalho e um humano executa.
• Nunca use o login pessoal de um funcionário. Se a ferramenta não oferece outra opção, isso é motivo para reconsiderar a integração ou colocar uma etapa de aprovação na frente dela.

Qualquer que seja a forma escolhida, aplique o menor privilégio: comece com o menor acesso que permita o papel funcionar e amplie só quando o trabalho real mostrar necessidade. O mesmo hábito aparece nas referências de autorização como negar por padrão e verificar cada requisição.

Como configurar a identidade de um agente, passo a passo?

Este plano serve para o primeiro agente e escala para os seguintes. Siga os passos na ordem, porque cada um depende do anterior.

• Escreva o papel em uma frase e liste as ferramentas e os dados necessários para esse trabalho. Se uma ferramenta não está na lista, o agente não recebe conta nela.
• Crie uma identidade por agente em cada ferramenta, com um nome que qualquer pessoa entenda ao ler um registro, por exemplo o nome do papel seguido da palavra agente. Use identidades separadas para teste e para produção.
• Atribua permissões em níveis. Conceda primeiro a leitura, depois a criação de rascunhos e só então o envio ou a gravação, seguindo a lógica de ler, preparar e enviar como três permissões diferentes.
• Guarde as credenciais em um cofre de segredos, nunca em prompts, documentos compartilhados ou na memória do agente. Uma credencial que o agente consegue ler é uma credencial que uma instrução maliciosa escondida em um documento pode tentar extrair.
• Nomeie um responsável humano e um substituto. Eles aprovam mudanças de acesso, recebem alertas sobre a identidade e respondem por ela nas revisões.
• Escreva os limites de aprovação: quais ações o agente pode tomar sozinho, quais exigem confirmação de uma pessoa e quais ele nunca pode executar.
• Ative um registro que capture a identidade, a ação, o alvo, o pedido que a originou e qualquer aprovação, como descrito em o que registrar na observabilidade de agentes de IA.
• Programe a troca de credenciais e as revisões de acesso, depois escreva o procedimento de revogação e ensaie-o uma vez, para que remover o agente seja uma tarefa conhecida de poucos minutos e não uma improvisação.

Como isso aparece em um fluxo real?

Cenário ilustrativo: uma distribuidora pequena quer um agente que faça a triagem da caixa de suporte, consulte o status de pedidos e prepare respostas para uma pessoa aprovar.

Na primeira versão, a gerente de operações dá ao agente o login do e-mail e a senha do sistema de pedidos dela. Funciona na mesma tarde. Algumas semanas depois, ela passa para outra equipe e as permissões mudam. O agente perde o acesso ao sistema de pedidos, passa a gerar respostas incompletas, e ninguém liga os dois fatos por dias. Enquanto isso, a conta dela ainda carrega direitos sobre cobrança e contratos que o agente nunca precisou ter.

Na segunda versão, a empresa cria uma identidade de agente de suporte. Ela tem leitura na caixa de suporte compartilhada, leitura no status dos pedidos e permissão para salvar rascunhos, mas não para enviar. Um líder de suporte nomeado é o responsável, com a gerente de operações como substituta. Cada rascunho é registrado com o nome do agente e o pedido consultado. Quando a gerente muda de equipe, nada acontece com o agente. Quando a empresa decide permitir respostas automáticas para uma categoria estreita de dúvidas, isso é uma mudança deliberada de permissão, aprovada pelo responsável e registrada no log.

O trabalho é o mesmo nas duas versões. A diferença é que a segunda tem responsável, limites claros e é fácil de ajustar.

Como a Be Human trata identidade e contas de agentes?

Num primeiro projeto, a Be Human define um papel útil, as ferramentas e a memória de que ele precisa e os limites de aprovação ao redor dele. Para esse papel, configura uma identidade dedicada em cada sistema conectado, com permissões restritas ao escopo combinado e credenciais mantidas fora de prompts e da memória. Na operação gerenciada, o trabalho recorrente inclui revisão de permissões, troca de credenciais, monitoramento da saúde das conexões, manutenção das integrações e resposta a incidentes, inclusive revogar o acesso de um agente sem afetar nenhuma conta de funcionário. As decisões de acesso ficam com pessoas nomeadas na empresa, e, quando uma conexão expira ou é revogada, o agente para e avisa em vez de improvisar, como explicado em o que um agente deve fazer quando uma conexão expira.

Quais erros evitar?

A maioria dos problemas de identidade com agentes vem de uma lista curta de hábitos que parecem convenientes.

• Compartilhar uma identidade entre vários agentes. Quando dois agentes usam a mesma conta, você perde a capacidade de distingui-los ou de remover um sem o outro.
• Conceder acesso amplo para evitar atrito no início. Permissões largas são fáceis de dar e raramente são retiradas.
• Deixar o campo de responsável vazio. Uma identidade sem dono não será revisada, renovada nem desativada.
• Colocar segredos em instruções ou documentos. Tudo o que o agente consegue ler pode acabar em uma resposta, em um log ou em uma saída manipulada. O OWASP Top 10 para aplicações com LLM discute esses riscos em detalhe.
• Pular o ensaio de revogação. Um procedimento que nunca foi testado tende a falhar justamente quando é mais necessário.
• Tratar a identidade como configuração feita uma única vez. Papéis mudam, ferramentas mudam e as permissões se desviam com o tempo, por isso programe revisões.

Perguntas frequentes

Um agente de IA pode simplesmente usar uma conta compartilhada da equipe? Uma conta compartilhada elimina justamente o que você mais precisa quando algo dá errado, que é saber quem agiu. Além disso, o acesso passa a refletir o que a equipe toda precisa, e não o papel do agente. Dê ao agente identidade própria e mantenha as contas compartilhadas para humanos que possam responder pelos seus atos.

Toda ferramenta precisa de uma conta separada para o agente? Toda ferramenta que o agente toca precisa de uma identidade sob a qual ele possa agir, mas a forma pode variar: uma conta de serviço em uma ferramenta, uma licença identificada em outra, um consentimento OAuth estreito em uma terceira. O que importa é que cada uma seja dedicada, delimitada e rastreável até o mesmo agente. Se uma ferramenta não oferece um jeito seguro de fazer isso, mantenha uma pessoa no circuito nessa etapa.

Quem deve ser o responsável pela identidade de um agente? Uma pessoa nomeada, da equipe que usa o agente, com um substituto. Ela aprova mudanças de permissão, recebe alertas e participa das revisões de acesso. Responsabilidade atribuída a um apelido de departamento ou a ninguém costuma significar que não haverá revisão alguma.

O que acontece com o agente quando um funcionário sai da empresa? Nada, se o agente tem identidade própria. Credenciais, permissões e registros são independentes de qualquer indivíduo, então mudanças na equipe não interrompem o agente nem deixam acessos escondidos. Só o papel de responsável humano precisa ser reatribuído, o que é uma mudança pequena e planejada.

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