Jacob Ideskog, CTO do vendor de identidade Curity, publicou esta semana uma peça argumentando que os stacks IAM que a maioria das empresas roda foram projetados em torno de um modelo — um humano faz login, ganha um token de sessão, toma ações dentro daquela sessão — que a geração atual de agentes de IA está quebrando. A estatística de manchete que ele cita é que identidades não-humanas agora representam mais de 90% de todas as autenticações em sistemas empresariais modernos. Você confiando ou não no número exato da Curity, a afirmação direcional é consistente com o que toda equipe de segurança cloud tem dito no último ano: contas de serviço, pipelines CI/CD, runners de automação e agora agentes movidos a LLM estão fazendo a maior parte do tráfego de auth, e os controles em torno deles são rio abaixo de suposições de design centradas em humanos que não combinam mais com a carga de trabalho.

Os modos de falha arquitetural específicos que Ideskog cataloga são reais. IAM atual assume um único gate de autenticação no início de uma sessão. Agentes não funcionam assim; eles encadeiam chamadas API multi-passo entre serviços, frequentemente abarcando minutos ou horas, sem humano no loop entre passos. Eles herdam as permissões de quem lançou o agente, o que significa que um único token de agente comprometido dá a um atacante o conjunto amplo de permissões do usuário que iniciou o agente em vez do conjunto estreito de permissões de qualquer ação individual que o agente deveria tomar. Tokens de acesso permanentes que funcionavam bem para um funcionário logado se tornam um risco quando um agente está tomando decisões por conta própria sobre quais APIs chamar. E o problema de dupla identidade — o agente tem sua própria identidade E atua em nome de um usuário — não tem primitiva limpa na maioria dos stacks IAM existentes.

O padrão recomendado é genuinamente sensato e não realmente proprietário da Curity. Autorização centrada em aplicação em vez de centrada em usuário. Credenciais just-in-time, de menor privilégio, escopados a ações específicas e janelas de tempo em vez de tokens permanentes. Autorização contínua em runtime em cada chamada API em vez de um único gate no início da sessão. Tokens que carregam contexto: identidade do ator, usuário representado, ação pretendida, nível atual de confiança. As primitivas técnicas para tudo isso existem no OAuth 2.0 hoje — token exchange (RFC 8693) para dupla identidade, dynamic client registration (RFC 7591) para credenciais de agente efêmeros, e rich authorization requests (RAR, RFC 9396) para tokens escopados por ação. A lacuna não são os padrões. É que a maioria dos deployments IAM empresariais ou não implementam esses endpoints, ou os implementam como toggles que ninguém usa.

Para desenvolvedores trabalhando em plataformas de agentes, a leitura prática é que o trabalho de controle de acesso é engenharia real e não um detalhe de compliance. Os agentes que sua plataforma roda provavelmente precisam de suas próprias identidades (não emprestadas do usuário), credenciais escopados de curta duração emitidos por tarefa (não de duração de sessão), e uma camada de autorização em runtime que pode recusar uma ação mesmo depois do token ter sido emitido (porque sinais de confiança podem mudar no meio da sessão). A Curity vende produtos que fazem isso; também a Okta com seu trabalho Workload Identity, a AWS com IAM Identity Center e Verified Permissions, e vários jogadores menores como Aembit e Astrix. O pitch de vendor na peça de Ideskog não está errado sobre a arquitetura, mas desenvolvedores deveriam avaliar as primitivas OAuth 2.0 diretamente e escolher um caminho de deployment em vez de tratar IAM de agentes como uma categoria de fonte única. O número de 90% não-humano é a parte que deveria fazer toda equipe de segurança revisar o que está rodando, independentemente de qual vendor acabarem comprando.