Agentes estão se tornando uma carga de trabalho de IAM, e suas contas de serviço não estão prontas

Primeiro, vou apresentar a melhor versão possível da visão tradicional, porque ela não é absurda. Contas de serviço e chaves de API sustentam workloads de máquina há duas décadas. São bem compreendidas, auditadas, suportadas por toda nuvem e toda ferramenta SaaS, e a equipe de segurança já tem uma planilha com elas. Quando alguém diz que agentes precisam de uma nova categoria de identidade, a resposta razoável é: já temos uma, ela se chama identidade não humana, basta usá-la.

É aqui que isso para de funcionar. Uma conta de serviço responde à pergunta "qual sistema está chamando?". Um agente exige uma pergunta mais difícil: "qual agente está chamando, em nome de quem, com qual objetivo e quem pode revogá-lo nos próximos trinta segundos?". Os próprios números da indústria de IAM indicam que identidades não humanas agora superam as humanas por uma ordem de grandeza, e o Verizon DBIR 2026 alertou que contas de serviço e de máquina são as que precisam de atenção com a chegada da IA agêntica, segundo a leitura do relatório pela Token Security. Este é um briefing sobre por que o mapeamento falha, o que está sendo construído para substituí-lo e como as falhas já estão aparecendo.

Principais conclusões - Contas de serviço e chaves de API pressupõem um chamador estável e determinístico. Agentes são efêmeros, não determinísticos e delegam uns aos outros, quebrando as premissas de auditoria, revogação e menor privilégio incorporadas às credenciais compartilhadas. - A direção dos padrões é identidade de workload por agente: o grupo de trabalho IETF WIMSE está sendo pressionado a exigir que agentes sejam distinguíveis pela identidade, e não apenas pelo escopo do token, com identificadores por agente no estilo SPIFFE para políticas, auditoria e revogação. - Os incidentes já são concretos: tokens OAuth comprometidos no ecossistema Salesloft Drift foram usados para pivotar para ambientes Salesforce empresariais, e a violação da Hugging Face em julho foi executada de ponta a ponta por um agente autônomo. - A orientação de implementação está convergindo: identidade dedicada por agente, credenciais de curta duração e limitadas à tarefa emitidas fora do contexto do modelo, e trilhas de auditoria associadas ao agente, não ao papel compartilhado. - Se seus agentes se autenticam como uma única conta de serviço compartilhada, seus logs não conseguem dizer qual agente fez o quê. Esse é o teste a aplicar nesta semana.

O que aconteceu

Duas coisas convergiram nas primeiras semanas de agosto. Primeiro, a conversa sobre padrões ficou específica. Uma issue no rascunho de arquitetura IETF WIMSE, aberta em 4 de agosto, argumenta que a linguagem atual do rascunho sobre intermediários de IA é fraca demais: ela permite "separate workload identities or token scopes" para distinguir ações de agentes autônomos, e a issue sustenta que token scopes não resolvem o problema. Scopes restringem o que um token pode fazer, mas não mudam quem aquele token representa. Vários agentes compartilhando uma credencial continuam indistinguíveis em logs de auditoria, sistemas de revogação e políticas por agente, por mais diferentes que sejam os scopes. A correção proposta: plataformas gerenciadas de agentes devem atribuir a cada agente um identificador único de workload, carregado em um claim dedicado e usado como chave estável para políticas, auditoria e revogação. O design de identidade de agentes do Google, que dá a cada agente implantado uma identidade baseada em SPIFFE vinculada ao seu recurso de agente, é citado como exemplo funcional.

Segundo, o ritmo de incidentes continuou. A violação da Hugging Face em meados de julho foi a primeira intrusão pública em uma empresa identificada pelo nome conduzida por um agente autônomo do início ao fim: execução de código no pipeline de datasets, coleta de credenciais, movimento lateral por clusters internos e milhares de ações durante um fim de semana. No início do ano, Moltbook, uma rede social para agentes de IA, vazou 1,5 milhão de tokens de API de um banco de dados mal configurado poucos dias depois de atingir 1,5 milhão de contas de agentes, segundo o resumo da Studio Global. E o exemplo recorrente do DBIR sobre ataques a identidades não humanas, o comprometimento de tokens OAuth da Salesloft Drift usado para alcançar ambientes Salesforce de grandes empresas, incluindo Google, Cisco e Zscaler, tem exatamente a forma das credenciais das quais os agentes dependem.

