Ana tem acesso ao ERP. Um agente é criado para ajudá-la e passa a executar algumas tarefas com as credenciais dela. Semanas depois aparece uma alteração relevante num cadastro, e o registro mostra uma linha só.
Ana alterou o dado.
A linha é verdadeira e não responde nada. Ana fez a alteração? Pediu ao agente? O agente alterou como etapa de outra tarefa? Algum processo acionou o agente sem que ela acompanhasse? Quando pessoa e agente aparecem no sistema como a mesma identidade, a empresa perde a capacidade de reconstruir a cadeia, e perde junto a capacidade de tratar os dois de forma diferente.
Autonomia, permissão e identidade respondem perguntas diferentes
Vale separar três perguntas que costumam chegar embaladas numa só.
Autonomia pergunta quanto o agente decide e executa sem nova aprovação. Permissão pergunta a que dados, ferramentas e sistemas ele tem acesso. A relação entre essas duas já foi tratada em quanta autonomia dar a um agente de IA. Identidade pergunta outra coisa: quem o sistema reconhece como autor no momento em que a ação acontece.
A terceira não deriva das outras duas. Um agente pode ter autonomia baixíssima e ainda assim precisar de identidade própria. Pense num agente que executa um pagamento já aprovado por uma pessoa. Ele não escolheu o fornecedor, não definiu o valor e não decidiu se a empresa deveria pagar. Mas foi ele quem entrou no sistema e executou a etapa. Nesse caso a empresa precisa preservar duas informações, não uma: quem autorizou e quem executou.
O registro precisa guardar dois papéis, não um
Durante muito tempo a identidade ligada a uma ação foi tratada como representação direta de quem realizou aquela ação. Com agentes, a associação se quebra. Uma pessoa pede, o agente executa, uma política permite, outro sistema recebe. Cada parte cumpre um papel distinto, e comprimir tudo numa credencial apaga a diferença.
A preview privada do Agent Identity no watsonx Orchestrate, anunciada pela IBM em setembro de 2026, descreve a separação em dois termos úteis. A execução registra o sujeito, que é o usuário em nome de quem a ação é feita, e o ator, que é o agente que a executou. São campos diferentes, preenchidos por entidades diferentes, e um não substitui o outro.
Isso não resolve responsabilidade. Identidade de agente não decide quem responde por uma decisão e não elimina responsabilidade humana. O trabalho dela é mais modesto e mais básico: preservar evidência de quem efetivamente executou. Sem essa evidência, discutir responsabilidade depois vira reconstrução de memória.
Uma conta de serviço não cobre o que o agente faz
A objeção razoável aparece rápido. Empresas criam identidade para software há décadas, com conta de serviço, certificado e token. Por que falar em identidade de agente como se fosse categoria nova?
Porque o agente se comporta diferente de um workload tradicional em quatro pontos. Uma aplicação costuma ter função estável, e o agente recebe uma meta e decide quais ferramentas usar para alcançá-la. Uma aplicação roda continuamente, e o agente pode existir por poucos minutos. Uma aplicação atende um sistema, e o agente pode trabalhar em nome de usuários diferentes ao longo do dia. Uma aplicação é provisionada, e o agente pode ser criado e encerrado dinamicamente, aos milhares.
A IBM aponta a limitação direto na origem do problema. Conta de serviço compartilhada, chave de API estática e reuso de credencial de usuário já não distinguem o que a pessoa fez do que o agente fez em nome dela.
Nada disso torna conta de serviço obsoleta, e nada disso obriga a empresa a comprar uma categoria nova de produto. A regra é mais simples. Quando for necessário atribuir e controlar ações separadamente, o ator precisa ser identificável separadamente.
Nome em catálogo não é identidade operacional
Existe uma confusão fácil de cometer e cara de descobrir. Uma empresa monta um inventário com dezenas de agentes. Finance Agent. Sales Agent. HR Agent. O inventário é útil e prova apenas que a empresa sabe que eles existem.
Identidade operacional é outra coisa, e se mede por quatro capacidades no momento da chamada. O sistema que recebe a solicitação consegue verificar qual agente está chamando. A política consegue aplicar regra àquele agente específico. O registro consegue preservar quem executou. E a empresa consegue retirar a autoridade daquele agente.
Sem essas quatro, o que existe é identificação administrativa. O agente tem nome numa planilha e continua anônimo exatamente onde importa, que é o instante em que ele toca um sistema de produção.
Revogar o agente não deveria exigir revogar a pessoa
O acoplamento entre as duas identidades cobra o preço no pior momento. Se o agente opera com a credencial de Ana e algo sai errado, interromper o agente significa derrubar o acesso dela. A empresa escolhe entre conter o problema e parar uma pessoa que não fez nada.
Identidade separada desfaz essa escolha. A pessoa continua com o acesso dela, o agente perde a autoridade dele, e as duas decisões ficam independentes.
A Microsoft publicou em outubro de 2026 uma formulação direta disso, afirmando que todo agente deveria ter identidade de primeira classe, distinta da pessoa que o usa ou patrocina. Junto veio um mecanismo chamado Dynamic Permissions, cuja proposta é o agente não herdar automaticamente o acesso permanente do usuário. Ele começa sem autoridade e recebe só o necessário para a tarefa aprovada, por tempo determinado, com a autoridade reduzida ou removida quando a tarefa muda ou termina. A separação entre identidade e permissão é o que permite aplicar esse limite ao ator correto.
O pagamento mostra o desenho funcionando
Em outubro de 2026, Visa, BILL e Billtrust colocaram no ar um piloto para agentes concluírem pagamentos de faturas já aprovadas. O agente não decide se a dívida deve ser paga, porque a aprovação já existe. O papel dele é executar a etapa seguinte.
O desenho interessa mais que o produto. O agente é registrado no Trusted Agent Protocol e no diretório de agentes da Visa, usa credencial de pagamento tokenizada em vez de login compartilhado do portal do fornecedor, e o lado do fornecedor reconhece e autentica o agente autorizado sem exigir que ele passe por um login humano. A autenticação chega a substituir proteções como CAPTCHA, que existem justamente para barrar quem não é pessoa.
A cadeia fica inteira e legível. A pessoa autoriza, o agente é identificado, o sistema autentica o agente, a política limita o que ele pode fazer e a ação é atribuída ao executor correto. É o oposto de entregar o login de alguém ao agente e tratar tudo o que vier depois como se a pessoa tivesse feito.
Os bancos encontraram o mesmo problema pelo lado oposto
Dois dias depois do piloto veio o sinal contrário. Reportagens de 22 de outubro de 2026 descreveram grandes bancos americanos restringindo agentes de terceiros que tentavam acessar contas de clientes, em casos que incluíam clientes compartilhando a própria credencial de login com o agente.
A apuração pede cuidado. Ela se apoia em boa parte em fontes anônimas, e uma das instituições citadas declarou publicamente não ter observado agentes não autorizados nas suas plataformas. O que sustenta o ponto não é a contagem de bancos, é o motivo da restrição.
Os dois movimentos parecem contraditórios e têm o mesmo fundo. De um lado, um caminho em que o agente é reconhecido antes de agir. Do outro, o bloqueio de um agente que aparece vestindo a credencial de uma pessoa. A pergunta é a mesma nos dois casos. O sistema consegue saber quem está entrando, em nome de quem e com qual autoridade?
Um agente reconhecido e autorizado é um problema de política. Um agente indistinguível de um cliente é um problema de identificação, e não há política que resolva o que o sistema não consegue enxergar.
Cinco perguntas antes de dar acesso real a um agente
Quem o sistema reconhece quando o agente age. Se a resposta for o nome de uma pessoa ou uma conta genérica compartilhada, existe lacuna de atribuição.
A ação do agente se distingue da ação humana. A diferença precisa aparecer no registro e nas integrações, não só na documentação interna.
O acesso do agente é revogável sem retirar o acesso da pessoa. Se não for, as duas identidades continuam acopladas e a contenção custa caro.
O sistema autentica o agente no momento da ação. Existir num catálogo interno não basta. A identidade precisa ser verificável quando ele interage com outro sistema.
O registro preserva quem autorizou e quem executou. Identidade própria não elimina delegação, ela permite registrar os dois lados dela.
Essas perguntas são de segurança e de arquitetura ao mesmo tempo. Quem já trata identidade e permissão mínima como capacidade instalada responde quatro delas sem projeto novo, porque o vocabulário é o mesmo e muda o ator.
O próximo problema de identidade da empresa pode não ser humano
Identidade corporativa foi construída ao redor de pessoas, aplicações e máquinas. O agente ocupa um espaço que não é nenhum dos três. Ele age em nome de uma pessoa sem ser essa pessoa, acessa sistemas sem funcionar como aplicação tradicional, pode existir durante uma tarefa e desaparecer, pode receber autoridade temporária, e produz ações que precisam ser atribuídas a ele.
Isso não obriga ninguém a redesenhar a arquitetura de identidade amanhã. A base para tratar o agente como ator governado já foi tratada em agentes autônomos e o que falta para escalar. O que muda agora é que uma pergunta antes dispensável virou operacional.
Quando um agente agir nos seus sistemas, eles vão conseguir saber que foi o agente? Porque a empresa só investiga, limita e revoga com precisão aquilo que consegue identificar.
Fontes
- Microsoft. "Agents are your newest insiders. Security must move at their speed" (19 de outubro de 2026). https://www.microsoft.com/en-us/security/blog/2026/10/19/agents-are-your-newest-insiders-security-must-move-at-their-speed/
- IBM. "Announcing the private preview of Agent Identity in IBM watsonx Orchestrate" (21 de setembro de 2026). https://www.ibm.com/new/announcements/announcing-the-private-preview-of-agent-identity-in-ibm-watsonx-orchestrate
- Visa. "Visa, BILL and Billtrust Launch First Live Pilot for Trusted AI Agent Payments Between Buyer and Supplier Platforms" (20 de outubro de 2026). https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.22856.html
- Reuters. "US banks are blocking third-party AI agents access to customer accounts, sources say" (22 de outubro de 2026). https://www.reuters.com/legal/government/us-banks-detect-unauthorized-ai-agents-customer-accounts-axios-reports-2026-1022/
Nota: a reportagem sobre bancos americanos se apoia em fontes anônimas e relata apuração de outro veículo. Uma das instituições citadas declarou publicamente não ter observado agentes não autorizados nas suas plataformas, e por isso o texto trata o motivo da restrição, não a contagem de instituições. A separação entre sujeito e ator é a nomenclatura usada pela IBM. Dynamic Permissions, Trusted Agent Protocol e o diretório de agentes são mecanismos nomeados pelos respectivos fornecedores, sem correspondência a padrão aberto.
