Identidades não-humanas (NHI): como gerenciar credenciais de serviços e agentes de IA

O que são identidades não-humanas (NHI)

São todas as identidades que existem para autenticar máquinas, aplicações e automações — não pessoas. Sempre que um sistema fala com outro sistema sem um humano na frente, há uma identidade não-humana no meio: a conta que roda uma integração, a chave que conecta dois SaaS, o token que autentica um pipeline de deploy. Elas são a cola invisível da operação de TI, e justamente por serem invisíveis passam despercebidas.

A categoria: contas de serviço, chaves, tokens, secrets e agentes

A NHI é uma categoria guarda-chuva, não um único tipo de credencial. Ela reúne contas de serviço (que rodam processos e integrações), chaves de API (que conectam sistemas), tokens de acesso (que autenticam sessões e pipelines), secrets embutidos em código e configuração, certificados de máquina, identidades de workload em nuvem e a novata da lista: a identidade de agentes de IA. O que une todos é o mesmo traço — autenticam software, respondem por um acesso e ninguém as trata como identidade de pleno direito.

Por que as NHI superam as humanas em volume

Porque cada pessoa gera muitas identidades de máquina ao seu redor. Para cada colaborador com login, a empresa opera dezenas de identidades que sustentam integrações, jobs, automações e serviços. Como referência de mercado, a proporção entre identidades não-humanas e humanas citada vai de 10 para 1 a 45 para 1 dependendo do ambiente^[4] — número que se apresenta como faixa de mercado, não como valor fechado, porque varia muito por setor e maturidade de nuvem. O ponto não é o número exato: é que as NHI são, de longe, a maior população de identidades da empresa.

A diferença entre identidade humana e não-humana

A diferença está no ciclo de vida. A identidade humana tem um ciclo guiado pelo RH — admissão, mudança de função, desligamento — que aciona provisionamento e desativação de acesso. A NHI nasce fora desse processo: é criada por quem precisou dela, na hora em que precisou, sem um evento de RH que a governe. Não há um "desligamento" automático quando a integração é aposentada. Por isso a NHI tende a começar, mas não a terminar — ela permanece ativa muito depois de deixar de ser necessária.

Por que a NHI é o maior ponto cego de acesso

Porque ela reúne, em uma só credencial, tudo o que um atacante procura: acesso amplo, validade longa, ausência de dono e nenhuma exigência de segundo fator. A identidade não-humana costuma ser criada ad hoc, recebe permissão excessiva para "não travar", é compartilhada entre times e quase nunca é rotacionada ou desativada^[4]. É o ponto cego clássico: existe, tem poder e ninguém está olhando.

Nasce ad hoc e fora do processo

A NHI aparece no momento de resolver um problema, sem passar por aprovação nem cadastro. Um desenvolvedor precisa integrar dois sistemas e gera uma chave; uma área liga uma ferramenta ao CRM e cria uma concessão; um script precisa rodar de madrugada e ganha uma conta de serviço. Cada uma dessas decisões é local e razoável, mas o somatório é um conjunto de credenciais que nunca passou por um processo de identidade — e que, por isso, ninguém consegue listar.

Credencial estática, longeva e sem dono

O maior risco da NHI é a combinação de ser estática e não ter responsável. Uma chave que nunca muda e vale por anos é um passivo que só cresce: quanto mais tempo existe, mais lugares a usam, mais cópias circulam e maior o estrago se vazar. Quando essa credencial também não tem dono humano — alguém que saiba para que serve e responda por ela —, ninguém a revisa, ninguém a rotaciona e ninguém a desliga. NHI órfã é a definição operacional do problema.

O que a credencial esquecida representa em segurança

Uma credencial não-humana comprometida permite movimento sem disparar os alarmes que protegem contas de pessoas. Ela não exige senha digitada nem segundo fator a cada uso, autentica de forma programática e costuma ter escopo amplo. Do ponto de vista defensivo, o que interessa é fechar essa exposição: reduzir o número de credenciais estáticas, encurtar sua validade e vigiar seu comportamento. Este artigo trata da disciplina de proteção — não de como uma credencial é abusada.

Como assumir o controle das identidades não-humanas

O eixo operacional é sempre o mesmo, independentemente do porte: descobrir o que existe, dar um dono humano a cada identidade, reduzir o escopo ao mínimo, rotacionar credenciais, monitorar o uso e desativar o que sobrou. Referências de mercado descrevem esse ciclo em estágios equivalentes — descoberta e inventário, provisionamento seguro, monitoramento contínuo, gestão do risco da credencial (rotação) e descomissionamento^[3]. É zero trust aplicado a quem não é gente.

Descoberta e inventário: o passo zero

Não há como proteger o que não se enxerga, então tudo começa por listar toda NHI ativa. Varrer nuvem, SaaS, código, pipelines e diretórios para registrar cada identidade — nome, tipo, onde é usada, o que acessa e quando autenticou pela última vez. O campo "última atividade" é o mais revelador: ele separa o que está vivo do que já podia ter sido desligado. Sem esse inventário, todos os passos seguintes são chute.

Dono nomeado por identidade

