Em abril de 2026, a Microsoft anunciou o Entra Agent ID, um sistema de identidade feito especificamente para agentes de IA — não para pessoas, não para aplicativos comuns. A justificativa oficial é direta: à medida que as empresas colocam em produção agentes assistentes e autônomos, "elas precisam de estruturas de identidade próprias para autenticar, autorizar, governar e proteger" essas identidades que não são humanas.
O motivo para um sistema de identidade separado fica mais claro com um número: segundo o relatório 2026 Identity Security Landscape, da Idira (marca da Palo Alto Networks que herdou a base da CyberArk), as identidades de máquina hoje superam as humanas na proporção de 109 para 1 dentro das organizações — e 99 de cada 100 empresas já adotaram algum agente de IA. Cada agente novo é, na prática, mais uma identidade que precisa de dono, permissão e prazo de validade.
O problema é que a maioria das empresas ainda trata agente de IA como se fosse um script qualquer: alguém cria uma conta de serviço, empresta a própria senha, ou usa uma chave que nunca expira e que ninguém mais sabe que existe. Funciona no primeiro mês. Depois disso, vira exatamente o tipo de identidade não controlada que os números acima descrevem.
Uma automação com senha emprestada é um problema esperando para acontecer
Pense no caminho mais comum hoje: alguém do time de operações configura um agente para atualizar cadastro de fornecedor, gerar relatório financeiro ou responder a um sistema de tickets. Para o agente funcionar, ele precisa de acesso — e o caminho mais rápido é dar a ele a própria senha, ou uma conta de serviço genérica que várias pessoas conhecem.
Esse atalho cria três problemas ao mesmo tempo. Primeiro, o agente herda todo o acesso daquela pessoa, não só o que a tarefa exige — se a pessoa tem acesso a folha de pagamento, o agente também tem, mesmo que só precise mexer em cadastro de fornecedor. Segundo, quando a pessoa muda de função ou sai da empresa, ninguém lembra de revisar o que o agente ainda pode fazer com aquela credencial emprestada. Terceiro, e mais grave em uma investigação: uma ação tomada pelo agente aparece nos registros como se tivesse sido a pessoa que fez, porque foi a identidade dela que foi usada.
O relatório da Gartner sobre o ciclo de maturidade de identidade digital para 2026, resumido pela Silverfort, chega à mesma conclusão a partir do outro lado: identidades de máquina estão crescendo mais rápido que a capacidade das empresas de descobri-las e governá-las, e a recomendação da consultoria é explícita — agentes de IA precisam de identidade própria, com credencial restrita ao necessário e um responsável humano definido, em vez de reaproveitar login de pessoa.
Por que "vou dar minha senha pra ele" não escala
A saída mais comum — emprestar credencial pessoal — funciona para um agente. Não funciona para dez, e definitivamente não funciona para cem. À medida que a proporção de 109 identidades de máquina para cada identidade humana se torna realidade dentro da empresa, o modelo de "cada agente usa a senha de alguém" simplesmente não tem como ser auditado: não existe lista central de quem emprestou o quê, para qual agente, com qual prazo.
Além disso, revogar acesso de agente vira tarefa manual e fácil de esquecer. Quando um projeto termina e o agente que ele usava deveria parar de funcionar, a credencial emprestada continua válida até que alguém, de memória, lembre de trocar a senha da pessoa original — o que raramente acontece no mesmo dia.
O padrão que a própria Microsoft descreve para o Entra Agent ID resolve esse ponto de um jeito específico: cada agente recebe uma identidade com relação clara de origem (qual time criou, para qual finalidade), políticas de acesso adaptativas como as de qualquer outra identidade corporativa, e todo o histórico de autenticação e atividade do agente registrado para auditoria — nada disso depende de alguém lembrar de revisar manualmente.
O que precisa existir na prática
Dar identidade própria a um agente de IA significa replicar, para ele, os mesmos mecanismos que já existem para pessoas — não inventar um regime à parte.
Identidade vinda do mesmo diretório corporativo. O agente entra no sistema com uma identidade criada e controlada pela empresa, do mesmo lugar de onde vem o login de qualquer colaborador — não uma conta improvisada por quem configurou a automação.
Acesso conforme o papel, também para agentes. Um agente de atendimento não precisa do mesmo alcance que um agente de análise financeira. O acesso é definido pela função que o agente exerce, não emprestado de quem o criou.
Credencial pessoal por ferramenta conectada. Quando um agente se conecta a um sistema externo, a credencial usada é dele, não de uma pessoa — e pode ser revogada isoladamente, sem afetar o acesso de mais ninguém.
Aprovação humana antes de uma ação sensível. Antes de o agente executar algo com impacto real — enviar um pagamento, alterar um cadastro crítico, publicar um documento — a ação para e pede confirmação de uma pessoa, dentro da própria conversa.
É assim que a Skyller trata identidade de agente: vinda do diretório da empresa, com escopo próprio por papel e aprovação humana antes de ações sensíveis, do mesmo jeito que já vale para qualquer pessoa da equipe.
O que a empresa ganha quando o agente tem identidade própria
O primeiro ganho aparece no dia a dia da área de TI: saber quantos agentes existem, quem os criou e o que cada um pode fazer deixa de exigir uma investigação manual e vira uma lista consultável, do mesmo jeito que já existe para pessoas.
O segundo ganho aparece quando algo precisa mudar rápido. Um projeto termina, um agente é desativado, uma ferramenta é substituída — desligar o acesso daquele agente específico não exige trocar a senha de ninguém nem revisar o que mais aquela credencial compartilhada estava liberando.
O terceiro ganho é o mais estratégico: escalar o número de agentes deixa de ser um risco crescente. Com identidade e escopo próprios, adicionar o agente 50 não é mais arriscado, em termos de governança, do que adicionar o agente 5 — porque cada um carrega só o acesso que a própria função exige, com dono e histórico definidos desde o início.
Isso muda também a conversa entre TI e as demais áreas. Hoje, pedir um agente novo costuma esbarrar em uma pergunta incômoda: "quem vai garantir que isso não vira um problema de acesso mais tarde?" Com identidade própria por agente, a resposta deixa de ser uma promessa e vira uma característica do próprio sistema — o agente nasce com escopo definido, dono identificado e trilha de uso, do mesmo jeito que uma conta de colaborador novo.
Um roteiro para começar
Antes de colocar o próximo agente em produção, vale seguir uma sequência simples com a área de TI:
- Liste os agentes que já existem hoje na empresa. Incluindo os informais — automações criadas por uma pessoa, para resolver uma tarefa pontual, que continuam rodando meses depois.
- Para cada um, identifique de quem é a credencial que ele usa. Se a resposta for "a senha de fulano" ou "uma conta genérica que várias pessoas conhecem", esse agente está na categoria de risco mais alta.
- Defina o escopo mínimo que cada agente realmente precisa. Não o que é mais conveniente configurar agora, e sim o que a função dele exige.
- Estabeleça um responsável humano por agente. Alguém que responda pela existência daquele agente, revise seu acesso periodicamente e saiba desativá-lo quando o motivo original deixar de existir.
- Coloque aprovação humana nas ações de maior impacto. Nem tudo precisa de confirmação manual — mas o que envolve dinheiro, dado crítico ou comunicação externa, precisa.
