Identidade de agente: o privilégio que ninguém revoga

Noventa e nove por cento das organizações adotaram agentes de IA. Trinta e sete por cento conseguem revogar as credenciais de um.

A distância entre esses dois números é o assunto deste post.

Provar quem o agente é já tem solução conhecida. O problema aparece depois: a credencial nasce mais ampla do que precisa, nunca rotaciona, e continua válida muito tempo depois de a tarefa acabar. Ninguém desliga, porque quase ninguém sabe como.

E há um agravante que não é de engenharia. Os padrões de identidade que existem foram desenhados para pessoas e organizações — entidades com personalidade jurídica. O agente não é uma.

Em maio de 2026, a Palo Alto Networks publicou o 2026 Identity Security Landscape, com 2.930 tomadores de decisão em segurança entrevistados (Palo Alto Networks, acesso em 28/08/2026).

Os números principais:

• 99% das organizações adotaram agentes de IA.
• 40% desses agentes já têm acesso a dados da organização.
• 37% conseguem revogar as credenciais de um agente de IA.
• 30% têm log de auditoria imutável do que esses agentes fazem.

O terceiro item merece ser lido devagar. Quase dois terços das organizações que colocaram agentes para rodar não sabem como desligá-los. A revogação não é lenta nem trabalhosa nessas organizações. Ela não existe como capacidade.

E o quarto fecha o problema. Sem log imutável, mesmo quem consegue revogar não consegue reconstruir o que foi feito antes de revogar.

Uma ressalva necessária: a Palo Alto Networks lançou uma plataforma de identidade junto com esse relatório. É pesquisa de fornecedor sobre o problema que o fornecedor resolve. Os números batem com o que outras fontes mostram, e a origem fica registrada.

Uma segunda pesquisa mede a mesma coisa por outro ângulo, e o resultado é constrangedor.

A VentureBeat Pulse AI Security and Trust ouviu 108 organizações com mais de 100 funcionários, entre 6 de janeiro e 15 de março de 2026 (VentureBeat, acesso em 28/08/2026).

Oitenta e dois por cento acreditam que a política protege. Oitenta e oito por cento tiveram incidente. A mesma amostra, a mesma pergunta, duas respostas incompatíveis. É a distância entre a política que existe no documento e a que existe na máquina.

A amostra é pequena, com 108 organizações, e a onda de março teve apenas 20 respostas, tratadas pelos autores como direcionais. Trato os percentuais como ordem de grandeza, e não como precisão decimal.

O número de 21,9% é a tese deste post com dado. Quase quatro em cada cinco organizações não tratam o agente como uma identidade. Ele usa a de outra pessoa.

Isso tem três consequências práticas, e todas aparecem no pior momento possível:

• O log mostra o nome do humano. Quando algo dá errado, a auditoria aponta para quem emprestou a credencial.
• Revogar derruba a pessoa junto. Cortar o acesso do agente significa cortar o acesso de quem o provisionou.
• A auditoria não distingue. Não há como separar o que a pessoa fez do que o agente fez em nome dela.

E os 25,5% de agentes que criam outros agentes sem supervisão levam isso ao limite. Um privilégio que ninguém revoga, usado para provisionar mais privilégios que ninguém vai revogar.

Aqui vale um cuidado que quase nenhum material sobre o tema toma.

A proporção entre identidades não humanas e humanas é citada em toda parte, e ela varia por um fator de seis entre relatórios sérios do mesmo período.

As duas medições estão certas. O que muda é o que cada uma conta como identidade e em que população. Ambiente nativo de nuvem gera identidades de carga de trabalho aos milhares; um parque corporativo tradicional, não.

A lição prática é a mesma que apareceu no post sobre juiz: número sem método ao lado não serve para decidir. Não use a proporção de ninguém para dimensionar o seu problema. Conte as suas.

