Agentes de IA também precisam de identidade: quem são e o que podem acessar?

Durante muito tempo, quando falávamos de identidade digital dentro das empresas, a pergunta parecia relativamente conhecida: quem é o usuário que está tentando acessar determinado sistema e o que ele está autorizado a fazer?

Depois vieram aplicações, APIs, serviços, workloads e outras identidades não humanas. Agora, os agentes de inteligência artificial acrescentam uma nova dimensão ao problema.

Um agente pode consultar documentos, acessar bancos de dados, utilizar ferramentas, chamar uma API, abrir um chamado, acionar outro sistema ou até solicitar a atuação de outro agente. Dependendo do nível de autonomia recebido, também pode executar ações que antes dependeriam diretamente de uma pessoa.

Quando isso acontece, saber apenas quem é o usuário que iniciou o processo deixa de ser suficiente.

Precisamos saber quem é o agente, em nome de quem está atuando, quais recursos pode acessar, quais ações está autorizado a executar e como reconstruir depois aquilo que efetivamente fez.

A questão parece técnica, mas rapidamente se transforma em uma questão de governança.

Um agente que age também precisa ter identidade

Essa discussão já começa a aparecer de forma bastante concreta nas iniciativas de segurança e identidade.

Em 2026, o National Institute of Standards and Technology (NIST), órgão norte-americano responsável pelo desenvolvimento de padrões e referências técnicas, por meio do National Cybersecurity Center of Excellence (NCCoE), centro do NIST voltado à aplicação prática de tecnologias e padrões de cibersegurança, publicou um documento conceitual dedicado especificamente à identidade e à autorização de agentes de software e de inteligência artificial [1].

O ponto de partida é bastante objetivo: à medida que agentes acessam diferentes conjuntos de dados, ferramentas e aplicações para cumprir suas tarefas, as organizações precisam compreender como princípios já conhecidos de identificação, autenticação e autorização podem ser aplicados a eles [1].

A diferença entre esses conceitos é importante.

Identificação responde quem é o agente. Autenticação procura confirmar que ele é realmente quem afirma ser. Autorização determina o que aquele agente pode fazer depois que sua identidade foi reconhecida.

Dar autonomia a um agente sem saber claramente quem ele é e o que está autorizado a fazer é criar uma nova identidade privilegiada sem os controles que já aprendemos a exigir das pessoas e dos sistemas.

Essa discussão também ajuda a corrigir uma simplificação comum. Um agente não deveria ser tratado apenas como uma extensão invisível da aplicação que o executa. À medida que recebe responsabilidades próprias, sua identidade também passa a ser relevante para controlar e auditar aquilo que acontece.

A identidade do agente não é necessariamente a identidade do usuário

Um dos problemas mais interessantes surge quando um agente executa uma tarefa em nome de alguém.

Imagine um agente autorizado a consultar documentos corporativos para preparar uma análise. O usuário que solicitou a tarefa possui determinadas permissões, mas o agente também precisa se identificar perante os sistemas que acessará.

São duas perguntas diferentes: quem é o agente? e em nome de quem ele está agindo?

A documentação do Google Cloud sobre Agent Identity mostra como essa distinção já está chegando às implementações. O serviço atribui uma identidade criptográfica própria a cada agente e permite que ele se autentique perante recursos, ferramentas e outros agentes, atuando tanto em nome próprio quanto em nome de um usuário [2].

Isso é importante porque compartilhar uma mesma identidade entre diferentes agentes reduz a capacidade de saber qual deles realmente realizou determinada ação. Uma identidade individual permite aplicar políticas específicas e construir uma trilha mais precisa do comportamento de cada agente.

O próprio documento do NIST trata explicitamente da delegação de autoridade em situações nas quais o agente atua on behalf of, ou seja, em nome de alguém, e também questiona como vincular a identidade do agente à identidade humana quando existe autorização com participação de uma pessoa [1].

Saber quem iniciou uma tarefa não é suficiente quando outro participante, com identidade e capacidade de ação próprias, passa a executá-la.