Toda NHI precisa de um responsável humano identificável. Esse dono é quem sabe para que a identidade serve, aprova mudança de escopo e responde quando ela vaza. A regra é simples e implacável: identidade sem dono não deveria existir. É o dono que garante que a credencial será rotacionada, que o escopo será revisto e que ela será desligada quando a função acabar — sem esse papel, a NHI vira órfã por padrão.

Escopo mínimo: nada de "admin para não travar"

Cada identidade deve poder apenas o que sua função exige — nem mais um privilégio. O atalho de conceder acesso amplo "para não travar" é a origem da maior parte do risco: uma credencial com permissão de administrador transforma qualquer vazamento em incidente grave. Reduzir a permissão acumulada ao mínimo necessário limita o raio de ação e contém o estrago se a credencial for comprometida. Menor privilégio na NHI vale exatamente como vale na conta de pessoa.

Rotação e o fim do secret estático

Credencial que nunca muda é passivo; o objetivo da rotação é encurtar a janela em que uma credencial roubada continua útil. Na prática, isso significa três movimentos: rotacionar chaves e tokens em ciclo definido, tirar o secret de dentro do código e movê-lo para um cofre, e migrar para credenciais de vida curta sempre que a plataforma permitir. A credencial efêmera é o ideal — ela expira sozinha, então nem precisa ser rotacionada manualmente.

Monitoramento de uso e descomissionamento

Monitorar é acompanhar como cada NHI se comporta — de onde autentica, o que acessa, em que horário — para flagrar o que foge do padrão: uma chave usada de outro país, uma conta de serviço acessando o que nunca acessou. Comportamento anômalo é o sinal de credencial comprometida. E o ciclo se fecha no descomissionamento: desativar a identidade quando a integração é aposentada, o projeto encerra ou o fornecedor é trocado. Identidade esquecida acumula acesso válido e vira porta silenciosa — o ciclo de vida da NHI termina, não só começa.

O caso dos agentes de IA: a identidade dinâmica

O agente de IA é uma NHI diferente de todas as anteriores porque sua identidade é dinâmica, não estática. Enquanto uma chave de API tem escopo fixo e previsível, o agente age em nome de quem o aciona, pode operar por vários usuários e disparar sub-agentes, criando cadeias de acesso que o inventário tradicional não enxerga. É o ponto em que o modelo de NHI estática deixa de bastar^[1].

Por que o agente muda a régua

Porque a permissão do agente não é fixa: ele herda o acesso de quem o chamou. Uma conta de serviço tradicional faz sempre a mesma coisa, com o mesmo escopo; um agente pode, na mesma sessão, agir com o poder de um usuário e, na seguinte, com o de outro. Isso quebra o pressuposto do inventário clássico, que assume identidade com escopo estável. De forma crescente, o mercado descreve a extensão do IAM à identidade de agentes como a próxima fronteira da gestão de acessos^[2].

Identidade própria, escopo por tarefa e credencial de vida curta

Cada agente precisa de identidade própria — nunca reaproveitar uma conta de serviço genérica ou humana. Sobre essa identidade valem três controles específicos: escopo por tarefa (o agente recebe apenas o acesso da ação que vai executar, não um acesso permanente amplo), credencial de vida curta (que expira ao fim da tarefa) e registro de qual humano ou processo autorizou cada ação. É a diferença entre um agente com poder difuso e um agente cujo poder é delimitado e rastreável.

A cadeia agente → sub-agente e a trilha de autorização

O maior desafio de governança do agente é a cadeia que ele cria ao delegar. Quando um agente aciona sub-agentes, cada elo precisa carregar a trilha de quem autorizou o quê — senão fica impossível reconstruir, depois, por que uma ação foi tomada e sob a permissão de quem. Governar isso exige integrar a identidade dos agentes ao mesmo catálogo das demais NHI, com trilha de autorização de ponta a ponta. É o que permite responder à pergunta que a auditoria sempre faz: "quem, no fim, mandou fazer isso?".

NHI como categoria que costura os controles existentes

A identidade não-humana é a categoria ampla que conecta controles que a TI já conhece por partes. Contas de serviço, contas privilegiadas, ciclo de vida de identidade e governança de identidades (IGA) são disciplinas maduras — a NHI é o conceito que as reúne sob uma mesma régua para tudo o que não é gente. Ver a NHI como categoria evita tratar cada tipo de credencial de máquina como um problema isolado.

Onde este tema encosta em outros controles de identidade

Os controles por tipo têm profundidade própria e ficam melhor tratados à parte. O detalhamento de contas de serviço e contas de aplicação, os cuidados específicos com contas privilegiadas, o ciclo de vida de identidade (joiner-mover-leaver) e a governança de identidades (IGA) são temas vizinhos que este artigo não reexplica. O papel da visão de NHI é costurar todos eles para o público que sempre ficou de fora do IAM: o software.

Zero trust aplicado a quem não é gente

O princípio final é não confiar por padrão só porque a identidade é interna ou "de máquina". Autenticar forte, autorizar por escopo mínimo, verificar o contexto de cada acesso e registrar tudo — o mesmo zero trust aplicado à identidade humana, estendido para a NHI. A mensagem central é direta: identidade que não é gente também é identidade. Descobrir, dar dono, reduzir escopo, rotacionar e desativar; e, para o agente de IA, tratar a identidade dinâmica com escopo por tarefa e trilha de autorização.