Agentes de IA precisam de identidade própria

Meus dias são infraestrutura de identidade. Minhas noites, ultimamente, são um mestrado em IA. Os dois vivem colidindo numa pergunta: quando um agente faz alguma coisa, quem fez?

A maioria das organizações responde por acidente: o agente roda numa service account compartilhada ou num token emprestado de um humano, e o log culpa outra pessoa.

Agente não é usuário com cron job

Uma service account faz uma coisa, num sistema, num horário que alguém definiu. Um agente decide: escolhe ferramentas e as encadeia em ordens que ninguém roteirizou. O modelo de acesso feito para pessoas, papéis revisados a cada trimestre por um gestor, não alcança isso. E a população não é pequena: identidades de máquina já superam humanos em uns 80 para 1 numa empresa típica, saindo de 50 mil por empresa em 2021 para 250 mil em 2025.

Então o primeiro requisito é sem graça: cada agente é uma identidade própria, com credenciais, escopos e dono próprios. O próprio nome no log.

O problema dos bearer tokens

Um bearer token funciona para quem estiver segurando a string. Agentes logam o próprio tráfego HTTP, passam tokens por cadeias de tool calls, guardam contexto em vector stores. Uma linha de log vazada entrega a string para outra pessoa, e você não consegue distinguir o atacante do agente.

DPoP (RFC 9449) corrige essa falha: o agente assina uma prova com uma chave privada a cada request, e o token fica amarrado a essa chave. Um token pescado de um log ou de um trace é inerte sem a chave, que nunca saiu do processo do agente. No Okta, isso funciona no fluxo client credentials em que os agentes vivem.

Antes do DPoP, um token num log é um incidente. Depois, é só uma string.

Um consentimento, ou cem?

Um assistente que lê sua agenda, escreve na sua ferramenta de docs e abre um ticket precisa de três apps como você. Consentimento OAuth por app, o padrão de todo SaaS, significa grants de longa duração espalhados pelos fornecedores, multiplicados por cada agente e funcionário, visíveis de lugar nenhum.

O Cross App Access passa essa autoridade pelo identity provider: uma troca em dois saltos em que o IdP emite uma assertion com escopo para um único recurso, válida por 300 segundos, e o agente a troca por um access token de escopo estreito. Um consentimento central. Uma revogação que mata tudo o que a cadeia emitiria. Agente precisa de botão de desligar mais do que de qualquer outra coisa.

Alguém precisa ser dono das chaves

Neste exato momento, a chave de algum agente está autenticando, fielmente, em nome de alguém que saiu há meses; nada liga a credencial à saída, então nenhum fluxo de offboarding vai encontrá-la. Um dono registrado é esse elo: saída dispara rotação, não órfão.

Então, quem fez? Se os seus logs respondem com o nome do agente, sustentado por uma chave que nunca saiu do processo dele, emitida por uma cadeia que você corta numa ação só, você está na frente de quase todo mundo.

Nesta semana, numa org de desenvolvimento: crie um app client credentials, exija DPoP, escreva o handshake, depois repita o mesmo access token sem a prova e veja o 401. A mesma string, um request funciona, o outro não. Esse par de requests é este ensaio inteiro, rodando na sua tela.