9 de setembro de 2026
Conceder a um agente de IA o uso irrestrito de uma conta de colaborador pode parecer a escolha mais pragmática. A conta já está autenticada, já dispõe das permissões adequadas e o projeto pode avançar sem 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 registo de auditoria indica que um colaborador abriu um ficheiro, alterou um registo ou aprovou uma transação, quando, na realidade, foi o agente que realizou o trabalho. A responsabilização torna-se uma questão de suposições, e o agente detém, discretamente, muito mais acesso do que o necessário para a sua tarefa.
Atribuir a cada agente a sua própria identidade é a correção adequada, e é a primeira de duas. Uma identidade distinta determina qual o agente que agiu. Não determina, porém, que um ser humano responsável tenha aprovado a ação do agente. Esse segundo problema persiste mesmo com um programa de identificação bem gerido, e é esse que acarreta consequências legais e financeiras.
O Hype Cycle™ 2026 da Gartner® para a Identidade Digital define a categoria da seguinte forma: «A identidade dos agentes de IA é a representação digital única dos agentes de IA no seio de uma organização. Estabelecer e gerir a identidade dos agentes de IA, incluindo assistentes e chatbots, permite que os sistemas de gestão de identidade e acesso (IAM) atribuam identificadores únicos, emitam credenciais específicas para o acesso a recursos (por exemplo, APIs, dados e serviços) e estabeleçam uma responsabilização humana clara e pistas de auditoria em todos os sistemas da empresa.»
Identificadores únicos, credenciais com âmbito específico e um registo de auditoria que atribui as ações ao agente correto são, todos, propriedades de atribuição. Estabelecem qual o agente que agiu e sob a autoridade de quem, o que é uma questão diferente de saber se uma pessoa identificada aprovou a ação que realizou.
As credenciais emprestadas e a segurança das contas de serviço criam um ponto cego
Os primeiros projetos de IA tendem a funcionar com os recursos que já estão disponíveis:
- Um assistente interno pode herdar permissões excessivas, a menos que o seu acesso delegado seja explicitamente restringido.
- Um fluxo de trabalho passa por uma conta de serviço partilhada.
- Um programador liga um agente a uma API utilizando uma chave de longa duração.
Estas configurações geram diversos riscos: acesso excessivo, atribuição ambígua ou credenciais persistentes. O agente pode receber mais permissões do que as necessárias para a sua tarefa. A atividade humana e a do agente podem confundir-se quando as credenciais são partilhadas. As equipas de segurança podem não dispor de uma forma fiável de saber quando um agente está a funcionar ou quais as transações que este concluiu.
É por isso que a segurança das contas de serviço se tornou um problema urgente, em vez de uma mera questão administrativa. Uma conta de serviço partilhada nunca foi concebida para representar um agente autónomo que toma as suas próprias decisões à velocidade de uma máquina, e uma chave de API estática não contém qualquer informação sobre quem autorizou o trabalho nem porquê.
As credenciais emprestadas também comprometem a não repudiação – uma característica de segurança que comprova que uma determinada pessoa enviou uma mensagem ou efetuou uma transação, e não pode posteriormente negar tê-lo feito. Quando uma pessoa e um agente partilham uma mesma identidade, a organização não consegue provar qual deles realizou uma determinada ação. De acordo com o relatório: «A prática perigosa de implementar agentes de IA como proxies que operam com credenciais de acesso humanas viola os requisitos de auditoria, rastreabilidade e não repúdio, aumentando 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 as resolver.
O que muda com uma identidade separada?
Uma identidade dedicada atribui ao agente o seu próprio registo no ambiente 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. Pode ser desativada sem perturbar o colaborador ou a equipa por trás dela. A autenticação do agente de IA torna-se um evento distinto que é possível visualizar e analisar, em vez de algo oculto no interior de uma sessão humana. Podem ser atribuídas ao agente credenciais de curta duração, em vez de uma palavra-passe permanente ou de uma chave API. O seu acesso pode ser limitado a uma aplicação, tarefa ou transação específica. A sua atividade pode ser analisada de forma independente, separadamente da de qualquer ser humano.
A reatribuição merece especial atenção. A reatribuição de um agente a um proprietário ou mandante diferente constitui uma mudança de identidade e não uma atualização de um campo, pelo que deve exigir uma nova verificação da pessoa que agora assume a responsabilidade. Um registo de propriedade que possa ser editado sem se restabelecer quem concordou em assumir o risco deixa a relação aberta a contestação.
Isto aproxima-se mais da forma como o Zero Trust deve funcionar, em que uma autenticação anterior não é considerada prova definitiva de nada. O caso «agentic» leva essa lógica um passo mais além. 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 costuma estar ligado a uma função profissional, uma vez que as responsabilidades permanecem. Alguns agentes funcionam da mesma forma. Um agente de reconciliação que é executado todas as noites, ou um agente de serviço a tratar de uma fila contínua, necessita de autorização permanente para ser útil. Outros precisam de muito menos: recuperar uma fatura, comparar-na com uma ordem de compra e apresentar o resultado. Conceder a qualquer um destes tipos o conjunto completo de permissões de um funcionário seria indefensável. As credenciais de curta duração ajudam em ambos os casos, embora reduzam a margem para uso indevido em vez de a eliminar por completo, 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: «A gestão do acesso às cargas de trabalho, que faz parte de um programa global de IAM (gestão de identidades e acessos) para máquinas, protege o universo em expansão das cargas de trabalho — que inclui agentes de IA, aplicações, contentores e microsserviços —, aplicando o princípio do privilégio mínimo em tempo de execução e substituindo credenciais estáticas por controlos dinâmicos e sensíveis ao contexto. A gestão do acesso às cargas de trabalho elimina as 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 as autorizações persistentes e colocamos uma questão diferente sobre elas. Não se trata de saber durante quanto tempo um agente detém a autoridade, mas sim quem a concedeu. Cada conjunto de autorizações deve ser aprovado por uma pessoa identificada, com base em provas que o agente não poderia ter produzido. Um agente capaz de produzir, reproduzir ou satisfazer essas provas pode, na prática, aprovar-se a si próprio.
A identidade, por si só, não explica a intenção
Uma identidade distinta determina qual o agente que está a agir. Não diz nada sobre o que esse agente está a tentar alcançar. A distinção torna-se relevante assim que um agente recebe uma instrução genérica, como «organiza a minha viagem de negócios» ou «resolve o problema com a conta deste cliente». O agente pode interpretar o pedido de formas que o utilizador nunca pretendia, e pode ser desviado do seu objetivo através da inserção de comandos ou de dados corrompidos.
A autenticação e a autorização separam-se aqui. A autorização do agente de IA tem de responder a uma questão que um processo de início de sessão não consegue resolver: esta 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 esta questão: «O controlo de acesso baseado na intenção é um quadro de autorização emergente que substitui as permissões amplas e permanentes e que, atualmente, se destina à IA agênica, mas oferece uma ampla aplicabilidade. O controlo de acesso baseado na intenção concede acesso a recursos de back-end com base na intenção captada ou inferida dos utilizadores 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 contributo útil para uma decisão de acesso. Não se trata de uma aprovação. A intenção captada a partir de uma conversa continua a ser uma descrição construída no contexto próprio do agente, pelo que um agente desalinhado ou com prompts injetados pode moldá-la. A avaliação da intenção pode restringir o que um agente faz dentro da autoridade que alguém lhe concedeu. Estabelecer que a autoridade foi concedida é um passo à parte. Três controlos estão, cada um, a desempenhar funções concretas nesta fase, e cada um tem o mesmo limite:
- A verificação da identidade permite determinar quem é a pessoa. Não determina o que essa pessoa concordou em fazer.
- A inferência da intenção determina qual era, aparentemente, o sentido do pedido. Não determina, porém, que a pessoa tenha visto a ação que daí resultou.
- A definição do âmbito de alcance estabelece, de forma restrita, o que o agente pode alcançar. Não estabelece, porém, que essa ação específica fosse pretendida.
O que as ações de maior impacto necessitam é de uma ligação entre três elementos: uma pessoa verificada, o agente que age em seu nome e a ação ou autorização específica que essa pessoa aprovou. Assim, a ação deve ser retida antes de entrar em vigor. A camada de controlo, e não o agente, deve apresentar o que a ação faz e dentro de que limites, e a decisão deve ser devolvida fora da banda, diretamente a essa camada de controlo, através de um canal que o agente proponente não medeia. Chamamos à evidência divulgada relativamente a essa decisão «resistente ao agente»: o agente não pode gerá-la, reproduzi-la nem obtê-la através do recrutamento de um segundo agente noutro 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 vinculada à ação exata. Explicámos como essa delegação deve funcionar num artigo separado sobre a autorização humana verificada na IA agênica.
Comece por distinguir 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 colaborador. Atribua a cada um a sua própria identidade, designe um responsável, mantenha as suas permissões restritas, acompanhe as suas ações e retire-lhe o acesso quando o trabalho estiver concluído. Quando tratado adequadamente, trata-se da gestão do ciclo de vida dos agentes de IA, em vez de uma configuração pontual: os agentes são provisionados, revistos, reatribuídos e retirados de serviço, e a governação dos agentes de IA é o que garante a integridade desse ciclo à medida que o número de agentes cresce.
Em seguida, decida quais as ações que não podem ser realizadas apenas com base na autoridade delegada, pois é aqui que uma prova mais sólida se justifica. As organizações limitam frequentemente os agentes a tarefas de baixo impacto, não porque o agente não seja capaz de 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 satisfazer elimina esse limite. A iniciação de pagamentos, as alterações de beneficiários, a elevação a funções privilegiadas e as alterações às próprias permissões de um agente podem, cada uma delas, ser automatizadas até ao ponto de aprovação e mantidas nesse ponto, prontas para uma autenticação reforçada, sendo depois liberadas mediante um recibo que indique o aprovador, a ação, os parâmetros que lhe foram apresentados e um período de validade de utilização única. O atrito concentra-se num punhado de momentos decisivos, enquanto o trabalho rotineiro entre eles decorre sem interrupções.
As provas de aprovação não podem ser reconstruídas a posteriori, pelo que a ligação entre uma decisão humana e a ação que esta autoriza tem de ser definida antes da implementação dos agentes. Estas etapas exigem um esforço no início de um projeto, mas evitam um problema muito maior mais tarde: milhares de agentes autónomos a operar através de credenciais partilhadas ou mal geridas, tomando decisões com consequências graves que não é possível atribuir a nenhuma pessoa identificável.
Gartner, «Hype Cycle for Digital Identity», 2026, Zachary Smith, Nayara Sangiorgio, 6 de julho de 2026.
A Gartner e o Hype Cycle são marcas registadas da Gartner, Inc. e/ou das suas afiliadas.
A Gartner não apoia nenhuma empresa, fornecedor, produto ou serviço mencionado nas suas publicações, nem aconselha os utilizadores de tecnologia a escolherem apenas os fornecedores com as classificações mais elevadas ou outras designações. As publicações da Gartner refletem as opiniões da organização de análise empresarial e tecnológica da Gartner e não devem ser interpretadas como afirmações de facto. A Gartner isenta-se de todas as garantias, expressas ou implícitas, relativamente a esta publicação, incluindo quaisquer garantias de comercialização ou adequação a um fim específico.
Próximo tema da série: por que razão a visibilidade da identidade é tão importante quando pessoas, máquinas e agentes de IA interagem no mesmo ambiente.
