9 de setembro de 2026
Conceder a um agente de IA acesso irrestrito à conta de um funcionário pode parecer a escolha mais pragmática. A conta já está autenticada, já possui as permissões adequadas e o projeto pode avançar sem a necessidade de outra demorada revisão de segurança. O problema surge no momento em que o agente começa a agir, e a linha divisória entre a pessoa e o software desaparece. O registro de auditoria indica que um funcionário abriu um arquivo, alterou um registro ou aprovou uma transação, quando, na verdade, foi o agente quem realizou o trabalho. A responsabilização se torna uma suposição, e o agente, discretamente, detém muito mais acesso do que sua tarefa exige.
Atribuir a cada agente sua própria identidade é a correção correta, e é a primeira de duas. Uma identidade distinta determina qual agente agiu. Ela não determina que um ser humano responsável tenha aprovado o que o agente fez. Esse segundo problema persiste mesmo com um programa de identidade bem administrado, e é ele que acarreta consequências legais e financeiras.
O Hype Cycle™ 2026 da Gartner® para Identidade Digital define a categoria da seguinte forma: “A identidade do agente de IA é a representação digital exclusiva dos agentes de IA dentro de uma organização. Estabelecer e gerenciar a identidade dos agentes de IA, incluindo assistentes e chatbots, permite que os sistemas de gerenciamento de identidade e acesso (IAM) atribuam identificadores exclusivos, emitam credenciais específicas para acesso a recursos (por exemplo, APIs, dados e serviços) e estabeleçam responsabilidade humana clara e trilhas de auditoria em todos os sistemas corporativos.”
Identificadores únicos, credenciais com escopo definido e uma trilha de auditoria que atribui as ações ao agente correto são, todos, propriedades de atribuição. Elas determinam qual agente agiu e sob a autoridade de quem, o que é uma questão diferente de saber se uma pessoa específica aprovou a ação que realizou.
Credenciais emprestadas e segurança de contas de serviço criam um ponto cego
Os primeiros projetos de IA tendem a ser executados em qualquer recurso de acesso que já esteja disponível:
- Um assistente interno pode herdar permissões excessivas, a menos que seu acesso delegado seja explicitamente restrito.
- Um fluxo de trabalho passa por uma conta de serviço compartilhada.
- Um desenvolvedor conecta um agente a uma API usando uma chave de longa duração.
Essas configurações geram diversos riscos: acesso excessivo, atribuição ambígua ou credenciais persistentes. O agente pode receber mais permissões do que o necessário para sua tarefa. As atividades humanas e do agente podem se confundir quando as credenciais são compartilhadas. As equipes de segurança podem não ter uma maneira confiável de saber quando um agente está em execução ou quais transações ele concluiu.
É por isso que a segurança das contas de serviço se tornou um problema urgente, e não apenas uma questão de manutenção. Uma conta de serviço compartilhada nunca foi projetada para representar um agente autônomo que toma suas próprias decisões na velocidade de uma máquina, e uma chave de API estática não contém nenhuma informação sobre quem autorizou o trabalho ou por quê.
As credenciais emprestadas também comprometem a não repudiação — um recurso de segurança que comprova que uma pessoa específica enviou uma mensagem ou realizou uma transação, e não pode negar posteriormente ter feito isso. Quando uma pessoa e um agente compartilham uma mesma identidade, a organização não consegue comprovar qual deles realizou uma determinada ação. De acordo com o relatório: “A prática perigosa de implantar agentes de IA como proxies que operam com credenciais de acesso humanas viola os requisitos de auditoria, rastreabilidade e não repúdio, elevando significativamente o risco de concessão excessiva de permissões, bem como o impacto do comprometimento de credenciais e da apropriação de contas.”
Trata-se de falhas de atribuição, e uma identidade distinta é a solução adequada para elas.
O que muda com uma identidade separada?
Uma identidade dedicada atribui ao agente seu próprio registro no ambiente de IAM, com um proprietário identificado, uma finalidade definida e um conjunto deliberadamente restrito de permissões aprovadas em seu nome por esse proprietário. Ela pode ser desativada sem interromper o trabalho do funcionário ou da equipe por trás dela. A autenticação do agente de IA torna-se um evento distinto que você pode observar e analisar, em vez de algo oculto dentro de uma sessão humana. É possível emitir credenciais de curta duração para o agente, em vez de uma senha permanente ou chave de API. Seu acesso pode ser restrito a um aplicativo, tarefa ou transação específica. Sua atividade pode ser analisada de forma independente, separada da de qualquer ser humano.
A reatribuição merece atenção especial. A reatribuição de um agente a um proprietário ou mandante diferente constitui uma mudança de identidade, e não uma simples atualização de um campo; portanto, deve exigir uma nova verificação da pessoa que agora assume a responsabilidade. Um registro de propriedade que possa ser editado sem restabelecer quem concordou em assumir o risco deixa a relação sujeita a contestação.
Isso se aproxima mais da forma como o Zero Trust deve funcionar, em que uma autenticação anterior não é considerada prova definitiva de nada. O caso “agênico” leva essa lógica um passo adiante. Uma autenticação anterior também não é prova de que uma pessoa tenha aprovado o que acontece a seguir
Os agentes de IA precisam de acesso permanente?
Muitas vezes, sim. O acesso humano geralmente está vinculado a uma função no trabalho, pois as responsabilidades permanecem. Alguns agentes funcionam da mesma maneira. Um agente de reconciliação que é executado todas as noites, ou um agente de serviço que trabalha em uma fila contínua, precisa de autorização contínua para ser útil. Outros precisam de muito menos: buscar uma fatura, compará-la com um pedido de compra e retornar o resultado. Conceder a qualquer um desses tipos o conjunto completo de permissões de um funcionário seria indefensável. Credenciais de curta duração ajudam em ambos os casos, embora reduzam a margem para uso indevido em vez de eliminá-la, e a expiração, por si só, não anula a permissão subjacente.
O relatório descreve um perfil de inovação adjacente da seguinte forma: “O gerenciamento de acesso a cargas de trabalho, que faz parte de um programa geral de IAM (Gerenciamento de Identidade e Acesso) para máquinas, protege o universo em rápida expansão de cargas de trabalho — que inclui agentes de IA, aplicativos, contêineres e microsserviços — ao aplicar o princípio do privilégio mínimo em tempo de execução, substituindo credenciais estáticas por controles dinâmicos e sensíveis ao contexto. O gerenciamento de acesso às cargas de trabalho elimina permissões permanentes, reduz as superfícies de ataque máquina a máquina e elimina o ponto cego crítico que compromete a maioria das estratégias de confiança zero.”
Mantemos permissões persistentes e fazemos uma pergunta diferente a respeito delas. Não se trata de por quanto tempo um agente detém autoridade, mas de quem a concedeu. Cada conjunto de permissões deve ser aprovado por uma pessoa identificada, com base em evidências que o agente não poderia ter produzido. Um agente capaz de produzir, reproduzir ou atender a essas evidências pode, na prática, aprovar a si mesmo.
A identidade, por si só, não explica a intenção
Uma identidade distinta define qual agente está agindo. Ela não diz nada sobre o que esse agente está tentando alcançar. A distinção se torna relevante assim que um agente recebe uma instrução genérica, como “organize minha viagem de negócios” ou “resolva o problema na conta desse cliente”. O agente pode interpretar a solicitação de maneiras que o usuário nunca teve a intenção, e pode ser desviado do curso pretendido por meio da inserção de prompts ou de dados corrompidos.
A autenticação e a autorização se distinguem neste ponto. A autorização do agente de IA precisa responder a uma pergunta que o processo de login não consegue: essa ação específica está dentro dos limites do que a pessoa realmente solicitou?
O relatório descreve outro perfil de inovação que aborda exatamente isso: “O controle de acesso baseado em intenção é uma estrutura de autorização emergente que substitui permissões amplas e permanentes e, embora atualmente seja voltada para a IA agênica, oferece ampla aplicabilidade. O controle de acesso baseado em intenção concede acesso a recursos de back-end com base na intenção capturada ou inferida dos usuários que interagem com um agente e avalia as ações pretendidas pelo agente em relação a essa intenção.”
A intenção inferida é um insumo útil para uma decisão de acesso. Não se trata de uma aprovação. A intenção captada a partir de uma conversa ainda é uma descrição construída dentro do próprio contexto do agente; portanto, um agente desalinhado ou que tenha recebido instruções predefinidas pode moldá-la. A avaliação da intenção pode restringir o que um agente faz dentro da autoridade que alguém concedeu. Estabelecer que a autoridade foi concedida é uma etapa separada. Três controles já estão desempenhando funções concretas neste ponto, e cada um tem o mesmo limite:
- A verificação da identidade da pessoa confirma quem ela é. Não confirma o que ela concordou em fazer.
- A inferência da intenção determina qual parecia ser o objetivo do pedido. Ela não determina que a pessoa tenha visto a ação que se seguiu.
- A definição restrita do âmbito de alcance determina apenas o que o agente pode alcançar. Ela não indica que essa ação específica fosse intencional.
O que as ações de maior impacto exigem é uma ligação entre três elementos: uma pessoa verificada, o agente que atua em seu nome e a ação específica ou permissão que essa pessoa aprovou. Portanto, a ação deve ser retida antes de entrar em vigor. A camada de controle, e não o agente, deve apresentar o que a ação faz e dentro de quais limites, e a decisão deve ser retornada fora da banda, diretamente para essa camada de controle, por meio de um canal que não seja mediado pelo agente proponente. Chamamos a evidência divulgada contra essa decisão de “resistente a agentes”: o agente não pode gerá-la, reproduzi-la ou obtê-la recrutando um segundo agente em outro dispositivo. O iProov Dynamic Liveness fornece essa evidência, comprovando a presença de um ser humano genuíno no momento da aprovação e vinculado à ação exata. Definimos como essa delegação deve funcionar em um artigo separado sobre autorização humana verificada em IA agênica.
Comece separando as pessoas dos agentes e, em seguida, comprove a aprovação
Os agentes não devem ser extensões invisíveis da conta de um funcionário. Atribua a cada um deles uma identidade própria, designe um responsável, mantenha suas permissões restritas, monitore suas atividades e remova seu acesso quando o trabalho estiver concluído. Quando tratado adequadamente, trata-se de uma gestão do ciclo de vida dos agentes de IA, e não de uma configuração pontual: os agentes são provisionados, revisados, reatribuídos e desativados, e a governança dos agentes de IA é o que garante a integridade desse ciclo à medida que o número de agentes cresce.
Em seguida, decida quais ações não podem ser realizadas apenas com base na autoridade delegada, pois é nesse ponto que uma prova mais robusta se justifica. As organizações costumam limitar os agentes a tarefas de baixo impacto, não porque o agente não possa fazer mais, mas porque não conseguem comprovar a aprovação humana para qualquer ação de maior importância. Uma prova de aprovação que nenhum agente possa fornecer elimina esse limite. A iniciação de pagamentos, alterações de beneficiários, elevação a funções privilegiadas e mudanças nas próprias permissões de um agente podem, cada uma delas, ser automatizadas até o ponto de aprovação e mantidas ali, prontas para autenticação reforçada; em seguida, são liberadas mediante um comprovante que indique o aprovador, a ação, os parâmetros que lhe foram apresentados e um período de validade de uso único. O atrito se concentra em alguns momentos decisivos, enquanto o trabalho rotineiro entre eles ocorre ininterruptamente.
A evidência de aprovação não pode ser reconstruída posteriormente; portanto, a ligação entre uma decisão humana e a ação que ela autoriza deve ser definida antes da implantação dos agentes. Essas etapas exigem esforço no início de um projeto, mas evitam um problema muito maior no futuro: milhares de agentes autônomos operando por meio de credenciais compartilhadas ou mal gerenciadas, tomando decisões de grande impacto que não é possível atribuir a nenhuma pessoa identificável.
Gartner, Ciclo de Hype para Identidade Digital, 2026, Zachary Smith, Nayara Sangiorgio, 6 de julho de 2026.
Gartner e Hype Cycle são marcas registradas da Gartner, Inc. e/ou de suas afiliadas.
A Gartner não endossa nenhuma empresa, fornecedor, produto ou serviço mencionado em suas publicações e não aconselha os usuários de tecnologia a selecionarem apenas os fornecedores com as classificações mais altas ou outras designações. As publicações da Gartner refletem as opiniões da organização de análises de negócios e tecnologia da Gartner e não devem ser interpretadas como afirmações de fato. A Gartner isenta-se de todas as garantias, expressas ou implícitas, com relação a esta publicação, incluindo quaisquer garantias de comercialização ou adequação a uma finalidade específica.
Próximo artigo da série: por que a visibilidade da identidade é tão importante quando pessoas, máquinas e agentes de IA estão todos interagindo no mesmo ambiente.