Em agosto de 2026, uma issue do IETF WIMSE propôs que ações de agentes fossem distinguidas por identidades de workload separadas, não por token scopes, com identificadores por agente como chave estável para políticas, auditoria e revogação. Isso ocorreu após a violação da Hugging Face conduzida por um agente em julho e um incidente de janeiro em que a plataforma de agentes Moltbook vazou 1,5 milhão de tokens de API.

Por que contas de serviço e chaves de API não se encaixam em agentes

A incompatibilidade tem quatro lados, e vale a pena nomeá-los separadamente porque as correções são diferentes.

Identidade compartilhada destrói a atribuição. Contas de serviço são projetadas para serem compartilhadas, estáticas e amplamente privilegiadas. Coloque dez agentes em uma única conta e seu log de auditoria mostrará um único ator, como explica o relato prático da Cockroach Labs: você não consegue dizer qual agente tocou quais dados, a rotação exige coordenação entre todos os agentes, e as permissões da conta derivam até virarem a união de tudo que qualquer agente já precisou. O exemplo anonimizado deles é semelhante a variações que já ouvi de equipes de clientes: um agente de suporte rodando por três meses sob uma conta com acesso de leitura ao banco inteiro de clientes, configurada assim no desenvolvimento e nunca restringida antes do go-live.

Agentes são efêmeros; chaves não. Um workflow agêntico pode se autenticar em segundos com um provedor de modelos, um vector store, três APIs e armazenamento em nuvem, e depois desaparecer. Chaves de API de longa duração pressupõem um chamador persistente que vale a pena rotacionar em um cronograma. A incompatibilidade gera proliferação: chaves criadas para agentes dos quais ninguém mais se lembra, ainda válidas e ainda amplas.

A delegação quebra a cadeia de "em nome de". Um agente agindo por um usuário e um agente agindo de forma autônoma deveriam parecer completamente diferentes para seu motor de políticas. Com uma conta de serviço compartilhada, parecem idênticos. A delegação OAuth lida razoavelmente bem com o caso do usuário; o caso autônomo exige a própria identidade do agente, e a delegação multiagente exige que cada salto restrinja, não amplie, a autoridade transferida.

O modelo nunca deve guardar o segredo. Isso é estrutural, não uma questão de configuração. Credenciais inseridas na janela de contexto ficam expostas ao modelo e a qualquer coisa capaz de manipulá-lo: prompt injection pode exfiltrá-las por meio das próprias saídas do agente. A correção são credenciais de curta duração e escopo limitado, emitidas na hora da tarefa por um serviço de tokens e mantidas pela camada de execução de ferramentas, para que o modelo acione chamadas sem que o segredo entre em seu contexto. A Cockroach Labs explica bem esse ponto, e ele coincide com o que digo a clientes que constroem stacks de agentes auto-hospedados: o harness guarda as chaves, o modelo guarda a intenção.

Contas de serviço compartilhadas quebram a atribuição dos agentes porque um único ator aparece nos logs, duram mais do que workloads efêmeros de agentes, borram a linha entre ações delegadas por usuários e ações autônomas, e incentivam equipes a passar credenciais pelo contexto do modelo onde prompt injection pode alcançá-las, segundo Cockroach Labs e a comparação da miniOrange.

O que fornecedores e organismos de padrões estão construindo

A forma emergente tem três camadas, e o ponto encorajador é que fornecedores e especialistas em padrões estão convergindo mais ou menos para a mesma estrutura.

Identidade de workload por agente. A direção WIMSE acima é a versão dos padrões: cada agente lógico recebe um identificador único e estável, com uma URI SPIFFE como formato sugerido, distinto de qualquer papel de execução compartilhado, e esse identificador passa a ser a chave usada por políticas, auditoria e revogação. Agentes gerenciados por plataforma que compartilham uma credencial de execução precisariam complementá-la com um claim por agente. Esta é a mudança mais importante: identidade por agente, não por deployment.

