Durante quatro décadas, a Gestão de Identidade e Acesso assentou numa base estável: um ser humano autenticava-se numa aplicação, e a aplicação mediava todo o acesso a recursos a jusante. A aplicação era, num sentido real, a política de autorização tornada visível — menus inacessíveis para utilizadores não autorizados, fluxos de trabalho a aplicar a ordem operacional, formulários a validar entradas. O humano era o âncora de confiança; a aplicação era o guardião; e o trabalho do IAM era gerir a ligação entre ambos.
Esse alicerce está a fracturar. Não porque a identidade se tenha tornado menos importante, mas porque dois dos seus três pilares mudaram fundamentalmente. A camada aplicacional está a dissolver-se — os agentes de IA interagem agora diretamente com APIs e repositórios de dados, contornando completamente a interface de utilizador — e o conjunto de principals que requerem identidade explodiu muito além dos seres humanos. As identidades não humanas (NHIs) — contas de serviço, bots, chaves API e agentes de IA cada vez mais autónomos — já ultrapassam as identidades humanas em rácios entre 45 para 1 e 144 para 1 em muitos ambientes empresariais. A questão já não é como gerir o acesso humano a aplicações. É como gerir uma hierarquia de principals humanos e não humanos, a operar à velocidade da máquina, além das fronteiras organizacionais, sem camada aplicacional para servir de ponto de controlo natural.12
Que trabalho de autorização estava a camada aplicacional a executar que ninguém modelou explicitamente?
A perda da camada aplicacional é apenas parcialmente sobre experiência do utilizador. Arquiteturalmente, a aplicação executava enormes quantidades de trabalho de autorização que nunca foi modelado explicitamente como tal. Delimitava as operações que um utilizador podia invocar. Aplicava sequenciamento — não era possível saltar etapas num fluxo de trabalho. Restringia o raio de impacto de qualquer sessão autenticada ao que podia ser realizado através da sua interface. Quando os agentes substituem as aplicações ao chamar APIs diretamente, toda essa autorização implícita tem de ser re-expressa explicitamente — como restrições de ação em tempo de execução sobre a identidade do agente, como âmbitos de token, como portas de aprovação humana ao estilo CIBA para operações de elevado risco. O trabalho não desaparece; torna-se visível pela primeira vez, e a infraestrutura IAM tem de o absorver.3
Por que as arquiteturas AIgénicas criam cadeias de delegação em vez de autenticação de salto único?
O fluxo de autenticação tradicional era de um único salto: o utilizador autentica-se, obtém um token, acede a um recurso. As arquiteturas AIgénicas criam cadeias de delegação. Um humano autoriza um agente orquestrador; o orquestrador gera sub-agentes (mais corretamente designados Agentlets); os Agentlets invocam ferramentas; as ferramentas chamam APIs externas. Cada elo é um principal distinto que requer a sua própria identidade. Cada um acrescenta um ponto onde a autoridade pode ser excessivamente concedida, mal configurada ou órfã muito depois de a tarefa estar concluída.4
Este padrão por defeito — em que os agentes herdam a identidade e as permissões do seu principal em vez de deterem identidades explicitamente aprovisionadas próprias — é o Modelo de Herança de Identidade. Não requer trabalho para implementar, o que explica a sua universalidade; e acarreta um risco desproporcionado, porque os direitos fluem pela cadeia de delegação sem restrições.
Gerir isto requer a transição da gestão de credenciais plana para a modelação de hierarquia de principals — expressar não apenas “o que é esta entidade” mas “quem autorizou esta entidade, sob que restrições, e por quanto tempo.” O IETF está já a rascunhar extensões OAuth 2.0 para suportar isto, introduzindo parâmetros actor_token que documentam criptograficamente a cadeia de delegação dentro do próprio token. O encanamento de protocolo está a ser alargado, não substituído — mas a riqueza semântica necessária é de uma ordem de magnitude superior ao que o OAuth foi originalmente concebido para transportar.5
Que quatro camadas de infraestrutura de identidade requer a arquitetura AIgénica?
Uma resposta coerente a estas pressões está a tomar forma na indústria, construída sobre quatro camadas complementares que cada uma aborda um aspeto diferente do problema.
LDAP/Active Directory mantém o seu papel, mas restringido ao que faz bem: integração e classificação por tipo. A disciplina crítica é a separação estrutural — agentes e humanos têm de ocupar unidades organizacionais distintas com esquemas de objetos diferentes, proprietários de ciclo de vida diferentes e processos de emissão diferentes. É o análogo arquitetural de países diferentes emitirem passaportes diferentes: não apenas uma partição de espaço de nomes, mas uma afirmação sobre proveniência e processo de governação. Uma credencial humana requer um fluxo de trabalho de RH e captura biométrica para ser emitida; uma credencial de agente requer um evento de aprovisionamento por parte de um programador. No momento em que estes processos partilham infraestrutura, a distinção humano/NHI torna-se inaplicável a jusante.6
PKI — especificamente SPIFFE/SPIRE para identidade de carga de trabalho — fornece aos agentes identidades criptográficas que codificam o que uma carga de trabalho é em vez de quem uma pessoa é. Certificados de curta duração (a indústria está a convergir para prazos máximos de 47 dias) impõem a rotação e limitam o raio de impacto do comprometimento. Crucialmente, a hierarquia de CA para agentes é fisicamente separada da hierarquia de CA para humanos, o que significa que uma parte confiante pode inspecionar a cadeia emissora e determinar imediatamente a classe de principal — as credenciais de agente não podem ser confundidas com credenciais humanas na camada criptográfica.7
As Credenciais Verificáveis (VCs) transportam a semântica de delegação que o PKI não consegue expressar nativamente. Uma VC emitida a um agente pode codificar a cadeia completa de principal — “este agente foi delegado pelo humano X, autorizado pela credencial organizacional Y, com âmbito Z, expirando em T” — como um documento com assinatura criptográfica e auto-verificável. Ao contrário do LDAP, que requer uma consulta ao diretório em tempo real e confia no servidor de diretório, uma VC é verificável por qualquer parte que consiga resolver a chave pública do emissor. Ao contrário de um JWT, transporta afirmações de proveniência ricas em vez de apenas afirmações de âmbito. As VCs encadeadas tornam as árvores de delegação auditáveis de ponta a ponta sem requerer um diretório partilhado ou um acordo de federação pré-estabelecido entre organizações.8
Os Identificadores Descentralizados (DIDs) e o Resolvedor Universal DIF completam o quadro para a confiança entre organizações. Um DID — estruturado como did:método:identificador — é um identificador globalmente único que resolve para um Documento DID contendo as chaves públicas e os métodos de autenticação da entidade, sem necessidade de CA. O Resolvedor Universal funciona como o DNS para o e-mail: um único ponto de resolução que encaminha para mais de 45 drivers específicos de método, permitindo a qualquer parte verificar qualquer DID independentemente do registo ou infraestrutura que o ancora. Para as interações de agentes entre organizações, isto elimina a necessidade de raízes de CA partilhadas ou acordos de federação bilaterais — a VC transporta a confiança, o resolvedor fornece o material de chave, e o registo é simplesmente um registo de chaves resistente a adulteração.910
Por que a fronteira humano/NHI tem de ser aplicada estruturalmente, e não detectada após o facto?
Duas em cada cinco plataformas SaaS actualmente não conseguem distinguir identidades humanas de não humanas. A resposta padrão — monitorização comportamental e detecção de anomalias — é necessária mas insuficiente por si só. Os sinais comportamentais operam após o facto, toleram falsos negativos e requerem uma linha de base treinada para ser significativos. A abordagem mais robusta é tornar o tipo de credencial estruturalmente inacessível pela classe de principal errada, de forma a que a detecção nunca seja necessária.6
Para humanos, a autenticação FIDO2/passkey fornece o nível criptográfico de base: a chave privada nunca sai do autenticador de hardware, e o gesto de Presença do Utilizador prova que uma entidade física actuou. Para agentes, o atestado com ligação a hardware via TPM ou enclave seguro prova que código específico e não modificado está a executar em infraestrutura autorizada — uma propriedade diferente da vivacidade biológica, mas igualmente impossível de falsificar remotamente.11
O desafio é que a detecção de vivacidade como discriminador humano/NHI está sob pressão genuína. Actuadores robóticos podem desencadear requisitos de gesto físico; a IA generativa tornou trivialmente produzíveis rostos sintéticos em tempo real à escala. A garantia de segurança está a deslocar-se de “prova definitivamente que um humano estava presente” para “prova que quem controla este hardware executou uma ação, suportada por sinais comportamentais e de proveniência de sinal.” Esse enquadramento probabilístico — desconfortável para os enquadramentos de conformidade construídos sobre garantia de identidade binária — é cada vez mais a descrição honesta do que a autenticação moderna consegue fornecer.12
Para onde converge a arquitetura IAM para sistemas AIgénicos?
A consequência prática de tudo o acima é que a identidade se torna o plano de controlo para os sistemas AIgénicos — a camada onde o âmbito de delegação é definido, os registos de auditoria se acumulam e a revogação é aplicada.
A trajectória aponta para um formato de credencial unificado baseado em DID para humanos e agentes, com a distinção de tipo humano/agente preservada como uma afirmação de primeira classe no esquema de credencial em vez de como um artefacto da estrutura de diretório. O papel dos RH evolui de gerir um diretório para funcionar como um oráculo de governação — a instituição autorizadora que emite a VC de arranque que estabelece a identidade de um humano, após o que o DID e a sua cadeia de credenciais são auto-sustentados. O enquadramento eIDAS 2.0 da UE, construindo carteiras de identidade digital nacionais sobre as bases W3C VC/DID, é a experiência em tempo real deste modelo à escala estatal.
A mudança mais profunda é filosófica. A Gestão de Identidade e Acesso foi concebida para responder a uma questão simples: esta pessoa está autorizada a utilizar esta aplicação? A questão emergente é mais complexa: este principal — humano ou agente, a operar numa cadeia de delegação de profundidade desconhecida, potencialmente além das fronteiras organizacionais — está autorizado a executar esta ação específica, e existe algures nessa cadeia uma decisão humana que possa ser responsabilizada? Responder a essa questão requer a pilha completa de quatro camadas. Requer também aceitar que o perímetro definido que o IAM foi construído para defender já não existe — e conceber para auditoria, rastreabilidade e confiança probabilística em vez de para a ilusão de uma fronteira definitiva.
Revisto em 2026-04-27. Rácio NHI corrigido para 45 para 1 a 144 para 1 (fontes primárias: CSA RSAC 2025, Entro Labs H1 2025); sub-agentes anotados como mais corretamente designados Agentlets; resumo executivo actualizado para padrão de conceção arquitetural de quatro camadas. Conteúdo substantivo inalterado.
Footnotes
-
The End of Traditional SaaS: How AI Agents Are Redefining Business Applications — Os agentes de IA eliminam a necessidade de uma pilha aplicacional rígida ao consultarem e atualizarem bases de dados diretamente. ↩
-
Cloud Security Alliance, “Securing Non-Human Identities in the Age of AI Agents,” RSAC 2025 — limite inferior de 45 para 1. Entro Labs, “NHI & Secrets Risk Report H1 2025” — limite superior de 144 para 1, face a 92 para 1 no primeiro semestre de 2024. ↩
-
Authorize an AI Agent to Perform Tasks on Your Behalf — Identity for AI — Série de tutoriais da Ping Identity sobre padrões de autorização de agentes, incluindo aprovação humana ao estilo CIBA. ↩
-
AI Agent Identity: The Foundation of Trust for Autonomous Agents — Por que os agentes autónomos necessitam de identidades digitais distintas e verificáveis e como funcionam as cadeias de delegação. ↩
-
OAuth 2.0 Extension for AI Agents Acting on Behalf of Users (IETF draft) — Extensão de protocolo em rascunho que adiciona parâmetros
actor_tokenpara documentar cadeias de delegação dentro de tokens OAuth. ↩ -
How to Distinguish Between Human and Non-Human Identities — As identidades humanas e não humanas requerem abordagens de autenticação e governação estruturalmente distintas. ↩ ↩2
-
Agentic AI Needs Stronger Digital Certificates — Por que os prazos dos certificados estão a reduzir para 47 dias como funcionalidade de governação para identidades de carga de trabalho. ↩
-
Aries RFC 0104: Chained Credentials — As cadeias de delegação com assinatura criptográfica permitem verificação offline e delegação de privilégios robusta. ↩
-
Universal Resolver — resolve practically any DID — Um utilitário único para resolver Identificadores Descentralizados em mais de 45 drivers de método DID. ↩
-
Decentralized Identifiers (DIDs) v1.1 — W3C — A especificação W3C para Identificadores Descentralizados, Documentos DID e resolução de DID. ↩
-
What Is FIDO2? — Microsoft Security — Passkeys e credenciais de início de sessão FIDO2 criadas com criptografia de chave pública com chaves privadas ligadas a hardware. ↩
-
What Is Liveness Detection? — Daon — Abordagens multi-sinal para confirmar a presença humana numa era de identidade sintética. ↩