O recorte que interessa, e que a Palo Alto isola, é outro: 79 das 109 identidades de máquina são agentes de IA. Se a proporção certa é a deles, a maioria das identidades não humanas de uma organização hoje é agente — categoria que praticamente não existia dois anos atrás.

O ciclo de vida de uma credencial de agente costuma ter quatro etapas, e três delas não acontecem.

O relatório State of Identity & Access 2026, da Veza, mede a parte do meio (Veza, acesso em 28/08/2026):

• 824 mil contas órfãs no conjunto analisado, equivalentes a 8% de todas as contas — sem dono humano nos sistemas de RH, e ainda com direitos ativos.
• 47% das identidades não humanas passaram mais de um ano sem qualquer alteração.
• 78% das organizações não têm política documentada para criar ou remover identidades de IA.
• 38% das contas estão dormentes.

Aqui também é pesquisa de fornecedor, e a Veza vende governança de identidade não humana. Registrado.

Por que isso acontece tem uma explicação simples e desconfortável. Escopo amplo é decisão de conveniência tomada uma vez, sob pressão, para o agente não travar no meio de um fluxo. Escopo estreito é trabalho contínuo: descobrir o que ele chama de verdade, cortar o resto, e voltar sempre que a tarefa mudar.

A primeira opção custa cinco minutos hoje. A segunda custa uma hora hoje e vinte minutos por trimestre. Quase todo mundo escolhe a primeira, e a conta chega quando alguém pergunta quem tinha acesso ao quê.

O caso concreto já apareceu neste cluster. Em OWASP Top 10 para agentes, o incidente batizado de "Double Agent" no Vertex AI aconteceu porque uma conta de serviço com privilégio excessivo permitiu roubo de credencial e acesso a recursos internos protegidos. A conta funcionou como projetada. O problema estava no que ela podia fazer.

<!-- [UNIQUE INSIGHT] -->

Em 28 de abril de 2026, Takumi Otsuka, Kentaroh Toyoda e Alex Leung publicaram um levantamento dos padrões de identidade aplicáveis a agentes, com as lacunas de cada um (arXiv 2604.23280, acesso em 28/08/2026).

Cinco lacunas aparecem no trabalho:

A terceira é a mais interessante e a menos discutida em qualquer lugar.

Todo sistema de identidade que existe pressupõe que, no fim da cadeia, há alguém com personalidade jurídica. Uma pessoa ou uma empresa: alguém que assina, responde e pode ser cobrado. É sobre essa suposição que se constroem contratos, termos de uso e responsabilização.

O agente não tem isso. Ele age e não responde. A responsabilidade recai sobre quem o provisionou — o que só funciona se existir registro de quem provisionou, quando e para quê.

Repare no círculo. A lacuna jurídica exige registro de provisionamento, e o registro de provisionamento é o que 78% das organizações não têm por política. O problema conceitual e o problema operacional são o mesmo problema.

Esta distinção resolve metade da confusão sobre o tema.

Autenticação responde quem é o agente. Aqui os padrões funcionam: OAuth e OpenID Connect fazem isso há anos, e fazem bem.

Autorização responde o que ele pode fazer, com qual recurso, por quanto tempo, e em nome de quem. Aqui os padrões param.

O ponto que merece destaque: OAuth prova que o agente é quem diz ser, e não permite que serviços a jusante verifiquem a cadeia de delegação. Quando o agente A pede algo ao serviço B em nome da pessoa C, o serviço B consegue verificar A, e não consegue verificar que C realmente autorizou aquilo.

Um exemplo torna isso concreto. Você autoriza um agente a ler seus e-mails para montar um resumo. O agente chama a API de e-mail, que verifica o token e responde. Até aqui, tudo funciona.

Agora o agente chama uma segunda ferramenta, para arquivar mensagens antigas. Essa segunda ferramenta recebe uma requisição válida, de um agente autenticado, e não tem como saber se você autorizou arquivamento ou apenas leitura. Ela vê identidade, não vê escopo de delegação.

