Identidades Não-Humanas: Como Gerenciar Acesso de Agentes de IA com Segurança

Faça um exercício rápido: abra o painel de identidades da sua empresa e conte quantas são de humanos e quantas são de tudo o mais. Service accounts, chaves de API, tokens OAuth, credenciais de CI/CD, e agora, uma categoria nova que cresce mais rápido que todas as outras, identidades de agentes de IA. Se a sua empresa é como a maioria, o número de identidades não-humanas já passou o de humanos há tempos, e a distância só aumenta.

O termo técnico para isso é NHI, non-human identity. Não é conceito novo, service accounts existem desde sempre. O que mudou é a escala e o comportamento. Uma service account tradicional fazia uma coisa fixa, chamava uma API específica, num horário previsível, com um escopo que alguém desenhou uma vez e raramente revisitava. Um agente de IA autônomo não é assim. Ele roda continuamente, decide sozinho quais ferramentas chamar, às vezes cria sub-agentes na hora para dividir uma tarefa, e cada um desses sub-agentes pode precisar de acesso a um sistema diferente. O IAM que sua empresa tem hoje foi desenhado para outro mundo, um onde alguém faz login de manhã, trabalha até a noite e desloga. Agente não desloga.

Esse descompasso entre a arquitetura de identidade que temos e o comportamento dos agentes que estamos colocando em produção é o assunto deste post. Não é uma questão teórica de segurança da informação. É o tipo de lacuna que vira manchete quando um agente com acesso amplo demais faz algo que ninguém previu, geralmente sem nenhum atacante envolvido, só a combinação de credencial de longa duração, escopo generoso e um comportamento inesperado do próprio agente.

---

Por Que o IAM Tradicional Quebra Com Agentes

O IAM que a maioria das empresas usa foi construído em cima de premissas sobre identidade humana que simplesmente não valem para um agente autônomo.

A primeira premissa quebrada é a de sessão. Login humano tem início e fim, você autentica, trabalha, e a sessão expira. Agente não tem esse ciclo natural. Ele pode ficar rodando por dias processando uma fila de tarefas, e se a credencial que ele usa foi emitida com validade de meses porque "é mais prático", você tem uma sessão de fato permanente com o mesmo risco de uma chave mestra pendurada na porta. O conceito de sessão, que é a unidade fundamental do IAM tradicional, não mapeia bem para um processo que nunca para.

A segunda premissa quebrada é a de identidade única e estável. Um humano é uma pessoa, com um usuário, associado a papéis que mudam devagar. Um agente pode instanciar sub-agentes dinamicamente para paralelizar uma tarefa, um agente orquestrador que cria três sub-agentes especializados para pesquisar, escrever código e rodar testes, cada um em paralelo. Se todos esses sub-agentes herdam a mesma identidade e o mesmo token do orquestrador, você perdeu a capacidade de saber qual deles fez o quê. E se cada um precisar de uma identidade própria, seu sistema de provisionamento, pensado para criar um usuário quando alguém é contratado, não foi desenhado para criar e destruir identidades em segundos, várias vezes por minuto.

A terceira premissa quebrada é a de volume de ações. Um analista humano faz, digamos, algumas dezenas de operações sensíveis por dia. Um agente pode chamar dezenas de ferramentas diferentes numa única tarefa, ler um banco de dados, consultar uma API externa, escrever num repositório, mandar uma notificação, tudo em segundos, sem pausa para reflexão humana entre uma chamada e outra. Sistemas de detecção de anomalia calibrados para comportamento humano disparam falso positivo o tempo todo com agente, ou pior, são ajustados para tolerar esse volume e acabam deixando passar o comportamento realmente anômalo.

O resultado prático é que empresas estão usando ferramentas de identidade desenhadas para pessoas para gerenciar atores que se comportam de forma fundamentalmente diferente. Isso não é um problema que se resolve com mais treinamento de usuário. É uma lacuna arquitetural.

---

A Explosão de Identidades Não-Humanas

O número por trás disso é o que deveria preocupar qualquer CISO ou tech lead que ainda não olhou para esse painel. Em várias empresas de tecnologia, identidades não-humanas já superam as humanas numa proporção de 10 para 1, e em algumas organizações mais maduras em automação essa proporção é ainda maior. Cada microserviço tem sua service account. Cada integração tem sua chave de API. Cada pipeline de CI/CD tem seu token. E agora, cada agente de IA, e cada sub-agente que ele gera, adiciona mais uma entrada nessa lista que praticamente ninguém está contando direito.