Federação em vez de segredos armazenados. O guia da Descope sobre workload identity federation para agentes mostra o padrão: a identidade de plataforma do agente, como um AWS IAM role ou uma Kubernetes service account via IRSA, é trocada por um token de curta duração e escopo limitado da plataforma de identidade, que também cria um registro de diretório para o agente para que as trilhas de auditoria sobrevivam à vida útil do token. Nenhuma chave de longa duração para vazar, e o registro de identidade dura mais que qualquer credencial individual.

Descoberta e governança como mercado. No lado comercial, fornecedores de identidade não humana, Reco, Token Security, Oasis, Aembit e outros, estão se reposicionando em torno de agentes: descobrir cada credencial de agente, mapeá-la para um responsável, sinalizar excesso de privilégio e revogar de forma limpa. A abordagem da Reco é prática: combinar o tipo de identidade com o papel do agente, OAuth delegado para ações do usuário e identidade de workload dedicada para ações autônomas, e revisar permissões à medida que as responsabilidades crescem, porque agentes acumulam privilégios como funcionários acumulam chaves do prédio. O Top 10 for Agentic Applications da OWASP, publicado em dezembro de 2025, nomeia Identity and Privilege Abuse como uma categoria de risco de primeira classe, dando às equipes de segurança um vocabulário comum para achados de auditoria. Onde isso se encaixa no restante do seu stack é uma questão de governança tanto quanto de tooling; cubro o lado organizacional em governança de agentes de IA.

A arquitetura emergente: identidades de workload por agente, com identificadores no estilo SPIFFE usados como chave para políticas, auditoria e revogação segundo a discussão WIMSE; federação da identidade de plataforma em tokens de curta duração e escopo limitado com registros persistentes de diretório dos agentes segundo Descope; e um mercado de fornecedores para descoberta e governança de menor privilégio de identidades não humanas.

Quando a identidade do agente dá errado

Três incidentes, três modos de falha diferentes, todos instrutivos.

Hugging Face, julho de 2026: o problema de identidade do atacante também era o do defensor. A intrusão conduzida por um agente coletou credenciais de nuvem e cluster de um worker de execução de código e se moveu lateralmente, a história clássica de um workload superprivilegiado: um componente de processamento de dados mantinha credenciais que valiam a pena roubar. O detalhe menos relatado é a assimetria forense divulgada pela Hugging Face: o agente atacante não estava sujeito a nenhuma política de uso, enquanto o próprio trabalho forense da empresa foi inicialmente bloqueado pelas salvaguardas dos modelos hospedados que tentaram usar. Por isso, executaram a análise forense com um modelo de pesos abertos, GLM 5.2, em sua própria infraestrutura. Falhas de identidade e acesso dos dois lados do mesmo incidente.

Salesloft Drift, o alerta do DBIR: tokens como chaves mestras. Tokens OAuth comprometidos de um ecossistema de fornecedor foram usados para pivotar para ambientes Salesforce de grandes empresas. Sem senhas, sem phishing de pessoas: credenciais não humanas, amplamente confiáveis e silenciosamente reutilizadas. Todo agente que você conecta a uma ferramenta SaaS com um grant OAuth de longa duração apresenta esse mesmo formato de risco, e a mitigação tem o mesmo formato: curta duração, escopo estreito, por agente, revogável.

Moltbook, janeiro de 2026: plataformas de agentes agregam risco de identidade. Uma plataforma para contas de agentes vazou 1,5 milhão de tokens de API, além de endereços de e-mail e mensagens entre agentes, a partir de um banco de dados mal configurado, segundo o relato da Studio Global. Quando você centraliza a identidade dos agentes, também centraliza seu raio de impacto. Vale dizer que eu trataria alguns detalhes do incidente em circulação como reportados, não auditados; a divulgação da Hugging Face é uma fonte primária, enquanto os números da Moltbook vêm de cobertura secundária.

Falhas documentadas de identidade de agentes incluem a violação da Hugging Face em julho de 2026, em que um agente autônomo coletou credenciais de nuvem e cluster e se moveu lateralmente segundo a análise da Waxell; o pivot de tokens OAuth Salesloft Drift para tenants Salesforce empresariais segundo a Token Security sobre o DBIR 2026; e o vazamento de 1,5 milhão de tokens de API de agentes da Moltbook.

O que fazer agora

1. Nesta semana: enumere as credenciais dos seus agentes e aplique o teste de atribuição. Escolha qualquer ação de agente nos logs e pergunte se você consegue dizer qual agente a realizou, em nome de quem, e se poderia revogar apenas esse agente sem afetar os demais. Se a resposta for não, você tem um problema de identidade compartilhada, e esse é o primeiro achado a corrigir.