Essa distinção tende a se tornar especialmente importante em processos nos quais diferentes agentes trabalham para diferentes usuários, departamentos ou clientes utilizando os mesmos sistemas corporativos.

Identidade sem autorização resolve apenas metade do problema

Reconhecer o agente é apenas o primeiro passo. Depois disso surge uma pergunta mais difícil: o que ele pode fazer?

Um agente responsável por analisar incidentes talvez precise consultar alarmes, topologia, inventário e mudanças recentes. Isso não significa que também deva ter permissão permanente para alterar configurações, reiniciar serviços ou acessar qualquer informação disponível no ambiente.

É aqui que o princípio de least privilege, ou menor privilégio, se torna particularmente relevante: cada identidade deve receber apenas os acessos necessários para realizar sua função.

O documento do NIST coloca justamente essa questão entre os desafios de autorização para agentes: como estabelecer menor privilégio quando as ações necessárias podem não ser totalmente previsíveis antes da execução? O mesmo documento também discute autorização dinâmica quando o contexto do agente muda e delegação de autoridade em cenários nos quais ele atua em nome de outra identidade [1].

A Blueprint Alliance, iniciativa multivendor anunciada em setembro de 2026 por empresas de identidade, nuvem, dados, aplicações e cibersegurança, segue uma direção semelhante. Entre seus princípios estão tratar cada agente como uma identidade própria, limitar o acesso à tarefa em vez de manter privilégios permanentes e preservar a rastreabilidade da delegação quando agentes criam subagentes ou atuam em nome de pessoas [3].

Essa mudança é importante porque agentes podem operar de maneira muito mais dinâmica do que aplicações tradicionais.

O acesso adequado pode depender da tarefa, do usuário representado, do recurso solicitado, do contexto da operação e até do momento em que a ação está sendo executada.

Em ambientes agênticos, a pergunta deixa de ser apenas “este agente tem acesso?” e passa a ser “este agente deveria ter este acesso, para esta tarefa, neste momento e neste contexto?”.

Isso aproxima identidade de contexto e transforma autorização em uma decisão potencialmente mais dinâmica.

Quando um agente chama outro, a cadeia de responsabilidade não pode desaparecer

A complexidade aumenta novamente em ambientes multiagentes.

Um agente pode receber uma tarefa e delegar parte dela a outro agente, que consulta uma ferramenta, acessa um serviço e devolve um resultado. Dependendo da arquitetura, essa sequência pode continuar por vários passos.

Se uma ação inadequada ocorrer no final dessa cadeia, será necessário reconstruir não apenas qual agente a executou, mas também de onde veio a autorização, quem delegou a tarefa e como ela chegou até ele.

A Blueprint Alliance coloca a delegação rastreável de ponta a ponta entre seus princípios para ambientes agênticos [3]. O NIST também trata a delegação, o vínculo entre identidades humanas e agentes e o registro das ações entre os elementos necessários para construir essa rastreabilidade [1].

Nesse contexto aparece também o conceito de non-repudiation (não repúdio), utilizado em segurança para garantir que existam evidências que permitam associar uma ação à identidade que a realizou, evitando que sua autoria possa ser posteriormente negada ou fique sem atribuição clara.

Essa capacidade será importante não apenas para segurança, mas também para auditoria, investigação de incidentes e responsabilidade operacional. Se vários agentes participaram de um workflow, precisamos conseguir reconstruir a cadeia completa: quem recebeu a tarefa, quem delegou, quem acessou determinado dado, quem tomou determinada decisão e quem finalmente executou a ação.

Quanto maior a autonomia e a colaboração entre agentes, mais importante será preservar a cadeia de responsabilidade por aquilo que eles fazem.

Antes de controlar os agentes, será preciso saber que eles existem

Há ainda um problema anterior à própria autorização.

Uma organização pode não ter visibilidade completa sobre todos os agentes que começam a surgir em seu ambiente.

