Quando um agente age “em nome de alguém”, três identidades importam: a pessoa que iniciou, o agente que interpretou e o sistema que executou. Colocar tudo sob uma conta técnica compartilhada apaga essa cadeia e transforma conveniência em privilégio permanente.
O controle adequado combina identidade do agente, contexto da pessoa, escopo da ferramenta, empresa, ambiente e duração. A autorização deve ser verificada no momento da ação, não apenas quando o usuário abriu a conversa.
Em uma frase
Um agente só deve conseguir provar e exercer a autoridade estritamente necessária para a ação atual — e essa autoridade precisa poder ser revogada.
A conta de serviço que lentamente vira administradora
Integrações começam com uma credencial ampla porque é mais rápido. Depois ganham novos fluxos, pessoas e canais. Meses mais tarde, ninguém sabe quais permissões são usadas; revogar a chave interromperia tudo. Se um prompt malicioso ou configuração errada acionar uma ferramenta, o impacto acompanha o maior privilégio disponível.
Há também confusão entre autenticar e autorizar. Saber que uma mensagem veio de determinado número ou usuário não prova que ele pode alterar uma ordem. É necessário vincular identidade externa a uma pessoa e função internas e avaliar a permissão sobre recurso e operação.
Identidade de agentes virou um problema explícito de padrões
Em 2026, o NCCoE do NIST abriu um projeto sobre identidade e autorização de agentes. O documento discute identificação, autenticação, menor privilégio, delegação em nome de pessoas, auditoria, não repúdio e mitigação de prompt injection.
Para APIs, a RFC 9700, prática corrente de segurança OAuth 2.0, recomenda restringir tokens ao privilégio mínimo e ao recurso de destino. Essas referências não prescrevem um único produto, mas deixam claro que credenciais amplas e indistintas são um antipadrão.
Exemplo composto: atualização de CRM em campo
Uma representante fictícia dita o resumo de uma visita. O agente pode criar nota apenas nos clientes atribuídos à pessoa. A integração usa autorização delegada ou um serviço limitado à operação de notas; não recebe permissão para exportar a base ou alterar condições comerciais.
Quando a colaboradora muda de carteira, o vínculo é atualizado centralmente. Ao desligar a conta, conversas e ferramentas deixam de executar imediatamente, mesmo que o canal ainda receba uma mensagem. O exemplo mostra como revogação faz parte do fluxo, não de uma limpeza futura.
Camadas de autorização que trabalham juntas
Primeiro, valide o canal e vincule a identidade. Segundo, confirme empresa e sessão. Terceiro, filtre ferramentas pelo papel. Quarto, valide os parâmetros e o recurso específico. Quinto, aplique alçada ou aprovação. Por fim, registre qual identidade e credencial chegaram ao sistema.
Use credenciais diferentes por ambiente e integração, segredos fora do prompt, rotação e expiração. Revogação precisa ser testada: desligue um usuário e uma ferramenta em ambiente de teste e confirme que pedidos novos e pendentes param de forma segura.
Controles mínimos de acesso
- Identidade única para pessoa, agente, empresa e integração.
- Ferramentas permitidas por papel, recurso, ambiente e finalidade.
- Tokens limitados, armazenados no servidor, rotacionados e nunca expostos ao modelo.
- Expiração de decisões pendentes e revogação propagada sem depender de novo login.
- Evidência que liga solicitante, agente, aprovação, credencial e resultado.
Como a Uiless ajuda
A Uiless separa identidade do canal, pessoa, empresa e ferramentas. Um número de WhatsApp, uma sessão do app ou um usuário do painel é associado ao contexto interno antes de qualquer execução. As mesmas portas de permissão se aplicam aos diferentes canais.
Conectores guardam segredos no servidor, ferramentas publicam apenas operações nomeadas e o painel permite habilitar, restringir ou revogar capacidades. Assim, a empresa evita entregar acesso genérico ao agente para ganhar velocidade.
Veja quem responde pelos agentes e como registrar a cadeia de execução.