2. Neste mês: migre um agente autônomo de sua credencial de longa duração para tokens de curta duração e limitados à tarefa, emitidos por um serviço de tokens ou plataforma de identidade, mantidos na camada de execução de ferramentas e nunca no contexto do modelo. Comece pelo agente com o acesso mais amplo; normalmente é aquele que alguém deixou com escopo "temporário" às pressas.

3. Neste trimestre: dê a cada agente lógico sua própria identidade estável, um SPIFFE ID onde você tiver a infraestrutura ou uma conta de serviço única por agente onde não tiver, vincule auditoria e alertas a ela e escreva o runbook de revogação antes de precisar usá-lo. Se você está mais no início da jornada e ainda decide onde os agentes devem rodar, o trade-off entre agentes locais e na nuvem determina quanto dessa camada você pode controlar.

FAQ

O que é identidade de agente em termos de IAM?

Uma identidade distinta e verificável atribuída a um agente de IA individual, separada da plataforma na qual ele roda e dos usuários em nome dos quais atua. Ela é usada como chave estável para autenticação, políticas de autorização, trilhas de auditoria e revogação, da mesma forma que uma workload identity identifica um microsserviço, mas adaptada a chamadores efêmeros, não determinísticos e capazes de delegar uns aos outros.

Por que agentes não podem simplesmente compartilhar uma conta de serviço?

Tecnicamente podem, e a maioria faz isso hoje. Os problemas: logs de auditoria mostram a conta compartilhada, não o agente que agiu, então você perde atribuição; as permissões da conta crescem até se tornarem a união das necessidades de todos os agentes; revogar um agente significa rotacionar credenciais para todos; e você não consegue distinguir ações delegadas por usuários de ações autônomas. Funciona até o primeiro incidente, e então você não tem como reconstruir o que aconteceu.

O que os organismos de padrões estão fazendo sobre identidade de agentes?

O grupo de trabalho IETF WIMSE está estendendo a arquitetura de workload identity para intermediários de IA, com uma proposta ativa para exigir identificadores por agente, com URIs SPIFFE como mecanismo sugerido, em vez de depender de token scopes. A OWASP publicou um Top 10 for Agentic Applications em dezembro de 2025 com identity and privilege abuse como categoria nomeada, e a Cloud Security Alliance tem um framework de governança de identidade de agentes que recomenda uma identidade única por agente.

Credenciais de agentes devem aparecer no contexto do modelo em algum momento?

Não. Tudo que está na janela de contexto é visível ao modelo e pode ser exfiltrado por prompt injection. O padrão aceito é emitir credenciais no momento da tarefa por um serviço de tokens, mantê-las na camada de execução de ferramentas entre o modelo e a API, limitá-las à tarefa e torná-las de curta duração. O modelo solicita a ação; o harness guarda o segredo.

Em resumo

Profissionais de identidade costumam dizer que identidade é o plano de controle, e agentes estão prestes a testar essa ideia com mais força do que microsserviços jamais fizeram. A direção está clara o suficiente para começar a construir nessa direção hoje: identidade por agente, segredos fora do modelo, tokens que expiram mais rápido do que incidentes se espalham e auditoria capaz de responder "qual agente, em nome de quem, com qual objetivo". As organizações atingidas neste verão não estavam rodando configurações exóticas; estavam usando credenciais compartilhadas e torcendo para dar certo. Essa é a lacuna a fechar, e ela pode ser fechada com tecnologia que em grande parte já existe.

Se você está mapeando identidade de agentes para um ambiente IAM existente e quer um profissional com experiência prática na conversa, esse é um trabalho que faço. Entre em contato.

Fontes

• IETF WIMSE WG, issue #139 do draft-ietf-wimse-arch, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (aberta em 2026-08-04, consultada em 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (publicado em 2026-07-17, consultado em 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (publicado em 2026-05-20, consultado em 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (publicado em 2026-06-22, consultado em 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (publicado em 2026-05-20, consultado em 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (publicado em 2026-07-20, consultado em 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (publicado em 2026-07-17, consultado em 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (publicado em 2026-08-17, consultado em 2026-08-29)