Times podem criar agentes internamente, fornecedores podem incorporar agentes às suas aplicações e usuários podem começar a utilizar serviços que introduzem novas identidades e integrações sem passar pelos mesmos processos tradicionais de governança.

A Palo Alto Networks chama atenção para a necessidade de descoberta contínua, inventário e classificação dos agentes, incluindo os chamados shadow agents, agentes que surgem ou operam fora da visibilidade e dos controles formais da organização [4].

A Blueprint Alliance também inclui descoberta e catalogação entre os primeiros elementos de sua arquitetura e propõe que cada agente seja registrado como uma identidade distinta, associada a um responsável humano ou time operacional [3].

Esse ponto aproxima a discussão do problema mais amplo de Shadow AI, o uso de recursos de inteligência artificial fora dos mecanismos formais de conhecimento e governança da empresa.

Não é possível governar a identidade, o acesso ou o comportamento de um agente cuja existência a organização desconhece.

À medida que criar agentes se torna mais fácil, inventário e ownership deixam de ser tarefas administrativas secundárias e passam a fazer parte da própria segurança da operação.

Identidade também precisa acompanhar o ciclo de vida

Pessoas entram, mudam de função e deixam organizações. Sistemas são criados, modificados e desativados. Agentes também terão um ciclo de vida.

Um agente pode mudar de versão, receber novas ferramentas, passar a atender outro processo ou deixar de ser necessário. As permissões que faziam sentido em uma determinada função podem se tornar excessivas depois de uma mudança.

Por isso, identidade não pode ser tratada apenas no momento em que o agente é criado.

A própria arquitetura proposta pela Blueprint Alliance relaciona a governança dos agentes a revisões de acesso, separação de funções e disciplina de entrada, mudança e saída aplicada ao escopo, ao responsável e às versões dos agentes [3].

Isso significa que a gestão precisará responder continuamente a perguntas aparentemente simples: este agente ainda existe? Continua exercendo a mesma função? Seu responsável continua sendo o mesmo? As permissões permanecem adequadas? Os recursos aos quais tem acesso ainda são necessários?

Em ambientes com poucos agentes, isso pode ser administrável manualmente. À medida que o número de agentes e workflows cresce, tende a se tornar um problema operacional.

É nesse ponto que identidade começa a se conectar diretamente com AgentOps.

Identidade, observabilidade e AgentOps começam a convergir

Nos artigos anteriores desta série, discutimos que colocar agentes em produção exige uma disciplina operacional capaz de acompanhar seu ciclo de vida, comportamento, custos, resultados e confiabilidade. Também vimos que observabilidade passa a incluir aquilo que os agentes fazem durante suas execuções.

Identidade acrescenta outra camada a essa arquitetura.

Um trace pode mostrar que uma ferramenta foi chamada. A identidade permite saber qual agente fez a chamada. A autorização ajuda a responder por que ele tinha permissão para fazê-la. A delegação permite reconstruir em nome de quem ou de qual outro agente aquela ação ocorreu.

Essas dimensões não substituem umas às outras. Elas se complementam.

A própria Blueprint Alliance organiza sua proposta em torno de questões que conectam descoberta, identidade, autorização, monitoramento em tempo de execução e resposta [3]. A documentação do Google Cloud também combina identidade do agente com mecanismos de gateway e políticas de acesso aos recursos utilizados durante a execução [2].

À medida que agentes ganham autonomia, portanto, identidade deixa de ser apenas uma preocupação de segurança e passa a integrar a própria capacidade de operar esses sistemas.

Governar agentes exigirá conectar quem eles são, o que podem fazer, o que efetivamente fizeram e qual resultado produziram.

Essa talvez seja uma das mudanças mais importantes em relação às identidades de máquina que já conhecemos. Não estamos apenas autenticando um componente técnico que executa uma função previamente definida. Estamos começando a atribuir identidade a sistemas capazes de interpretar contexto, escolher caminhos e realizar ações com graus crescentes de autonomia.

Da visão à prática: ARGUS

Esse cenário também amplia a forma como pensamos o ARGUS.