O problema não é só o volume, é a opacidade. Pergunte para o time de segurança da sua empresa quantas identidades humanas existem, e alguém vai ter uma resposta razoavelmente confiável, o RH sabe quem foi contratado e desligado. Pergunte quantas identidades não-humanas existem, e a resposta comum é "não temos certeza". Chaves de API criadas há dois anos por um desenvolvedor que já não trabalha mais na empresa, ainda ativas, ainda com acesso, porque ninguém as revogou. Service accounts com nome genérico tipo svc-app-prod que ninguém sabe mais para que serviam exatamente. Esse é o terreno que já existia antes dos agentes chegarem, e é nesse terreno já bagunçado que estamos adicionando um tipo de identidade que se multiplica sozinha.

Com agentes, a dinâmica piora porque a criação de identidade deixa de ser um evento humano deliberado, alguém pede uma chave, alguém aprova, alguém provisiona, e passa a ser um evento automatizado que o próprio sistema decide fazer. Um agente que precisa delegar uma subtarefa para um sub-agente especializado pode, dependendo de como foi construído, solicitar ou herdar credenciais sem que exista um humano no meio validando se aquilo é razoável. Multiplique isso por centenas de agentes rodando em paralelo numa empresa grande e você tem uma superfície de identidade que cresce mais rápido do que qualquer processo manual de governança consegue acompanhar.

Isso não é motivo para pânico, mas é motivo para tratar identidade de agente como uma categoria de risco de primeira classe, não como um detalhe de implementação que se resolve depois. Empresas que já lidam com isso de forma madura fazem inventário contínuo, automatizado, das identidades não-humanas ativas, exatamente porque sabem que uma planilha atualizada manualmente uma vez por trimestre não tem chance nenhuma de acompanhar esse ritmo.

---

Least Privilege Aplicado a Agentes

O princípio de menor privilégio não é novidade em segurança, mas a forma como ele precisa ser aplicado a agentes é diferente da forma como sempre foi aplicado a sistemas tradicionais.

O erro mais comum, e mais compreensível, é dar ao agente uma API key mestra com acesso amplo, porque é mais simples de configurar e o agente "pode precisar de qualquer coisa" dependendo da tarefa. Esse raciocínio é exatamente o oposto do que deveria orientar a decisão. Um agente com uma chave mestra é um agente que, se enganado por conteúdo malicioso, sequestrado por um comportamento inesperado do próprio modelo, ou simplesmente mal instruído, pode causar dano na extensão total do que essa chave permite, não na extensão do que a tarefa específica exigia.

A alternativa correta é escopo granular por tarefa. Em vez de uma credencial que abre todas as portas, o agente recebe, para cada execução, um conjunto de permissões mínimo, calculado a partir do que aquela tarefa específica precisa. Um agente instanciado para resumir tickets de suporte recebe acesso de leitura ao sistema de tickets e nada mais, não recebe acesso de escrita ao banco de produção só porque "pode ser útil algum dia". Um sub-agente criado para rodar testes recebe permissão para executar comandos num ambiente de sandbox, não para fazer deploy. Isso soa óbvio quando dito em voz alta, mas na prática exige infraestrutura, um sistema capaz de emitir credenciais com escopo fino sob demanda, não uma decisão manual de configuração feita uma vez e esquecida.

Vale conectar isso com o que já escrevi sobre o problema do agente com fome de permissão. O risco de segurança que descrevi no post sobre permission-hungry agents e o lethal trifecta é alimentado exatamente por essa lacuna de identidade. A trifecta letal, acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa, fica muito mais perigosa quando o acesso a dados privados vem de uma credencial ampla e de longa duração em vez de um escopo mínimo e temporário. Menor privilégio em identidade não é só boa prática abstrata, é a mitigação estrutural mais direta que existe contra o cenário que já detalhei naquele post: se o agente sequestrado só tem acesso ao que a tarefa exigia, o estrago possível tem um teto muito mais baixo.

Na prática, isso significa desenhar o sistema de permissões pensando em tarefas, não em agentes como entidades fixas. Um mesmo agente, em duas execuções diferentes, pode e deve receber escopos diferentes, dependendo do que está fazendo naquele momento. Isso é mais trabalho de engenharia do que emitir uma chave e esquecer. É também a diferença entre um incidente contido e um incidente que vira manchete.

---

Credenciais Efêmeras e o Fim da Chave de Longa Duração

Se menor privilégio resolve o "quanto" de acesso, o ciclo de vida da credencial resolve o "por quanto tempo". E aqui a resposta que a indústria está convergindo é clara: chaves de longa duração são um risco que não compensa mais a conveniência que oferecem.