Na prática, o que sustenta a fronteira ali é a esperança de que a primeira ferramenta tenha limitado corretamente o que passou adiante. Escopo de token ajuda, e depende de quem emitiu ter previsto o caso. É uma corrente em que cada elo confia no anterior sem conseguir verificá-lo.

O post de ontem descreveu os Agent Cards assinados do A2A, que permitem confirmar que o cartão de um agente foi emitido pelo dono do domínio. É um avanço real, e para na mesma parede: o cartão diz quem é, não diz o que pode.

A conclusão prática vale para quem está desenhando isso agora. Identidade verificável é condição necessária e não suficiente. Quem decide o que o agente pode fazer é a camada de trava, e não a credencial — o argumento que desenvolvi em guardrails para agentes.

Cinco medidas, na ordem de retorno. Nenhuma exige comprar nada.

1. Conta própria por agente. É a correção que muda três coisas de uma vez: o log passa a mostrar o agente, a revogação deixa de derrubar uma pessoa junto, e a auditoria consegue separar o que foi feito por quem. Se você fizer só uma coisa desta lista, faça esta.

2. Escopo mínimo, a partir do que ele chama de verdade. Não do que ele talvez precise. Olhe o rastro de uma semana, liste as chamadas reais e corte o resto.

3. Credencial de vida curta. Expiração em horas. Token permanente é uma decisão de hoje que continua valendo daqui a três anos, quando ninguém lembrar por que ele existe.

4. Inventário com dono e data. Quem provisionou, quando, para qual tarefa, até quando. É o registro que a lacuna jurídica exige e que quase ninguém mantém.

5. Teste de revogação. Desligue e veja o que quebra, antes de precisar desligar com pressa.

A quinta é a menos feita, e é a mesma disciplina de testar backup: ninguém sabe se funciona até precisar. Considerando que apenas 37% das organizações conseguem revogar credencial de agente, é bem provável que o primeiro teste revele que a capacidade não existe.

E quando não dá para criar conta própria

Nem sempre dá. O sistema não suporta contas de serviço. A licença cobra por assento. O provisionamento passa por um processo que leva semanas.

Nesses casos, três medidas reduzem o dano sem exigir conta nova.

Use uma credencial dedicada, ainda que na mesma conta. Uma chave só do agente, separada da que a pessoa usa. Não resolve a auditoria, e resolve a revogação: dá para matar aquela chave sem derrubar o acesso da pessoa.

Registre a origem em tudo que o agente escreve. Commit, ticket, arquivo, comentário. Não é log de sistema, e é rastro. Recuperar depois "quem fez isso" fica possível.

Limite pelo lado do recurso. Se não dá para restringir o agente, restrinja o que ele alcança: repositório separado, ambiente de teste, cópia dos dados em vez do original.

Nenhuma das três é a resposta certa. As três são melhores que emprestar a credencial inteira e torcer.

Para conferir se a revogação de fato aconteceu, o rastro descrito em observabilidade de agente responde em minutos: chamadas com aquela credencial depois do corte deveriam ser zero. Para quem usa Claude Code, a fronteira de permissão do dia a dia está em permissões e auto mode.

<!-- [PERSONAL EXPERIENCE] -->

O agente que produz este blog roda com as credenciais do dono. Não tem conta própria, não tem escopo reduzido, não tem credencial de vida curta e não está em inventário nenhum.

É o anti-padrão descrito nas seções anteriores, e ele está aqui.

O que existe de mitigação é real e vale ser específico. Os commits levam atribuição de coautoria, o que deixa rastro no histórico de quem fez o quê. Nada é publicado sem ordem explícita, o que é aprovação humana para ação irreversível. E o repositório inteiro está sob git, o que torna quase tudo reversível.

Por que isso é aceitável aqui cabe em uma frase: escala de uma pessoa, uma máquina, e nenhuma ação irreversível sem confirmação. As três condições da tabela de reversibilidade que montei na camada de trava estão satisfeitas por acidente de escala, não por arquitetura.