O ARGUS nasceu com o propósito de correlacionar eventos de múltiplas fontes, reduzir o ruído e construir contexto operacional compartilhado. À medida que agentes passam a participar das operações, esse contexto pode ajudá-los a compreender melhor o ambiente sobre o qual estão decidindo e agindo.

Com a incorporação das capacidades de AI Gateway e AgentOps (Agent Operations), o ARGUS passa também a incorporar os agentes como participantes da própria operação. O AI Gateway permite aplicar políticas e controlar o acesso de aplicações e agentes a recursos de inteligência artificial, enquanto o AgentOps amplia a capacidade de orquestrar agentes, acompanhar suas execuções e ações e estabelecer mecanismos de observabilidade, governança e supervisão.

Isso cria uma conexão direta com identidade e autorização. Diferentes agentes podem operar sob políticas específicas, enquanto sua atuação pode ser acompanhada dentro do contexto em que cada decisão e ação ocorreu.

O ponto mais importante, porém, está em conectar essas dimensões.

Saber qual agente executou uma ação é importante. Entender o que estava acontecendo na operação quando ele tomou aquela decisão torna essa informação muito mais útil.

Ao relacionar identidade, ações, eventos, infraestrutura, serviços, ferramentas e resultados em uma visão operacional compartilhada, torna-se possível construir uma trilha mais completa do comportamento dos agentes e das consequências de sua atuação.

Essa capacidade ganha importância à medida que a autonomia aumenta. Governar agentes não significa apenas limitar o que podem fazer, mas criar condições para orquestrar sua atuação, compreender suas decisões, aplicar políticas, auditar ações e ampliar responsabilidades gradualmente, mantendo supervisão humana quando necessária.

Conheça o ARGUS e veja como funciona na prática.

Sobre a Target Solutions

A Target Solutions é uma empresa brasileira de tecnologia especializada em soluções para ambientes críticos de TI e Telecom.

Ao longo de mais de 15 anos, participamos de projetos envolvendo infraestrutura, monitoramento, observabilidade, automação, integração de plataformas e operações de redes e serviços, trabalhando com grandes organizações e ambientes de alta complexidade.

Essa experiência nos permitiu acompanhar de perto a evolução das operações, do monitoramento tradicional à observabilidade, da automação à AIOps (Artificial Intelligence for IT Operations), aplicação de inteligência artificial às operações de tecnologia, e, agora, aos primeiros passos em direção a operações cada vez mais orientadas por inteligência artificial.

É nesse contexto que desenvolvemos o ARGUS, nossa plataforma AIOps que correlaciona eventos de múltiplas fontes, reduz o ruído e constrói contexto operacional compartilhado, agora ampliada com capacidades de AI Gateway e AgentOps para apoiar a orquestração, observabilidade e governança de agentes de IA.

Sobre o autor

Paulo Florêncio de Menezes é sócio e CoFounder da Target Solutions e atua há mais de 15 anos em projetos relacionados a infraestrutura, monitoramento, observabilidade, automação e operações de TI e Telecom.

É graduado em Processamento de Dados pela Universidade Federal do Amazonas (UFAM), possui MBA em Gestão Empresarial pela Fundação Dom Cabral (FDC) e Mestrado Profissional em Economia pela Fundação Getulio Vargas (FGV).

Em sua pesquisa de Mestrado, desenvolveu o IBEOP-IA (Índice Brasileiro de Exposição Ocupacional Potencial à Inteligência Artificial), investigando a exposição potencial das ocupações brasileiras às capacidades da IA por meio da combinação de dados ocupacionais, patentes de inteligência artificial e técnicas de processamento de linguagem natural.

Referências

[1] National Institute of Standards and Technology / National Cybersecurity Center of Excellence. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. Concept Paper, 2026.

[2] Google Cloud. Agent Identity overview. Identity and Access Management documentation, 2026.

[3] Blueprint Alliance. Industry leaders form the Blueprint Alliance to advance a shared architecture for securing AI agents. 2026.

[4] Palo Alto Networks. Secure AI Agent Identities & Access. 2026.