(1/3) Já não há ninguém ao teclado
Há dias que ando a matutar muito sobre a identidade — pessoal e pública, humana e sintética — e não publiquei nada para conseguir reservar tempo e trabalhar nisto. Tenho andado mergulhado num único problema, a ler especificações e rascunhos de protocolos até tarde, porque acho que está prestes a tornar-se um dos problemas estruturais da nossa área e quase ninguém, fora de um punhado de grupos de normas, o explica em termos claros.
O problema é este: todos os sistemas de identidade que construímos nas últimas três décadas dão como certo que há um humano à frente do teclado. Alguém inicia sessão. Alguém vê um ecrã de consentimento. Alguém carrega em «aceitar» e pode, depois, ser responsabilizado pelo que se segue. A autenticação responde a quem és, a autorização a o que podes fazer, e o registo de auditoria a quem fez isto. As três assentam no mesmo pressuposto silencioso: que por trás de cada acção está alguém. Os utilizadores que escapavam a esse "alguém" fomos cobrindo-os à pressa com contas de serviço, artefactos vários, sistemas de permissões.
Os agentes quebram esse pressuposto e misturam as acções das contas de serviço com as dos utilizadores reais.
Nós, que somos engenheiros seniores, gerimos o IAM, a resposta a incidentes e os guardrails que se interpõem entre um serviço e aquilo que tem permissão para o chamar. Por isso, quando digo que o modelo actual não dá conta dos agentes autónomos, não é uma previsão. É que fui ver onde estão as costuras, e já se estão a descoser.
Um agente age com as tuas credenciais, indistinguível de ti
Comecemos pelo caso mais simples, porque já está em produção por toda a parte. Dás a um assistente acesso à tua caixa de entrada, ao teu calendário, ao teu repositório. Por baixo, reutiliza os teus tokens, os teus cookies, a tua sessão. Para qualquer serviço a jusante, o agente és tu. O recente grupo de trabalho da OpenID Foundation disse-o com clareza: os agentes "agem muitas vezes de forma indistinguível dos utilizadores, criando lacunas de responsabilização e riscos de segurança".
É o problema do confused deputy, só que agora o delegado raciocina, improvisa e continua a trabalhar durante horas depois de te teres levantado da cadeira. Um cliente tradicional age sobre "entradas de utilizador estruturadas e sem ambiguidade" — um clique num botão, o envio de um formulário, uma concessão de intenção clara e auditável. Um agente interpreta instruções não estruturadas, uma cadeia de email reencaminhada, uma captura de ecrã, e decide o que fazer no momento da inferência. O sinal de consentimento explícito e legível por máquina sobre o qual foi construído todo o mundo do OAuth desapareceu. Resta software a agir com toda a tua autoridade e nada do teu critério, e um registo que não vos sabe distinguir um do outro.
Qualquer um pode cunhar um cliente anónimo, e ninguém o assina
Desce uma camada, até à forma como os agentes obtêm a sua identidade de início, e piora. O Model Context Protocol — a norma de ligação para a qual convergiu a maior parte do tooling de agentes — apoiou-se em Dynamic Client Registration para se manter sem atrito: qualquer cliente se pode registar num servidor e obter credenciais, sem papelada. Cómodo, e um buraco de segurança por onde passa uma frota inteira. Como o descreve o paper da OpenID, "um endpoint de registo público e não autenticado permite criar clientes sem qualquer ligação a um programador real… uma ausência total de rasto documental", aberto ao "abuso do endpoint (p. ex., DoS por registo em massa)".
Assim, a população de agentes está a explodir, e boa parte dela é anónima por construção. Não há nenhuma parte responsável do outro lado da credencial. Quando um desses clientes faz algo que não devia, não consegues seguir o fio até ninguém a quem pedir contas. Os autores da OpenID dão ao resultado o nome exacto: "um buraco negro para a responsabilização e a análise forense". Essa frase ficou-me na cabeça uma semana, porque já fixei registos assim. Vês a acção. Não encontras o actor.
A delegação parte-se no instante em que cruza a fronteira de uma empresa
Dentro de uma só empresa, uma equipa de plataforma competente consegue tapar boa parte disto. Dá ao agente uma identidade de workload, fá-lo passar pelo IdP corporativo, limita-lhe as permissões, e o caso de um único domínio de confiança funciona razoavelmente bem hoje. Quero ser justo nisto: as peças fundamentais — OAuth 2.1, PKCE, tokens de vida curta e âmbito limitado — são sólidas, e para um agente que chama ferramentas internas são, para já, suficientes.
A costura rasga-se no instante em que um agente cruza uma fronteira organizacional. Um agente financeiro que puxa do teu banco, de uma API de dados de mercado e de uma central de crédito opera em três domínios de confiança distintos, e nenhum fornecedor de identidade é a fonte de verdade para os três. As frameworks de identidade de workload como SPIFFE/SPIRE assentam no controlo de uma infraestrutura partilhada e, nas palavras do paper, "não se estendem naturalmente entre organizações". A verdadeira delegação exige que o token de acesso transporte duas identidades distintas — a pessoa que delegou e o agente que age — e que o âmbito se atenue a cada salto quando um agente subdelega noutro. A delegação recursiva entre empresas, com o rasto de auditoria intacto de ponta a ponta, está em grande medida por resolver. E a economia aberta de agentes entre organizações para a qual todos correm vive inteira do outro lado dessa costura.
Mil pedidos de aprovação equivalem a nenhuma aprovação
A correcção instintiva para tudo isto é "mantém um humano no ciclo: que o agente pergunte". Não sobrevive ao contacto com a escala. Um só agente de marketing a optimizar um orçamento pode disparar centenas de acções distintas em segundos; uma só pessoa pode ter atrás de si dezenas de agentes a tomar milhares de decisões por dia. O EU AI Act, e bem, exige "supervisão efectiva" para os sistemas de alto risco. Mas pedir a um humano que aprove cada acção autónoma produz aquilo a que o paper chama fadiga de consentimento: "um dilúvio incontrolável de pedidos de permissão" que "reduz paradoxalmente a segurança", porque uma pessoa que carrega em "aceitar" quatrocentas vezes por dia não está a exercer critério nenhum. Carimba sem olhar, e a um atacante basta-lhe que carimbe uma vez.
A supervisão que não escala não é supervisão. É teatro, com um modo de falha pior do que não ter nenhuma, porque tem o aspecto de controlo.
Revogar um agente continua a ser um problema em grande medida por resolver
Supõe agora que aconteceu o pior: um agente está comprometido, ou simplesmente porta-se mal. Queremo-lo fora. Também aqui a resposta honesta em 2026 é que ainda não somos bons nisto. Os autores da OpenID chamam à revogação "um problema crítico, e em grande medida por resolver", e com os agentes agrava-se, porque uma única identidade comprometida pode "desencadear uma falha em cascata por todo um ecossistema de sub-agentes" nos quais já tinha delegado. Revogar um token ao portador não chega ao fundo de uma cadeia de autoridade que já foi sendo passada de mão em mão.
E a revogação é apenas o travão de emergência. O requisito mais profundo é o desaprovisionamento: apagar de forma permanente a identidade de um agente e cada permissão que acumulou, em todos os sistemas que tocou, com rapidez suficiente para que uma credencial comprometida e adormecida não possa ser reactivada mais tarde. Um agente opera a velocidade de máquina com a autoridade delegada de um humano e um raio de impacto enormemente amplificado. A capacidade de fazer desaparecer um, de forma verificável e em toda a parte, não é um conforto operacional. É uma condição prévia para sequer os deixar funcionar.
Podes ter responsabilização ou privacidade, e hoje tens de escolher
Deixei para o fim aquele que não me sai da cabeça, porque é o nó de que trata o resto desta série.
Tudo o que precede empurra-te para uma só resposta: para tornar um agente responsável, ata-lhe uma identidade real e conhecida. Liga cada acção do agente a uma pessoa com nome e o buraco negro fecha-se. Mas fá-lo e terás construído outra coisa: um sistema onde cada agente que alguém executa fica ligado para sempre à sua identidade real, onde a rastreabilidade que acrescentaste para auditar "possibilita um rastreio entre domínios" e deixa qualquer um compor "perfis comportamentais completos e potencialmente sensíveis" do que os agentes das pessoas fazem o dia todo. Resolveste a responsabilização eliminando a privacidade.
Isto apresenta-se, quase por toda a parte, como um dilema fechado. Ou os agentes são anónimos e irresponsáveis, ou são responsáveis e vigiados. O paper da OpenID é invulgarmente honesto ao admitir que talvez haja uma terceira porta — técnicas de divulgação selectiva, "provas de conhecimento zero e credenciais anónimas", que deixam um agente provar uma afirmação concreta sem revelar quem está por trás —, mas é igualmente honesto ao reconhecer que "integrar estas técnicas com as normas de identidade e os requisitos regulatórios existentes continua a ser um desafio considerável". Caminho assinalado. Porta ainda por construir.
Afasta-te destas seis dores e verás que partilham uma mesma origem. Falsificação de identidade, clientes anónimos, delegação que se parte ao cruzar fronteiras, fadiga de consentimento, agentes que não consegues revogar de forma limpa, responsabilização que te custa a privacidade: não são seis problemas separados. São seis sintomas de uma só garantia que falta: a de que por trás de cada acção está uma pessoa concreta e responsável que consegues encontrar. A autenticação, a autorização e o registo de auditoria foram todos construídos sobre essa garantia. Os agentes tiraram-nos a capacidade de reconhecer com clareza quem detém a autoridade.
Um agente pode ser autónomo — é todo o sentido de construir um —, mas a responsabilização tem de permanecer. Um agente não é uma pessoa jurídica: não o podes processar, nem multar, nem sentá-lo a perguntar-lhe o que tinha em mente. Por isso, por mais camadas de delegação que se empilhem pelo meio, a responsabilidade tem de acabar por assentar num humano real e responsabilizável que escolheu pô-lo a funcionar. É disto que trata todo o problema desta série: de como tornar essa ligação — esta acção remonta àquela pessoa responsável — demonstrável a quem precise de a verificar, sem expor a pessoa a todos os que não precisam. Um agente que não remonta a ninguém não é autonomia. É risco sem dono, a correr a velocidade de máquina: todos a jusante o sofrem, e ninguém pode ser chamado a responder por ele.
Para onde vai isto
Nada disto é ficção científica, e nada está longe. A escala, por si só, força a questão: os autores da OpenID descrevem o destino como "um mundo povoado por milhões de actores não humanos", e as projecções dos fornecedores — indicativas, não palavra de ordem — colocam os agentes em muitas vezes o número de utilizadores humanos dentro de poucos meses. Estamos prestes a implantar uma população de actores autónomos maior do que a humana, sobre uma stack de identidade que dá como certo que cada um deles é uma pessoa capaz de carregar num botão.
Por isso fui à procura do mapa mais claro deste terreno, e encontrei um. O próximo post desta série é uma leitura atenta dele: Identity Management for Agentic AI, da OpenID Foundation, o estudo mais honesto destes problemas que li, incluindo os que admite que ninguém resolveu. Depois, esboçarei como atacaria mesmo o nó mais difícil — responsabilização e privacidade ao mesmo tempo —, porque tenho andado a fazer mais do que ler.
Se estás a construir sistemas agênticos hoje e queres a peça vizinha, a de delimitar o que um agente tem permissão para fazer assim que sabes quem está por trás, escrevi sobre governança verificável para a IA agêntica no início do ano. A identidade é a pergunta do quem; aquela é a pergunta do quê. Precisas das duas. E andamos curtos das duas.