Onde deixaria de ser aceitável é o que importa registrar, com data:

• Se houvesse chave de API paga acessível ao agente, o teto de gasto e o escopo virariam obrigatórios.
• Se houvesse deploy automático no push, a reversibilidade acabaria e a conta própria passaria a ser necessária.
• Se o agente tocasse dado de terceiro, a atribuição deixaria de ser detalhe de histórico e viraria requisito.

Nenhuma das três é o caso em 30 de setembro de 2026. Quando alguma for, esta seção muda.

O que é identidade de agente de IA?

É tratar o agente como uma identidade própria no sistema, com credencial, permissões e ciclo de vida separados dos de qualquer pessoa. Na prática, significa que o agente tem conta, o log registra o nome dele, e revogar o acesso dele não afeta ninguém mais. Numa pesquisa de 2026 com 108 organizações, apenas 21,9% tratavam agentes dessa forma.

Agente precisa de conta própria?

Precisa, e é a medida de maior retorno da lista. Sem conta própria, três coisas quebram ao mesmo tempo: o log mostra o nome do humano que emprestou a credencial, revogar o acesso do agente derruba a pessoa junto, e a auditoria não consegue separar o que cada um fez. As três só aparecem no dia do incidente, quando é tarde para corrigir.

IAM tradicional serve para agente?

Serve para autenticar, e não cobre o resto. Um levantamento de abril de 2026 aponta que os padrões existentes foram desenhados para pessoas e organizações, e tratam mal entidades sem personalidade jurídica. As lacunas específicas são atribuição de responsabilidade, verificação retrospectiva de ação e verificação da cadeia de delegação, que OAuth não resolve.

Como revogar o acesso de um agente?

O primeiro passo é ter o que revogar: conta própria e credencial identificável. Depois, expiração curta faz metade do trabalho sozinha, porque o acesso morre por decurso de prazo em vez de depender de alguém agir. E vale testar o corte antes de precisar dele — apenas 37% das organizações relatam conseguir revogar credencial de agente, o que sugere que a maioria descobre a lacuna na hora errada.

Meu agente é interno e roda na minha máquina. Isso muda algo?

Muda o tamanho do risco, não a natureza dele. A pergunta útil é o que aquela credencial alcança: se ela chega a repositório com segredo, banco de produção, chave paga ou dado de terceiro, os problemas descritos aqui valem igual, com uma pessoa a menos para perceber. Se ela alcança apenas arquivos versionados e reversíveis, o risco é pequeno e a decisão de não separar identidade pode ser consciente. O erro é não ter feito a pergunta.

Quem responde pelo que o agente faz?

Do ponto de vista dos padrões técnicos, essa pergunta está em aberto, e é uma das lacunas apontadas na literatura: os sistemas de identidade pressupõem uma entidade com personalidade jurídica no fim da cadeia, e o agente não é uma. Na prática operacional, a responsabilidade recai sobre quem provisionou o acesso, o que torna o registro de provisionamento — quem, quando, para quê — a peça central. Sobre o que a lei determina em cada jurisdição, consulte quem entende de direito; o que se pode afirmar aqui é que os padrões técnicos não resolvem isso sozinhos.

• 99% adotaram agentes. 37% conseguem revogar as credenciais deles. É a distância que define o problema.
• 82% acham que a política protege; 88% tiveram incidente. A política existe no documento, não na máquina.
• Só 21,9% tratam o agente como identidade própria. Os outros emprestam a de alguém.
• 47% das identidades não humanas passam de um ano sem rotação, e 78% das organizações não têm política para criá-las ou removê-las.
• Autenticar resolve quem é. O que pode e por quanto tempo continua sendo trava, inventário e prazo — trabalho seu.
• Teste a revogação antes de precisar dela. É a mesma disciplina de testar backup.

O próximo post do cluster fecha a semana pelo lado do dinheiro: onde o orçamento vaza numa operação com agentes. O mapa das cinco camadas continua no pilar sobre harness engineering.