Uma chave de API criada uma vez e usada por meses ou anos é, por definição, um alvo parado. Ela aparece em logs, em variáveis de ambiente, às vezes até em repositórios por acidente. Quanto mais tempo ela vive, mais oportunidades existem para que vaze, seja copiada, ou continue ativa depois que deveria ter sido revogada. Com agentes, esse risco cresce porque o próprio agente pode manipular essas credenciais como parte do seu trabalho normal, lê variáveis de ambiente, escreve arquivos de configuração, chama ferramentas que recebem a chave como parâmetro. Cada uma dessas operações é mais uma chance de a credencial vazar para um lugar que não deveria, um log, uma resposta gerada pelo próprio modelo, um comentário público num sistema de tickets.

A direção correta é credencial efêmera, de curta duração, gerada por sessão ou por tarefa. Em vez de uma chave que vive para sempre, o agente recebe um token que expira em minutos ou poucas horas, suficiente para completar a tarefa em questão e nada além disso. Se esse token vazar, a janela de exploração é curta, e se o agente tentar usá-lo fora do escopo temporal esperado, a própria expiração barra a ação sem exigir que ninguém tenha detectado o problema em tempo real.

Isso exige infraestrutura de emissão dinâmica de segredos, o tipo de coisa que ferramentas como HashiCorp Vault foram desenhadas para resolver, gerando credenciais sob demanda, com validade curta, e revogando automaticamente. A combinação de credencial efêmera com escopo mínimo é o que transforma "o agente tem acesso" em "o agente tem exatamente o acesso certo, pelo tempo certo, para a tarefa certa". Rotação automática deixa de ser um item de checklist de compliance e passa a ser a arquitetura padrão, não uma exceção que alguém lembra de fazer.

Vale notar que isso conecta diretamente com o que escrevi sobre autenticação em servidores MCP. Boa parte dos servidores MCP em produção hoje ainda usa API keys estáticas por simplicidade, exatamente o padrão que a comunidade de identidade de agente está tentando deixar para trás. A convergência entre OAuth 2.1 nativo no protocolo e emissão dinâmica de credenciais no cofre de segredos é a mesma direção vista de dois ângulos diferentes, o protocolo de comunicação do agente e a infraestrutura de identidade por trás dele precisam evoluir juntos.

---

Auditoria e Proveniência: Saber Quem Fez O Quê

Ter controle de acesso bem desenhado resolve metade do problema. A outra metade é saber, depois do fato, exatamente o que aconteceu, e essa é a parte que mais frequentemente fica incompleta em implementações de agente.

A pergunta que a maioria das empresas consegue responder é "esse agente tem acesso a esse sistema". A pergunta que poucas conseguem responder é "qual sub-agente, executando qual tarefa, chamou qual ferramenta, em que momento exato, e com qual resultado". Essa segunda pergunta é a que importa quando algo dá errado, porque sem ela, investigar um incidente vira arqueologia, tentando reconstruir uma cadeia de eventos a partir de logs incompletos ou inexistentes.

Proveniência, nesse contexto, significa rastrear a cadeia de decisão e ação de ponta a ponta. Não basta logar que "o sistema X foi acessado". É preciso saber que o agente orquestrador A, executando a tarefa T para o usuário U, criou o sub-agente B, que usou a credencial C, com escopo D, para chamar a ferramenta E, no timestamp F, e recebeu o resultado G. Cada elo dessa cadeia precisa estar registrado de forma que não possa ser apagado ou alterado pelo próprio agente que gerou o log, porque um agente comprometido que também controla seus próprios registros de auditoria não oferece nenhuma garantia real.

Isso é particularmente crítico quando agentes criam sub-agentes dinamicamente. Se a identidade do sub-agente não for distinta da identidade do orquestrador, você perde a granularidade exatamente no ponto em que mais precisa dela, no momento em que a tarefa se ramificou e múltiplos atores autônomos passaram a agir em paralelo. A prática recomendada é que cada sub-agente receba uma identidade própria e rastreável, mesmo que efêmera, para que o rastro de auditoria consiga distinguir quem fez o quê mesmo dentro de uma árvore complexa de delegação.

Essa disciplina de auditoria conversa diretamente com o que descrevi no post sobre bounded autonomy em produção. Um dos três pilares daquele modelo é justamente a trilha de auditoria completa, e a identidade de agente é a peça de infraestrutura que torna essa trilha possível na prática. Sem identidade granular por agente e por sub-agente, o pilar de auditoria de bounded autonomy vira um objetivo bonito no papel sem sustentação técnica por baixo. As duas coisas, arquitetura de autonomia limitada e arquitetura de identidade, precisam ser construídas juntas, uma sem a outra deixa uma lacuna que vira ponto cego exatamente quando um incidente acontece.

---

Padrões Emergentes: SPIFFE, Vault e OAuth de Agente

