Automação nunca deveria aparecer em um audit log como uma credencial sem explicação. Cada bot, workload, pipeline e agente de IA precisa de uma identidade que explique o que ele é, quem responde por ele, quem delegou a ação e qual runtime a executou.
Uma API key identifica a posse de um segredo. Um cliente OAuth identifica uma aplicação. Uma service account identifica uma aplicação ou workload com permissões atribuídas. SPIFFE entrega identidades curtas e criptograficamente verificáveis a workloads individuais. Uma identidade de agente adiciona autonomia, delegação, ciclo de vida e um sponsor responsável. Chamar tudo isso de “bot” apaga distinções necessárias para controle de acesso e resposta a incidentes.
O trabalho do NIST sobre identidade de agentes pergunta como ações podem ser vinculadas de volta a humanos e se tornar não repudiáveis. O modelo Agent ID da Microsoft inclui identificador único, blueprint, owner e sponsor. A orientação do Google Cloud alerta que um log contendo apenas uma service account compartilhada pode não revelar qual usuário ou aplicação causou a ação.
O mecanismo deve corresponder à pergunta operacional. Para medir tráfego de uma API pública, uma API key pode bastar. Quando um SaaS age por um usuário, OAuth delegado registra essa relação. Para um workload backend com permissões cloud, service account ou workload identity federada faz mais sentido. Para um agente autônomo decidindo entre tarefas e usuários, é necessária uma identidade estável própria mais delegação por tarefa.
| Tipo | Melhor uso | O que prova | Principal fraqueza | Exigência de auditoria |
|---|---|---|---|---|
| API key | Identificação e medição de baixo risco. | Caller possui um segredo compartilhado. | Atribuição fraca; frequentemente copiada e duradoura. | Owner, rotação, origem e contexto do request. |
| Cliente OAuth | Acesso de aplicação e fluxos delegados. | Identidade do cliente e consentimento do usuário. | Escopos amplos e ações downstream ambíguas. | Cliente, usuário, escopos, consentimento, audience e ação. |
| Service account | Jobs backend, pipelines e workloads cloud. | Workload age como principal de máquina atribuído. | Chaves compartilhadas ocultam o caller real. | Impersonator, emissão do token, workload, run ID e ação. |
| Workload identity | Infraestrutura dinâmica e chamadas entre serviços. | Identidade de runtime vinculada criptograficamente. | Não explica intenção de negócio automaticamente. | Workload ID, attestation, ambiente, política e request. |
| Identidade de bot | Chat, repositório e automação de workflows. | Ator de automação nomeado em uma plataforma. | Pode ocultar service account ou usuário por trás. | Bot, instalação, usuário/evento disparador, permissões e ação. |
| Identidade de agente | Trabalho autônomo, delegado e em múltiplas etapas. | Instância estável, tipo, sponsor e ator delegante. | Ciclo de vida novo e lacunas de atribuição. | Agente, sponsor, principal, tarefa, escopos, decisões, tools e resultados. |
Chaves persistentes achatam a identidade. Qualquer pessoa com o segredo vira o mesmo principal, e o audit log não consegue distingui-las com confiança. O Google recomenda impersonation de service accounts porque começa em um principal autenticado e gera credenciais curtas; a maioria dos logs pode então registrar caller e service account. SPIFFE segue a mesma direção para workloads com SVIDs curtos em vez de segredos implantados.
Para agentes, a cadeia útil é maior: sponsor responde pelo agente; principal delega uma tarefa; agente solicita uma capacidade; runtime a usa; resource server autoriza; auditoria une os identificadores. Remover qualquer elo enfraquece a reconstrução de incidentes.
Eu construiria um registro de identidades não humanas que conecta dados de IAM, agent registries, service accounts, clientes OAuth, API keys, SPIFFE IDs, bots de repositório e identidades de CI/CD. Cada registro exigiria owner responsável, finalidade, ambiente, recursos permitidos, tipo de credencial, política de expiração e última atividade.
O produto visível seria um explorador de linhagem. Partindo de qualquer mudança em produção, ele caminharia para trás da ação até runtime, identidade não humana, principal delegante, aprovação e sponsor responsável. Partindo de um owner, mostraria cada identidade e privilégio sob sua responsabilidade.
Autenticação responde qual credencial funcionou. Boa identidade não humana responde qual sistema agiu, sob autoridade de quem, para qual tarefa, a partir de qual runtime e quem precisa responder quando algo dá errado. A trilha de auditoria deve preservar essa frase completa.
Artigo comparando API keys, clientes OAuth, service accounts, workload identity, bots e identidades de agentes de IA com ownership, delegação, credenciais curtas e trilhas de auditoria reconstruíveis.