(2/3) O melhor mapa que temos do problema da identidade agêntica
No primeiro post desta série expliquei porque é que a IA agêntica parte a stack de identidade: tudo o que construímos dá como certo que há um humano ao teclado, e os agentes deitam abaixo esse pressuposto logo no primeiro dia. Prometi o mapa mais claro que conseguisse encontrar deste terreno. É este o mapa.
Quase tudo o que se escreve hoje sobre «identidade de IA» é um fornecedor a explicar porque é que a resposta é, precisamente, aquilo que ele vende. Isto é o oposto disso, e é exactamente por isso que confio. Identity Management for Agentic AI foi preparado para a OpenID Foundation, com edição principal de Tobin South, escrito ao longo de 2025 com o AI Identity Management Community Group e a Loyal Agents Initiative de Stanford, e revisto por um banco enorme de engenheiros de identidade. É o levantamento de um organismo de normas, não um argumento de venda. Diz-te o que já funciona, o que está a emergir e — a parte rara — o que ainda ninguém resolveu. Li-o em profundidade. Aqui fica o que me ficou.
A stack de hoje funciona — dentro de uma empresa, para um agente que espera
O paper divide-se com nitidez em dois: as soluções imediatas para os agentes que enviamos hoje e os problemas de futuro para os agentes que estamos prestes a enviar. O veredicto honesto sobre a primeira metade cabe numa frase, e eu enquadraria toda a área à volta dela:
«Os agentes e os padrões de autenticação e autorização de hoje podem funcionar para agentes síncronos que usam várias ferramentas dentro de um único domínio de confiança, mas não para contextos assíncronos ou multidomínio.»
Lê isto duas vezes. Dentro de uma só empresa, para um agente que age enquanto esperas, os alicerces aguentam. OAuth 2.1 com PKCE protege o fluxo. Externalizas a decisão para um fornecedor de identidade ou para um ponto de decisão de políticas, em vez de a deixares cravada no código — a separação Policy Enforcement Point / Policy Decision Point que o NIST escreveu há uma década. Geres o ciclo de vida do agente com a mesma maquinaria que usas para os colaboradores: SSO para iniciar sessão, e SCIM para aprovisionar e, sobretudo, para desaprovisionar. O paper aponta para trabalho experimental que dá ao SCIM um tipo de recurso AgenticIdentity de primeira classe, de modo a que um agente passe a ser uma entidade gerida, com donos e pertenças a grupos, em vez de uma chave de API órfã. Nada disto é exótico. Uma equipa de plataforma competente consegue construí-lo já.
Há, no entanto, duas condições a segurar este quadro inteiro: síncrono, e domínio de confiança único. Quebra qualquer uma delas e cais na segunda metade do paper, onde os problemas resolvidos se esgotam.
Dar nome aos problemas de futuro, com precisão
Dá nome a um problema com precisão e estás a meio caminho de o resolver — e este paper, tal como o meu próprio trabalho, recusa-se a acenar de longe para as partes difíceis. Enumera-as, com a franqueza de quem já tentou de facto construir isto.
Começa, então, pela pergunta mais básica de todas — afinal, o que é a identidade de um agente? O paper expõe quatro modelos arquitectónicos: a conta de serviço enriquecida (uma identidade de workload acrescida de metadados como agent_model e agent_version — o padrão empresarial provável a curto prazo); a subidentidade de utilizador delegada (uma identidade derivada da sessão do utilizador e atada a ela, o verdadeiro fluxo on-behalf-of); a confiança federada (um tecido interoperável entre domínios, construído sobre algo como o OpenID Federation); e a identidade soberana e portátil (cada agente guarda as suas próprias chaves e um identificador globalmente único, através de esquemas como os DIDs). Propostas como o OpenID Connect for Agents tentam normalizar as claims de identidade por baixo de tudo isto. Ainda não podemos coroar um vencedor — tens de conhecer o território antes de poderes construir o caminho de saída.
Delegação, não personificação, é a espinha dorsal
Se tivesse de comprimir o argumento do paper a um único gesto, seria este: deixa de deixar os agentes personificarem utilizadores, começa a deixá-los carregar autoridade delegada. Hoje um agente age com as tuas credenciais e o registo de auditoria não vos sabe distinguir — o buraco negro que descrevi da última vez. A correcção é um verdadeiro fluxo on-behalf-of em que o token de acesso transporta duas identidades distintas: o utilizador que delegou (na claim sub) e o agente que age (na claim act). Uma única ligação limpa e auditável, desde o primeiro passo.
O poder, e a dificuldade, aparecem com a delegação recursiva — um agente a passar uma subtarefa, e uma fatia da sua autoridade, a outro. Como uma matrioska, diz o paper, e di-lo como aviso. Um servidor de recursos ao fim de uma cadeia de cinco saltos tem de verificar criptograficamente o caminho inteiro de regresso ao humano original, e não apenas o último agente que o chamou. Isso exige atenuação de âmbito: estreitar a permissão de forma demonstrável a cada passo. O paper é refrescantemente concreto quanto às opções — OAuth 2.0 Token Exchange para montagens centralizadas, em estrela, e capability tokens como os Biscuits e os Macaroons para as descentralizadas, onde o portador pode cunhar offline uma versão mais restrita de um token, com a autoridade embutida na própria credencial sob um modelo de capacidades-objecto. É nesta parte que a maioria dos sistemas de agentes em produção se engana em 2026. Correm todos os agentes ao mesmo nível de autorização, com todas as ferramentas, e chamam «fronteira» a um system prompt.
E o problema que faz sombra a tudo isto: a revogação, a que os autores chamam, sem rodeios, «um problema crítico, e em grande medida por resolver». Os tokens atenuados offline pioram-no — revogas o pai e não há forma limpa de chegar aos filhos já delegados a jusante. As respostas que emergem são honestas, mas parciais: a Shared Signals Framework para propagar eventos de revogação em quase tempo real, e o gesto pragmático de limitar uma credencial por número de execuções, para que uma revogação atrasada limite ainda assim o estrago.
A governança tem de passar do clique para o código
No meu primeiro post desta série defendi que a supervisão humana no ciclo colapsa, à escala, em fadiga de consentimento. A resposta do paper é a que eu daria, e é estrutural. Não resolves a fadiga de consentimento pedindo às pessoas que prestem mais atenção. Tiras a governança de cima do clique e pões-na dentro do código.
São três os padrões que o paper expõe, em sofisticação crescente. Política-como-código: um administrador define uma única vez o envelope operacional do agente — limites de orçamento, escalões de dados, velocidade de chamadas — e o sistema impõe-no programaticamente. Autorização baseada na intenção: o utilizador aprova uma intenção de alto nível em linguagem natural («reserva-me a viagem para a conferência»), e o sistema compila-a num conjunto de permissões de menor privilégio. Autorização dinâmica baseada no risco: as acções de rotina passam automaticamente, e só um pedido anómalo desencadeia uma aprovação humana fora de banda, através de CIBA. A ideia que liga tudo é um híbrido — usa o modelo para traduzir a intenção humana difusa numa política formal, legível por máquina, e deixa depois o sistema determinista segurar a linha mesmo que o agente leia mal a instrução. O humano aprova algo intuitivo; o runtime impõe algo exacto. É nessa folga, entre o intuitivo e o exacto, que a segurança de facto vive.
E depois há o dinheiro
A secção que eu não esperava que fosse a mais esclarecedora é a económica. A verdadeira utilidade de um agente aparece quando ele consegue transaccionar — comprar dados, pagar uma API, liquidar uma compra — e todo o modelo de segurança do comércio electrónico dá como certo que há um humano presente no ponto de venda. Tira o humano e precisas de carris novos.
O paper mapeia três camadas que já se estão a formar. O FAPI, o perfil de alta segurança da OpenID Foundation, endurece o OAuth para acções financeiras irreversíveis, com tokens atados ao emissor. O Agent Payments Protocol da Google introduz o Mandate — um artefacto de intenção assinado criptograficamente, dividido num Intent Mandate («eis o que autorizei») e num Cart Mandate («eis a compra concreta que cumpriu essa autorização»), de modo a existir um rasto de auditoria não-repudiável para uma transacção autónoma. E o KYAPay propõe um processo de «Know Your Agent» que, nas palavras do paper, estende «a verificação de identidade tradicional KYC/KYB ao próprio agente», emitindo um token que junta identidade verificada e informação de pagamento. Fica um momento com a expressão — Know Your Agent. O mercado já estende a mão a uma responsabilização com a forma do KYC para os agentes. Só que não a estende de uma maneira que proteja o humano que está por trás do agente. Guarda-me esta ideia.
O único nó que o paper deixa em aberto
Apesar de todo o seu alcance, o documento volta sempre a uma única tensão que é demasiado honesto para resolver, e é a mesma à volta da qual eu ando há uma semana.
«A própria rastreabilidade necessária para as auditorias possibilita um rastreio entre domínios capaz de criar perfis comportamentais completos e potencialmente sensíveis. Os mecanismos de divulgação selectiva — alavancando técnicas criptográficas como as provas de conhecimento zero e as credenciais anónimas — oferecem um caminho em frente… mas integrar estas técnicas com as normas de identidade e os requisitos regulatórios existentes continua a ser um desafio considerável.»
Lá está outra vez, afirmado por quem está mais bem colocado para saber. Para tornar um agente responsável, atas-lhe uma identidade; atas-lhe uma identidade e constróis vigilância. As provas de conhecimento zero e as credenciais anónimas são nomeadas como o caminho que atravessa o muro — provar que «há por trás de mim um humano real e responsável» sem revelar qual humano — e nomeadas, com a mesma clareza, como ainda não integradas com as normas e os reguladores que as tornariam reais.
A própria conclusão do paper enquadra o trabalho desta década em três viragens: verdadeira delegação em vez de personificação, governança escalável em vez de fadiga de consentimento, e confiança interoperável em vez de silos proprietários. Eu acrescentaria a linha que os autores deixam quase de passagem, porque é a restrição que afasta as respostas preguiçosas: aquilo que construirmos «não se pode tornar um jardim murado». O movimento bem financiado, aqui, é um serviço centralizado de identidade de agentes que alugas. O paper, e com razão, diz que a economia aberta de agentes não pode funcionar com a permissão de uma só empresa.
É este, então, o mapa: os alicerces são reais, os problemas de futuro estão nomeados com honestidade crua, e o mais difícil de todos — responsabilização e privacidade ao mesmo tempo, sem um guardião central — fica como desafio em aberto, com uma direcção criptográfica e nenhum caminho construído.
Eu tenho andado a construir o caminho. No terceiro e último post vou esboçar, a alto nível, como desataria esse nó em aberto — como um agente pode provar que há por trás de si um humano real, responsabilizável e verificado, sem que ninguém chegue alguma vez a saber quem. Desta vez não como um levantamento das ideias dos outros. Como a abordagem em que ando a gastar as minhas noites — e que persigo desde 2014, quando comecei a construir com identidades digitais.
Fonte: OpenID Foundation, Identity Management for Agentic AI (editor principal Tobin South, com o AI Identity Management Community Group e a Loyal Agents Initiative de Stanford), Outubro de 2025. Todo o texto citado é do paper.