A boa notícia é que esse problema não está sendo resolvido do zero. Existe um conjunto de padrões e ferramentas, alguns já maduros em outros contextos, que estão sendo adaptados ou já servem diretamente para identidade de agente.

SPIFFE, e sua implementação de referência SPIRE, é um padrão originalmente pensado para identidade de workload em ambientes de microsserviços, dar a cada serviço uma identidade criptográfica verificável, independente de rede ou configuração manual. A ideia central, cada unidade de computação prova quem é através de uma identidade emitida por uma autoridade central e verificável por qualquer parte que precise confiar nela, mapeia de forma quase direta para o problema de dar identidade a agentes e sub-agentes. Um agente instanciado dinamicamente pode receber uma identidade SPIFFE no momento em que é criado, sem que alguém precise provisionar isso manualmente antes, e essa identidade pode ser verificada por qualquer sistema downstream que o agente tente acessar.

Cofres de segredo dinâmicos, com HashiCorp Vault como o exemplo mais estabelecido, resolvem a parte de emissão e rotação de credenciais efêmeras que descrevi antes. Em vez de segredos estáticos guardados em algum lugar esperando serem lidos, o cofre gera credenciais sob demanda, com validade curta, atreladas a uma identidade e a um escopo específico, e revoga automaticamente quando a validade expira ou quando a tarefa termina. Para agentes, isso significa que a credencial que um agente usa numa execução pode, na prática, nunca ter existido antes daquela execução começar e deixar de existir logo depois que ela termina.

OAuth de agente e delegação de escopo é a peça mais nova e ainda em maturação. A ideia é que, em vez de um agente operar com uma credencial própria e opaca, ele opere com um token que carrega explicitamente em que nome está agindo, delegado por um usuário ou por outro agente, com um escopo que pode ser verificado e limitado por quem concedeu a delegação. Isso resolve um problema sutil, mas importante, distinguir "o agente tem essa permissão porque foi configurado assim uma vez" de "o agente tem essa permissão porque um humano ou outro processo delegou especificamente essa autoridade para essa tarefa, agora". Provedores de identidade como Okta já estão desenhando extensões dos seus fluxos de OAuth justamente para cobrir esse caso, delegação encadeada onde o agente é um ator intermediário, não o dono final da permissão.

Nenhum desses padrões, isoladamente, resolve o problema inteiro. SPIFFE dá identidade verificável, Vault dá credencial efêmera, OAuth de agente dá delegação de escopo rastreável. Juntos, formam a base de uma arquitetura de identidade que trata agente como o que ele é, um ator autônomo que precisa de identidade própria, credencial temporária e escopo delegado, não como uma extensão invisível do humano que o configurou.

---

Conclusão

O padrão que emerge quando você junta todos esses fios é simples de enunciar e trabalhoso de implementar: agente precisa de identidade própria, verificável, com escopo mínimo para a tarefa específica, credencial de vida curta, e um rastro de auditoria que sobrevive mesmo que o próprio agente seja comprometido. Cada um desses elementos, isoladamente, já é conhecido em segurança há anos. A novidade é a urgência de aplicá-los juntos, numa escala e numa velocidade que o IAM tradicional nunca precisou suportar.

O risco de não fazer isso não é abstrato. É a mesma classe de risco que já discuti quando falei sobre agentes com fome de permissão e sobre autonomia sem limites bem desenhados, só que visto pela lente da identidade em vez da lente do comportamento. Um agente com escopo mínimo e credencial efêmera é um agente cujo pior dia causa um estrago pequeno. Um agente com uma chave mestra de longa duração é um agente cujo pior dia pode ser catastrófico, mesmo que ele nunca tenha sido "atacado" por ninguém, só tenha se comportado de um jeito que ninguém previu.

Se você está colocando agentes autônomos em produção, ou já colocou sem ter pensado nisso com esse nível de detalhe, o primeiro passo prático não é adotar todas as ferramentas de uma vez. É fazer o mesmo inventário que já recomendei para o problema da trifecta letal, só que agora olhando para identidade, quantas identidades não-humanas existem, quais têm credenciais de longa duração, quais têm escopo mais amplo do que a tarefa exige, e quais não têm nenhum rastro de auditoria granular. Esse mapa, por si só, já revela onde o risco está concentrado, e é o ponto de partida para toda a arquitetura que descrevi aqui.

---

Fontes:

• HashiCorp Vault — Dynamic Secrets and Identity-Based Access
• SPIFFE — Secure Production Identity Framework For Everyone
• CyberArk — Securing Non-Human Identities in the Age of AI Agents
• The New Stack — Why AI Agents Need Their Own Identity Layer